The game is being made with Turbo Rascal and a bit of assembler. I've implemented some neat little tricks, in large thanks to the help of the supportive Denial community and of course have Jeff's Vic 20 Quick Reference Handbook by my side which is proving very useful.
Raster split
I have a screen split at the bottom thanks to
this thread which allows me to have a set of 'tile' graphics for the rooms and a separate custom text character set for the status area.
Local 'sprites'
Some time back I was
intrigued by a missing snippet of code for creating sprite-like movement in a regular character display. I had already implemented a full screen bitmap mode (VBM) in Turbo Rascal some years back, again with many pointers and help from Denial to get me started, and this mode has a lot of commands to help you build games with a bitmap, including sprites, tiles and text. However, the disadvantage of a bitmap on the Vic is the size and effect of the colour memory on the bitmap images you can create. I have one game in progress using all multicolour graphics which are generally 16x16 pixels in size and this works great. However, for games with smaller images (eg: 8x8 pixels) it can be a challenge as you may know.
This is where I returned to my LBM (local Bitmap Mode) unit to address that. My first attempt at this unit did the job, creating free moving 8x8 'sprites' by creating those small
local bitmaps of characters around where the sprite is displayed, copying in the character data underneath and overlaying the sprite on top. Unfortunately this first attempt was awkward to use. It was included with Turbo Rascal but I never used it in a game.
More recently when I read the thread linked above it got me thinking again, resulting a rewrite from scratch. The LBM8 unit was created and it has just two commands. One to place a 'sprite' on the screen which you use as many times as needed at the beginning of the game loop and another to remove all the sprites and restore the original characters underneath at the end of the game loop after the raster reaches the bottom of the display area. There are some variations on the sprite drawing functions, most for 8x8 sprites, one for 8x16 and a set for compiled sprites. Compiled sprites use code instead of binary data to draw the sprites (which I have added an export directive to Turbo Rascal to generate) which can have some small advantages over drawing with binary data. For starters, the assembler instructions needed are simpler so you get some cycles back and the exporter generating the code is able to remove any lines (bytes) where a 0 would be drawn (ie: no pixels or blanks) saving more cycles and space. The size in memory of compiled sprites is roughly the same as having binary data, sometimes a little smaller depending on the shape of the sprite.
Other stuff
The game has some music in already, thanks to the talents of Mince: Unknown, and warning its an ear worm you'll be humming all day if you end up playing the game for any period of time!
I'm able to build and run as a cartridge quite quickly in VICE from Turbo Rascal and have a script to convert to a D64 image loading in blocks for testing, thanks to some help from Mike.
I've had an itch about the unused colour memory in the vic and have wanted to use it 'just because' for some time. In this game I've got up to four item pickups per room and I'm using the lower nybbles to store the collected state of the items in each room. I could probably spare the bytes in regular RAM but this is something I wanted to do just because.
I've got 64 rooms, placing most of them compressed in the $A000 block but will likely need to put some elsewhere. Compression is working out at about 50% or better depending upon how detailed the rooms are.
The game will possibly be released in some physical form and later as a free download. That's about it for now, I'll post some updates as I add anything new that is of interest.
what enemies are you going to use ,I think grotbags had a crocodile? Looking forward to playing it
