| |
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....
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Nice to see this thread revived. I would like to see a sprite record using the 9 sprite trick as well. |
| |
Digger
Registered: Mar 2005
Posts: 421 |
Talking about multiplexers/multiplexors or plain splits I am thinking of an effect with two 4x4 sprite blocks (aka bosses) moving independently in X and Y directions with independently moving screen ($D011, $D016 + classic screen rewrites).
What would be the best technique to tackle this?
I guess it gets tricky when both sprite blocks are on the same Y position. I though I could "reserve" certain rasterlines for Y swiching for each sprite block so they would never clash but would that work? |
| |
Mr. SID
Registered: Jan 2003
Posts: 421 |
@Digger: It's a bit tricky. If you can, try to get rid of bad lines. Also I'd recommend using timer IRQs to schedule the sprite pointer rewrites. And you'll probably have to use $d018 screen switching. Will be a lot easier if you can have some overlap in your sprites, which will make the sprite pointer switching easier. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
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: 886 |
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: 421 |
@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: 1989 |
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: 1989 |
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: 1714 |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
