I believe I have a rather novel problem with AGS:
If the repeatedly_execute script gets too complex, it causes the (MP3) music to stutter.
This is still under v2.72, and the reason is probably that the rep_ex makes extensive use of RawDraws (yes, I know you're not supposed to combine those), as well as looping through a substantial number of structs for custom things that move around. Interestingly, the frame rate is unaffected, and is somewhere between 30 and 40.
Aside from the obvious ("don't do that, then"), I was wondering if anyone, in particular CJ, had a suggestion on how to deal with this? Perhaps I should upgrade to 3.0, or use OGG, WAV, or MIDI instead? Or perhaps there's some clever workaround? Would PlayMusic/PlaySound/PlayAmbientSound make any difference?
Have you tried running the rawdraw code in a separate repeated_execute function from another script? Also, I don't think you'll see any marked improvement between mp3 and ogg since both are compressed, though playing a midi/wav should be fine. AGS 2.72 already uses ddraw for rawdrawing so I'm not sure you'll see a benefit switching to 3.0, but it's possible. Another thing you could try is breaking up the work into smaller loops so it doesn't stay in one for too long.
Quote from: ProgZmax on Tue 22/01/2008 00:42:52
Have you tried running the rawdraw code in a separate repeated_execute function from another script?
No, but I'm not sure how that would help, since it still executes the same code during each frame.
QuoteAlso, I don't think you'll see any marked improvement between mp3 and ogg since both are compressed,
Well, they're compressed in very different fashion, using completely different libraries.
QuoteAGS 2.72 already uses ddraw for rawdrawing so I'm not sure you'll see a benefit switching to 3.0, but it's possible.
Hm... I know percentual transparency is a performance hit, but what about scaling? Is a scaled rawdraw much slower than a non-scaled one? And what if the scale turns out to be exactly 100% some of the time?
Which is faster - RawClearScreen(), or RawRestoreScreen() to a screen that happens to be pre-cleared, or RawDrawRectangle()?
A frame rate of 30-40 fps should be enough to keep the music playing, unless your track is a particularly high bit rate. Can you post a sample of the problem?
QuoteWell, they're compressed in very different fashion, using completely different libraries.
Aye, but if you're getting stuttering in mp3 (but not wav) then you'll likely suffer it in ogg as well. I would venture to say it takes a near-equivalent amount of effort to decompress and play either format.
Quote
Which is faster - RawClearScreen(), or RawRestoreScreen() to a screen that happens to be pre-cleared, or RawDrawRectangle()?
The best way to determine this is, of course, testing it yourself(if I remember right, ags has an fps display). You may not notice any difference at all, but then again it could be worth looking at. Let us know what sort of results you get with your system specs. Also, seeing exactly what you're doing would help.
Quote from: Pumaman on Tue 22/01/2008 19:25:11
A frame rate of 30-40 fps should be enough to keep the music playing, unless your track is a particularly high bit rate. Can you post a sample of the problem?
Good point, it may be the bit rate. I can PM you with the AGS executable if you think that helps?
Quote from: ProgZmax on Wed 23/01/2008 05:09:05
Quote
Which is faster - RawClearScreen(), or RawRestoreScreen() to a screen that happens to be pre-cleared, or RawDrawRectangle()?
The best way to determine this is, of course, testing it yourself(if I remember right, ags has an fps display).
Yes, obviously I'm aware of that. I was hoping that either somebody had already done so (such as OUXX, who was doing performance tests earlier) or that CJ could tell me that one of those is much faster (or not) because of the way the code is written.
Quote
Good point, it may be the bit rate. I can PM you with the AGS executable if you think that helps?
If it's a reasonable size, that would be helpful, yes please.
QuoteI was hoping that either somebody had already done so (such as OUXX, who was doing performance tests earlier) or that CJ could tell me that one of those is much faster (or not) because of the way the code is written.
Well, if you just want to clear the screen to a solid colour then RawClearScreen should be the fastest method. However, the difference between those three methods is relatively small compared to the cost of that fact that you're doing a full-screen raw draw every frame.
When you raw draw to the whole screen, then the following happens:
* With the software gfx driver, the entire screen is marked as "dirty" and has to be repainted for the next frame
* With the D3D driver, the entire background image is invalidated and has to be re-loaded into the graphics card's video RAM
These operations are quite slow (particularly the D3D one), so no matter which method you use, my advice is still to try and avoid rawdraw completely in repeatedly_execute.
Quote from: Pumaman on Wed 23/01/2008 17:13:44
These operations are quite slow (particularly the D3D one), so no matter which method you use, my advice is still to try and avoid rawdraw completely in repeatedly_execute.
So in essence, it would then be faster to have a series of objects and/or characters on-screen (with Z ordering) that fill the entire screen, than to use rawdraw? Okay, that'd be good to know, and I can work with that. Does it matter whether I use objects or characters or GUIs or overlays? Assuming that each individual one does not animate much?
Assuming that you just want to display some large images that don't change their graphics very often, full-screen objects would probably be fastest with D3D, but raw draw probably would be faster with DX5.
Sorry, that's probably not a very useful answer but it's what I think would probably be the truth!
Okay. So AGS2.7 is Dx5, and AGS3.0 is D3d, is that correct? Thanks for your advice. By the way, would you agree that OGG playing is roughly as fast as MP3 playing, or are there significant differences between the libraries?
I've seen this issue come up in the past, and I'm suffering from the same problem aswell, although I've sort of accepted it as an inevitability. I'll try to describe it as best I can. (I use 2.62. btw)
I think it definitely has something to do with the complexity of the game. My game is approaching 150 mb now, so I'm not too surprised. I don't think it's exclusively the fault of the rep_ex though (or maybe it is in Radiants case). In my rep_ex there is a small cursor text overlay script, a check to automatically close the inventory in a certain condition and a keypress setup for keyboard movement. Nothing fancy.
During normal play, the framerate is fine (steady 40), but during room transitions and the loading of the dialog options the audio stutters, sometimes for several seconds. I use only Oggs (and some WAVs for short sounds effects, since apparently Ogg or MP3 can't play sounds shorter than a second). I use 8/10 compression on music, probably equivalent to something like 44k 128 kbit, and something lower for sound effects. I don't think it has to do with the audio though, because if I disable the digital music pack, as far as I can tell the delay persists.
Interestingly though, when I check 'Downgrade 32 bit graphics to 16 bit' in the winsetup, the problem is gone.
Quote from: largopredator on Fri 25/01/2008 14:35:04
During normal play, the framerate is fine (steady 40), but during room transitions and the loading of the dialog options the audio stutters, sometimes for several seconds. I use only Oggs (and some WAVs for short sounds effects, since apparently Ogg or MP3 can't play sounds shorter than a second). I use 8/10 compression on music, probably equivalent to something like 44k 128 kbit, and something lower for sound effects. I don't think it has to do with the audio though, because if I disable the digital music pack, as far as I can tell the delay persists.
The same thing happens in
The Blackwell Legacy. As I recall, turning down the resolution helps (but of course mangles the graphics).
Quote from: largopredator on Fri 25/01/2008 14:35:04
During normal play, the framerate is fine (steady 40), but during room transitions and the loading of the dialog options the audio stutters, sometimes for several seconds.
Hmm, what do you mean by "loading of the dialog options"? Nothing particularly intensive is happening here, so I'm surprised that it can stutter at this point.
If someone is able to post a sample that demonstrates the music stuttering, I'd be interested to investigate it.
Quote from: Pumaman on Sun 27/01/2008 00:36:05
If someone is able to post a sample that demonstrates the music stuttering, I'd be interested to investigate it.
I PM'ed you with that.
Quote from: Pumaman on Sun 27/01/2008 00:36:05
Hmm, what do you mean by "loading of the dialog options"?
If someone is able to post a sample that demonstrates the music stuttering, I'd be interested to investigate it.
It's basically when you talk to someone (activate a dialog), and the dialog options GUI shows up, but the options are not there yet. At that point, it stutters for a second or two, then the options show up and everything works again. When a response is done and it has to go back to the dialog options, then it hangs again. I'm using a custom GUI for dialogs, but it happens with the default one aswell.
Here is a video I recorded of it (http://dinerdate.net/stutter.avi) to show what I mean (I skipped some things to get to the good bits). When I walk into the office you can hear the music stutter for a sec, and then very heavily during the following dialog with Jake.
Hmm, there's no way it should take that long for the dialog options to appear.
What version of AGS are you using, and do you know what spec your PC is?
The thing is that in 16bit mode there is no delay. I run AGS 2.62 on an Intel Core2 Duo 2.2 Ghz, 2 GB RAM, Geforce 8600M GT, Vista. Had the same problem on my old PC, AMD 2800+, 1 GB RAM, Geforce 6800XT, XP. The delays were no different or anything, just that the game ran about 10-15 fps slower on that one.
Hm. CJ, does the MP3 decoder run in a different thread?
Quote from: largopredator on Sun 27/01/2008 16:46:09
The thing is that in 16bit mode there is no delay. I run AGS 2.62 on an Intel Core2 Duo 2.2 Ghz, 2 GB RAM, Geforce 8600M GT, Vista. Had the same problem on my old PC, AMD 2800+, 1 GB RAM, Geforce 6800XT, XP. The delays were no different or anything, just that the game ran about 10-15 fps slower on that one.
Are you running in 32-bit when the delay happens, then? Were most of your game graphics (the dialog options GUI and room background) imported at 32-bit or 16-bit?
QuoteHm. CJ, does the MP3 decoder run in a different thread?
No, not at the moment. The sound system AGS is using doesn't seem to work properly if you try and run it in a separate thread, which is part of the reason why the music can stutter if one single operation takes a long time to execute in the main thread.
Quote from: Pumaman on Sun 27/01/2008 17:44:47
Are you running in 32-bit when the delay happens, then? Were most of your game graphics (the dialog options GUI and room background) imported at 32-bit or 16-bit?
Yes. I believe all graphics are imported at True color (32-bit).
Would you be able to upload a sample of this for me take a look at, or are the game files too large?
Well, the main .exe by itself is 100 mb, I don't know how you feel about that. :) I'd have no problem uploading it though, I already send out beta's every now and then. Can you manage with just the Compiled folder contents, or do you need actual editor files aswell?
Well, if you were using a recent version of AGS the Compiled files would be enough -- I'm not sure though since you're using 2.62. If you don't mind uploading it anyway, I'll give it a go and see.
I've had a look at this now, but I can't really investigate very far because it was made with 2.62.
What I would say is that there have been a lot of optimisations and performance improvements in the 3 years since that version of AGS was released, so it might be worth having a go at upgrading it to 2.72 at least, and see if the problem is still there.
Ok. Well, thanks anyway. :) I've tried once or twice to upgrade, but half the game broke, and I didn't want to invest time in learning the new programming language yet, so I'll finish this one in 2.62 and do the next game in 3.0. But maybe it'll help Radiant or any others struggling with this problem.
Quote from: largopredator on Thu 31/01/2008 12:22:50
Ok. Well, thanks anyway. :) I've tried once or twice to upgrade, but half the game broke, and I didn't want to invest time in learning the new programming language yet, so I'll finish this one in 2.62 and do the next game in 3.0. But maybe it'll help Radiant or any others struggling with this problem.
2.62 -> 2.72 isn't that big of a switch (at least, you can still use the non-OO code in 2.72 without problems).
But, I'm afraid I'm having pretty much the same issue in 2.72 so that might not help :)
Radiant, can you try out 3.0.1 because I've made a few changes that might improve this for you.
Quote from: Pumaman on Thu 31/01/2008 19:48:14
Radiant, can you try out 3.0.1 because I've made a few changes that might improve this for you.
I'll give it a shot this weekend. It's complex code, too, so I hope it upgrades to 3.0-style well :)
Well, I'm having some troubles upgrading to 3.0, that can be blamed squarely on Bill Gates.
In the meantime, I found out, to my surprise, that using WAV files rather than MP3 doesn't actually help.
(edit) However, the problem does disappear almost completely if I don't do a RawClearScreen before all the rawdrawing. Apparently that's a pretty slow operation.