http://www.fileden.com/files/2006/12/22/543510/vdpbug.PNG By the way, it's a common VDP bug that even Genecyst emulates. The reason is simple: every sprite and tile in the scrolls have a priority bit, either low or high, that determine where do they appear. However, this only works between planes, not between sprites. Sprites are ordered according to their index in the sprite list (first sprite gets over the rest). This means that a low priority sprite can get over a high priority sprite. And since all sprites are taken as a single plane, funny things can happen when that situation is mixed with high priority scroll, like in the screenshot I just linked. I was gonna make a demo ROM about this, but I'm too lazy =P So I'm gonna ask you: how would you exploit this bug? I came with an idea, but I would like to see with what would you come up. It's always nice to see new ways to make unusual stuff out of hardware =] If you can make it into a working ROM, better, but if you just want to detail how would it work, it's fine. So, who starts?
I'm thinking parallax scrolling of sorts could be abused by this, though I am not really clear on the situation so what I am saying could be garbage =P.
In some sense, maybe (as the game could have avoided it), but still, the game never renders the screen itself, it's the VDP, so somewhere it's the VDP fault. The docs never say anything about this weird behaviour.
Let's say this: you have a sprite with the priority set to low, and one with the priority set to high. Which would you expect to appear over the other? The fact here is that a low priority sprite appears over a high priority sprite, and this is never documented (or is but the possible issue is never mentioned). Unexpected, right? That's the bug. Of course, it doesn't seem much of a trouble at first, but when you also mix that with a scroll on high priority, really crazy things happen, like in the screenshot I mentioned. The scroll plane finishes up being shown, despite the fact there's a high priority sprite that should go over it. The result is a total mess. Now, stop blaming Sonic 1 for a weird behaviour of the VDP =/ EDIT: and just to make things clear, Sonic 1 never messes up with the priorities. It just turns out the green block makes it in the sprite list before the platform. Probably the game never checks for this, and I guess that's because normally it shouldn't =/ It probably just renders all objects in whatever order they appear to be, and that's it.
Like mentioned in another thread, this is not a bug, it is a feature. Some games are making use of this, Castlevania, for example: (that thing at the center is rotating smoothly and takes takes half of your health too)
Stop saying it isn't a bug, I don't think Sega wanted this side-effect. That a game exploits a bug doesn't make it stop being a bug.
It's not a bug. I'm pretty sure this was intentional, they just didn't bother fully documenting it (just like many other things).
AFAIK, this sprite/background relation feature is not an intentional feature. Also the same feature is present in PCE/TG-16, and something else IIRC... in all cases is undocumented, and its use is unintentional in most cases.
ok, then how do you think it should behave to be "correct"? - draw the sprite without priority bit in affected area? -> would break "sprites without priority bit are behind high priority layer" rule. - draw the sprite with a priority bit in affected area? -> would break "sprites are drawn in order they appear in the list" rule. - draw the low priority layer? -> also wrong, layer with priority bit must be on top. - draw backdrop color? -> duh. IMO current behavior is the correct one. It is also easier to implement in hardware, I guess.
It is nowhere indicated that VDP must act like this, it works like the docs say (follows the rules mentioned), so is not bugged in any way. If the software has problems with it it's the fault of the software, not VDP.
I'm all for calling it a [acronym="A peculiarity of behavior; oddity"]quirk[/acronym]. It might just be an unaccounted for procedure in how it draws things; in any case, it seems to be somewhat trivial to avoid on the software side, and lends itself towards interesting effects; these qualities make it hard to classify as either a full bug or a feature. I think the NES has a similar example (somewhat), where a sprite "under" the background will block out a sprite "over" it (SMB's pipes and bullet bills are a good example of this)
SMS used that too, incidentally -- Kega's option to disable the sprite limit makes note of that fact.
Stop saying that the software is wrong when it does nothing when rendering >_> Also this effect was almost never exploited by games (and I remark "almost", don't come and say some games did) and it isn't very useful unless you're extremely creative. And still the hardware is full of documented bugs, and that doesn't make them stop being bugs. Unless you come with one of the designers of the VDP and he/she claims this was done in purpose wanting that exact effect rather than being a hardware limitation, I'll still think it's a bug. PS: when looking for the info, I also found out this: Wait, what? How did I ignore this before? o_o;
That X coord 0 disabling all next sprites in the list on the lines The sprite occupies is a REALLY useful feature.
I don't think any of us can ever do that. I can see our ways of thinking are completely incompatible.
Well, now what if we just return back on-topic and start thinking in ways to exploit this bug? =D Castlevania's was a very good example.