Commander X16

My $0.02's worth - I understand about the intermediate 48px size, but I really can't honestly say one of the other sizes that should be discarded in favor of 48px.

8 and 16 - no way. Those are tile-sized aspects and there are far too many uses for such, and furthermore, there are far too many "little" things that would become bloated in VRAM if 8x8 were dropped as a sprite size, especially. I've already done many programs where I used free slots in the tilemap as sprite slots or else used letters/numbers from the tilemap as digits, e.g. the score counter in Flappy Bird....

64 - useful for bosses / making panels for things like radar / HUD overlays / popup dialogs, etc. (for instance, in games like StarFox where a character's portrait pops up along with their dialog/voice clip, having a 64x64 sprite for this is perfect)



32 is probably the only one I'd say is "up for discussion" as an atomic size that could be considered expendable in favor of 48. Both are "middle" sizes, and maybe 40 or 48 offer more utility than 32, but the extremes are both quite valuable and dare I say, indispensable?

 

@ZeroByte This is the lru cache in action ...

 

On 10/3/2022 at 9:25 PM, ZeroByte said:

My $0.02's worth - I understand about the intermediate 48px size, but I really can't honestly say one of the other sizes that should be discarded in favor of 48px.

8 and 16 - no way. Those are tile-sized aspects and there are far too many uses for such, and furthermore, there are far too many "little" things that would become bloated in VRAM if 8x8 were dropped as a sprite size, especially. I've already done many programs where I used free slots in the tilemap as sprite slots or else used letters/numbers from the tilemap as digits, e.g. the score counter in Flappy Bird....

64 - useful for bosses / making panels for things like radar / HUD overlays / popup dialogs, etc. (for instance, in games like StarFox where a character's portrait pops up along with their dialog/voice clip, having a 64x64 sprite for this is perfect)



32 is probably the only one I'd say is "up for discussion" as an atomic size that could be considered expendable in favor of 48. Both are "middle" sizes, and maybe 40 or 48 offer more utility than 32, but the extremes are both quite valuable and dare I say, indispensable?



 

Very cool feedback, yes, probably you are right and the 8px is required as a sprite map. It would be great if the vera would allow to configure the sprite map sizes somehow with a bit map flag, just as @AndyMt already indicated. Your suggstion to blow up the 32px is a good one. Or to reduce the 64px. I think a "dynamic solution" would be the best maybe.

That dynamic heap manager makes things easier from the programmer's perspective,  but it adds a lot of computational overhead at run time. It might be that one of the tradeoffs of having the dynamic heap manager is slightly more complicated sprite management code. And really it's all about tradeoffs.

The current sprite dimensions make a lot of sense if speed is the goal, and 48 or 40 make sense from an ease-of-programming goal. Hard call.

Breaking a 48x48 into 2 or 4 or 9 sprites is probably the best option here. Combining smaller sprites into a single image actually sounds like something the heap manager should be good at.

Addendum: maybe dividing up into several heaps, one of 16x16, one of 32x32, one of 8x16 etc. Each heap just one size of sprite, perhaps all of them controlled by a master heap manager? It's just one more layer of abstraction. 

I definitely want to keep the 8x8. The stars in Asteroid Commander are 8x8 4bpp sprites, and really only one pixel in the center has color. Anything more than 32 bytes and I'd have to cut the number of stars in half. Getting rid of 8x8 also means getting rid of 8x16 and 16x8 and 32x8 (which I also use) and 8x32 and 64x8 and 8x64.

Thanks Ed. I read your mail with great interest. 

On 10/4/2022 at 12:34 AM, Ed Minchau said:

Breaking a 48x48 into 2 or 4 or 9 sprites is probably the best option here.

Probably yes, but not convinced. Allow me to reflect my thinking about this idea a bit further, let's talk about complexity elements, like heap manager, cpu overhead, code size and data size...

Complexity factors to be taken into account:

• 
  Copying the image data (in my case 1152 bytes) onto those asymetrically distributed sprites.... For a 48x48 I would paint a 32x32; 32x16; 16x32; 16x16. This combination gives the most memory efficiency.
  


• 
  Selecting which sprite offsets to use... It matters as sprites with offsets lower in memory are painted above sprites with offsets higher in memory. So when sprites overlap each other, in my case enemies, you want to have enemies showing a consistent overlap and not one part overlapping while an other part appears behind the sprites. So the sprite offsets to be selected carefully. Maybe the offsets even have to be sorted, which also takes CPU time.
  


• 
  Moving the sprites.... moving gets more overhead on the CPU. Imagine 16 enemies on the screen moving. Each enemy having 4 sprites. Moving for my case, means 2 things: x and y axis plus animation image updates. So that would mean 4 (sprites) times 4 (x/y) times 2 (image offset addresses) times 16 bytes to be updated every frame. It's not that the cx16 cannot pull this at 8Mhz, it can do this easily, but it adds CPU time per frame.
  

These things can be done but it gives extra CPU overhead and extra code to manage all this.

The heap manager in combination with the lru cache can help greatly with dynamically allocating those sprite image parts. However:

• 
  Each image part would have a handle pointing to the place on the heap, which again consumes memory. Instead of one handle the logic now needs to reserve more handles pointing to the images per sprite.
  


• 
  I would need to put an extra layer to manage the lru cache. Since sprites are composed out of multiple images, the elements in the lru cache should point to an array of image offset handles, and not to the handles itself ...
  


• 
  Allocating sprites on the heap and memory checking becomes more labour intensive. A sprite with 16 animations in a 48x48 setup results in 64 images allocated on the heap, thus 64 heap manager index entries.
  


• 
  For speed reasons the vera heap manager indexes are only one byte long. A maximum of 255 images can be stored in the heap manager because NULL value is also required. That would mean a maximum of 4 enemies (having 16 animation frames). No ... 3 enemies as the heap also manages player, bullets, particles, weapons, ground installations. Maybe even 2 enemies maximum possible. Or the heap manager should have 16 bit indexes increasing memory and decreasing speed. So it looks like the heap manager index size would become an issue.
  

 

On 10/4/2022 at 12:34 AM, Ed Minchau said:

That dynamic heap manager makes things easier from the programmer's perspective,  but it adds a lot of computational overhead at run time.

In fact, not really. In the current setup, the heap manager really helps and it is very efficient. I would say a very little CPU overhead, some code overhead and some data overhead. 

Regarding overhead:

• 
  The vera heap manager from a code perspective is about 0x600 bytes for the core heap functions. However, the heap needs data which adds another 0x0800 bytes. The indexes are managed in banked ram.
  


• 
  The lru cache is also an object that requires code and memory. It consumes about 0x0400 bytes of code, and the lru heap is located in main memory in address 0x0400. It consumes only 0x01FF bytes.
  

sv.

May it also be noted, that the sprite registers have a lot of unused areas, like register 3 and 5.

There are free bits which potentially could be used by vera for further settings. @Wavicle.

On 10/4/2022 at 12:28 AM, svenvandevelde said:

May it also be noted, that the sprite registers have a lot of unused areas, like register 3 and 5.



There are free bits which potentially could be used by vera for further settings. @Wavicle.

The existence of space in the register mapping doesn't automatically mean there are the on-chip resources to populate those resources ... but on the other hand the design seems to be I/O pin constrained, so here's hoping.



A similar saving to the 48x48 square sprites could be achieved with options of 32x64 and 64x32 rectangular sprites. 48x48 is 2,304 pixels, and 32x64 is 2,048 pixels.

On 10/4/2022 at 1:56 PM, BruceMcF said:

A similar saving to the 48x48 square sprites could be achieved with options of 32x64 and 64x32 rectangular sprites. 48x48 is 2,304 pixels, and 32x64 is 2,048 pixels.

Very true however, then the figures are either very flat or very wide, unless i'm misunderstanding thefeedback. But yes, this has crossed my mind and will use these in the game.

For lasers or for structures like walls with lasers etc.

 

On 10/4/2022 at 10:26 AM, svenvandevelde said:

Very true however, then the figures are either very flat or very wide, unless i'm misunderstanding thefeedback. But yes, this has crossed my mind and will use these in the game.



For lasers or for structures like walls with lasers etc.



 

This is, if neighboring powers of two as vertical and horizontal dimensions are easier to add to the circuitry than a common dimension that is the sum of two powers of two.

If the use case is, "I would use a 64x64 here, but given the empty space that is wasting too much VRAM per sprite", the user side question is whether the empty space is going to be evenly spread vertically and horizontally, or whether it is going to be biased either to taller objects with excessive horizontal empty space and wider objects with excessive vertical empty space.

I agree with @ZeroByte if we could add a flag to upscale a sprite the sprite best suited to be upscaled is the 32 bit one.

I have a thought : looking at the sprite registers: is anyone using the palette offset at its full potentiality? maybe we could have 3 bits for sprite width and height such as

8 12 16 24 32 48 64 (7 in total) and still have 2 bits of palette offset to display the same sprite in  4 different hues.