To reiterate the same topic that was brought up in the help thread. Take careful note but to sum things up, Danmakufu is not a very well optimized engine, it isn't designed to be that way, not to mention lag is also a fault of your computer, just because you get lag doesn't mean everyone else will. The poor coding habits mkm(the author) used requires our computers to work harder than it typically needs to.
Ways to improve your FPS:
-Short circuit your boolean expressions:
if (x && y) {} //if x is false, then y won't even be evaluated -Remove unused variables and redundant statements
-etc.
These two yield zero increase in performance, variables are just value lookups on the script's virtual stack. Mkm handles these things quite well.
Optimization
can be taught, but you really want to focus on optimization
after you reach a certain level in your project, for example: after finishing a boss battle, stage, or even cleaning up and preparing for a demo. If there's one thing about programming games you should know, you build your game the smart way, and worry about "what can I do make improve performance" later. The last thing you need to do is develop unnecessary lag safety habits early on, danmakufu is not a very performance optimized engine so there is a limit to what you can do to improve and avoid lag.
I suggest being mindful of sprite objects you have going around, deleting unused things is best, textures can stay in memory no problem but sprites, bullets, enemies etc... need to go. Be mindful of the calculations you make, you don't need to have an ellipse formula for a ring of bullets, or some other unnecessary trig ran each frame.
But after all of these things are said and done, at the end of the day, it is all left up to how good your computer is. Don't let worrying about optimization discourage you and take away the fun of making games. I had to learn that the hard way, and most serious programmers will tell you the same. (after I spent nights worrying about improving my personal danmaku engine I made in both C++ and C#, I ended up seeing that those efforts were unnecessary)
- Loading resources on the fly is a frequent issue, so preload things that need to be loaded at time-critical points.
- Curvy lasers. Don't use too many.
- Primitives with many vertices ? consider simplifying, or use sprites, meshes (ph3), or shaders (ph3).
- Lingering tasks ? always check if the object in question is deleted.
- Array accesses (probably only 0.12m), though ph3 benchmarks show this isn't the case.
2: About 50% of the lag from curvy lasers occur due to the excessive hitbox calculations, you can develop a system that disables the hitbox of lasers that are not near the player to combat those problems, same thing applies to bullets.
3: shaders have nothing to do with primitives, they're post processing effects that are handled on the GPU it is not a solution to every graphical problem as a shader can lag as well. Meshes are really premade primitives, the lag that comes from using primitives in dnh is almost always because of excessive trig from calculating vertices and or calculations being handled on the UVs. Using cos/sin 500+ times is bad regardless.
4: This can also cause abit of problems for deleted objects but tasks that are still running, remember that object IDs are recycled, always keep task usage to a minimum if you can.
5: Can still be a problem when there is other underlying code being ran. That benchmark doesn't show the the negative effect it could have on a real game.
