| |
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....
|
| |
WVL
Registered: Mar 2002
Posts: 886 |
Being an even bigger idiot right now :
How many sprites are on the screen if you use the 9 (or 10!) sprite trick invented by Crossbow in Krestage 3? Or do those only count as 0.5 sprites?
What if you combine '9 sprites trick' + more displayable rasters (C128 only and only if that's possible at all) + sprite shrinking? Does that count as real sprites?
In short, what is a sprite? Should a sprite display 63 different bytes on the screen? then what about xbow's wider sprites (also krestage 3), do those count as more than 1 sprite? Is that a 'valid' way to get real 120 sprites? (by having 112 sprites that count as >1.0 sprite?) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
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. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Sprites are very important! I am not sure whether I can see a "correct" way of judging what is a "real" sprite though. There are obviously different definitions, each making sense in its own way. Ayeah? |
| |
WVL
Registered: Mar 2002
Posts: 886 |
So in Jackasser's opinion, you can't have 9 sprites in a row, since there are only 8 sprites that have an internal offset that reached 62 and exhausted bit shift register.
But how about more lines on a c128? How many lines could you make and how many real sprites? :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Quote:Question : Can we also _increase_ the number of displayable lines on C128 and in that way reach 120 real fully displayed sprites?
no. you can _skip_ scanlines by setting the testbit. but as soon as the internal counter reaches 312 (313 infact) the retrace will start and the frame is over. |
| |
Skate
Registered: Jul 2003
Posts: 490 |
About 9th sprite or 50 pixels wide sprite tricks, they will steal almost all of your cycles and won't let you make extra tricks like sprite crunching with maximum number of sprites. just so you know. :) |
| |
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 :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
