| |
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? |
|
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Umm.. that last calculation should read "104+16" ofcourse. |
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
AFAIK the Crest demo uses a technique that reduces the height of a sprite to 17 pixels and thus achieves the higher amount of sprites. Not sure if it has to do with the doubling of sprites you described. |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Ice Cream Castle does 120 and as far as i know that's the upper limit without using something to shorten the sprites. Krestage does 144 with tricks to make the sprites 17 pixels high. |
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Alright, thanks for the info guys. Looks like I was on the right track with my calculations then. |
| |
Stryyker
Registered: Dec 2001
Posts: 465 |
If you're curious and want to try the sprite shrinking, it's anti sprite streteching which the VIC Article details (to the cycle). Just reverse the writes I think. |
| |
Ninja
Registered: Jan 2002
Posts: 404 |
stryyker: Not exactly. If the store instruction which sets the $D017-bits is exactly at a certain cycle, the sprite-data-pointer is messed up. Crossbow has made some effort to create a table, which shows how it gets confused (anyone verifyed this table?). It is included in the world-record-multiplexer in "Krestage 1" (press RUN/STOP). |
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Wow! Thanks for letting me know about "Krestage". There's a very good explanation on the whole sprite multiplexer issue, with 112/120 sprites etc.
Btw. I hadn't seen that demo before. What a brilliant piece of absolute hardcore coding! That text-mode, I was just blown away! I thought I had turned on my Amiga by mistake! :) I just don't understand how you can get that half-pixel X-interlace thing going. Crossbow is unbelivable!
|
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
Nice bit of code, but a multiplexer? I don't think it can be classed as one. Standard y movement doesn't need a multiplexer sort to decide which sprites are on which raster, just have a routine that draws 8 sprites at a time at various positions down the screen then move the appropriate x,y,colour and defininition list round in a cyclic buffer and its all done, no sorting needed, imho can't class it as a multiplexer without the sort :P |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Ah, the gameprogrammer's perspective :)
But this would imply the boss enemy routines in Turrican or Armalyte aren't multiplexers either? (because they don't need to be sorted)
I'd guess the beauty in demo-multiplexers is especially the error-free display, in addition to large amount of sprites. This is something that game-multiplexers (general, sort-based approach) will always fail in, with sufficiently tight sprite formations
|
| |
Warbaby
Account closed
Registered: Mar 2002
Posts: 60 |
In my oppinion, there are two cathegories of multiplexers:
standard multiplexers
sorting multiplexers
|
| |
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: 1153 |
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: 1153 |
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: 30 |
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: 1153 |
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: 30 |
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 ;) |
| |
CyberBrain
Administrator
Posts: 392 |
I thought multiplexors was >8 sprites that all moves past eachother in y.
Maybe a little bad explained, but like you can make a simple sprite routine that moves 8 sprites up/down in a sinus movement, an example of what i thought was a multiplexor is >8 sprites moving up/down in a sinus movement.
(...and moving them in x makes it look sweet :) )
Are you sure multiplexors are just displaying the same sprite more than once in a frame?
(would be nice with a library of all these words on the net) |
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
Sorry, brain lost focus in my last post, I meant "moving more than 8 sprites (sorting) in an intelligent manner". Having just read my last post again it's utter rambling nonsense :) I'd just woken up, thats my excuse. Still not properly awake so this post won't make sense either haw |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
JCB wrote:
"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 ;)"
i dont think that it has anything to do with opinions. "multiplexing" is a term which has a certain meaning of using something multiple times. for example, some older processor multiplex their adress lines to allow 16 or 24 bit adresses over an 8 bit adress bus. now adapting this term for sprites would simply mean that you use a single sprite multiple times. multiplexing does not implicate any kind of "intelligence", in fact all the hardware multiplexing is done without intelligence at all. just very basic logic.
|
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
I know where the word multiplexing comes from and it in fact originally has nothing to do with computers ;) And I still believe that I am right to have an opinion on its use in the realms of c64 sprites. Someone gave the use of more than 8 sprites displayed using a SORTING method the term multiplexing, the fact that others then decided to encompass just more than 8 sprites on screen doesn't make it correct. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
honestly, this is the first time ever i hear that multiplexers should include sorting routines. no coder i ever met used that term in that way, and thinking about it's meaning on other subjects it wouldn't make sense to implicate sorting.
|
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Ah.. I could imagine JCB & MT having a quarrel about Turrican boss-display routine:
JCB: That routine isn't a multiplexer, 'cos it isn't sorting anything
MT: It doesn't *need* to sort, the order is fixed
JCB: So, you even admit it yourself, it isn't a multiplexer
MT: WTF??
:) |
| |
Dr. Jay
Account closed
Registered: Jan 2003
Posts: 32 |
Silly argument.
It's simple, really. Multi - latin root, i.e. "many".
Plex - from latin plico - fold or wrap, i.e. comPLICated literally means "many things together".
Multiplex - basically folding or wrapping the display so the sprites appear multiple times.
Beyond that is really opinion.
JCB, you like sorted sprites? Fine. But blue is blue and multiplexed is multiplexed. If you're worried about something being sorted, then worry about multiplexed sprites with a sort routine. There is NO implication of "sort" in the word multiplex, anywhere. Now whenever you hold your own demo competition, you are certainly free to say that any multiplexed submissions must have proof of an intelligent sort.
|
| |
CyberBrain
Administrator
Posts: 392 |
Erhm... i don't know what's right or wrong... But the question is not the origin of the word, or in which historical context it can be placed. It's about how it's used in the C64 Scene.
I know that the only places i've seen the use of the word "multiplexer", is in demos with those sort routines (where >8 sprites moves around between eachother). That's why i got pretty puzzeled by grahams definition.
Not that i say Graham is wrong (coz' i'm not at all sure) but i've just never seen "multiplexer" used for anything else than the sorting-thing. |
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
Well it IS a silly argument and I was just trying to point out that IN MY OPINION it isn't a multiplexer, the fact that when I started coding c64 more than 8 sprites was just known as a sprite split and one that would allow you to move the Y positions and sort them was known as a multiplexer. Go back, check your scene history, try to find me a demo that claims to use a multiplexer when the 1st games/demos started using them and it WILL sort the sprites, nobody USED to claim having more than 8 sprites on screen was anything of the sort. I'm sorry if you guys these days have to insist on using this word when it never used to be so all encompasing, I'm just sticking to what I SEE as being a multiplexor.
Cadaver, I don't care if MT would think its a multiplexor, he didn't invent it, so if he wants to call it that then fine, I'll say it one more time IN MY OPINION it isnt, you can do all the RECORD multiplexer demos you want and sit waiting for $d012 to equal something then move your sprites Y pos but it won't change my mind.
Dr. Jay, same goes for you blue is blue, wow cool argument. I'm not trying to piss people off for the sake of it but I've always know the word to mean one thing, I also (Graham) know lots of coders who would disagree with you and agree with me.
ps one LAST time IN MY OPINION. you guys ganging up on my won't change my mind ;) you're not the be all and end all of c64 coding, you didn't invent any of this I'm just pissed that I seem to be unable to have an opinion on something and being told by people what multiplexer means in latin so that makes them right. wtf ?!?
You have your opinion, I'll have mine. ok?
Get the message now, IN MY OPINION ;) |
| |
CyberBrain
Administrator
Posts: 392 |
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? |
| |
CyberBrain
Administrator
Posts: 392 |
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?) |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
What personally interests me in this discussion is that where the line is drawn; I took the turrican example because there sorting could be used (for uniformity of engine code, if nothing else, which I personally like btw. being a lame game-coder :) ), or not be used, but it doesn't make any difference in the visible output
Then another example: 16 sprites rotating in circular fashion. Instead of full sort one could divide them into a "upper half" and "lower half" of 8 sprites each, and load the lower half register values in a raster interrupt at the middle point. This would also be visually indistinguishable from something achieved with a full sort, so is it multiplexing or not? |
| |
JCB
Account closed
Registered: Jun 2002
Posts: 241 |
I've not looked at turrican recently but I would think that like armalayte (and I may be wrong here too) that it uses a non-realtime sorted set of sprites for the big ships AND a sort for any other sprites, your ship, weapons etc at the same time. Even if it doesn't the games still use a sorting method for other parts of the game.
The 16 sprites rotating by just using an upper and lower set could still be seen as a sort and the definition does indeed become blurry here BUT I'd expect someone who did it that way to not claim it to be a multiplexer, it's the "freedom" of movement that is important to me, like those 16 rotating sprites should be able to change patterns etc. I've done demos where some sprites were just split and the others were used so there were about 20 sprites all moving over each other, no sorting and I never claimed it was a multiplexer because if I had at the time people would've asked me where I got my drugs from ;)
I just think the definition has changed from when I was doing demos/games and that is why I hold this opinion.
It's like how some people will saying an OS or a processor is multitasking because if taken litteraly the "multi" and "tasking" could just mean it runs more than 1 task at a time BUT try arguing the point with some tech guy and see what they say about what it really means. |
| |
Dr. Jay
Account closed
Registered: Jan 2003
Posts: 32 |
Great points and interesting discussion. I think one point certain is true ... where does one draw the line? In this case, it seems that the sorting is popular but there are plenty of gray areas. As for coding/being a coder, I could possibly be the WORST C=64 coder that ever existed, so I definitely won't add hype to my opinion over my virtue as a demo writer -- I was just interested in the conversation. Thanks for all of the clarifications and I'll try not to stick my nose where it doesn't belong. :)
Dr. Jay
|
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
(everything afaik)
From Dan's evidence, Armalyte:
Spr1 - player ship
Spr2 - 2nd player ship / satellite
Spr3-8 - enemies+bullets etc. Sorted and multiplexed with one and same routine throughout, incl. bossfights
Turrican, just reverse-engineered a few minutes ago :)
Spr1-3 - player sprite and overlay
Spr4-8 - enemies+bullets sorted and multiplexed OR
boss displayed with separate high-performance routine; no sorting used then
In some cases (was it the big fish?) overlay disappears and one more sprite is used for the enemy.
Anyway, I guess this needs no further argument. Sorting of course rules :) But now as you helpfully pointed, we may continue the discussion about the difference of Amiga & PC multitasking :)) |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
[looks around, wonders if it's safe but goes for it anyway =-]
i've always understood that a multiplex involved the physical sprites swapping jobs, in other words something like the Turrican bosses are "zone splits" or whatever you'd like to call them whilst the ingame stuff is multiplexed. But at the same time, there are pre-sorted multiplex routines in demos (and one or two rare games) where the possible situations have been worked out in advance and only the display part of the code is there. The sprites still swap jobs to make the display as efficient as possible but the sort was done during the setup or, in some cases, even before the code was crunched.
i've done both, Contraflow was sorted whilst Spectral was and they use similar sprite handling code. It also shows how shyte the sort-of-Shell-Metzner sort routine on Contraflow was 'cos 16 was the max it could handle! =-) |
| |
DanPhillips
Registered: Jan 2003
Posts: 30 |
I think it was Andrew Braybrook who publicly coined the
phrase Multiplexor...and it definately involved sorting.
For me a Mutiplexor has always included sorting, without
it they aren't much use for "general" game useage.
All my dev disks were called Plexor1-???
Splitting sprites is the term we used for just a reposition
further down the screen. In Deadlock the main guy used
that technique for his head+legs while a normal plexor
did it's stuff in the background.
Multiplexor = Splitting sprites + sort IMNSHO.
Anyway...After deciding to mess with the Armalyte code again
I'm having trouble getting multiple files linked together
with Tass, Tslink doesn't seem to have a docs/help anyone
got an example ?
Cheers
Dan
Lead Pro..Arma...thing.
|
| |
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: 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: 675 |
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: 11114 |
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: 886 |
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? |
| |
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 :) |
| |
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. |
| |
HCL
Registered: Feb 2003
Posts: 716 |
@Skate: 112 or 120 *does* matter since we have the same situation whatever we do. if we count 120 sprites instead of 112, we could also have 152 instead of 144. If you count displaying one single rasterline of a sprite as valid, then we're into deep waters. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: 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.
True, but that was easier to write than saying that: "when fetching the 3rd byte into the shift register and that offset is 62, then we're done". :)
|
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: @Skate: 112 or 120 *does* matter since we have the same situation whatever we do. if we count 120 sprites instead of 112, we could also have 152 instead of 144. If you count displaying one single rasterline of a sprite as valid, then we're into deep waters.
Imo, any part of a sprite (see my definition of a sprite) visible should be counted.
Also, since showing just a bit of a sprite will still eat cycles for the whole sprite it's just fair imo. |
| |
HCL
Registered: Feb 2003
Posts: 716 |
Ok, then expect HCL breaking some world records soon with no more sprites than before, but just counting them more "cleverly".
No, seriously. The problem here is also that.. If you count a small part of a sprite at the bottom of the screen, that sprite will also be displayed at the top of the next screen. You can not count the same sprite twice just because it occupies two different screens, can you!? *THAT* i would definitely call a cheat.
..and that's also why i question Crossbows 120 sprites. Either he only has 112 sprites on each screen (i think so), or he counts the same sprite twice here and there -> cheat. |
| |
Skate
Registered: Jul 2003
Posts: 490 |
@HCL: Ok, 120 sprites can be considered as a cheat in a way but since 18*17 = 306 < 312 and Crossbow didn't claim more than 144 sprites, what i'm really saying is "forget about 112/120, that's sooo yesterday".
Probably Crossbow wanted to break the multiplexer record so much. He first tried a cheaper method for 120 sprites but later he thought that was not enough (because he knew it was kinda cheating), he digged a better trick and figured out how to crunch sprites. Maybe he could have made more than 144 sprites just like more than 112 sprites but he didn't do it because this time it was %100 legal trick.
Of course these are my assumptions. But my point still remains. 112/120 sprite discussion is pointless. Let's take a bob record for instance. If someone makes a 128 16x16 bobs, I can easily break his record with 512 2x2 bobs. But 16x16 != 2x2 right? Just like "completely visible" != "partially visible". They are both different records. We all know that it's not always easy to use all 312 raster lines with music and other stuff. So, I believe "partially visible" makes sense in a way, too.
HCL, you are always welcome with >144 sprites even if some of them are not completely visible. I'm sure you will get the credit for the improvement. But of course Crossbow will remain as the inventor of the trick. That's how it works and that's also why I never gave it a real shot. :) |
| |
HCL
Registered: Feb 2003
Posts: 716 |
Ok, don't worry. I'll not do more than 144 sprites since my whole point in this is that more than 144 sprites would also be a cheat (unless you manage to shrink them more). |
| |
Skate
Registered: Jul 2003
Posts: 490 |
@HCL: You only mention sprite clipping. What about $d010 usage? In Krestage, sprites map over >256 pixels width area. Without using $d010, we will have many cycles free for additional tricks, probably we can find a way to crunch more even if not entirely linear. So, would it count if I make more than 144 sprites in 256 pixels wide area?
It's always hard to compare records. :) |
| |
HCL
Registered: Feb 2003
Posts: 716 |
@Skate: You don't seem to find this topic relevant. I got that now, you don't need to make it more clear. I am questioning how to count sprites in delicate situations, bob-issues and other stuff is out of topic, ok? |
| |
Skate
Registered: Jul 2003
Posts: 490 |
I've started with "@HCL:" but continued to write my message for public reading in the middle, sorry about that. I was not trying to explain only to you. |
| |
algorithm
Registered: May 2002
Posts: 702 |
The sprites that appear on the bottom as well as the top would be in my opinion valid as an extra 8 sprites even though it is a "cheat" but still sprites none the less. So would the sprite crunching multiplexer displaying 144 or so sprites as each block is a full sprite even when using the sprite crunching trick. What is of course not valid are non sprites claiming to be sprites or segments of small images in a whole sprite block. Sprite multiplexing is so 90's however. (meaning the swirling stuff etc) |
