VERA and number 48 ...

[AndyMt]

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?

Makes a lot of sense!

[Yazwho]

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.

 

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

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

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

[svenvandevelde]

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.

Do what i'm doing with vera and then you will see that it is not that simple. And 128x128 would be great, but impossible to manage at acceptable frame rates, as vera and cx16 don't have dma.

[svenvandevelde]

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.

As I wrote earlier:

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!

 

But thank you for the suggestion. Indeed, it is a good method to do and this would be a solution.

However, it would make things way more complicated. I've posted a video below that shows what is in the make. This is way past a demo.

It is an actual game, with lots of enemies and thus, sprites ... I want to render them as one object, but will combine the player sprite with additional modules picked up on the flight.

However, for the enemies, if i need to model those also, then i am looking at a project to be release in 2 years ...

Think the 48x48 is the viable option in my opinion, but only if doable technically. Actually, it would be great if vera would have some function to set the scales of sprites by the user.

[svenvandevelde]

I hope this clarifies a bit what i meant to say ... look at video around 2:30...

https://screencast-o-matic.com/watch/c36ebrVtI3J

[Yazwho]

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.

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


 

[svenvandevelde]

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?




 

Nicely done! Great demo!

However, it is not what I was looking for. I also expressed myself a bit bluntly I see upon your feedback.

What I wanted to express is the vram memory consumption issue.

Pls check my video if you have the time to see the challenge ...

We are going waaaay beyond the scope of this post.

 

[Yazwho]

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?

 

[ZeroByte]

I think the main issue at hand is that the engine uses a heap management approach to allocating VRAM which comes with benefits and drawbacks, as with all design decisions. That's what makes this an engaging hobby. ?

[svenvandevelde]

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?



 

I have written in my original post exactly what ZeroByte has expressed, pls check the sentences below. Also i replied to the feedback of ZeroByte.

What i'm trying to say, is that a 64x64 sprite size is quite large, and there is no size in between. I am not trying to request to change the machine, and it is upon much more people to judge if chaning it would be an option or not.

Then why Wavicle is doing changes that are accepted by Frank? And why is Frank replying to my posts about transparency, that such would be possible to implement?

Because maybe, just maybe, there is a valid reasoning that may improve the machine, and that might result in a better system overall, over time.

If changing the machine is not an option, then fine, so be it. At least I've raised it and it is up for the community to consider.

Latest changes by @Wavicle were accepted by Frank though. Also, Frank replied to me that alpha channels in bitmap rendering would be an option according to him also.

Alpha Channel · Issue #3 · fvdhoef/vera-module (github.com)