| |
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....
|
| |
DanPhillips
Registered: Jan 2003
Posts: 30 |
Quote: [Looks up from reading Mental Procreation for the Nth time]
Braybrook said that the Morpheus multiplex doesn't use sorting...? =-)
"Got a 'phone call with all the answers at about 11 o'clock this morning. "Why don't you try this..." were the pearls of wisdom. Eventually ascertained what was going on, and it doesn't involve a sort routine at all. No bubbles, no insert sorts, no Shell Metzner (who?), no McPherson Struts...no matter - my logical chain sort isn't quite working anyway!"
http://www.zzap64.co.uk/zzap23/mental1.html
(What's a McPherson Strut anyway?! =-)
Morpheus uses a bucket sort. IIRC
Id have to look at the code...but Im pretty sure he spoke
to Mr Liddon...bucket sort on the stack was the outcome.
Dan
Lead Pro...Arma..thing. |
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
Quote: i pull out issue 10/1990 of svenska hemdator nytt, and turn to the programming pages and there we have an assembler listing called 'multiplex' which displays one sprite on two places on the screen, no sorting whatsoever. who took the risk to be called lame? answer: linus nielsen aka boogaloo/horizon
1990 is waaaaay after the fact. A lot of the original sceners had moved on by then and I think it was around the 89-90 period when "new skool" people started making demos and this is imho where the confusion started.
@Graham
This is another phrasing where it's easy to missunderstand. "Splitting sprites" I would agree with you, changing something during the sprites display but "Sprite splits" I just see as raster splits to use the sprite multiple times.
@Dan
I'm pretty sure I'd seen the term multiplexer used b4 Braybrook used it but my memory is soooo bad I can't pinpoint a time when I was using it from ;) |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Chris Butler did an interview with Zzap! around the time he'd just done Commando, maybe he used the term there...? |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
120 full height sprites is the limit, or actually it's a bit over the limit. The c64 has 312 rasterlines in PAL, althought not all of them are visible. But Crests 120 sprite multiplexor from Ice Cream Castle uses all of them anyway.
120 sprites means that each sprite has to be displayed 120/8 = 15 times, but 312 lines divided by 21 is only ~14.86. We actually need 315 lines to multiplex each sprite 15 times.
So what happens if we try to do it anyway? We miss 3 lines when reaching the first sprites again. Crossbow solves this problem by moving all sprites 3 lines down each frame, which means he virtually gets 315 lines.
Actually you could get even more virtual lines this way, but that would mean you had to move the sprites so fast it would look too ugly I guess. For instance, if you moved them down 24 lines/frame you could make 128 full height sprites, although there wouldn't be any more visible on a screenshot than on Crest's routine. |
| |
HCL
Registered: Feb 2003
Posts: 716 |
I just wrote about this on codebase, and i though there must be a topic about this here already, and it was. Badly spammed with irrelevant shit as usual, but perhaps we can stick to the topic now.
Cruzer just explained above exactly how this "record" was made, and i question (ever since ~20 years ago) if this is really a valid record. Crossbow's opinions and theories about which sprite-record was valid or not was like the word from god back in the days. At the same time he explains that "with a little trick" you can make 120 sprites instead of 112. I think perhaps today is the day we start to seek the truth about this :).
Fact is that you can only display 112 *whole* sprites on one screen. Those last 8 have to be displayed just partly (like Cruzer stated, 3 pixel lines are missing). If that is valid 120 sprites, then it is fairly easy to do 128 sprites also, displaying 3-4 lines of the first sprite, then 14 whole sprites, and then a few lines of the last sprite. I would say only whole sprites count.
Further if you want to display all these sprites each frame (i consider that be normal), then you have to move the sprites down 3 pixels each frame. This will make the upper and lower part of the screen display only fractions of sprites -> same problem as above, does it count? Perhaps the most correct way is to calculate an average on several frames, and then we'll probably end up on ~14.86 * 8 sprites = ~118.86 sprites, if Crossbow didn't leave any free space there :). Opinions? |
| |
enthusi
Registered: May 2004
Posts: 674 |
I agree ;-)
But since I dont like (and dont see) the need to place absolute numbers for records such as this one I'd say 112 is correct (quite naturally) and 120 is correct WITH that explanation which can (and was) easily given within 5 lines of text. So being asked about max no of sprites on screen I'd say 112 because.... but there is a trick to have visually 120... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11101 |
until someone adds a software sprite and claims that "sprite" doesnt mean it has to be drawn by the hardware =) |
| |
Mason
Registered: Dec 2001
Posts: 459 |
Quote: I agree ;-)
But since I dont like (and dont see) the need to place absolute numbers for records such as this one I'd say 112 is correct (quite naturally) and 120 is correct WITH that explanation which can (and was) easily given within 5 lines of text. So being asked about max no of sprites on screen I'd say 112 because.... but there is a trick to have visually 120...
I remember Hungry Hero made the 101 sprites multiplexer in Showcase Bonanza... he also explains why you can do more than 101 20-lines sprites |
| |
Skate
Registered: Jul 2003
Posts: 490 |
Quote:
crossbow's opinions and theories about which sprite-record was valid or not was like the word from god back in the days.
@hcl: now you stole his role of being god? :)
since sprite crunching is a valid vic trick just like any other vic tricks and there are 144 individual sprites placed in 144 different sprite address blocks, sprite multiplexer record is 144.
about 112/120 sprites, everybody knows how to divide 312 by 21, right? :) but missing 3 lines doesn't mean we are unable to show more than 112 sprites, either. 112 or 120? since the answer is 144, try to beat the record by <17 pixels height sprites instead of discussing 112/120. :)
|
| |
WVL
Registered: Mar 2002
Posts: 885 |
This makes me wonder.. in Risen from Oblivion we have seen that on the c128, you can increase the frequency of the screen update by displaying less lines.
Question : Can we also _increase_ the number of displayable lines on C128 and in that way reach 120 real fully displayed sprites? |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
