| |
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....
|
| |
HCL
Registered: Feb 2003
Posts: 727 |
@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: 2014 |
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: 2014 |
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: 727 |
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: 494 |
@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: 727 |
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: 494 |
@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: 727 |
@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: 494 |
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: 705 |
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) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
