Linepicks/Camerapicks/Entitypicks
Writepixel(fast),Readpixel(fast),plot,getcolor - when performed on large areas of the screen (or smaller areas on slower machines)
Nested for loops with large numbers of iterations in each loop. For example if you were to do something like this every frame it would have an impact:
Also, using vertexcoords, vertextexcoords, vertexcolor commands on meshes with many vertices will affect speed regardless of how many vertices you actually alter.
Using collision method 2 (ellipsoid - polygon) can slow things down if the object using the polygon collision detection is complex. It can be better, for example with a level, to create a nice detailed level as normal but to create a much simpler mesh which is hidden using entityalpha mesh,0.0 and using that for collision detection instead.
Using many sprites (3d) instead of single surface quads. Obviously the more powerful the system the more sprites that you can get away with using - so a small number (define small?) should not be a problem overall but many of them can cause a performance hit.
Using hideentity/showentity when an entity is out of the camera frustrum is of no use - but using hide/show entity when an entity is out of view but in the camera frustrum can reduce overdraw (drawing same pixels twice). However if you start using linepicks or other slow line-of-sight checks to determine this before hiding then that will slow things down. If you are going to hide entities and show them based on Line of Sight then it can be worthwhile to precalculate zones where objects are visible to each other in your level, say in a 3 dimensional array for which each value represents a cube of the level and holds a pre-prepared list (perhaps using banks) of which other zones can 'see' each other.
Using text commands in 3d or using drawimage/drawblock commands in 3d mode with large images (once again - define large it all depends on the system you are aiming for).
Writepixel(fast),Readpixel(fast),plot,getcolor - when performed on large areas of the screen (or smaller areas on slower machines)
Nested for loops with large numbers of iterations in each loop. For example if you were to do something like this every frame it would have an impact:
For Creature.CreatureList =each CreatureList For OtherCreature.CreatureList=each CreatureList ;assuming many hundreds/thousands of creatures in the list ;place a decent number of calculations here such as checking if each creature can see each other or is within a certain distance. next next
Also, using vertexcoords, vertextexcoords, vertexcolor commands on meshes with many vertices will affect speed regardless of how many vertices you actually alter.
Using collision method 2 (ellipsoid - polygon) can slow things down if the object using the polygon collision detection is complex. It can be better, for example with a level, to create a nice detailed level as normal but to create a much simpler mesh which is hidden using entityalpha mesh,0.0 and using that for collision detection instead.
Using many sprites (3d) instead of single surface quads. Obviously the more powerful the system the more sprites that you can get away with using - so a small number (define small?) should not be a problem overall but many of them can cause a performance hit.
Using hideentity/showentity when an entity is out of the camera frustrum is of no use - but using hide/show entity when an entity is out of view but in the camera frustrum can reduce overdraw (drawing same pixels twice). However if you start using linepicks or other slow line-of-sight checks to determine this before hiding then that will slow things down. If you are going to hide entities and show them based on Line of Sight then it can be worthwhile to precalculate zones where objects are visible to each other in your level, say in a 3 dimensional array for which each value represents a cube of the level and holds a pre-prepared list (perhaps using banks) of which other zones can 'see' each other.
Using text commands in 3d or using drawimage/drawblock commands in 3d mode with large images (once again - define large it all depends on the system you are aiming for).