VRBasic for Lynx

[VladR]

About 6 years ago, for a Jaguar, a created a VRBasic Translator (in .NET) that translates VRBasic code into C and then feeds it into the C compiler to get the target platform (Jaguar) binary.

 

Since, allegedly, there's no BASIC for Lynx (I really wouldn't know, as I'm ignorant on the platform's history and only got familiar with coding it in C/Asm few months ago) - it looks like it might be worthwhile to port the VRBasic to Lynx as that might entice more users to the platform.

 

I took the liberty to implement the Microsoft's syntax of BASIC, so this would be unfortunately quite far from the Atari 800 XL's Basic syntax (with line numbers), but:

- it's still much more accessible than C

- no Line numbers

- no curly braces

- no semicolons

- you can use hardcoded paths to your art assets (sprites) right in your code (without using any external tools), and the backend will do all the heavy lifting (loading, conversion, alpha keying) at the compile-time, so on Jaguar it just works

 

Here's one sample to show the syntax:

' VRBasic Sample 05 - Sprite Drawing
' Sep-2013

	' Declare the sprite variable as a global variable to avoid passing it to every function using it
Module Globals
	Dim ImgWall As Sprite
End Module

	' Draw all colors in the palette
Sub DrawPaletteAt (xp As Integer, yp As Integer)
	For idxColor As Integer = 0 To 255
		DrawPixel (xp + idxColor, yp, idxColor)
	Next idxColor
		' Draw some helper points every 32 pixels to assist with picking the color index
	For idxHelper As Integer = 0 To 8
		DrawPixel (xp + idxHelper*32, yp+1, 127)
	Next idxHelper
End Sub

Sub Main ()
	SetGraphicsMode ()
	DrawPaletteAt (32,0)
	
		' LoadImage takes a full path, so you will have to update it based on where you installed the VRBasic
	LoadImage (ImgWall,"c:\jaguar\_Projects\_VRBasic\src\Samples\ArtAssets\TileA2_16_Colors_Palette.gif",8)
		' Now let's place the palette of the loaded image at the desired destination in our palette - for example at index 100
	CopyPalette (100,ImgWall)
		' Of course, since we changed the palette indices of the image after loading, we need to update the image data for the same offset
		' Under Virtual Jaguar, upon every restart of the *.j64 (e.g. when it reaches End Sub for Main () ), this will have the effect of further offseting the colors, since VJ does not seem to reload the *.j64 (merely jump to Sub Main), thus the Image Data are not physically reloaded
	OffsetImage (100,ImgWall)

		' Let's display the sprite roughly in the middle of the screen
	ShowImage (ImgWall, 160,100)
	
	Wait (5000)
End Sub
 

 

Obviously, the platform's specific functionality (sprites, palettes, etc.) would have to be recoded for Lynx (or use TGI), but the basic language should, in theory, compile fine (assuming no major differences between jaguar's C and cc65) right out of the box.

 

I should also have a full PDF documentation, somewhere on my hard drive...

[+karri]

That is not a bad idea. I would suggest ditching TGI as the default font just eats up space and we might ditch collision detection and line graphics as well.

 

The VRBasic could come with its own drawing primitives and typography. To automate palette handling I could create an colour mapping extension to sp65. You could feed in your target palette and the sprites would directly re-map the indices to the correct order. It might also make sense to be able to request a certain number of pixels for the output sprite and also export the penpal of the sprite. With these tools you could just feed in the bitmaps and get predictable outputs.

 

PS. I found out that we are just a few tables apart at PRGE (my table is 129 and yours is 126). If people don't find our stands we could have a chat about this. I could also grab my laptop and implement the new features in sp65.

[VladR]

