JinxDojo / genplus-gx

Automatically exported from code.google.com/p/genplus-gx
Other
0 stars 0 forks source link

First scene is missing in Switch/Panic intro #313

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.Load any version of the game
2.Wait for the SEGA logo and the intro to start

What is the expected output? What do you see instead?
Following the SEGA logo, the intro music starts with a black screen before 
anything shows up. There should be a first scene with some guy flying a plane.

What version of the emulator are you using (official, SVN revision,...)?
I think this has been happening since Mega CD support was added (I just forgot 
about it until I played it again using real hardware).

Please provide any additional information below (Emulator settings, Console
setting,...)
Any settings, to my knowledge.

Original issue reported on code.google.com by iceknigh...@gmail.com on 17 Dec 2012 at 12:18

GoogleCodeExporter commented 9 years ago
Weird, the exact same thing happens in Kega actually (in Gens, it simply hangs 
at Sega logo, even with perfect sync). There is indeed a black (well, more grey 
with some strange black marks) screen before the intro starts then it starts 
directly with the guy on motorcycle.

I don't have tested a full image with CD tracks so I cannot say anything about 
music but could you make a video recording of how real hardware behaves ?

Original comment by ekeeke31@gmail.com on 17 Dec 2012 at 7:42

GoogleCodeExporter commented 9 years ago
Sure, here's a video of it.

Original comment by iceknigh...@gmail.com on 17 Dec 2012 at 8:45

Attachments:

GoogleCodeExporter commented 9 years ago
Thanks, i will have a look at it when i got some time.

Original comment by ekeeke31@gmail.com on 17 Dec 2012 at 9:31

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Hmm, i could not figure out what is wrong, the game engine does not seem to 
miss anything or to do anything wrong... although i am not really confident 
about that, there is still the possibility the isos available on the internet 
are corrupted, did you burn yours to test on real hardware or dumped an image 
from a real disc ?

Original comment by ekeeke31@gmail.com on 2 Jan 2013 at 4:02

GoogleCodeExporter commented 9 years ago
I got the US version from the internet, and ripped the Japanese version from 
the original disc I own. Both act the same in the emu and real hardware when 
burned...

Could this be related with subchannel reading, perhaps?

Original comment by iceknigh...@gmail.com on 2 Jan 2013 at 6:10

GoogleCodeExporter commented 9 years ago
I doubt it, Kega Fusion emulates subcodes but has the same issue.

Seems more like a timing issue (missing or delayed event like an interrupt, 
etc) which leads to some communication mistakes between Main & Sub CPUs 
(Word-RAM handshake, etc) but honestly, at that state, i haven't found anything

Original comment by ekeeke31@gmail.com on 4 Jan 2013 at 9:44

GoogleCodeExporter commented 9 years ago
Some progress on this one: I figured it was caused by CRAM (Color RAM) being 
filled with 000 instead of the correct palette values, at least for the first 
frames of the intro (during when the airplane is normally showed).

I noticed that if I hack the emulator to ignore CRAM writes if data=000, I got 
the missing scene displayed (although the color palette is wrong off course).

Original comment by ekeeke31@gmail.com on 6 Apr 2013 at 6:21

GoogleCodeExporter commented 9 years ago

Original comment by ekeeke31@gmail.com on 6 Apr 2013 at 6:45

GoogleCodeExporter commented 9 years ago
Damn, this one was pretty hard to debug but I finally figured it.

It actually needs drive SEEK time to be emulated correctly (currently, the 
emulator only emulated drive access and seek latency when a PLAY command was 
received, but this game also relies on latency when a SEEK command is received).

Precisely, when the intro scene program/data is loaded from disc to RAM and is 
ready to be displayed by MAIN-CPU, SUB-CPU will:

1) seek the audio track to be played during intro

2) when the audio track is reached by the drive, send a command to MAIN-CPU 
side so it starts processing the video scenes

3) start audio track playback

The thing is that between 1) and 2),  MAIN-CPU is supposed to slowly increase 
Color RAM values from black to the desired color palette required by the video 
scene (some kind of fade in effect) so, if 2) happens too fast, Color palette 
do not have the time to be properly setup and all pixels appear in black or 
dark grey. Further scenes do not have the issue because color palette is later 
adjusted for specific sequences.

Original comment by ekeeke31@gmail.com on 28 Apr 2013 at 4:38

GoogleCodeExporter commented 9 years ago
Fixed in r774

Original comment by ekeeke31@gmail.com on 28 Apr 2013 at 6:38

GoogleCodeExporter commented 9 years ago
Wow, once more, great work! Makes you wonder why on earth would they purposely 
make it so the palette stops fading in as soon as the track starts playing.

Out of curiosity, what would happen if the drive took to long to find the 
track? Do the colors stay at the correct brightness or do they keep getting 
brighter?

Original comment by iceknigh...@gmail.com on 2 May 2013 at 9:59

GoogleCodeExporter commented 9 years ago
it's not really done on purpose, just the way the intro is sequenced and synced 
to audio, it just appears that the last step before the audio starts was used 
to setup the palette during the wait.

and no, the code only updates the palette up to a programmed limit

Original comment by ekeeke31@gmail.com on 3 May 2013 at 7:08