Chrono Cross on E}I{ 0.981

[spajdr]

Since E}I{ you wanted report about CC,so here it is.If i dont have enabled fix for CC its fine until im in menu if i click on status i get black screen :

[spajdr]

if i enable fix for CC cursor keys stops respond at here

[spajdr]

i tried to save a game without enabled fix for CC then loaded a game with enabled fix for CC it was same,in character menu cursor keys didnt respond.

[E}I{]

Try to save without fix when you got black screen and load immediately. It probably will work, because my CC savestate works for sure
Sorry for bothering with this problem, but I still cann't find not screwed up version of CC.

[spajdr]

well it work when save and load on status screen.Can you fix it without stupid loading a saved game ?

[E}I{]

Don't know. This actually can require extending of GPU interface, including scanline detection, or GPUreadstatus_async().
Do CC actually load something before showing black screen? If i only had a savestate done slightly before the moment it hangs up....

[Lewpy]

E}I{: my "hack" for ChronoCross is as follows

DLLEXPORT unsigned long PSECALLBACK GPUreadStatus(void)
{
  // Clear down any unknown bits
  lGPUstatusRet &= ~GPUSTATUS_UNKNOWN;

  StatusRequestsThisFrame++;

  // A hack - fixes Chrono Cross status display - without it, the game hangs
  if ((StatusRequestsThisFrame > 1000) && (PSXDisplay.Interlaced))
    lGPUstatusRet ^= 0x80000000;

  return lGPUstatusRet;
}

It does the job, but it may not fit well in to your plugin.

[E}I{]

Well, i tried many approaches, but never tried to count that high thanks anyway.

[E}I{]

I actually trying to change this bit each frame to make timings right, but "and" it to zero in first read after UpdateLace(). Also i reset it to 0=even at screen mode change. This avoids hangup in other interlaced games, but not in CC. IMO weird hacks like yours don't affect vsynching only because most games keep their internal track of odd/even flag, and only have to synchronize it with real at mode change. And if they cannot, they hang up.

[Lewpy]

E}I{: the more I think about it, the more I like the idea of the main emulator signalling to the GPU when VSync starts and when it finishes (i.e. identifying the vsync blank period).
Not only may it resolve vsync/timing hangs in certain games (such as CC), but it may also make the display of VRAM more correct in h/w GPUs. For example: a problem case at the moment is when a game switches display position (perhaps at start of vblank?) and then renders more primitives to the area of VRAM which is now being displayed (or rather, not being displayed yet, because the system is in vblank). Currently, the GPU can not tell that this extra rendering is within the vblank period, and it is a headache to correctly handle this.

I suggest promoting a new GPU export, which can be used by the emulator to signal the start of, and end of, VSync. If the GPU supports this export, then the main emu should not call gpuUpdatelace() at all, but use the new interface. Thoughts?

[Rumbah]

Hi!

I did two savestates. one right after pressing the button to go to the status menu and one short before the hang and the black screen (I think the second one is too late, because when I load it, it shows the status correctly).

Here they are: http://jan.humbracht.bei.t-online.de/sstates.rar

Hope it helps.

Rumbah

PS: Will there be framebuffer support in the future so that i can see all the effects in CC?

[E}I{]

Originally posted by Lewpy

Not only may it resolve vsync/timing hangs in certain games (such as CC), but it may also make the display of VRAM more correct in h/w GPUs. For example: a problem case at the moment is when a game switches display position (perhaps at start of vblank?) and then renders more primitives to the area of VRAM which is now being displayed (or rather, not being displayed yet, because the system is in vblank). Currently, the GPU can not tell that this extra rendering is within the vblank period, and it is a headache to correctly handle this.

This problem also exist for soft plugins if they don't draw directly in display memory, like my plugin And FF7-FF9 problems really can be annoying in HW plugins, as they draw battle cursor/whole battle menu during VBLANK+start of next frame after selecting new display area.

I suggest promoting a new GPU export, which can be used by the emulator to signal the start of, and end of, VSync. If the GPU supports this export, then the main emu should not call gpuUpdatelace() at all, but use the new interface. Thoughts?

Are you heard of scanline tracking on real PSX? I thought of several approaches too. New vsync start/end interfaces, new readstatus or several other procs with tick counter parameter..., or maybe just NextScanline() export.. your method look simplest .. maybe other will be hard to do. Maybe we should ask them?

[E}I{]

Rumbah: First savestate - too early, 2nd - too late

[Lewpy]

Originally posted by E}I{
Are you heard of scanline tracking on real PSX? I thought of several approaches too. New vsync start/end interfaces, new readstatus or several other procs with tick counter parameter..., or maybe just NextScanline() export.. your method look simplest .. maybe other will be hard to do. Maybe we should ask them?

No, I've not heard of scanline tracking ... I thought they could only poll for VSync, not for individual scanlines?
I tend to favour having the main emulator keep track of things (ie. control the timers/counters/etc.), as it keeps everything "ticking" from a central source. It would be possible to have a timer in the GPU show that it could try to time the vblank period, but it would not be synchronised with the core emulator, so I think there may well be timing issues.

[Rumbah]

Well, I tried it once again, this is the closest savestate I could get. It is short before the crash! The link from above contains the new savestate.

Rumbah

[E}I{]

I heard in many sources that PSX can count scanlines and call IRQ for each. And also i heard that games use scanline interrupt to determine frame start. So emu probably already have internal scanline counter and since PAL and NTSC timings are known all we need is scanline callback export in our plugins. It will get called only 256-315 times per frame and also will allow for emulation of realtime dmachain processing if any game will require it(for example several games intentionally use bad DMA chains and then break execution by force ). in current implementations GPU have to process whole list before return.
So, if ePSXe keeps counter value, we will ask
void UpdateScanline(int) called each line before H-Sync callback. If value became zero(start of actual frame), then we'll change our flag second time.

[E}I{]

This savestate is of no use for me too Gotta find CC myself.
BTW, Lewpy , I noticed one thing: When this savestate hangs up and plugin uses normal method of flag updating, music is played with normal speed (slow), but if i flip flag each read music is way too fast...... Or this is caused by something else...

[Lewpy]

I think music derives its timing from VSync, so it is possible by flipping the value on each read, you "fool" the system in to thinking vsync is happening faster than it really is. Unless you are causing your frame-limiter to mal-function somehow?

[E}I{]

Thats also can be vsync delay method difference... BTW what yours plugin does while waiting for next frame?

[Lewpy]

Originally posted by E}I{
BTW what yours plugin does while waiting for next frame?

Do you mean what does my plugin do in GPUupdateLace()?
It does [basically] as follows:-

• makes a decision on whether the display needs refreshed from VRAM (ie. singlebuffered display being used)
• applies a frame-cap algorithm, to regulate frame-rate
• calculates the FPS of rendering
• toggles the ODD/EVEN status bit, unless a special fix is controlling the ODD/EVEN status bit differently
• updates the display if required (if interlaced, or if the display was disabled and has just been re-enabled)