Nice! But I'm curious, @Manel46, which technique did you use? Are you modifying a SAT copy in RAM and then updating it all at once to VRAM, or are you updating the SAT directly in VRAM?
All sprites with their coordinates and settings are pointed to by the two indexed records.
Then some macros do the necessary calculations. Example INX 25, increment the X of sprite 25.
I update at once, all the sprites in the VRAM.
Write 500 bytes take a significant amont of time on the CPU side. Nothing problematic for a tech demo but still big for a real game. But the real problem is on the gameplay side: updating 125 entities can take a huge amont of time depending on the gameplay needs.
Exactly.
My fastest code takes more than 12000 CPU cycles to update the V9990 SAT.
500x outi might be faster (9000 CPU cycles), but we're talking about a 1000 byte code here !
I cannot afford 12000 CPU cycles each frame.
I guess my only solution is to split the full update on multiple frames.
Anyway 125 sprites is an insane number. Other than update them all you need to check all of them for collision too... probably doable on r800 but on z80 it would be a hard work
In the V9990 there are 2 sets of sprites. Effectively, your patterns are in ram, so you can modify them on the fly. Then at each frame they are updated separately. Each indexed record points to a different set.
In a rom that I have unfinished, each frame looks at more than 100 possible collisions. We are not going to see the collisions of all against all sprites. Let's not exaggerate.
When you have groups of sprites with the same color or same pattern (or both) things can be done even faster. Let's suppose you have a lot of white bullet sprites. If you make the pattern correspond to the color (15) then you can do something like:
ld a,15
outi
outi
out (&98),a
out (&98),a
outi
outi
out (&98),a
out (&98),a
... etc
This will save 12 clock cycles per sprite.
Of course this will change the way your RAM copy of the SPAT is organised...
another thing you can do is a compromise between an OTIR and 1000 bytes of OUTI such this
Yes, thanks, I think I'll use that compromise.
Manel46 wrote:
In the V9990 there are 2 sets of sprites. Effectively, your patterns are in ram, so you can modify them on the fly. Then at each frame they are updated separately. Each indexed record points to a different set.
Could you explain that ?
I don't understand what you mean ...
Unless you are speaking of the 8 possible offsets for the sprite pattern table (all in VRAM 0).
In the P1 graphic mode we have two planes for scrolling, with different palettes, as well as the possibility of two sets of sprites, with other different palettes each. That is, 64 different colors.
I explained that I handle the sprites with the indexed records, the IY for the first set, and IX for the second. At each frame I update the patterns that are needed, in ram, to later update them in the vram, generally all 64 + 61.
I explained that I use a series of macros to handle them.
