sprite multiplexing part 2

[Heaven/TQA]

does this method found on MSX suite more to the atari hardware than the "standard multiplexing" methods used f.e. on amiga & c64?

 

konami's "ringbuffer" on MSX:

 

Method: A sprite position ring buffer is held in main memory. Up to 32 of the leading entries are copied to TMS9918 memory. Next video frame, the start position of the ringbuffer is incremented by 4 entries (this value leads to minimum flicker on a chip that can do 4 sprites per scanline). If the ringbuffer got more than 32 entries, then even without 5th sprite condition (more than 4 sprites per scanline), sprites start to flicker. But even more than 32 sprites are visible, i.e. the max 32 sprites onscreen limit is broken the same way as the max 4 sprites per scanline limit. It can happen that rotation of the list is nessesary even when no 5th sprite condition occured (when there are more than 32 enemies), and it can happen that objects collide without the videochip noting it (because the sprite multiplexer displayed them in distinct video frames), which is why an advanced game engine does not use those hardware flags.

 

what do you think?

[Heaven/TQA]

hmmm... just thinking about it... why should this method lead to less flickering?

 

let's have a look on the following situation (each no. representing one sprite)

 

12345

6

7

8

9

10

 

1st frame... 1234678910 are visible as 5 is the 5th on the scanline and will be rejected by the hardware

 

2nd frame (ring buffer incremented by 4)... 5678910... so now sprites 1,2,3,4 are completly left out? would it not make more sense to start with 2 so just sprite 1 is left out???

 

maybe some of you might know the clue...

[sack-c0s]

hmmm... just thinking about it... why should this method lead to less flickering?  

 

let's have a look on the following situation (each no. representing one sprite)

 

12345

6

7

8

9

10

 

1st frame... 1234678910 are visible as 5 is the 5th on the scanline and will be rejected by the hardware

 

2nd frame (ring buffer incremented by 4)... 5678910... so now sprites 1,2,3,4 are completly left out? would it not make more sense to start with 2 so just sprite 1 is left out???

 

maybe some of you might know the clue...

 

ringbuffers wrap around to their start point

 

so.. 1st frame 1,2,3,4,6,7,8,9,10 - 5th is rejected as it is picked up by the hardware after its reached its sprites per line quota.

 

2nd frame 5,6,7,8,9,10,1,2,3 - 4th is rejected as its attempted to be displayed after the 4th sprite on a line

 

that's my interpretation from what I've read about the MSX chip anyhow

[Heaven/TQA]

so....as it seems just 4+5 are flickering?

 

ok. i understood... but is this practical for atari's player/missle hardware? still thinking on Joust's clever but flickering and 8 players/missles engine...

[sack-c0s]

I think its only useful for architectures where you have a large-ish spritelist and a limited amount of sprites per line.

 

for the A8 and C64 you have a list that only contains the sprites you can display on a line, so I'm not so sure it's useful as you still need the plexor to reload the spritelist.

[Shawn Jefferson]

In the case where you have 5 sprites on the same scanline:

 

What do you think is less noticeable flicker? Always flickering the same sprite, or rotating through the sprites to flicker, so that each sprite gets at least 4 frames of drawing and one missed (I think.) ?

[TMR]

for the A8 and C64 you have a list that only contains the sprites you can display on a line, so I'm not so sure it's useful as you still need the plexor to reload the spritelist.

 

It'd be quite nasty on the C64 actually, most plex routines have a fixed sprite order and sprite 8 onwards are doled out based on the end positions of sprites 0 to 7 - it would need multiple routines to handle cycling.

[Heaven/TQA]

shawn: i guess the flickering through the scanline is less noticable.

 

tmr, sack: why would the "msx" approach not work on c64? i mean msx has 16 16x16 sprites with the restriction only 4 per scanline? c64 has 8 with 8 per scanline?

 

please have a look on atari joust. as far as i remember the engine is kind of "cycle msx" one...

 

still searching for the HASG method...

 

ps. Holy Atari Sprite Grail

[Heaven/TQA]

http://www.softnfuzzy.freeserve.co.uk/ngpc/uridium/

 

just stopped over it when feading google with sprite multiplexor

[TMR]

tmr, sack: why would the "msx" approach not work on c64? i mean msx has 16 16x16 sprites with the restriction only 4 per scanline? c64 has 8 with 8 per scanline?

 

Well, from what's been said the MSX system is just a matter of cycling which physical sprite is assigned to which job and there's no attempt to increase the number of sprites past the hardware limit. When plexing on the C64 there's already a load of assignment going on as to vertical positioning (sprite 0 is the highest of the first eight, sprite 7 the lowest) and, since most plex routines "break" if you try getting nine sprites on one line (the raster splits moving the sprites around begin to collide a lot of the time) changing which sprite gets assigned where is just an extra drag on CPU grunt - it'll still break anyway... =-)