768 sprites

[sometimes99er]

I almost think so.

Below is an XB demo that shows 28 sprites on 7 horizontal lines. Background characters still available (not used in the demo).

I haven't got real hardware, so I'm not going to attempt 768 sprites in Assembly. I guess you can have any background modes except those with sprite problems ? I think it requires some tight 5th sprite detection and sprite list swapping, but only on every 8th scanline ? Will the sprite priority crack ? Will there be any CPU power left ? Will some sprites have to be sacrificed ? Can it better high resolution pictures ? Will it take a massive 24 sprite lists ? And what about motion ?

Any ideas and attempts are appreciated in this thread.

Edited April 3, 2018 by sometimes99er

[Asmusr]

Interesting idea. It should be simple enough to set up 24 sprite attribute lists in VDP RAM and swapping between them using 5th sprite detection. If you only put 3 sprites on the first scanline in a group of 8 lines you have a 5th sprite left for the last line. While the visible part of the screen is drawn you won't have much time left to move the sprites (this code will be swap, wait, swap, wait ...), but there might be enough time during vertical refresh.

 

This should also work in Classic99/MAME/JS99er.net, so why not try it?

[sometimes99er]

Excellent. Thanks.

 

I'm thinking there's already a 5th sprite occurrence on the last 7 of the 8 scanlines (with the demo and 32 sprites in mind). Do emulators support giving away the no. of the 5th sprite ? I guess it would be the same sprite no. one would try and catch. And the VDP write address could be set previously (before the 5th sprite catch).

 

Depending on the internal hardware buffering, the trick may be to change to a sprite attribute list, that has some similar attributes as the line already being pre-scanned ? Well, the last 4 sprites displayed are those with higher priority. They will overshadow what comes on the next line, except if I can be fast enough, - or wait long enough (catch one line above and wait for the right moment) ...

 

Edited February 12, 2017 by sometimes99er

[+RXB]

Just messing around I made a change using RXB:

100 call screen(2)::call char(33,"8")::for i=27 to 0 step -1
110 call sprite(#i+1,33,16,100-(i and 252)/4,100,0,rnd*50-25)
120 next i
130 IF RND<.01 THEN CALL RMOTION(ALL) :: GOTO 130 ELSE 130

Has a look to it.

[sometimes99er]

Yeah. Nice one. RXB seems somewhat faster than XB with this demo. When I put XB on CPU Overdrive there were also a different look to the randomness as is with RXB. And RMOTION is a nice touch.

 

[Asmusr]

I'm thinking there's already a 5th sprite occurrence on the last 7 of the 8 scanlines (with the demo and 32 sprites in mind). Do emulators support giving away the no. of the 5th sprite ?

 

I think they do, but why would you need to know that for the demo?

[sometimes99er]

We have the hardware 32 sprites on 8 scanlines. Trick is low priority first. The last scanline is showing sprites with highest priority. It is crucial we change the sprite attribute list at the right time to fool the hardware and restart the process (hardware forced to display low priority sprites after displaying one line of high priority sprites). The last high priority sprites have to go through the prescan, when that has happened and before the next prescan, we have to change the sprite attribute list. With 5th sprites on 7 out of 8 scanlines, we need only react on one of the last ones ?

 

Edited February 13, 2017 by sometimes99er

[Opry99er]

heh.... that's pretty neat there.

[Asmusr]

We have the hardware 32 sprites on 8 scanlines. Trick is low priority first. The last scanline is showing sprites with highest priority. It is crucial we change the sprite attribute list at the right time to fool the hardware and restart the process (hardware forced to display low priority sprites after displaying one line of high priority sprites). The last high priority sprites have to go through the prescan, when that has happened and before the next prescan, we have to change the sprite attribute list. With 5th sprites on 7 out of 8 scanlines, we need only react on one of the last ones ?

 

 

You're right, it's more complicated than I thought.