| |
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.... |
| |
Graham Account closed
Registered: Dec 2002 Posts: 990 |
Quote: By the way.. talking about sprites.. A D.Y.S.P. (="Different Y Sprite Position") requires rasters to be behind the sprites, right? (i mean, just some sprites with different y positions isn't a DYSP is it?)
DYSP = different y sideborder positions (with sprites)... so DYSP requires sideborder, not rasterbars... the first DYSP routine ever (photon dysp by triangle) didnt have rasterbars behind them.
|
| |
Graham Account closed
Registered: Dec 2002 Posts: 990 |
now it get's really confusing since "splitting sprites" would mean something entirely different to me. i would understand something like changing x-pos during sprite display or similar.
|
| |
hollowman
Registered: Dec 2001 Posts: 474 |
Quote: Yeah... I think that, in the old days, if you claimed you had done a 32 sprite multiplexer, and it turned out that all you did was showing 32 sprites on the screen at once, people would consider you pretty lame.. :) Have anyone got an example of a demo where the word multiplexer isn't used for the sorting thing?
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 |
| |
T.M.R Account closed
Registered: Dec 2001 Posts: 749 |
[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?! =-) |
| |
DanPhillips
Registered: Jan 2003 Posts: 31 |
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: 727 |
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: 677 |
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... |
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |