0.6.0 has been released

[Guest]

sound_thread_priority has been renamed CE_sound_thread_priority in this release, and must be specified in the game section ... don't know if that helps, but there is no way to fiddle with the sound buffer size as a configuration parameter for the moment - I'll do some tests to see what's the problem with Digital Imuse, because I have noticed some hickups with The Dig on my A620 while my Ipaq 3630 plays it perfectly, which is a bit puzzling

CE_sound_thread_priority is what I have used, and I've put it in both the game section and scumm section, but whatever number I specified, I couldn't hear any difference. What are the numers I should try? Positives? Negatives? Zero? Bigger than 10? Bigger than 100? At first I thought the CPU is being overwhelmed with decoding too many sound streams, or that SD card is too slow to stream all that, so I removed the big music file, leaving only the voices. But it changed nothing! Small skips were still here and there, just as before. So I switched the music file back, as the game is much nicer with it It's not a big deal, hickups are not annoying, especially since the music in the background seems to play smoothly. My best guess is that it might be solved just by increasing the sound buffer slighty, because it just sounds like one of those things that you can do in emulators to get rid of such problem.

otherwise the error message with a path in it doesn't sound too good, it looks like a failed assertion in the engine code - you should give me the exact message, and check that your game files are not corrupted in case this isn't an engine bug.

Elfbs has gave you everything I could at this point. He has experienced exact same problems I did, and saw the exact same error message. It's good to know sound static is fixable, I'll see how much it slows down on my h1945 when I enable high quality FM. It's great that Elfbs even found the workaround for the crashing bug in FOTAQ, but that seems like something that would be pretty easy to fix. You now know the exact cpp file where it occurs, and the string to search for The only thing I can still test, is to try the talkie version of FOTAQ, as well as non-talkie version, to make sure if it crashes with both.

[Arisme]

you should set it to a SetThreadPriority priority OK it doesn't help much ... here are the valid values

#define THREAD_PRIORITY_TIME_CRITICAL 0
#define THREAD_PRIORITY_HIGHEST 1
#define THREAD_PRIORITY_ABOVE_NORMAL 2
#define THREAD_PRIORITY_NORMAL 3
#define THREAD_PRIORITY_BELOW_NORMAL 4
#define THREAD_PRIORITY_LOWEST 5
#define THREAD_PRIORITY_ABOVE_IDLE 6
#define THREAD_PRIORITY_IDLE 7

however as I said, this sound problem is subtle, because it doesn't happen on some devices - that's why it may be a bit tricky to fix properly.

Regarding FOTAQ problem, I'm still investigating. The bug seems to be only present in release builds, which would show an illegal memory access hidden somewhere in the code

[Arisme]

FOTAQ bug is fixed, it was (guess what ?) yet another compiler bug

Next build coming probably tomorrow ...

[Marconelly]

Hey, just to make it clear, that post above yours was made by me, but I forgot to log-in at the time.

Can you tell me what is the default thread priority? Is it 3? I guess I should try 1 or 0, and see what happens.

Thanks for the quick fix on FOTAQ!

[Marconelly]

Arisme, here's some more observations on the COMI workings in 0.60 version, as well as in 0.51 version.

