Nodes of Yesod : ZX Spectrum Next : Update #1
 |
| A ZX Spectrum Next, in its natural habitat |
A quick progress report on Nodes of Yesod for the Spectrum Next. The good news - I worked on it! I managed to spend a couple of evenings last week working on (or more accurately, toward) the game. I am in that preparation phase where I think I have a handle on how to do things, but can't do those things until the other things are done. Such as having some data in a useful format.
Most effort has been spent against wrangling graphics, specifically sprite graphics. I already have all the art I need, in (or close to) the appropriate (pixel and color) resolution. The main challenge with the sprite graphics is to wrangle them into a format suitable for the Next hardware sprites. It will be cool to really lean into the custom hardware on the Next, but the problem is that there are way too many sprites to fit in the internal 16KB of VRAM. For example, each animation frame of the main character, Astro Charlie, is nominally 24 pixels wide by something just over 32 pixels tall, and some animation frames are larger than that. Each hardware sprite on the Next is 16x16 pixels, so we'll need to reserve 6 sprites for each animation frame. As you can see from the image below, we have about 38 frames of animation for Charlie, or the equivalent of 228 Next sprites.
 |
| Astro Charlie animations consume 200+ Next hardware sprite. |
The Next can fit 64 x 256 color sprites or 128 x 16 color sprites into the internal 16KB sprite VRAM. To cut a longer story shorter, in addition to leaning into the hardware sprites, I am also planning to lean into the 1MB of base memory present in the Next. Basically, I'll be uploading sprites into the sprite VRAM dynamically, possibly with some sort of least recently used caching, or maybe just brute force on demand, since the DMA transfers on the Next are so fast. And this leads to the real point of these ramblings which is that I have been working on a Python script to convert the original sprite data into the precise format needed to upload to the Next sprite hardware. My tool accepts .PNG images and spits out 'C' language source code that can be compiled directly with the Z88DK toolchain. The tool is basically working but needs a few additions before it can be useful (I need to spit out a header, wrangle the palette data, and a few other things). The output from this tool looks like this (this is a single 16 color sprite, 8 bytes per row @ 4 bits per pixel x 16 rows):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | static const uint8_t sprite_player_010[] = { 0xff,0xff,0xff,0xff,0xff,0xff,0xff, 0xff,0xff,0xff,0xff,0xff,0xff,0xff, 0xff,0xff,0xff,0xff,0xff,0xff,0xff, 0xff,0xff,0xff,0xff,0xff,0xff,0xff, 0xff,0xff,0xff,0xff,0xff,0xff,0xff, 0xff,0xff,0xff,0xff,0xff,0xff,0xff, 0x77,0x7f,0xff,0xff,0xff,0xff,0xff, 0xee,0xa7,0x77,0xff,0xff,0xff,0xff, 0xde,0xba,0xbb,0x7f,0xff,0xff,0xff, 0xee,0xaa,0xb9,0x7f,0xff,0xff,0x77, 0xaa,0xbb,0xaa,0xa7,0x77,0x77,0xaa, 0xbb,0xbb,0xab,0xba,0xaa,0xaa,0xbb, 0x99,0x99,0xba,0xbb,0xbb,0xba,0xb9, 0x0,0x0,0x9a,0xb9,0x99,0x9a,0x99, 0xb9,0x9,0xab,0x90,0x0,0x9a,0x9, 0xab,0x9b,0xab,0x90,0x9,0xaa,0x9, }; |
I'll release source code to any tools that turn out to be useful.
I've also been using a cool commercial tool called Aesprite to wrangle the position of these sprites into the hardware sprite extents. It runs on Windows, Linux, and Mac and seems flexible and intuitive, and I've been able to do what I need to do with it easily, so far. For $19.99 it is a steal.
Additionally, shout out to the Next team (thanks Mike and Allen!) for sharing their findings on using Z88DK on the Next! I feel fortunate to be benefiting from their wealth of real-world experience using the Z88DK toolset, and my confidence level is higher because of that.
So my rough plan of attack is "get the output from my sprite tool to display on-screen" and then build out spiral-fashion from there. I'll post updates here as and when there's progress to report, hopefully, next time I'll have something on the screen!
Comments