Closed GoogleCodeExporter closed 8 years ago
Well, that's weird, it's not really "drawn by half", it seems more like that
the screen is drawn entirely but "moving" instead of scrolling/repeating behind
like it should. This is probably a stupid mistake with the VDP rendering, I'm
just curious that it was only noticed there, must be some edge case.
Can I have a save state just before the end sequence starts ?
Original comment by ekeeke31@gmail.com
on 8 Apr 2013 at 8:47
Okay, i replay this game and send new save state before the end sequence. ;)
Original comment by Metal.So...@yandex.ru
on 8 Apr 2013 at 9:13
Here two save states. First - at death a final boss, and second before final
fight.
Original comment by Metal.So...@yandex.ru
on 8 Apr 2013 at 11:40
Attachments:
Thank you for finishing this game twice in a row, since it is not really that
easy or enjoyable...
I will look at the savestates when i got the time for it but i can already say
that it seems to be an error with the virtual screen size (background planes):
it is setup to 512x512 pixels but the game seems to assume it is only 256x256
(or 256x512) so it scrolls incorrectly. I need to figure if this is an error
when setting the screen dimension (missed VDP register write) or when filling
the screen data (missed VRAM writes).
Original comment by ekeeke31@gmail.com
on 9 Apr 2013 at 11:01
More on that: before the end sequence starts, the game deliberately sets the
virtual screen size to 512x256 then to 512x512, in the same function, but only
512x256 is filled with data, hence the scrolling issue.
The problem is not in my rendering code as far as i can tell but either that
the screen size is incorrect or VRAM writes are missing. However, I could not
figure what the right size should be from debugging the code and there is
nothing odd with the code flow.
Would it be too much to ask for the same savestates but with Regen this time,
so i could compare code flows ? Thanks in advance.
Original comment by ekeeke31@gmail.com
on 10 Apr 2013 at 10:53
[deleted comment]
Ready, regen not have this bug.
I seen same problem in Kega Fusion few years ago, and think, it still there.
Original comment by Metal.So...@yandex.ru
on 10 Apr 2013 at 5:16
Attachments:
Thank you.
But did you just finished the game in one hour ? Do you use cheat codes ?
Original comment by ekeeke31@gmail.com
on 10 Apr 2013 at 5:22
No, i not use cheat codes. :)
I have blood sword, initially weapon has 0 hit points, if use scrolls which
increase damage by 1 point, and weapon will be no longer cursed. All monsters
dies just in few hits, even final boss have no chances.
Original comment by Metal.So...@yandex.ru
on 10 Apr 2013 at 5:58
[deleted comment]
Ok, I was able to find what is wrong: the Regen savestate confirmed the virtual
screen size was the same in both emus and that 512x512 pixels was correct: for
the record, the game actually only fills the top of the screen using normal
VRAM writes then uses VRAM Copy DMA to fill the rest (so that lower area is
identical to upper area).
The problem is that the game uses an undocumented code to trigger the VRAM Copy
operation (110001 instead of 110000), which Genesis Plus GX (and apparently
Kega as well) interprets as an invalid code => no data is written to VRAM
during DMA
Regen does not seem to check code validity when doing DMA Copy so has no issue
with this game.
Now, can you confirm this does not happen on real hardware ? I can't seem to be
able to find any video capture from real hardware for this game.
If it is supposed to display fine, it means that both code values 110001 or
110000 are both correct for VRAM Copy DMA operation. It would need to be
checked to be sure, maybe there are subtile differences that can not be seen
here.
Original comment by ekeeke31@gmail.com
on 10 Apr 2013 at 7:40
On my real Mega Drive 2, end sequence was fine.
Original comment by Metal.So...@yandex.ru
on 10 Apr 2013 at 7:50
OK, fixed in r768
Original comment by ekeeke31@gmail.com
on 19 Apr 2013 at 2:36
Original issue reported on code.google.com by
Metal.So...@yandex.ru
on 8 Apr 2013 at 2:33Attachments: