This is a list of performance problems I have found while experimenting with the Dev Source.
Excessive Step Events on Objects
Now this one is a real FPS leech. I've talked to JS about this in the MKF Chat room, so I'll put our little conversation here, it explains pretty much everything:
DTurboKiller: Hello JS.
JudgeSpear: yoyoyo.
DTurboKiller: I think I found a performance hog in MKF, but I'm not completely sure.
JudgeSpear: We found two memory leaks in MKF that we just fixed.
DTurboKiller: The brick, coin/powerup/etc blocks, don't they all have step events (looking for stuff constantly, even if it isn't there)? Couldn't we borrow some of the terrain collision code for this?
JudgeSpear: I never looked at the coding for those things
JudgeSpear: It could be possible
DTurboKiller: Well, while I was "jokingly" making level 1-2 from SMB, using all the bricks, I noticed how much the FPS would drastically lower. I checked the code, and guess what? It's those damn step events. Perhaps Obreck could take a look at this.
DTurboKiller: It went as low as little more than 20 FPS, where without them I would get close to 60.
JudgeSpear: It's not just the step events...
JudgeSpear: Instances in general in a room tend to slow things down immensely.
JudgeSpear: I'll bring this issue up to Obreck too
JudgeSpear: did you make apost of this in the forums?
DTurboKiller: No. I was going to check the code first in the Dev Source, but I have to get GM7 again...
JudgeSpear: I will go check.
DTurboKiller: Thanks for listening
And so he goes, after a while...
JudgeSpear: Anything we can do to make this game less CPU-demanding will be excellent
DTurboKiller: I know, I'll try to experiment with different objects. First technique will be to make a test room and spam them with a single object, preferably with step events and the like, and see what happens.
JudgeSpear: And yes
JudgeSpear: The coins and blocks themselves have Step events
JudgeSpear: Wow
JudgeSpear: so if you fill a room with coins and blocks, it's a big lag issue
JudgeSpear: Be sure you post about this finding in case I forget to myself
DTurboKiller: Also, I'm pretty sure there was a script somewhere at the GM forums where you could deactivate instances when they're far away from you, say, a distance of 3 game rooms
DTurboKiller: Your view, that is.
JudgeSpear: I can easily put all coin and block collision events into the Mario player object
DTurboKiller: I know, it would pretty much be a code borrow for the terrain collision
JudgeSpear: There is already a system in place to deactivate instances not in view
DTurboKiller: That's nice to hear.
DTurboKiller: How much distance is needed to deactivate instances?
JudgeSpear: 16 pixels outside the view
JudgeSpear: 1 block
JudgeSpear: It's just that, right now, the coding is quite inefficient
JudgeSpear: and Obreck Psychopath, and I are trying to fix up these problems that have existed since the original hello Engine III
DTurboKiller: There's always room for tweaking. I hope we can find out more about them.
DTurboKiller: But a definite performance tip is to avoid Step events as much as possible.
JudgeSpear: The Step Events for coins and blocks should be a step forward
JudgeSpear: Like I said
JudgeSpear: I never looked at the coding of those things
JudgeSpear: So I wouldn't have known
DTurboKiller: Glad I helped you with this
JudgeSpear: I basically picked up someone else's engine and built upon it
JudgeSpear: at the same time, I was also learning Game Maker
DTurboKiller: I have very little experience with Game Maker, unfortunately.
DTurboKiller: But I made my own Game Maker games when I was 10 years old, though they are terrible
JudgeSpear: I now know enough to be able to make my own game engine.
JudgeSpear: <-- Like this. *shows SHMUP game*
...
Well, that's it. If you find any performance problems, do tell.
Also, I'll try to find more performance issues as soon as I reinstall GM7 and the Dev Source.