[GM6/GM7] speed and size issues

[Godmaster]

After seeing that topic about MMf2 file size issues I got some questions about Game Maker. Today I use the GM7 instead of GM6, beside that can compile GM games in Windows Vista, but I didn't noticed any difference about memory and speed issues.

My BrazSonic 2, has almost 8MB of filesize, and consumes between 150 and 200 MB of RAM when I compile that, even with: preloaded resources, external heavy gfx (like movies), object deactivaction (not for tiles), scripted functions for character gameplay (to avoid the mess on their gml), moving platforms by instance_id, draw events only when the object is visible, and separated sprites for animations.

Who played my game knows what I talking about. That ran slow in pcs below to 1.5 ghz...

I think that could run my game much better than other times, but it doesn't... it runs fine on my not-so-very-old PC (3ghz of processor and 512 of RAM), but there's many hic-ups caused by preloaded resources (like scenery objects and improvised event sensors).

Obs: in my older pc (a Pentium 3. 650mhz with 320 of ram) this runs veeeeery slow.

This makes me angry, damn it's impossible to make that you want runs perfectly to others ¬¬

How I decrease the gmk filesize?

How I decrease the loading time?

Is there a way to deactivate out of view tiles?

Is true that deleting and adding even more sprites in the project can make that gain weight?

Is scripted functions works slower than in-event code ones?

What's the best way to deactivate objects?

Why draw_sprite_ext slows the game?

[VectorSatyr]

Consider these:

• Decrease filesize by cropping sprites.
  
• Sprite resolution can effect the filesize.
  
• Decrease load time by decreasing the number sprites that are "preloaded."
  
• Tiles that are not in view are not drawn, and therefore do not need deactivating.
  
• Drag-and-drop executes faster than GML, but is also harder to organize.
  
• Create a parent object for the purpose of deactivation. Make all deactivable objects children of that parent, and deactivate the parent. Reactivate only the objects of that parent that are within the view.
  
• DrawSpriteExt uses color blending, rotation, and transparency. Think about it.
  

[Kain]

# Drag-and-drop executes faster than GML, but is also harder to organize.

I'm pretty sure just the opposite is true, actually (in terms of speed, anyway). And my (very brief) test seem to agree.

# DrawSpriteExt uses color blending, rotation, and transparency. Think about it.

But the thing is Game Maker (versions 6 and higher) is built on top of the DirectX library with alpha and color defined inside the coordinates. So even if you're not using color and alpha, you are (namely a color of c_white and an alpha of 1). Also all vertices go through a world, camera, and perspective transform, so whether you rotate the world transform or not, it'll take roughly the same amount of time.

The reason you experience a small boost when letting the object draw itself is probably because of the time it takes Game Maker to run an event and parse a fairly complicated function (i.e. one with lots of arguments). I wouldn't draw everything with draw_sprite_ext, but if you can't avoid it, or you'd have to create and coordinate tons of separate objects, I wouldn't bother worrying.

As for the deactivation issue, deactivating objects is slower than deleting and creating them. Dami made an object management system a while back that used sectors and such to create a faster deactivation system for objects that do not need to remember their previous actions/states when they leave the screen. It could work great for level pieces. As for other things, it depends on your game.

Is true that deleting and adding even more sprites in the project can make that gain weight?

There is some residual file space. But it's not that significant even if it increased linearly.

[Godmaster]

As for the deactivation issue, deactivating objects is slower than deleting and creating them. Dami made an object management system a while back that used sectors and such to create a faster deactivation system for objects that do not need to remember their previous actions/states when they leave the screen. It could work great for level pieces. As for other things, it depends on your game.

Yes, I tried to use that on a side project and I noticed that would be more useful only for static instances, like scenery, rings, monitors, etc. Maybe I use that only for this, and for moving instances that can travel far distances and can be deactivated without being reseted (that the Dami method does), like enemies I should use the instance_deactivate_region function to only deactivate that instances. But that doesn't deactivate instances, just objects.

So, I'll have to make to ways of deactivating in a single level.

But the thing is Game Maker (versions 6 and higher) is built on top of the DirectX library with alpha and color defined inside the coordinates. So even if you're not using color and alpha, you are (namely a color of c_white and an alpha of 1). Also all vertices go through a world, camera, and perspective transform, so whether you rotate the world transform or not, it'll take roughly the same amount of time.

The reason you experience a small boost when letting the object draw itself is probably because of the time it takes Game Maker to run an event and parse a fairly complicated function (i.e. one with lots of arguments). I wouldn't draw everything with draw_sprite_ext, but if you can't avoid it, or you'd have to create and coordinate tons of separate objects, I wouldn't bother worrying.

I tried to use on minor enemies, that uses 360 physics, instead of using draw_sprite_ext, using sprite_index for sprite change, image_index to animations_frame, and image_angle for the character's angle. Only sprite_blend that doesn't work at all ¬¬ (whatever blend you input, the sprite goes black o.O)

Decrease filesize by cropping sprites.

Sprite resolution can effect the filesize.

image frames can affect the memory usage on compiling too?

Decrease load time by decreasing the number sprites that are "preloaded."

All of scenery sprites are preloaded... so, that should that annoying fps "hic-ups"

Create a parent object for the purpose of deactivation. Make all deactivable objects children of that parent, and deactivate the parent. Reactivate only the objects of that parent that are within the view

As I said above about the Kain reply, for non-deactivating and non-static objects I create a parent, and for the static ones I created another to be processed by the Grid Spacial Indexing. And I need to find a way to only deactivate a kind of object where its instances finds out of view.

[dark team]

I think that you'll have to use very much external resource loading. Because there is (was) a problem with gm6 because of too much resources it can't compile the exe, if it can it makes it corrupt. I'm not sure about this with gm7 but still to lower the filesize you'll need to use external resources loading. Btw gm6 exes can be made to load on vista:

http://www.yoyogames.com/wiki/show/44

[Kain]

Only sprite_blend that doesn't work at all ¬¬ (whatever blend you input, the sprite goes black o.O)

You mean "image_blend?" You know to set it to a color, like c_white or c_red?

image frames can affect the memory usage on compiling too?

The resources themselves don't get compiled, so yes. (Actually, in game maker, nothing gets compiled. So actually white space in code wastes memory/time, it's just utterly insignificant)