don't click here

VDP bug exploiting

Discussion in 'Technical Discussion' started by Sik, Aug 24, 2008.

  1. Sik

    Sik

    Sik is pronounced as "seek", not as "sick". Tech Member
    6,718
    1
    0
    being an asshole =P
    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?
     
  2. Flygon

    Flygon

    Member
    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.
     
  3. Uhh, it's a bug in the game, not in the VDP itstelf >_>
     
  4. Sik

    Sik

    Sik is pronounced as "seek", not as "sick". Tech Member
    6,718
    1
    0
    being an asshole =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.
     
  5. Well, the GAME is the thing that screws with the priorities, right?
     
  6. Sik

    Sik

    Sik is pronounced as "seek", not as "sick". Tech Member
    6,718
    1
    0
    being an asshole =P
    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.
     
  7. Uberham

    Uberham

    King Of Oblivion Member
    So does this go some way to explaining why sonic can "duck" through those blocks in MZ2?
     
  8. notaz

    notaz

    Tech Member
    32
    0
    6
    Like mentioned in another thread, this is not a bug, it is a feature.
    Some games are making use of this, Castlevania, for example:

    [​IMG]
    (that thing at the center is rotating smoothly and takes takes half of your health too)
     
  9. Sik

    Sik

    Sik is pronounced as "seek", not as "sick". Tech Member
    6,718
    1
    0
    being an asshole =P
    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.
     
  10. notaz

    notaz

    Tech Member
    32
    0
    6
    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).
     
  11. TmEE

    TmEE

    Master of OPL3-SA2/3 Tech Member
    1,726
    2
    18
    Estonia, Rapla City
    T-04YBSC-A !
    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.
     
  12. notaz

    notaz

    Tech Member
    32
    0
    6
    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.
     
  13. Sik

    Sik

    Sik is pronounced as "seek", not as "sick". Tech Member
    6,718
    1
    0
    being an asshole =P
    Order sprites first by priority, then by list index, then the plane priority rules =P
     
  14. notaz

    notaz

    Tech Member
    32
    0
    6
    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.
     
  15. Xkeeper

    Xkeeper

    lgkdfvlbjepasvdjzcvpaaaaaaaaaaaaaaaaaaaaaaaa Researcher
    1,509
    10
    18
    the bone zone
    current-project-fart
    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)
     
  16. muteKi

    muteKi

    Fuck it Member
    7,845
    131
    43
    SMS used that too, incidentally -- Kega's option to disable the sprite limit makes note of that fact.
     
  17. Sik

    Sik

    Sik is pronounced as "seek", not as "sick". Tech Member
    6,718
    1
    0
    being an asshole =P
    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;
     
  18. TmEE

    TmEE

    Master of OPL3-SA2/3 Tech Member
    1,726
    2
    18
    Estonia, Rapla City
    T-04YBSC-A !
    That X coord 0 disabling all next sprites in the list on the lines The sprite occupies is a REALLY useful feature.
     
  19. notaz

    notaz

    Tech Member
    32
    0
    6
    I don't think any of us can ever do that.

    I can see our ways of thinking are completely incompatible.
     
  20. Sik

    Sik

    Sik is pronounced as "seek", not as "sick". Tech Member
    6,718
    1
    0
    being an asshole =P
    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.