Just right off the bat, I've noticed that 0.51 runs COMI videos *MUCH* smoother. I can't stress that enough. It does de-synchronize graphics and sound every now and then, but generally it plays nicely - videos are super-smooth in 0.51, while they run very choppy (with visible frameskip) in 0.60. Also, while in-game, the sound hickups in the character voices are pretty much gone in 0.51! However, not all is great with 0.51. Sound output is definitely lower quality compared to 0.60 (in a sense that it's sampled at a lower rate), and the graphics interpolation/downsampling from 640x480 to 320x240 is not as good as in 0.60. New version really is doing an amazing job with an interpolation. I wonder what algorithm is used?

I've tried setting CE_high_sample_rate to false, hoping that 0.60 would get some speed gain and run videos as smooth, and voices with no hickups as 0.51 does, while preserving the great screen interpolation. However, setting that parameter to 'false' did absolutely nothing. Sound remained high quality in 0.60, just as it was, and when I set it to 'true', 0.51 still played lower quality audio. Also, before you ask, I've put the parameter in COMI, SCUMM and WINCE sections in the settings file.

From what I've figured out here, the perfect version of Pocket SCUMM would use the 0.51 engine for video playback in COMI, while using the in-game engine from 0.60 (with high quality graphics and sound, but with voice hickups eliminated)

During video playback, lower quality graphics interpolation in 0.51 looks just fine, as the video is anti-aliased to begin with - it's in-game graphics where 0.60 really shines.

Maybe I'm off base here - maybe it's the apparently forced high / low sound quality in 0.60 / 0.51 that is causing the hickups and speed difference? 0.60 really does seem to have forced HQ sound, and it's forced to LQ in 0.51.

It would be great if you could look into those new parameters. I have noticed that CE_high_sample_rate and CE_sound_thread_priority basically don't work - they don't seem to do anything. Also, if CE_landscape is supposed to run SCUMM interface screen in landscape, it doesn't.

I've also noticed that when I assign 'skip' action to a button, it doesn't work in 0.60. I always have to press the on-screen icon to skip the talk/video. The same assigned button does skip when I run 0.51 version.

Also, in 0.60, whenever I run COMI, it always asks me to assign 'zoom up' and 'zoom down' buttons, although I have assigned them already. Also, said functions don't do anything, when I press the assigned zoom up/down buttons :\

Another small thing I've noticed in 0.60 - sometimes parts of the screen start shaking a bit, when the user selectable conversational text appears on the bottom of the screen. Even after you select the line of text, those parts of the screen still shake. This problem, again, is not present in 0.50

As you can see, that's a small heap of bugs... I hope you can sort it out sometimes in the future :)

[Arisme]

Can you tell me what is the default thread priority? Is it 3? I guess I should try 1 or 0, and see what happens.

you should only try 1 I think 0 will lock up everything (1 will probably slow down everything else anyway ...)

I wonder what algorithm is used?

The fixed (mean, with (yet another) compiler bug fixed) lame bilinear interpolation look-alike filter I used in 0.5.1 You can check here http://minilien.com/?BuLNg633Ne (PocketPCHalf)

I've tried setting CE_high_sample_rate to false, hoping that 0.60 would get some speed gain and run videos as smooth, and voices with no hickups as 0.51 does, while preserving the great screen interpolation.

mmh in fact you're right, Digital Imuse is forcing CE_high_sample_rate, forgot about that, but it was already doing that in 0.5.1. I guess this means that the "problem" really was introduced in the new Digital Imuse code. I'll look at what has changed and see if I can revert it for our beloved devices

It would be great if you could look into those new parameters. I have noticed that CE_high_sample_rate and CE_sound_thread_priority basically don't work - they don't seem to do anything. Also, if CE_landscape is supposed to run SCUMM interface screen in landscape, it doesn't.

CE_sound_thread_priority should be active COMI, all other parameters won't do anything as you suspected

I've also noticed that when I assign 'skip' action to a button, it doesn't work in 0.60. I always have to press the on-screen icon to skip the talk/video. The same assigned button does skip when I run 0.51 version.

Also, in 0.60, whenever I run COMI, it always asks me to assign 'zoom up' and 'zoom down' buttons, although I have assigned them already. Also, said functions don't do anything, when I press the assigned zoom up/down buttons

Problem with the dialog box has been fixed. However, Zoom up, Zoom down and Skip should be working - do you have any working hardware button ? (such as Hide)

Another small thing I've noticed in 0.60 - sometimes parts of the screen start shaking a bit, when the user selectable conversational text appears on the bottom of the screen. Even after you select the line of text, those parts of the screen still shake. This problem, again, is not present in 0.50

uh, never noticed that. It may be related to a generic dirty_rects algorithm bug, but I'll recheck it.

[elfbs]

does pocketscumm re-create the error log if i delete it? or there must be a file that PS update?
I'm asking that cause i deleted the log, then i get an error message (the one of fotaq that you already fixed) but there's no new log file.

byez
fbs

[Arisme]

no, the new build doesn't keep an error log anymore - I think your log file was from a previous build. Nothing to worry about

[Marconelly]

you should only try 1 I think 0 will lock up everything (1 will probably slow down everything else anyway ...)

With version 0.60, I tried both 1 and 0, and they did absolutely nothing! No change in sound and/or performance whatsoever.

The fixed (mean, with (yet another) compiler bug fixed) lame bilinear interpolation look-alike filter I used in 0.5.1 You can check here http://minilien.com/?BuLNg633Ne (PocketPCHalf)

So you are saying, both 0.51 and 0.60 use the same scaling algo, it's just that it was broken in 0.51 so that's why it didn't look as good? That's good news, I think, as that would mean the better looking scaling is not what is contributing to video slowdown and sound hickups in 0.60.

mmh in fact you're right, Digital Imuse is forcing CE_high_sample_rate, forgot about that, but it was already doing that in 0.5.1. I guess this means that the "problem" really was introduced in the new Digital Imuse code. I'll look at what has changed and see if I can revert it for our beloved devices

I'm suspecting, it's that high quality audio that is making video cutscenes crawl and voice hickups in COMI. Don't get me wrong, the actual sound quality is *awesome*, audibly better than in 0.51, but I think I'd rather have the option to revert back to lower quality audio and have no hickups... Or in the best case scenario, have the ability to set sound quality separately for video cutscenes and separately for in-game, if it's indeed the sound sampling quality that is making such performace hit on videos.

CE_sound_thread_priority should be active COMI, all other parameters won't do anything as you suspected

If it's active, I must be doing something wrong. I tried setting it to every parameter you suggested, 0 included, and it never seemed to do anything :(

Problem with the dialog box has been fixed. However, Zoom up, Zoom down and Skip should be working - do you have any working hardware button ? (such as Hide)

Hide button works in 0.60 when I assign it. Skip, however, doesn't, and the same goes for Zoom up, Zoom down. I didn't try other button functions yet, but skip is something I use very often when testing, and I'm 100% sure it doesn't work in 0.60 while it does in 0.51.

Which build has the dialog box problem fixed?

uh, never noticed that. It may be related to a generic dirty_rects algorithm bug, but I'll recheck it.

You can see it at the very beginning of the game, on Wally's cannon. Just talk to Wally, and as soon as the conversational text appears on the bottom of the screen, you'll see cannon starts shaking.

[Arisme]

With version 0.60, I tried both 1 and 0, and they did absolutely nothing! No change in sound and/or performance whatsoever.

mmh weird ... I just saw that the code is correct while debugging - perhaps your device is too powerful to notice

So you are saying, both 0.51 and 0.60 use the same scaling algo

yes, right

I'm suspecting, it's that high quality audio that is making video cutscenes crawl and voice hickups in COMI

it's a possibility - problem is that Digital Imuse handling was almost rewritten from scratch for 0.6.0 that's why I'll need more time to study the code and see where are the CPU heavy parts that I can adapt to our devices (same I did with non-digital Imuse).

But I think Smush (the video subsystem) was changed too, this can cause some problems too ! guess I need to spend some time to play with the profiler in EVC 4

Hide button works in 0.60 when I assign it. Skip, however, doesn't, and the same goes for Zoom up, Zoom down.

I'll recheck that tomorrow - I didn't have too much time today, and already lost precious time to identify and fix the FOTAQ bug properly. btw I improved low audio quality while I was at it

Which build has the dialog box problem fixed?

this one, which is perhaps not listen on my page, sorry
http://arisme.free.fr/PocketScumm/binar ... PC_ARM.zip

You can see it at the very beginning of the game, on Wally's cannon. Just talk to Wally, and as soon as the conversational text appears on the bottom of the screen, you'll see cannon starts shaking.

OK I'll recheck, but it looks like a dirty rect bug ... thanks for mentioning it, because this can lead to interesting side effects (random memory corruption ...)

[Marconelly]

mmh weird ... I just saw that the code is correct while debugging - perhaps your device is too powerful to notice

Maybe, but I doubt it :P
h1945 is not all that powerful. However, maybe the problem is just in the sound sampling, so changing the sound priority just won't help.

it's a possibility - problem is that Digital Imuse handling was almost rewritten from scratch for 0.6.0 that's why I'll need more time to study the code and see where are the CPU heavy parts that I can adapt to our devices (same I did with non-digital Imuse).

But I think Smush (the video subsystem) was changed too, this can cause some problems too ! guess I need to spend some time to play with the profiler in EVC 4

Ouch... maybe it was all re-written for the sake of better compatibility, but at the expense of speed, which is not an issue on desktop PCs but sure can be on Pocket PCs. From what I've seen, video decoding was just fine in 0.51, except for some desynchronizing. It's way, way worse in 0.60, as far as performance goes :\ As for the in-game graphics, they run at about the same speed in both 0.51 and 0.60, except that 0.60 has better looking scaling and also better sound qualty, but quite a bit more hickups when playing voices.

this one, which is perhaps not listen on my page, sorry
http://arisme.free.fr/PocketScumm/binar ... PC_ARM.zip

True! The dialog box problem is gone! Assigned Zoom up / Zoom down buttons still do nothing, though.

[Arisme]

Maybe, but I doubt it
h1945 is not all that powerful. However, maybe the problem is just in the sound sampling, so changing the sound priority just won't help.

let's not forget another possibility, threading support can be different (meaning, even more broken) in Windows Mobile 2003 ... I'm worried about this, because I have a lot of glitches in The Dig music (small hickups as soon as something new is feeded into the mixer) on my A620 that do not appear on my 3630 with PocketPC 2000

Ouch... maybe it was all re-written for the sake of better compatibility, but at the expense of speed, which is not an issue on desktop PCs but sure can be on Pocket PCs

that's what I'm investigating. For the moment I've the feeling that the new iMuse "ticks" more often that the 0.5.1 code, which can be a problem in a system where timers are not very reliable if the CPU load is too high.

but I'm having a look at the synchronization mechanism between Smush video and sound playback, because I've noticed that it makes things worse if something starts lagging (I've seen the same video sequence in The Dig playing smoothly or crawling without recovery if I have a different CPU load at the beginning of the video)

Assigned Zoom up / Zoom down buttons still do nothing, though

think I'll add some debugging code to know if the buttons are recognized properly in the next build.

[Guest]

I'm worried about this, because I have a lot of glitches in The Dig music (small hickups as soon as something new is feeded into the mixer) on my A620 that do not appear on my 3630 with PocketPC 2000

Just wanted you to know that I am expierencing the EXACT same thing, but with speech, as I don't have any music (low space on card ). The speech glitches the first 0.5 second when someone starts to talk, but after that, it is fine.

This is on my Pocket LOOX, sadly, also on WM2003.

[s.c.s.i.]

Damn, forgot the username again!!

Im registering as soon as I get home! Sorry for the double post.

[Arisme]

The speech glitches the first 0.5 second when someone starts to talk, but after that, it is fine.

exactly and I have not noticed this problem on my 3630 ... guess it'll be fun to fix this ... well, new OS, new glitches, this is just sad because the music and voices are now perfect on PocketPC 2000