Performance

[Dualnames]

Well, there are many topics, but nothing based on what I'm after.

I hope this goes actually here and not the beginners.
Now, I'm having some modules, and a quite big global script (10.000 lines just the GC), anyway, Although the visual effects are possible to be disabled, and that actually boosts performance, the modules and the global and the room, run constant commands via the repeatedly execute. Perhaps merging some of them into one repeatedly execute command would boost things up?

My FPS are around 60, but the rooms which are less than downfall which is 20 times bigger, take 2-3 seconds to load. My computer is quite perfect, and also Jim Reed, has noticed a slowdown there. I'm using 3.1.2 and I'm using ogv files and a preload pcx. However when skipping a cutscene, is the most obvious, as the game freezes and takes like 5-10 seconds to skip. When there are visual effects on, I'm not allowing the skipping of cutscenes because it makes around 1 minute to unfreeze.

I know people will going to say clean up your code and stuff, but I'd love some really helpful suggestions besides that. Would replacing repeated fractions of script with functions improve speed? Would merging all modules into one huge one fix stuff?

[Scarab]

You could try making all the modules run on diferrent game loops, and just run them sequentually. This should cut down the work that the processor is doing at any one time to a fraction of what you have now.

I'm not sure, but you may have to put all the repeatedly executes together to make this work.

Scar

[GarageGothic]

If you haven't done so already, put an "if (!Game.SkippingCutscene)" conditional at the beginning of your repeatedly_execute. That should reduce the freezing considerably.

And as scarab says, try to reduce the CPU load per loop - e.g. if you have a particle system, update half the particles in one game loop and the other half the next. Nobody will notice. Hell, most physics subsystems in modern games have a capped framerate of 20-30fps.

Would be easier to give optimization advice if you tell us which kind of operations you are performing for your effects. Especially a lot of DrawingSurface stuff can be optimized quite a bit once you realize that it isn't the drawing as such that slows the game down, but rather the repeated calling of Allegro bitmap functions from script.

Edit: The long room load puzzles me though - what kind of stuff are you doing in the enter_room and leave_room events?

[SSH]

Another thing you can do is cache dynamic stuff. My shadow module did this by pre-drawing all the shadows and saving the sprites.

Also, mnmay of your module things may not be needed during a cutscene, so you can add a manual control to trun off their rep_ex and other triggers, just bung:

if (disable_module_X) return;

at the start of all your event and rep_ex functions

[Dualnames]

You could try making all the modules run on diferrent game loops, and just run them sequentually. This should cut down the work that the processor is doing at any one time to a fraction of what you have now.

I'm not sure, but you may have to put all the repeatedly executes together to make this work.

Scar

Nice idea there Scarab. I haven't actually tried it, but reason is explained below.

If you haven't done so already, put an "if (!Game.SkippingCutscene)" conditional at the beginning of your repeatedly_execute. That should reduce the freezing considerably.

And as scarab says, try to reduce the CPU load per loop - e.g. if you have a particle system, update half the particles in one game loop and the other half the next. Nobody will notice. Hell, most physics subsystems in modern games have a capped framerate of 20-30fps.

Would be easier to give optimization advice if you tell us which kind of operations you are performing for your effects. Especially a lot of DrawingSurface stuff can be optimized quite a bit once you realize that it isn't the drawing as such that slows the game down, but rather the repeated calling of Allegro bitmap functions from script.

Edit: The long room load puzzles me though - what kind of stuff are you doing in the enter_room and leave_room events?

I'm using a lot of DrawingSurfaces things Garage. Also, I'm constantly updating GUI.Control.Property values. Like labels, button images and stuff.
Modules:
-ParticleSystemManager
-HyperText
-Tween Module
-Smooth Scrolling Parallax
-Abstauber's Custom Dialog GUI
-Savelist
-Lake
-Character_Control

First, yeah, those are a lot. They're all however needed, and I've reduced them to this number. I'm also having modules to control some of them ().

For the last question I have to tell you that the lines per room are like 12-24 and I seriously doubt it's the one giving trouble. However I'm using on event on various modules and global script. Perhaps joining all of those together might reduce it?

I did your in skipped thing and it increases the performance by 90% (just random percentage I came up with), the improvement, is definitely great and perfect enough!!
So thanks on that! I'm just now more curious if there's something else that can be done.

I haven't used the in_skippable cutcene thing on the room repeatedly, so perhaps doing that will fix the room load, it might be affected by that, though not 100% sure.

[GarageGothic]

Also check that the modules are properly deactivated for rooms where you don't intend use them. Most modules DO have a deactivate function or an "off" property, but check in any case that they're not running any unnecessary on_event or repeatedly_execute scripts when not in use.

One thing to check for in particular, since you say room change is slow, is whether any of the modules that use DynamicSprite and DrawingSurface functions save a copy of the background surface upon room change, and whether  it does this even when the module isn't active (check particle system and lake in particular, hypertext is less likely, but even so it doesn't take long to make sure).

[Shane 'ProgZmax' Stevens]

Another thing that might cause you some trouble is that some of these modules may be using similar methods to do their work, and if they are interfering (like one locking a surface to draw while another is vying for it or you are in need of it) this could create a queue that will slow things down somewhat.

Something I definitely recommend is to find out WHERE the problem is and then approach it.  Do this by disabling the functioning code for each module, one by one, then going to one of these cutscenes that skip really problematically and try it (make a shortcut to speed this up).  If none of them affect it individually, try disabling two or three of the  more intensive ones like ParticleSystemManager and Lake and Parallax and retry again.  Note that I'm not telling you to get rid of anything, this is a diagnostic phase to see which direction your trouble is coming from.  Once you find the specific source of your trouble you can examine it more closely and come up with a solution (a couple tweaks to the problematic module to fix things, for example).  If none of the modules seems the culprit then it falls down to your code and custom functions you have made, so go down the line and disable those one at a time as well.  

[Dualnames]

GG, I worked on what you suggested and there has been a minor improvement, nevertheless it's been an improvement. The Lake isn't using any on events. (). Particle however is. I'm going to actually go with Progz, and see if there's room for improvement.