This thread is for keeping a list of not-obvious things that will slow down Danmakufu.
Things that are obvious, like massive amounts of bullets/graphics/enemies/effects/loops do not belong here. Feel free to suggest things to the list, but try to test it and give reasonable proof that what you suggest is causing slowdown. Also feel free to suggest solutions and alternatives to the problematic situations listed here.
Trigonometric functions
If you are doing a lot of positioning every frame with sin, cos, and atan2, you will be slowing Danmakufu more than if you are using precalculated numbers.
Example:
ascent(i in 0..8){
SetGraphicAngle(i*45, 0, 0);
DrawGraphic3D(sin(i*45), 0, cos(i*45));
}
Solution:
The framerate can be improved by writing out each SetGraphicAngle and DrawGraphic3D while writing in the exact values of sin and cos instead of calling the functions. Of course writing the same thing with different values is quite tedious, especially if you need to do it for several hundred functions. This solution should only be used if you are desperate to regain a stable framerate.
Looking up values in large arrays
Contrary to what you might expect (especially if you are a programmer that is used to more... conventional... languages), the larger the array, the longer it takes for Danmakufu to find a value in it. Incidentally, this makes look-up tables for sin, cos, and tan too slow to be a solution to the previous problem.
Example:
let Array = [0, 1, 2, 3, 4, etc..., 390892];
let Value = Array[95397]; //This line will take longer, the longer Array is in length.
Solution:
Simply avoid large arrays as much as possible and split 2D arrays into multiple arrays instead.
Calling functions on non-existent/deleted objects
Even if the object is deleted already it will still cost a bit of processing power to call the functions on it. This seems like common sense, but consider the example below.
Example:
task SomeObject {
let obj = Obj_Create(OBJ_SHOT);
// other stuff, let's assume I wrote it already.
let counter = 0;
loop {
// do some other stuff
if(counter==180){
Obj_Delete(obj);
}
counter++;
yield ;
}
}
Solution:
The obvious solution is to replace loop {} with while(!Obj_BeDeleted(obj)){}, but sometimes, even with a while block instead of loop, some functions may still run before the while block finishes executing and the condition is checked again before it exits the loop. To prevent this, you can call return; right after the Obj_Delete(obj); and it will exit out of the task immediately.
Anyone else discover anything interesting?
