Commander X16

On 10/3/2022 at 4:41 PM, svenvandevelde said:

I suggest to model it that the high resolution 640 width supports 16, 32, 48, 64 resolutions.



And the lower resolution 320 supporting 8, 16, 32, 48?

On 10/3/2022 at 3:41 PM, svenvandevelde said:

And the lower resolution 320 supporting 8, 16, 32, 48?

On 10/3/2022 at 5:15 PM, Yazwho said:

64 x 64 is very useful though.



As would be 128 x 128 and 256 x 256 if there were 1bpp and 2bpp modes available.



 



Vera only has one resolution, 640x480, we use scaling to create 320x240 or indeed any other 'resolution' lower than 640x480.

On 10/3/2022 at 4:34 PM, ZeroByte said:

honestly, the correct solution is to use multiple sprites for one object. This is how it was done on classic systems.



Take this sprite of Samus from Super Metroid:





It requires 36px to cover the full width of the character on screen. However, most of that extra 4px of width is blank, with only 10px height for back foot. This can be contained in an 8x16 sprite placed correctly in relation to the main 32x32 sprite. If I were to make a demo/game using artwork of this sort, I would simply make the actor/object control these sprites and define animation frames for each one.  In cases where the "extra bits" (like Samus's foot) move around relative to the main sprite, the engine would also need an x/y offsets table. In the Samus animation, the back foot is near the bottom of the sprite for one frame, and closer to the top on the next frame. This "foot sprite" would just be drawn at different relative locations to the main sprite during each frame of the animation cycle.









My Sonic demo faced a similar issue on the Sonic sprite, which is 40px tall. I used one 32x32 sprite for the main part of Sonic:



and I use a separate sprite for the ears:



Interestingly, the ears only require 2 frames of animation (frames 3 and 4 are duplicates of 1 and 2). I didn't bother deleting frames 3 and 4 from the resource, as I've got plenty of VRAM for this simple demo, but the engine never uses those frames. I set up an animation frames table with the VRAM locations of the frames, and the engine cycles through these tables. So the main body's data is the VRAM address equivalents of: 0, 1, 2, 3 and the ear's data is 0, 1, 0, 1. This is also useful for "pingpong" animations where you only need pixel data for 3 frames of a walk/run cycle and you just display them as 0,1,2,1,0,1,2,1... no need to have frame 1 in VRAM twice.



This is part of the challenge of programming retro. It's nice when HW just does the work for you, but when it doesn't, that doesn't mean you're stuck. You just have to code a solution. This stuff I've explained here actually saves more memory too, as you only need exactly the pixel data for exactly the parts that go out-of-bounds. The lazy alternative would've been to use a 64x64 sprite, but yes, that would gobble up VRAM needlessly.



Hope this makes sense.

On 10/3/2022 at 8:30 AM, svenvandevelde said:

One could argue, that yes, we can do magic and start combining sprites to make larger pictures to draw a 48x48 bitmap, like drawing 9 16x16 sprites, or 1 sprite of 32x32 + 1 sprite of 16x32 + 1 sprite of 32x16 + 1 sprite of 16x16 ... But that would make things very, very complicated, and also notice by having to draw 9 or 4 sprites instead of one, there is a performance impact. Also notice, that if I would draw a 48x48 sprite out of 9 sprites of 16x16, that would mean 72 sprites to be drawn if i want to show 8 images of 48x48 pixels!

On 10/3/2022 at 6:06 PM, svenvandevelde said:

Do what i'm doing with vera and then you will see that it is not that simple.

On 10/3/2022 at 7:51 PM, Yazwho said:

You mean coordinating the moving of a lot of sprites on the screen at every frame -- say 1160 of them -- like this?




 

On 10/3/2022 at 8:13 PM, Yazwho said:

If it's just a vram issue, then ZeroByte suggested a way around it.



At the end of the day there are lots of ways to mitigate the issue, but I dont think changing the machine is one of them. This is meant to be a limited machine afterall.



There are plenty of people on Discord who can offer suggestions, workarounds, or can just talk about things in a more conversational way than can be done here. Maybe thats worth a go?