A couple good fixes this time. There is one currently known bug that I will explain below.
- Fix for Phoenix 3 hanging in load screens – A continuation of the changes to move 4DO to the new timing behavior. It will not always work (it works about 50/50, in my experience), so you will have to save beforehand and try skipping the cutscenes at differing times. But the game is otherwise quite playable!
- Once-a-second stuttering/lag spike resolved – It was discovered that some systems were slower to perform than others in polling for input devices, which was causing a noticeable delay in emulation every second. This is now resolved.
However there is one bug I know of in the system which I just recently noticed. As of 188.8.131.52, the emulation is presently working slightly too fast from normal. This is also causing the audio playback to get pushed ahead about once every 4 seconds if using the default audio buffer size. You could run 4DO with “-DebugLogging AudioDebug” to see the symptoms. This is a result of the new timing improvements that are newly worked in, so it will be ironed out in time. Anyway, please be aware that this issue exists in both 184.108.40.206 and 220.127.116.11.
I’ve also updated the about screen to more clearly Viktor’s contributing role. I am hoping he stays motivated to continue helping with core emulation improvements! 🙂
As always, I reiterate that any feedback is appreciated, especially for spotting recent changes!
If you want to try 4DO 18.104.22.168 beta, head to to the download page:
How much would you recommend increasing/decreasing the buffer from default until the bug is resolved?
Also, good to see you’re still pushing at it. Great to see there’s still people who care about the less popular gaming systems out there.
If you are running into audio problems, try increasing the buffer by increments of 50ms until the audio is fixed or the problem doesn’t happen as much. But remember that the more buffer, the more you will notice a constant desync between audio and video. Hopefully the audio issue will be ironed out soon.
Well, unfortunately this time around no audio buffer size will be immune to the problem. The audio buffer usually gets taxed in the other direction (the audio data available runs out). In this case, there’s a surplus of audio data because the emulation is running slightly too fast.
Nice work guys! Now I play phoenix 3, its work good!
Now I can play Guardian War, the audio/video are sincronized
This build has some pretty nasty issues (there are no such problems with any of the previous builds):
1. After starting a game, then opening the 4DO options window, setting some options and leaving the options window open for a couple of minutes, the rendering thread fails and a red “X” on a white background appears in the emulation window.
2. (Gamepad) controls stop working after 2 minutes of play. Then, after selecting ‘configure input’ from the menu, the whole WIndows 7 OS (!) becomes unresponsive and the FreeDO process must be closed with the Task Manager.
The emu author should get a PC or laptop with a *single core* CPU (without hyper-threading) running Windows 7 and test his builds on that machine. It’s the best way to reproduce threading issues and nasty timing bugs that go undetected when using a multi-core CPUs.
Hm, well, I think I have #2 solved for the upcoming version. I noticed my CPU higher than normal. The new “isolated” device lookup was doing back-to-back lookups.
I can only hope that #1 is a symptom of that issue, although I find it pretty worrying. If you find time, can you try that with a 1.1.4.x version? It would be interesting to know if you can see it there. Also, I’d be interested in knowing if that occurs with the About screen open instead, or with no windows open, for that matter. I haven’t seen the issue, but haven’t let the emulator run with windows open.