| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Is 120 the max number of full height sprites that can be displayed?
I've been on a nostalgia trip and checking out some demos from the real oldschool, record-breaking times. So I started thinking a bit about the world record for most sprites in a multiplexer. I started calculating, and got the following:
8 sprites can be displayed per 21 lines (since a sprite is 21 pixels high). Now you have 256 y-positions available to place sprites on. That should give us 96 or maybe 104 (I wasn't quite sure on this).
Since I saw demos with 112 and even 120 sprites (think it was in Ice Cream Castle/Crest), this couldn't be the limit.
Anyway, I started coding on a little test program and discovered that sprites placed on position $01 to $1e was displayed twice (both in the upper and lower border. I guess this is common knowledge, but I've been out of the loop for a while!)
Now, those $1e lines gives us the possibility to display two batches of 8 sprites that essentially gets doubled, thus we have 104+116 = 120 sprites as the absolute maximum.
Is this correct reasoning? Any oldtimer hardware specialits who can shed some light on this? |
|
... 67 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11360 |
i'd probably try something with overlapping sprite data in a game... 2 screens quickly get very annoying when scrolling comes into play :) |
| |
WVL
Registered: Mar 2002
Posts: 899 |
Quote: i'd probably try something with overlapping sprite data in a game... 2 screens quickly get very annoying when scrolling comes into play :)
What groepaz says. You have sprites with overlapping sprite data, f.e. :
last 5 pixelrows of spriterow 1 is the same as last 5 pixelrows of spriterow 2 (you dont use the last 5 pixelrows of spriterow 2, they're only there to make multiplexing easy).
Next pixelrows 12-16 of spriterow 2 is the same as pixelrows 6-11 of spriterow 3 (you dont use.. bla bla, see above).
Same as above, except you the overlap moves around, blabla |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Quote: Imo a sprite has been displayed when the internal offset has reached 62 and the current 24-bit shift register being exhausted => xbow is currently king of the hill.
I think Jackassers definition is appealing. It's a precise definition that allows spritechrunching.
The nine sprite argument doesn't bother me. I think of it as 'There have still only been showed 8 sprites on one 'spriteline'. Crossbow just exploids that spritelines
aren't perfectly aligned with the screenlines. |
| |
Digger
Registered: Mar 2005
Posts: 427 |
@WVL: hmmm OK, but did you mean first 5 pixelrows of spriterow 2 rather than last 5? Like:
spriterow 1:
1 AAA
...
21 AAA
spriterow 2:
1 AAA
2 AAA
3 AAA
4 AAA
5 AAA
6 BBB
...
21 BBB |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: I think Jackassers definition is appealing. It's a precise definition that allows spritechrunching.
The nine sprite argument doesn't bother me. I think of it as 'There have still only been showed 8 sprites on one 'spriteline'. Crossbow just exploids that spritelines
aren't perfectly aligned with the screenlines.
Indeed, and addition to my definition is that:
When offset 62 is reached AND the 24-bit shift register is empty, then the sprite is finished. And this is _the_ definition the VIC itself use. After this the VIC will start comparing y-positions to the raster beam again etc. not before.
Regarding the 9th sprite I'm completely with you there. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: @WVL: hmmm OK, but did you mean first 5 pixelrows of spriterow 2 rather than last 5? Like:
spriterow 1:
1 AAA
...
21 AAA
spriterow 2:
1 AAA
2 AAA
3 AAA
4 AAA
5 AAA
6 BBB
...
21 BBB
No, because when you switch pointers you do that at the end of sprite 1, and independent of raster line (within those last 5) is doesn't matter if you're showing row 1 or 2, it's still just AAA. After a while the sprites will multiplex and start showing the top of sprite row 2 which will be the BBB lines automatically and perfectly aligned.
|
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting JackAsserWhen offset 62 is reached AND the 24-bit shift register is empty, then the sprite is finished. And this is _the_ definition the VIC itself use. After this the VIC will start comparing y-positions to the raster beam again etc. not before.
AFAIK the contents of the shift register doesn't really affect the y-compare. |
| |
HCL
Registered: Feb 2003
Posts: 727 |
@Skate: 112 or 120 *does* matter since we have the same situation whatever we do. if we count 120 sprites instead of 112, we could also have 152 instead of 144. If you count displaying one single rasterline of a sprite as valid, then we're into deep waters. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Quoting JackAsserWhen offset 62 is reached AND the 24-bit shift register is empty, then the sprite is finished. And this is _the_ definition the VIC itself use. After this the VIC will start comparing y-positions to the raster beam again etc. not before.
AFAIK the contents of the shift register doesn't really affect the y-compare.
True, but that was easier to write than saying that: "when fetching the 3rd byte into the shift register and that offset is 62, then we're done". :)
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: @Skate: 112 or 120 *does* matter since we have the same situation whatever we do. if we count 120 sprites instead of 112, we could also have 152 instead of 144. If you count displaying one single rasterline of a sprite as valid, then we're into deep waters.
Imo, any part of a sprite (see my definition of a sprite) visible should be counted.
Also, since showing just a bit of a sprite will still eat cycles for the whole sprite it's just fair imo. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
