AGI: SQ2 (AppleIIGS) - frame/audio sync issues

[jpc-ae]

This comes in a few flavours, it seems certain code is running to hot causing sync issues. To explain:

When the ship enters the dock in the intro, certain letters show up too fast as if running at 30 cycles per second (cps), when it should be a steady 10, this may not matter so much, but is illustrative of the issue.

The clearest case is with the sweeping scene in the opening, where the audio is clearly out of sync with the sweeping when it should be. I have attached a recording of it when run using mame (which currently provides the most accurate play experience but crackles terribly). Roger here sweeps at 5 cps. In ScummVM, Roger sweeps at the correct speed, but his body is seen moving at 10 cps (also attached, sorry for the extra blackspace) with the audio out of sync.

My guess at what's happening is the audio is being triggered at twice the speed it should be, similar to how Roger's body is moving at twice the speed of his sweeping, causing sync issues. I also suspect that fixing this issue would help to address some of the other speed related issues sometimes seen on the Apple IIgs.

[jpc-ae]

Just to clarify, in ScummVM, Roger's sprite cycles at 5 fps correctly, but moves at 10 fps relative to the background with the audio obviously out of sync, whereas in the emulator his body moves and cycles together, both at the same 5 fps rate, with the sound perfectly in sync.

[m-kiewitz]

Please understand that as far as I can remember the interpreter on Apple IIgs ran slow and was easily overloaded with too many sprites, Sierra removed all sorts of delays because of that "to make it somewhat work".
That's also why the speed workarounds have to be in there.

The games running under ScummVM AGI do not have these limitations, that's why there are some issues. I fixed quite a few using speed workarounds.

In theory it may be somewhat possible to figure out how many animated sprites are on screen and other stats and then somehow try to act on that and make the game slower / faster depending on the elements that are shown. That was a method I thought up back then, but never implemented it.

I would also really prefer a comparison between real Apple IIgs hardware and ScummVM.
I can look into this issue, but please keep all of this in mind.

In ScummVM Apple IIgs games do not have these slowdowns and I personally think that's a good thing.

Manhunter for example has quite a few speed workarounds, because on some screens almost nothing is going on and the game runs way too fast because of Sierra's "optimizations" for the slow Apple II hardware. If I turn the speed down, these screens work fine, but other screens are way too slow. It's a mess to be honest. Even these screen specific workarounds are messy, but they work for the most part.

A heuristic like the one I mentioned will never work perfectly, that's why I never implemented it.

Apple II emulators do not work like ScummVM. ScummVM reimplements the whole game engine and thus it runs natively on the user's modern hardware.
An Apple II emulator emulates the hardware itself including the original CPU speed and also runs the original interpreter. It's completely different approaches and in ScummVM/AGI we can add all sorts of additional features, which you can't add when emulating the hardware itself and running the original interpreter.

[jpc-ae]

Sorry, looks like I originally uploaded the version where I had set slowdown to 4 in my locally built copy of scummvm, so the audio did sync with the sweeping but runs at half speed obviously. In SVMNormalout.mp4 you can see how the sweep cycle is correct but the audio is not triggering at the right intervals.

The rest of my comment has more to do with scummvm not running at a consistent speed during the opening typing sequence. It should run at a consistent rate, but instead some text is coming at the right speed while other text is too fast. And it doesn't seem related to the number of sprites on screen from my (poor) investigation. If that's just me feel free to ignore it. I will upload video of that in mame vs scummvm as well. Unfortunately I don't have a physical machine to test on (move too often).

[jpc-ae]

Sorry, now I'm confusing myself. It's MAME that's not playing at a consistent rate, but is overall playing slower than scummvm (seems to be around the slowdown 3 setting). Anyway, the issue there is when I set the slowdown to 3 in scummvm some of the sound cuts off too quickly, before the ship is fully in the doc. I will upload the video of mame vs scummvm with the timeDelayOverride set to 3 so you can take a look if you want.

The reason I care about this is that the sound in ScummVM is just overall so much better.

[m-kiewitz]

I would prefer fixing all sorts of flaws as well, because ScummVM is able to also combine features of various platform releases, but as I said - Apple IIgs versions are complicated.

The PC version has all the proper delays etc. so that one works really well, at least as far as I can remember.

Did you play through the whole game already and did you notice any other problems with the timing?

[jpc-ae]

Not yet, but that's next on my list to do.

[m-kiewitz]

That would be great. I must have played through all Apple IIgs games, but I only played through them using ScummVM, not also using an emulator and I also don't have the real hardware here, which is a shame. Back then I was making sure that the games were beatable.

[jpc-ae]

Yeah, being able to play at all is already a blessing :-) And I get that emulating the iigs is a whole other beast compared to PC.

To help, in the videos, You'll also maybe be able to notice at the end that the original name screen draws top to bottom, but in scummvm it shows the whole page instantly. Not sure if that's significant. Anyway, that's all from me for now. I might have a look at the code later but I'm not sure how much help I could be there.

[m-kiewitz]

That is simply the Apple IIgs interpreter and it simply shows what is drawn to the screen right when it's drawn.

In ScummVM transitions are slowed down so you can see what the transition looks like, but that one isn't a transition, it's just the interpreter drawing some text on the screen.

In DOS the interpreter even changed for that to regular text mode (a mode of the graphics card for displaying text).