next »

[Tokyoma]

I think vsync does work, in that it keeps you in synch with the screen's refresh cycle. It just seems to put you at the wrong place in the cycle. But it can still be made to work -- see the other thread: http://forums.tigsource.com/index.php?topic=3711.msg109620#msg109620

Speaking back on the topic of vsync: it seems that using the image_xscale and image_yscale variables can cause for some nasty tearing. I've always defaulted to using variables named just xscale and yscale. Also using views in GM seems to have have an adverse effect as well sometimes I have to make the view or the port one or two pixels over or under for everything to scale properly.

However, more-so towards the topic of optimization, my current project is a multi-player GM game that is all run in a while(1) loop. The reson for this is that I hope to achieve UDP lockstep between all of the clients. So that there is a global game speed and no game logic is executed until all clients are sure they're on the same step. And of course only the "hosting" client has final say in any collisions or definite variable status.

[ஒழுக்கின்மை (Paul Eres)]

That's a good technique. I've never gotten multiplayer games in GM to work well, mainly because I can't seem to figure out how to implement dead reckoning.

[Zaphos]

That's a good technique. I've never gotten multiplayer games in GM to work well, mainly because I can't seem to figure out how to implement dead reckoning.

The basic idea should just be predicted_pos = last_pos_sent + last_vel_sent*time_since_sent ...
And then if ((predicted_pos - current_pos).magnitude() > acceptable_error) don't bother sending the actual current pos over the network; other clients will use the predicted_pos instead (since that was computed exclusively with info you already sent out)

[ஒழுக்கின்மை (Paul Eres)]

That second part sounds like a great optimization, I didn't think of that.

I think the problem is that GM's timing system is only accurate to the nearest 60th of a second or something, which may leads to errors in multiplayer action games, so perhaps I should combine the timing dll with a multiplayer dll.

My biggest regret about my game Alphasix is that it plays best when players play against one another, yet without online multiplayer the only way they could do that is on one computer, and not everyone has a friend at home. One day I plan to add online multiplayer to it, I tried twice before and failed.

[MrLollige]

Very nice writing Derek!

This really inspires me to try game maker again, as it still is the most easy and accessible way to get your ideas working!

[mirosurabu]

So just a toss up question.  Say for a particle system.  Is it better to have an object that maybe has an array of every particle currently on screen, and have it loop through that array to control and draw them?  Instead of each particle being an object that behaves independently.

Such practice is always good when you program in C++. I guess it applies to GM as well.

Speed optimization may come from the fact that when you don't use objects you are not having additional code running in the background and you are not using memory more than you actually need it. With general-purpose objects there always may be a portion of code and memory which is not necessary for your specific needs.

Though, depending on what kind of behavior you want to apply to your particles it may do nothing for performance and memory usage.

[ஒழுக்கின்மை (Paul Eres)]

GM has its own particle system and I'd recommend using that for most of your particle needs because it's much faster than doing it yourself (either with objects or with arrays) and it's fairly robust, and can do most anything you'd want out of a particle system (with some exceptions).

[Mr Dumle]

Question:

Will my game run faster if I make my objects invisible(no sprite) and instead use tiles?

[ஒழுக்கின்மை (Paul Eres)]

Usually no, sometimes yes, it depends on the situation and circumstance. It depends on the rate-limiting factor in your particular game. If it's the fill-rate, then changing a sprite for a tile of equivalent size will do nothing. If it's the code interpretation, adding a draw event and more code to display a tile instead of just having GM automatically display its sprite may work slower. Tiles also work slower than backgrounds, because there's additional processing regarding where you partition them. Also, if an object is set to invisible, it will not execute its draw event at all, so you won't see anything: either way an object has to be visible, unless it's a third-party object drawing the sprites/tiles for all the other objects, which also may be faster or may be slower depending on the circumstance. So the best I can recommend is to experiment and see for yourself, but if your game is already running at an okay speed there's no reason to do all these optimizations, the whole point of GM is to make making games easier.

[Eclipse]

640x480 is fine for most games. I kind of regret making [Immortal Defense] 1024x768 -- it looks nice, but just the fill rate makes it much slower. Use dedicated resolutions, they work faster than windowed and much, much faster than stretched.

 
the world seriously needs a better game editor than this one :\

[TeeGee]

640x480 is fine for most games. I kind of regret making [Immortal Defense] 1024x768 -- it looks nice, but just the fill rate makes it much slower. Use dedicated resolutions, they work faster than windowed and much, much faster than stretched.

 
the world seriously needs a better game editor than this one :\

Don't take Rinku's words too literally. That he said he thinks 640x480 is enough for most game is his personal opinion, not GM's limitation. Of course, lower resolution always means less fillrate for any game, but it's not like GM can't handle more. ArcMagi is in 1024x768, very heavy on graphical effects, and still has no trouble running even on a 6 years old laptop with integrated Intel graphic card.

Also, Rinku's games tend to be more CPU heavy because of the coding techniques he uses (checking most stuff every "Step" instead of using dedicated events) and general architecture of his games. Still, Immortal Defense ran smoothly on my old Celeron 1100MHz with GeForce5500fx.
 

[ஒழுக்கின்மை (Paul Eres)]

Also note that even modern 3D games run much faster at lower resolutions. I was playing through Defense Grid, and even on my 3.2 core 2 duo cpu / NVIDIA 8500GT video card / 2 GB of RAM computer, it ran slow on my monitor's preferred resolution of 1440x900, so I reduced it to 800x600 and it ran fine.

[Jordan]

I know this is old, but just wanted to say thanks for the thread Derek, and to everyone who contributed.

[Hideous]

Also note that even modern 3D games run much faster at lower resolutions. I was playing through Defense Grid, and even on my 3.2 core 2 duo cpu / NVIDIA 8500GT video card / 2 GB of RAM computer, it ran slow on my monitor's preferred resolution of 1440x900, so I reduced it to 800x600 and it ran fine.

NVIDIA 8500GT video card

That's your problem right there, sonny.

[fafafrei]

One of the more common optimization techniques for game engines in general is object pooling, where objects are reused from a pool rather than being allocated and destroyed constantly. This technique is especially popular for bullet-hell games. 

However, it doesn't really look like object pooling is a thing in Gamemaker Studio, as I have found absolutely no information for the technique in this engine. Does anyone know why this is?  Is something going on at a lower-level that I don't know about, or is there something else I may be missing?