I figured out a trick that helps for dealing with this particular puzzle.

Wait a second between each click.

Instead of AVOOZL or AAVVOOOOZZLL
it's A....V....O....O...Z....L....

For some reason, the game just needs a moment to process that you actually clicked it.

There's a similar bug in QFG1VGA where if you buy potions from the healer too fast, you're giving her money but not getting potions in return, because the game didn't get to fully process the transaction.

I've had that problem for years and this is the first time I've seen anybody mention it online! My strategy has always been to buy a potion, open and close the inventory, and then open the inventory again to make sure the new potion appears.

I fixed this bug when you play the game in ScummVM.

Fantastic! Too bad sourceforge seems to be down right now.

I mean, I do have scummvm 1.7.0 but there's a few issues with it and the Quest for Glory games. Did future versions also fix the insane loading times when going between rooms in QFG2?

I fixed it march this year, which means the fix is only available atm when using a daily build. 1.8.0 will also fix it of course when it's released.

btw. scummvm.org is available again. insane loading times? There shouldn't be. Do the transitions take way longer? On which hardware are you playing them on?

Yeah, the transitions take way longer than they should (it's what I meant, actually). It's a similar problem for QFG1 EGA version, but that seems to have less transitions, and the transitions that do exist seem to actually move by quicker.

As for hardware, I have 4 GB RAM. It's a really cheap laptop, handles a surprising number of games. Is there a setting in ScummVM I flubbed up or something?

Now that's weird. on my PC they work as they should. Transition frames are delayed for a few milliseconds so that it's possible to actually see the transition itself, so in case your computer delays a bit longer then that could explain it.

What are you using? Windows 64-bit? Mac? Also which renderer do you use in ScummVM?
Also: can you make a video of one of those transitions? Are all transitions that slow or are just some of them that slow?

As I said - the transitions are delayed a bit so that it's possible to actually see the transition itself. But they should take a few hundred milliseconds at worst. If you compare them to dosbox, then ScummVM probably has slower transitions, but that's on purpose. When using dosbox, plenty of transitions can not really be seen because they run way too fast.

Okay, that helps me help you help me.

Windows 64 bit, yes.
I'm using the default renderer (render mode is literally <default>). Graphics mode HQ3x so that I can actually see what I'm doing.

I don't currently have any programs capable of recording stuff, and I remember Camstudio always being temperamental. Unless ScummVM has a built-in method of recording like DOSBox does?

I'm actually using Fluidsynth for the audio, which is the main reason I wanted to use ScummVM at all. It'd be nice to get it working in DOSBox, too, but that's a different problem for a different day.

I just tried using HQ3x and it works just fine, although I'm using Windows 32-bit (and the latest daily build).
Can you please tell me how long the transitions take on your system? A second or even more?

Which Windows version are you using? I'm using Windows XP.

And you could use CamStudio to capture footage. I used CamStudio to capture various videos for a youtube channel.

Windows 8.1
About 3 seconds

And my history with Camstudio on previous computers is that it's quite finicky, especially when it comes to sound. But I guess I'll give it a shot later.

UPDATE!

When I turned the scaling from 3x down to "Normal", the pixelated screen transition in QFG3 (which was taking about 3 seconds, just like QFG2) ended up taking less than a second, which felt proper.

However, this means that unless I'm running full screen, the game is too small for me to see.

Hm.

ADDENDUM:

Also, for some reason, full screen ignores aspect correction, and has a huge border around it. I hate having a widescreen monitor sometimes. Things are actually visible now but the widescreen squishes everything and makes it distracting.

Ugh. Isn't there a way to play the game in DOSBox while ScummVM handles the audio or something?

ADDENDUM 2:

Also I know I'm not the only one having this problem now.

From this ScummVM IRC Chat log:
http://echelog.com/logs/browse/scummvm/1425596400

[02:58:38] <Sir_Burpalot> Also?and this is an unrelated issue?setting the scaler to 3x causes ScummVM to be slow, with the mouse cursor being laggy and with SCI screen transitions taking up to 7 seconds.
[02:59:35] <LordHoto> Any specific game where it's easy to test?
[02:59:48] <LordHoto> KQ1 SCI seems to work just fine with 3x here when I start it and move around a bit
[03:00:23] <Sir_Burpalot> With "OpenGL (No filtering)", the mouse cursor is fine, and SCI transitions, although still slow, are not that horribly slow.
[03:00:28] <Sir_Burpalot> LordHoto: are you on OS X?
[03:00:41] <LordHoto> nope
[03:01:07] <Sir_Burpalot> Well, the problem I'm describing is specific to OS X on Retina displays.
[03:01:17] <LordHoto> so, bascially the issue is that your hardware is slow?
[03:02:53] <LordHoto> I'm pretty sure if SCI transitions on OS X in general are that slow, someone would've asked about it so far.
[03:03:20] <clone2727> They're broken
[03:03:29] <clone2727> Well, "slow"
[03:03:47] <clone2727> It does screen updates too fast
[03:04:14] <Sir_Burpalot> My hardware is too slow? I hadn't thought of it that way, but yes, I suppose you're right.
[03:04:57] <clone2727> LordHoto: ie. it does do http://wiki.scummvm.org/index.php/HOWTO-Backends#updateScreen.28.29_method
[03:05:03] <clone2727> doesn't*
[03:05:17] <LordHoto> ah, it forces vsync
[03:05:28] <clone2727> Even without OpenGL
[03:05:39] <LordHoto> well, then a lot of updateScreen requests will slow things down, yeah
[03:07:19] <LordHoto> That's something we'll need to fix one day. But it's not specific to OS X on Retina displays.
[03:08:18] <Sir_Burpalot> The slow screen transitions are just part of the problem.

(Also, trying to run my games in either OpenGL setting just causes the games to crash)

It's weird that it only happens when you use 3x. Have you tried 2x? That's the one that I'm using all the time and it works for me.

I just tried 3x and the pixelation transition works maybe a tiny bit slower, but still within a few hundred milliseconds at worst.

Have to ask someone from the backend team about aspect correction.

I have already figured out that it's the too many updateScreen() calls, still it's really weird that it's happening on Windows for you. I guess for Windows it occurs when certain graphic drivers are used. Maybe in your case it's waiting for a V'Sync on every updateScreen() call, which would explain 3+ seconds.

I had a similar problem on Nintendo Wii, but that was solved by dynamically delaying between frame changes during transitions and even on Wii the transitions work properly. My main problem is that on my system it works, which means I would have to change code without having the ability to try it out. Now that's really weird and probably your graphics driver. Can you run ScummVM from commandline and then try again? That way you can hopefully see any warnings that are getting shown right before it crashing (in case there are warnings).

EDIT: oh and btw. is it just the pixelation transition or are all sorts of transitions that slow? Like for example is scrolling that slow too?

Yeah, it's pretty bad in 2x, too. Significantly better, but still bad.

Scrolling and wipe-like transitions are bad, as well. Screen shifts that have no transition, however, or simply invoke a palette change, are still quite as instantaneous as they are in DOSBox.

My graphic drivers are up to date but it's a crappy chipset on a laptop, so that's probably a problem. My VRAM is... well, pathetic. And yet I can somehow run Skyrim well enough *shrugs*

I don't seem to get an error message, actually. I get the following text:

User picked target 'qfg3' (gameid 'sci')
Looking for a plugin supporting this gameid... SCI [SCI0, SCI01, SCI10, SCI11]

Starting 'Sierra SCI Game'

...And then after that, it's just back to the usual command prompt. No error, no acknowledgment that ScummVM closed abnormally, just... that.

scrolling is also too slow? That's weird, because I just looked into the code and scrolling transitions should actually skip frames already.

Anyway, I have just changed some things inside transitions and it should hopefully work now. I can't really test it out, but I added longer delays right after pumping out a frame and it definitely skips frames on my system in that case.

You can download the latest daily build from here:
http://buildbot.scummvm.org/builds.html

Please try it out. I'm not sure when daily builds are generated. Just check the timestamp. In case my post is older than the daily build, then it's the right one.

Oh and the aspect ratio fullscreen issue seems to be a problem with either Windows or the graphics driver. We ask for a specific resolution and aspect ratio and according to a backend developer it seems that Windows doesn't do what we ask it to do. We can't really do anything about that, but what would and should work is using the OpenGL renderer (which doesn't work on your system atm). But with that one it would work properly.

Just a little update - our daily builds currently do not work since 24th of july. I can not fix it, because I do not have access and the people that do have access have very limited time. I hope that it will get fixed soon and then I will post another message. I could also upload a current 32-bit build on another site, but I don't really like that approach.