First of all, look carefully at the sprites and backgrounds you use. Animated sprites take a lot of memory and drawing lots of sprites takes a lot of time. So make your sprites as small as possible. Remove any invisible area around it (the command crop in the sprite editor does that automatically). The same applies to background images. If you have a covering background, make sure you switch off the use of a background color.
If you use full screen mode, make sure the size of the room (or window) is never larger than the screen size. Most graphics cards can efficiently scale images up but they are more slow in scaling images down! Whenever possible, switch off the cursor. It slows down the graphics.
Also be careful with the use of many views. For each view the room is redrawn.
Besides the graphics, there are also other aspects that influence the speed. Make sure you have as few instances as possible. In particular, destroy instances once they are no longer required (e.g. when they leave the room). Avoid lots of work in the step event or drawing event of instances. Often things do not need to be checked in each step. Interpretation of code is reasonably fast, but it is interpreted. Also, some functions and actions take a lot of time; in particular those that have to check all instances (like for example the bounce action).
Think about where to treat the collision events. You normally have two options. Objects that have no collision events at all are treated much faster, so preferably treat collisions in those objects of which there are just a few instances.
Be careful with using large sound files. They take a lot of memory and also compress badly. You might want to check your sounds and see whether you can sample them down.
Finally, if you want to make a game that many people can play, make sure you test it on older machines.
| Converted from CHM to HTML with chm2web Pro 2.85 (unicode) |