Well, TGI offers all the sprite (and other) functionality that I don't currently have implemented in my engine, as I am not using sprites in my flatshader. Another advantage is, that it's already in my dev environment. Besides, nothing stops me from having a TGI-based distribution and a separate non-TGI-based distribution (using my own or other people's libraries).

 

I could, for the time being, offer a SW-rasterizer codepath (via some new command : SpriteEngine (SW)) and eventually, once I get around to implementing it, supply Suzy-based codepath (via HW flag). I don't believe it should take me more than couple days, anyway, to debug how to use sprites and scaling via Suzy.

 

I, for sure, wouldn't want to have to call other EXE tools (the sprite exe files that are used currently to convert the sprites) that might later down the road break the whole thing because of some unforeseen dependency. For jaguar, I was doing all sprite import, conversion and palette work using custom-written .NET code, hence I was able to supply nice error messages if something went wrong, right during the translation process.

 

Of course, since all this is just remapping between the BASIC and C, supplying a different version of a sprite library should be as easy as replacing a *.h or *.c file of the specific implementation.

From what I could see so far, cc65 does a pretty good job of not linking a function unless it's explicitly called, so it won't matter if the library has hundred functions, it won't affect the executable size.

[VladR]

1 hour ago, karri said:

PS. I found out that we are just a few tables apart at PRGE (my table is 129 and yours is 126). If people don't find our stands we could have a chat about this. I could also grab my laptop and implement the new features in sp65.

I'm going to be setting up my table on Friday (highly likely afternoon). When are you arriving ? I'd love to go out on Friday - I suspect I'll be beat on Saturday

 

Though, truth be told, it's hard to precisely estimate my arrival, as it's a 2,600 km drive and there's a fresh snow coming in 2 days covering about 2,000 km of the drive and not much will melt by the time I depart (with a current 30% likelihood of another storm exactly around my departure).

 

Since I survived 2 winters in Montana without winter tires, driving through blizzards, white-outs and ditches, I'm not going to change that habit now

 

Maybe I should target arriving Thursday night, I'll keep an eye on weather forecast...

[+karri]

I am actually "just a little" addicted to pinball machines... I spent half the night in Budapest earlier this year playing Elvira and a few other machines. Friday just could be my day to try out some new machines at PRGE. So you should find me easily in the Pinball hall on Friday  

 

In the evening I need to program the On Duty carts I have with me with Kevin. Most likely in my hotel room a block away from PRGE.

 

I also need to program two sets of competition carts for all entries. One set will be at mark/space booth 101 Main hall and another at White Lynx booth 129 Annex hall.
Plus re-encode the latest video clips to ogv format for the jukeboxes.

 

PS. Just get regular studded winter tires. I would not drive a meter without them.

[VladR]

Did you schedule at least some sleep ?

 

Metal Studded winter tires are a major legal problem. Plenty states outlaw them with very strict timeframes when they are allowed and they could easily impound your car plus give you hefty fine.

The only way you can drive them hassle-free is to be ready to keep changing the tires on a weekly basis, based on current weather. It's plain ridiculous. Haven't checked North Dakota yet, so perhaps they're useable here for the whole season, regardless of current weather, but I would not dare to drive them during winter across U.S.

 

 

Back in Europe, I also used to change between winter and summer tires, but here in U.S., the all-season ones are a "good enough" compromise for both summer and winter. Few years ago, I drove for 8 hours straight through a major winter storm in Newfoundland from one edge of the island to another. Never saw that many cars in a ditch in one day, but my all-season tires gave me just enough traction (even without 4x4).

 

Current forecast for my spot is 3 feet (almost a meter) of snow till Saturday. Undeniably, it's first week of October, though I'm not complaining, as at least this year the first winter storm was delayed 

[Igor]

I would also suggest ditching TGI. In fact @SainT and I will be working on an alternative to it for use with the new Lynx SD cart, with just the bare minimum sprite functionality - that's all you really want/need on the Lynx anyway (who wants to draw lines or circles anyway).

 

Idea of a basic seems cool, but don't forget us Mac users too!

[+karri]

I have a mini-tgi that I use in On Duty. It just replaces the large TGI but it is a drop-in replacement. You can delete even more stuff and leave just palette handling and sprites if you want.

 

I just needed more RAM so I threw out the fonts.

mini-tgi.s

[Igor]

Awesome, probably what I was after! Will check it out when I get time.