New game for the ZX Spectrum : Vallation.

[Sokurah]

Phew, it's been a long time coming, but here is my latest game.



It's for the 48K Spectrum and has been written from scratch in Z80 assembler.

It's a remake of a C64 game from 2013 and it's basically a Cybernoid clone. The original game had 70 screens but I've added an extra stage and the Spectrum version how has 101 screens (and shooting enemies - that wasn't in the original, but I got the idea from the programmer of the original as that was something he wanted to add later himself).

It's available from my site, here: http://tardis.dk/wordpress/?page_id=1444

[headkaze]

Awesome :cheers:

[flash]

Really great work (as always) Sokky.

Well done for fitting all the 101 screens in. Just curious what compression system you used? I can tell there are more than 16 different blocks, so half bytes could not have been used. at a single byte, all screens would have taken 16k. Though not massive, that is still a lot for the screens.

Just for the sake of me thinking out loud. Each screen is 16x10 blocks. So, you could have used a coord, direction, length structure. But then more complex screens would have been bigger, and simple ones are not saved that much. ie. scr104 would end up around 129byte. So, what about a simple RLE? Perhaps 2 bytes, tile & len. scr104 would then be around 126 bytes. wow... 3 bytes ok, RLE with single plot as well. so 2 bytes for RLE and a single byte for plot (using bit 7 to denote) = 78 bytes. woot.
Actually, perhaps you used 2x2 block plots (like Sabre Wulf).

Well, that kept me entertained for a little while lol....

Anyway. Really great work and a brilliant version of a class 64 game

PS. Great visual work from Craig.

[spacefractal]

This game is not designed as a 16kb game, but as 48kb game. So its not a issue (the filesize is 41kb).

So he have plenty much more memory than the 16kb C64 entry (which used compressed), which the limit was not required in this version. So the 160->200 bytes per screen is really not a issue at all, even without any compression.

Its also clearly 2x2 tiles he used....

The c64 version did used a 16kb cartridge, so more compressed mightbeen used.

Im like the graphics in this one, and im are newer fan of the beeper (the spectrum 128 have do nice sound, even still behind C64 sound, but its nice), but im do like this style of graphics with down priotity backgrounds, so its dosent clash with the game. Im like it and suit Spectrum so nice :-).

Im test the game soon (and sorry the VERY VERY long reply time).

[Sokurah]

I've gone out for beer(s) (again) but I will go into more detail about how the screen is stored and such, in a day or two.

[flash]

Naughty sokky.

[Sokurah]

This game is not designed as a 16kb game, but as 48kb game. So its not a issue (the filesize is 41kb).

So he have plenty much more memory than the 16kb C64 entry (which used compressed), which the limit was not required in this version. So the 160->200 bytes per screen is really not a issue at all, even without any compression.

Actually the game uses a lot of compression. The game is actually only 34KB - the other 7KB of the filesize is the loading screen.
But the game doesn't just take up 34KB, the remaining 7KB memory (up to the available 41KB in a 48K machine) is actually in use as well and is being used as workspace.

Naughty sokky.

Alright. Let's take a look at the internals of Vallation.

There are 96 tiles in the game which amounts to 3.456 bytes of data.

The screenformat is pretty simple - just a block of 160 bytes for a screen (16x10 tiles - using a byte for each). For all 101 screens that amounts to 16.160 bytes. However, they're LZ compressed and compresses close to 50% and thus takes up only 8.217 bytes. An average of 81 bytes a screen. A bit of a brute-force compression method but I didn't think RLE compression would gain me much.

The data for the enemies are stored separately. The format is a bit inefficient because it contains a bit of workspace for each enemy, something I was going to improve on later but never got around to. Each enemy - on screens where there aren't enemies that move in a circular pattern - takes up 12 bytes. On screens that *has* enemies that move in a circular pattern they each take up 13 bytes. For all enemies in total that amounts to 5.446 which was stored as 1:1 up until about two weeks before release, but then I realized that there was too little room for music, so I LZ compressed that too, which dropped memory usage to 4.255 bytes - that's a saving of about 23% and taking up about 42 bytes a screen on average.

So I guess you could say that each screen takes on averate 123 bytes for layout and enemies combined (down from 213 bytes before compression). Or in other words - the levels take up about 37% of the total filesize. If that data hadn't been compressed it would've taken up about 67% and there wouldn't have been room for much else.

And speaking of compression: To get the fast and fluid sprites movement they should be stored pre-shifted, but there is no room to store all the sprites pre-shifted. To put that into perspective: a sprite stored as 16x16 frames takes up 128 bytes but prefshifted it takes up 1536 bytes. Fluid movement doesn't come cheap, lol. So many of the enemy sprites are stored as regular 16x16 sprites and then between every screen the needed enemies are being pre-shifted into some of that 7KB at the top of the memory.


So...lots of compression and tricks.

[flash]

I gathered there would have to have been some involved compression to fit it all in. That's why I pondered the subject. I could see that 16k for screen structure was perhaps a little excessive (with all the rest that was needed). Thanks for sharing that mate. I do enjoy the technical aspects of 8-bit coding perhaps more than the I should

I understand the problem with smooth movement on the dear old ZX. Haven't dabbled for a long long time though, but remember playing with software sprite styled code back in the mid 80's.

I really do miss playing with the old 8-bits and ASM coding. One day I do intend to revisit some of it, perhaps even finish one of the Vectrex games (there's a platform for you Sokky ).

[spacefractal]

Do you have plans to do a 128kb and then using the AY-3-8912?

Im have looked Beepola for run (a Tracker software to Windows for doing Spectrum Beeper music). Its a little bit annoying to work with, while the plain interface does works nice, its nowhere good as the excellent SidTracker 64 (which is very easy to deal with), due some missing features (where is pattern loop?).

But its useable really and using various kind of drivers. Im do like the Special FX style, which seens would suit the Space Taxi theme very nice (not from the C64 original, but from by old remake), which im might tryout recreate that tune. Im was howover to late to get asked to do music for this game, but im do sure Spectrum musicans is better than im are (but would been fun to tryout of course).

[Sokurah]

Thanks for sharing that mate. I do enjoy the technical aspects of 8-bit coding perhaps more than the I should

No problem - we have that in common. I love the technical stuff too. It's always the first type of articles I read in Retro Gamer.

Do you have plans to do a 128kb and then using the AY-3-8912?

Absolutely - it's happening. A 128K version with a new loading screen, more enemies, more tiles, more screens, a somewhat changed shooting mechanic and AY music instead of beeper music. I'm keeping the current sound effects but I want a continuous AY-soundtrack while you're playing, so if you're up for it I'd be more than happy.   

[spacefractal]

AY-3-8912 based SFX would also been nice too (mixed in with the beeper SFX). Its just not for music. Then the added 128kb could been used in the same tape file, when more memory is detected (while here Spectrum 128 was much better than Commodore 128, which was pretty not used at all).

Im have newer experimenteret with AY-3-8912 and spectrum coding, which seen is required for the AY tracker. But how over could been cool to do something AY remake of some of my C64 tunes. Im do need to do something my self first.

Im only started doing C64 tunes because Sid Tracker 64 was very easy to work well and nice interface and was first time im did sid tunes. Im wish they reused that tracker, but with using Spectrum AY-3-8912 instead of C64 SID.