# wondering how smb3 would look like on msx1

Página 6/33
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10 | 11

Huey you forgot my game objects have 2 colors each.

Mario = 8 (16x32 + 16x16 for tail + 16x16 when grabing a shell)
Fireballs = 3 x 2 (16x16)
Powerup= 2 (16x16)
NPCs = 4 x 4 (16x32)

So I can't have more than 1 powerup, more than 3 fireballs and more than 4 enemies on screen. the Bowser should take 2 NPCs slots.
For the ship I can have up to 9 cannon balls since there is plants there and I can borrow plant's fireball.

The slots have fixed positions, so this make the animation sets a lot easier. Mario has an updside down T shape.

You're ambitious
Please continue your way. It is always good to see other approaches then the general ones.

>>with 32 sprites on a row you need 8 frames to display all. looks horrible.

what about a pseudo-random order, scrambling the SAT instead of ring buffering it ?

The reverse SAT method: the result is incredible

Example, showing the positions of the RAM table the way they end up in top of SAT:

00,01,02,03 ...
31,30,29,28 ...
04,05,06,07 ...
27,26,25,24 ...
08,09,10,11 ...
23,22,21,20 ...

Take the standard ringbuffer method advancing by 4 every frame. Then, every second frame, do not change the offset, instead make sprites end up reverse order in the SAT. The reverse copy shall also use the offset, in the other direction, as you can see in the numbers.

Imagine 4 hidden sprites. Next frame with reverse SAT they must be ahead of the 4 that caused the hiding. This is true no matter where in chaos the both groups ended up. Means max 1 frame disappearance up to 8 sprites per scanline

p.s. because of reversing stuff, the patterns of 2 color sprites must not overlap each other.

Interesting technique. I'll try this as my patterns do not overlap themselves. This makes the copy little slower as extra logic is inserted.

Your flicker looks like much more than 8 sprites are somewhere, and the recent sprite count discussion makes me think it was about fixed allocation of SAT positions? No good. A variable size SAT without bubbles of dead bodies got better roundtrip, and it goes beyond 32 sprites without fuzz.

I have fixed pattern slots, not fixed SAT slots. It's a new concept (i suppose). But you are right, I could end up having holes in the sat, but I can move them to the end of the SAT without any problem and avoid flicking them. In the demo I have 24 used sprites, so 8 holes are flicking around.
how can I do it ? Simple, I have 2 SAT tables in RAM, those sats are double buffered, i update the off-screen SAT always, synchronizing with the interrupt. Those RAM SATs they have fixed slots. But the interrupt will copy the SAT to VRAM ringing it every 1/60s. (i can add a check for the 5th sprite). So the interrupt will selectively flick only the used slots or use any different algorithm.

In case of the pattern problem, it does not sound strange to me that you are doing some group things, but the SAT should be dynamic.

Rotate to 5th sprite does not work, it can lead to total sprite disappearance when there is more than one 5th in a frame, very bad.

I did not really understand what is in RAM, I can only hope that in vram it ends up cleanly rotating by 4, and every second frame cleanly reverse.

I like it how you shamelessly use so many sprites

Right now I rotate the entire SAT 4 sprites left every vsync. Why do I have a SAT in ram ? because the code updates the RAM SAT 0 which is always mario. But the interrupt will take the RAM SAT 0 and copy to VRAM shifting it left every vsync. So I don't care what position is the mario SAT in VRAM (there is only one mario in VRAM, all the SAT is copied but rotated), I always use RAM instead. And why 2 SATS ? Because I use a lot of sprites, I don't want to disable interrupts when updating several sprites, or allow sprites to tear because an interrupt occurred between the update, so I update the second buffer then I flush it at the end. When I flush the interrupt will look for the second buffer and leave the first for me to update. This forces me to update all positions to the current buffer but it's ok.
The same thing I do for patterns. I have the sprite pattern 0 and 32 for the first sat position, 1 and 33 for second and so on. When I need to update a pattern I take the pattern that is not being displayed. And the new pattern will be displayed only when I flush the SAT.
If I need to use more than 32 sprites I will need to share the same pattern, but this is not the ideal for my engine, as patterns flips, can receive special effects like scissors (when mario is going down a pipe), etc.

I feel you know where your turtles are in a RAM SAT - do you work with fixed size arrays? Do you iterate over dead bodies?

I advocate the variable size array that never got dead holes. Using arrays of pointers pointing to objects or sub-parts of objects.

Walking dead holes ranges between slow and ultra-slow.

Página 6/33
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10 | 11