AGS performance and RawDraw

[zabnat]

I have tried some things with rawdraw and wanted to confirm some performance things.
So I kind of have some statements which I've found to be true at least on my machine and would like to hear if people have similiar experiences.
My program is heavy with some math and have couple of hundred creation of dynamic sprites and RawDrawImages and is for resolution 320x200 and am using 3.02.

1. Using precalculated tables for sin, cos, tan etc. is faster than using Maths.Sin etc. when you only need to have like 360 values of each (this I haven't actually tried with AGS)
2. Using bitwise operations instead of arithmetic operations is actually a little slower. For example: x = x * 64; -> x = x << 6;
3. Using 16-bit color mode instead of 8-bit seems to have no performance hit at all.
4. Direct3D9 is a little slower than DirectDraw5 with RawDraw. (IIRC this was mentioned in the manual)
5. Launching the compiled exe rather than testing the game from editor results in about 1,5x performance.

Feel free to prove any of these statements wrong 

Actually the most important one for me is the number 3. as this would prove that there is no reason to have all that hassle with palettes.

ps. have any tips for performance optimization?

[DoorKnobHandle]

1. Using precalculated tables for sin, cos, tan etc. is faster than using Maths.Sin etc. when you only need to have like 360 values of each (this I haven't actually tried with AGS)

That one's definitely true, for obvious reasons.

2. Using bitwise operations instead of arithmetic operations is actually a little slower. For example: x = x * 64; -> x = x << 6;

Are bitwise operations even possible in AGS? I doubt it, but am prepared to be surprised.

3. Using 16-bit color mode instead of 8-bit seems to have no performance hit at all.

True.

4. Direct3D9 is a little slower than DirectDraw5 with RawDraw. (IIRC this was mentioned in the manual)

Yup, it's mentioned and true. Actually, it's a lot slower. Also, if you're using a higher resolution, or, even worse, a filter, performance drops significantly.

5. Launching the compiled exe rather than testing the game from editor results in about 1,5x performance.

Doesn't apply here, there's no difference in performance, and I'm pretty sure there shouldn't be one. This might be a problem within AGS.

ps. have any tips for performance optimization?

Try finding your bottlenecks, if it's the math, try to simplify it as best as possible using smart and elegant formulas and terms. If it's the drawing, don't drawing anything off screen or hidden, also design your game in a way that it's not necessary to draw quite as much stuff.

[zabnat]

2. Using bitwise operations instead of arithmetic operations is actually a little slower. For example: x = x * 64; -> x = x << 6;

Are bitwise operations even possible in AGS? I doubt it, but am prepared to be surprised.

Yes they are. But instead of 300% preformance gain you might get with this in C, you get about 10% performance hit

[Pumaman]

4. Direct3D9 is a little slower than DirectDraw5 with RawDraw. (IIRC this was mentioned in the manual)

This depends on how often you're doing rawdraw, and what you're rawdrawing to. If you're just creating new Dynamic Sprites and raw drawing to their DrawingSurface it shouldn't matter, but if you're rawdrawing to the room background, D3D will be slower since it has to re-upload the background into video memory.

5. Launching the compiled exe rather than testing the game from editor results in about 1,5x performance.

This is most likely due to the fact that you run it full-screen when launching the compiled EXe, whereas you run it windowed when testing in the editor. Full-screen will generally be a lot faster than windowed mode due to the way DirectX works.

[Rocco]

I encountered that the RawDraw Performance in AGS 3.xx is "significantly" slower then in 2.72.
I tried to make this game with 3.02 -> http://www.adventuregamestudio.co.uk/yabb/index.php?topic=35278.0
but there was nothing on screen except the players car and the screen stucks every time when the car reaches a screen-corner.
If i tried an non-scrolling screen fitting background, the game doesnt start.

No problems with 2.72, perfomance is no problem and the games works also with non-scrolling backgrounds.
I planned to release the Car-Driving Module, but makes not much sense if it wont work playable with 3.02.

surface.DrawImage(....); is the bottleneck i guess.
Is this function slower now, then it was before with the RawDraw Commands?

[SSH]

If you have the room BG saved as a large sprite, then each frame copy that sprite, draw on it and then copy it to the BG, I think that would be faster... is that right, CJ?

[zabnat]

5. Launching the compiled exe rather than testing the game from editor results in about 1,5x performance.

This is most likely due to the fact that you run it full-screen when launching the compiled EXe, whereas you run it windowed when testing in the editor. Full-screen will generally be a lot faster than windowed mode due to the way DirectX works.

Actually no. I run it in windowed mode and with same setup when launching compiled exe and when running from editor. And infact, I just tested and I got better performance when running windowed than running in fullscreen.

[Pumaman]

I encountered that the RawDraw Performance in AGS 3.xx is "significantly" slower then in 2.72.
I tried to make this game with 3.02 -> http://www.adventuregamestudio.co.uk/yabb/index.php?topic=35278.0
but there was nothing on screen except the players car and the screen stucks every time when the car reaches a screen-corner.
If i tried an non-scrolling screen fitting background, the game doesnt start.

No problems with 2.72, perfomance is no problem and the games works also with non-scrolling backgrounds.
I planned to release the Car-Driving Module, but makes not much sense if it wont work playable with 3.02.

surface.DrawImage(....); is the bottleneck i guess.
Is this function slower now, then it was before with the RawDraw Commands?

If you're using the DX5 driver, AGS 3 should behave the same way as 2.x used to.
If you're using the D3D driver, and your method is basically to raw-draw the entire screen every game loop, then I would expect that to be a lot slower.  Rather than raw-drawing to the background you could consider raw-drawing to individual dynamicsprites for whatever it is that you need to rawdraw, and then drawing those dynamic sprites normally as objects/characters.

If you have the room BG saved as a large sprite, then each frame copy that sprite, draw on it and then copy it to the BG, I think that would be faster... is that right, CJ?

If you have a full-screen-size sprite and rawdraw to that, I wouldn't expect it to be any faster than just rawdrawing to the background -- either way, a very large image still needs to be uploaded into video memory.

[Rocco]

The game doesnt work with DX9 at all, there is no sprite visible on the screen.
And with DX5 the described problems occur, but i guess it belongs to the backgroundpicture handling and scrolling,
cause the car stucks when the edge of the backgroundpic is reached.
here is an example, what happens with AGS Beta 3.01.050 -> http://www.datenschleuder.eu/download.php?file=773Pitstop_AGS_3.zip

[Pumaman]

Without seeing your script code it's hard to know why that might be, are you remembering to Release the surface at the appropriate times?

[Rocco]

well maybe not, this was the failure. 
i released the surface only when the driving part was over, that was not enough. 

It seems that it works now same way as with 2.72.
Big thx, i withdraw my statement about the AGS 3.xx performance. 

[Pumaman]

Hehe, glad it's solved