| |
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....
|
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
Cadaver, Armalyte and Turrican, I suppose it depends if they're done with the normal game sorting routine or have a special routine just to display them.
Hoth, I'm still not convinced, if you say a multiplexer doesn't need a sort and in that case would be called "standard" then in theory something like ESCOS style routines and full screen vertical sprite message scrollers etc could be classed as multiplexers. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
I remember, at least the boss enemy routines in Turrican didn't seem to access the "sort-order" table at all. (correct me if I'm wrong) And for as high errorfree-ness, especially in Armalyte, the raster interrupt to display the sprites must be specifically optimized (unrolled, no X-coord changes at all) |
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
I was in the Thalamus offices one day and saw a "demo" version of Armalyte b4 it had all the attack waves etc edited to stop any overlapping sprites, glitch glitch nasty :P I think they must have spent 50% of the time writing that game just changing the sprite movement to get it glitch free.. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Perfection has its price... I'm all for letting sprites glitch a bit if playability overall doesn't suffer. But I'm sure some consider MW1-3 abysmally lame because of that :) |
| |
DanPhillips
Registered: Jan 2003
Posts: 31 |
Quote: Perfection has its price... I'm all for letting sprites glitch a bit if playability overall doesn't suffer. But I'm sure some consider MW1-3 abysmally lame because of that :)
Just catching up :-)
We automated the process...eventually.
The editor gave warnings when more than 6 sprites(we
reserved 2 for the players to avoid priority flicker) were
getting close. And I changed the bullet routines to
detect if they were going to cause a flicker (flak type
effect which makes them blow up in mid air and change
direction).
We used a bucket stack sort...all the time even for the
motherships (I published it on the Scene section of the
Lemon forums)
Might have been nice to custom write the display for the
motherships...maybe next time :-)
If truth be told...50% of my time was spent playing and mapping
Dungeon Master on the ST and Lazer Squad + Wasteland on the 64 :-)
Cheers
Dan
Lead Programmer Armalyte
|
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
hehe tut tut |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Hehe, up to now I thought Armalyte used some hyper-optimized, unrolled multiplexer interrupt for the bosses, because there was never any kind of error.. Only now I realize there wasn't enough sprites to cause errors at all! :)
|
| |
DanPhillips
Registered: Jan 2003
Posts: 31 |
Quote: Hehe, up to now I thought Armalyte used some hyper-optimized, unrolled multiplexer interrupt for the bosses, because there was never any kind of error.. Only now I realize there wasn't enough sprites to cause errors at all! :)
The bosses used 16 sprites max in total, plus 4 for enemy
bullets.
It was the skill with which they were used that allways
impressed me :-)
Dan
Lead Programmer Arma...thing. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
JCB, sprite multiplexing simply means that you use a sprite more than once per frame, so escos is indeed a multiplexer, same as a lot of other stuff.
|
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
Quote: JCB, sprite multiplexing simply means that you use a sprite more than once per frame, so escos is indeed a multiplexer, same as a lot of other stuff.
hmm to me a multiplexer has to be usable for moving the sprite more than once per frame in an "intelligent" manner. Still, thats just my opinion ;) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
