Avoid always conditions with any actions that use moderate CPU power, but use them instead of using timer conditions on things you need repeated every loop.
With heavy calculations, put them in a Not Active at Start (NAAS) event group and activate them only when they are used. For example, if it's a constantly used formula (e.g. calculating range/distance between enemy and player), calculate it only when the enemy is about to shoot and can see the player. If it's something that has to always be used (e.g. calculating line of sight), try to calculate it in only one event, place the calculated answer in some data storage, and use that number instead of the formula, when needed. [Obvious, quite important tip, but one that many, including myself tend to forget]
Keep animation frames to a minimum, use anything other than top-view, so you won't have to do 32-directions per animation (thus keeping animation power minimized).
Use minimum resolution so the screen won't have to process so many things at once.
Eh, I know a lot more, but can't think of them for now.
Edited by the Author.
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
About formulae calculation - I think events with multiple conditions are always handled from the top down, so using this:
(Player presses Fire button)
+ (Massive formula to calculate line of sight)
would be a lot more efficient than having the two events the other way round - the formula is only run through if the first condition has already taken place. Otherwise, it would be calculated in each frame, and the results discarded.
Dont repeat conditions:
So make only one always condition and put all events related on that single line instead of making several alwayses.
Same thing with all simple conditions, shared commands, or start/end of frame or , etc.
Edited by the Author.
It's regrettable that TDC is the arsehole of the click scene, but somewhere has to be.
a. It works much better if you resize it by 2x or 4x. Like, if you rezize a 640x480 playfield to fit in a 320x678 window, it will run horribly, whereas resizing a 320x240 playfield to a 640x480 window runs pretty smoothly. Look at Blokkoland.
It's still a horribly slow way of resizing. However changing the desktop resolution to something lower (like 640x480) speeds it up.
It looks scruffy if the original window size is not exactly half or one quarter of the desktop resolution.
Of course Multimedia fusion can make the desktop size 320x240 during runtime which TGF cannot. So only us TGFers have that problem.
An idea for keeping particle effects low would be to make the game check where allot of particles are together, and then remove allot of them & replace them with objects that look like allot of particles together. That way you get the appearance of thousands of particles, but you only have like 10 objects!
The alpha channel object is nice yes, but not good at all for this version of MMF... it KILLS frame rate, frame rate that is already being murdered by MMF's frame rate limit of 50fps.
In addition, the only reason the collision with object doesnít work with custom movement is because just 1 pixel over a backdrop of object is considered overlapping and 1 pixel off is considered not overlapping, so its either overlapping or not. On collision is built for basic movement and basic movement only, because basic movement supplies the event trigger when it hits another object, custom movement doesnít, & canít.