Graphical issues in "Adventures of Batman and Robin"

[Former user]

Original [issue 180](https://code.google.com/p/genplus-gx/issues/detail?id=180) created by gora.patrick on 2011-08-14T23:26:59.000Z:

What steps will reproduce the problem? 1. First Boss fight against Two Face check this video as it shows the issues as well. does this happen on real hardware either? look pretty broken.

http://www.youtube.com/watch?v=mWKHpptxBhk\#t=4m44s

i mean the garbage right after the explosion. i can attach a savestate if needed.

[Former user]

Comment # 1 originally posted by gora.patrick on 2011-08-14T23:33:49.000Z:

here the savestate

[Former user]

Comment # 2 originally posted by ekeeke31 on 2011-08-15T09:20:17.000Z:

Thanks for the savestate. I tested the game on real hardware and there are no glitches.

It also seems that if you destroy the 4 cannons before Two Face appears, the glitchy line does not appear (only a few garbage pixels on the top right). Also, during the previous level, when Two Face successively drops bombs on you, this does not happen either so it's not related to the explosion effect but some unknown combination.

For the record, it also happens in Kega (and most likely every other emulators out there) so at first glance, I'd say it is a problem due to very precise VDP timings not accurately enough emulated.

If you can , try the game in Retrocopy which claims to have more accurate VDP than other emulators and tell me how it behaves.

[Former user]

Comment # 3 originally posted by ekeeke31 on 2011-08-15T10:27:36.000Z:

That was fast but I found it.

For technical record, the game uses 2-cell vertical scrolling mode (each 16-pixel block constituting the 320-pixel line can be scrolled independently) and change VSRAM (vertical scrolling RAM) values mid-screen and mid-line. It expect the writes to be taken in account on the current line, which indeed require accurate emulation of when these values are being used to render the line.

In most emulators, accuracy is limited to the line level (mid-screen changes are emulated fine) and Genesis Plus GX also emulates changes that are done during HBLANK on a line (since they technically happen before the line is rendered) but in this case, writes are performed during active display so they are postponed on the next line, which makes it look wrong.

I guess it's time to improve accuracy once again, it's actually the first game I found to use such trick mid-line ;-)

[Former user]

Comment # 4 originally posted by gora.patrick on 2011-08-15T10:33:55.000Z:

just tried in in retrocopy and that grey garbage line doesnt appear, yet the one on the upper right does appear. in retrocopy theres also a garbage line nearly all the time one the upper border of the plattform you are standing on, which looks like the one that appears on the upper right during the bossfight.

btw: when you get hit your charakter is supposed to flicker, but in retrocopy he just disappears which makes i quiet difficult... so retrocopy isnt that accurate at all i guess...

[Former user]

Comment # 5 originally posted by gora.patrick on 2011-08-15T10:35:34.000Z:

aahh...great you've found the fix! ;)

[Former user]

Comment # 6 originally posted by ekeeke31 on 2011-08-15T10:42:29.000Z:

Yes, Retrocopy have some emulation bugs and still do some things wrong.

But it is also more accurate in the way that it renders lines and process accesses to VDP at a finer granularity level. I try to limit myself to very specific cases (here for example, VSRAM writes when 2-cell vertical scroll mode is used) only when I found a game that needs it, otherwise it would affect emulation speed too much.

Anyway, this should be fixed in next version of Genesis Plus GX.

[Former user]

Comment # 7 originally posted by gora.patrick on 2011-08-15T10:46:07.000Z:

Ok, great! Hope the next version won't take to long to be released...;)

[Former user]

Comment # 8 originally posted by ekeeke31 on 2011-08-15T14:32:11.000Z:

Just to keep tracks of it or for anyone interested into technical stuff:

- the top-right glitch is due to a few VSRAM writes occuring during HBLANK that should be taken in account for the coming line. No emulators handle this correctly as they generally render the line at once, before hblank. Retrocopy doesn't but apparently latch VSRAM values before hblank, which is not correct in 2-cell vscroll mode.

-the full line glitch is due to Plane B nametable base address being changed during HBLANK. Only retrocopy handles this correctly as it renders line in a different way.

So i was wrong and the game does no need cycle accurate mid-line access, it's just additional VDP changes done during HBLANK that need to be emulated.

[Former user]

Comment # 9 originally posted by ekeeke31 on 2011-09-25T10:08:36.000Z: