Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1362990 Posts in 63661 Topics- by 55543 Members - Latest Member: Gaban

July 17, 2019, 09:22:41 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityTownhallForum IssuesArchived subforums (read only)TutorialsGame Maker: Optimizing For Speed/Memory
Pages: 1 2 [3]
Print
Author Topic: Game Maker: Optimizing For Speed/Memory  (Read 104165 times)
Tokyoma
Level 1
*

wut


View Profile
« Reply #40 on: November 30, 2008, 02:49:48 AM »

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.
Logged
ஒழுக்கின்மை
Level 10
*****


Also known as रिंकू.


View Profile WWW
« Reply #41 on: December 03, 2008, 03:11:26 PM »

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.
Logged

Zaphos
Guest
« Reply #42 on: December 04, 2008, 12:22:18 PM »

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)
Logged
ஒழுக்கின்மை
Level 10
*****


Also known as रिंकू.


View Profile WWW
« Reply #43 on: December 04, 2008, 12:27:35 PM »

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.
Logged

MrLollige
Level 0
**


Pixel artist


View Profile WWW
« Reply #44 on: December 09, 2008, 01:07:06 AM »

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!
Logged

mirosurabu
Guest
« Reply #45 on: December 19, 2008, 04:26:53 AM »

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.
Logged
ஒழுக்கின்மை
Level 10
*****


Also known as रिंकू.


View Profile WWW
« Reply #46 on: December 19, 2008, 09:44:47 AM »

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).
Logged

Mr Dumle
Level 1
*



View Profile
« Reply #47 on: December 25, 2008, 10:52:16 AM »

Question:

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

ஒழுக்கின்மை
Level 10
*****


Also known as रिंकू.


View Profile WWW
« Reply #48 on: December 25, 2008, 11:28:59 AM »

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.
Logged

Eclipse
Level 10
*****


0xDEADC0DE


View Profile WWW
« Reply #49 on: December 27, 2008, 03:17:12 AM »

Quote
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.

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

<Powergloved_Andy> I once fapped to Dora the Explorer
TeeGee
Level 10
*****


Huh?


View Profile WWW
« Reply #50 on: December 27, 2008, 03:50:46 AM »

Quote
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.

 Shocked
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.
 
« Last Edit: December 27, 2008, 07:09:44 AM by TeeGee » Logged

Tom Grochowiak
MoaCubeBlog | Twitter | Facebook
ஒழுக்கின்மை
Level 10
*****


Also known as रिंकू.


View Profile WWW
« Reply #51 on: December 27, 2008, 03:53:52 AM »

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.
Logged

Jordan
Level 1
*


One time known as Flaming Pear.


View Profile WWW
« Reply #52 on: November 04, 2009, 05:01:28 PM »

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

Hideous
That's cool.
Level 10
*****


3D models are the best


View Profile WWW
« Reply #53 on: November 06, 2009, 05:37:16 AM »

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.
Logged

fafafrei
Level 0
*


View Profile
« Reply #54 on: August 14, 2016, 07:25:03 AM »

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?
Logged
Pages: 1 2 [3]
Print
Jump to:  

Theme orange-lt created by panic