Graphical issues in "Adventures of Batman and Robin"

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by gora.pat...@gmail.com on 14 Aug 2011 at 11:26

[GoogleCodeExporter]

here the savestate

Original comment by gora.pat...@gmail.com on 14 Aug 2011 at 11:33

Attachments:

• save.rar

[GoogleCodeExporter]

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.

Original comment by ekeeke31@gmail.com on 15 Aug 2011 at 9:20

• Changed state: Accepted
• Added labels: Type-Defect, Priority-Medium, CoreEmulation

[GoogleCodeExporter]

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 ;-) 

Original comment by ekeeke31@gmail.com on 15 Aug 2011 at 10:27

• Changed state: Started

[GoogleCodeExporter]

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...

Original comment by gora.pat...@gmail.com on 15 Aug 2011 at 10:33

[GoogleCodeExporter]

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

Original comment by gora.pat...@gmail.com on 15 Aug 2011 at 10:35

[GoogleCodeExporter]

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.

Original comment by ekeeke31@gmail.com on 15 Aug 2011 at 10:42

[GoogleCodeExporter]

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

Original comment by gora.pat...@gmail.com on 15 Aug 2011 at 10:46

[GoogleCodeExporter]

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.

Original comment by ekeeke31@gmail.com on 15 Aug 2011 at 2:32

[GoogleCodeExporter]

Original comment by ekeeke31@gmail.com on 25 Sep 2011 at 10:08

• Changed state: Verified