Jump to content


Photo

Speeding Things Up


  • This topic is locked This topic is locked
540 replies to this topic

#1 RandomBlackMage

RandomBlackMage

    We all look alike

  • New Member
  • 325 posts

Posted 09 February 2006 - 02:01 AM

Many GM games at one time or another run into the obligatory problem we all know, slowdown. Things like the dreaded midi hiccup, and the horrible lag experienced when creating many instances of an object. There are also some functions which should be pretty much avoided unless you plan to have your game slow down to a crawl.

I've learned that pathfinding in multiple instances all at the same time (especially with the A* algorthirm) can kill a game with slowdown. Instead, create a group path, and let the little things handle the rest.

Also, creating mass amounts of instances of an object at the same time can be ghastly. If you have to create a large number of objects, do it a few a step, or deactivate objects outside the view so that the memory will be cleared, allowing more processing for what's important at the moment.

Another thing you can do is increase the priority of your game in the game options. This will make your game run faster, but you'll probably make many users mad when setting it to highest, as all other processes will pretty much be ignored, so this is usually a bad idea unless absolutely necessary.

So now, I ask you a question. What are your techniques for speeding games up? What are some of the functions you know to cause slowdown if used frequently like in the step event? What can you do instead of the afformentioned things to get the same desired affect? Please post any of your answers here.

Edited by xot, 13 April 2008 - 06:13 AM.
** Old Experts Topic **

  • 0
Current Project: Necromancer - Posted Image Chapter 1 Full Demo scheduled for release around October.

#2 Tarik

Tarik

    GMC Member

  • GMC Member
  • 2731 posts
  • Version:GM:Studio

Posted 10 February 2006 - 06:24 PM

Well, one thing that's important to know is that the game is drawn for every view. So that you will draw everything multiple times with multiple views. Minimising the amount of views is a good idea.

Secondly, controlling the amount of memory your resources consume is an important aspect of making a smooth game as well. Freeing memory and loading them at the correct times can make gameplay smoother.

Migth post some more stuff later.
  • 0

#3 Tobs

Tobs

    GMC Member

  • New Member
  • 599 posts

Posted 10 February 2006 - 06:48 PM

A nice one is to disable all views, don't set any sprites (only collision masks), and draw only the things you need to...
if x<room_width && y<room_heigh{
draw object
}
Which could add to speed if you optimise it enough.
Skipping a frame every few seconds could also help, but may make the game choppy or too fast...
Deleting the objects you don't need also boosts speed, or setting visible to false if the object is far from the player

Generally, don't do anything that isn't optimised

Tobs
  • 0

#4 takua108

takua108

    GMC Member

  • GMC Member
  • 582 posts

Posted 10 February 2006 - 11:05 PM

Hows about using an external resource loader, like the ones in the Extending GM forum? If you use them correctly to only load resources when you need them (i.e. before a level), you can drastically cut not only the game pre-load time (which greatly annoys users, if you can load a titlescreen and then a loading screen for the selected level, that's not as bad).
  • 0

#5 Potnop

Potnop

    GMC Member

  • GMC Member
  • 3103 posts

Posted 11 February 2006 - 06:09 AM

Well a lot of people leave on the checkboxes in sprite options for use video memory and precise checking and stuff. Leave those off mostly, and the game runs A LOT faster. I've been doing that since my noob GMing days.

Also deactivating thisngs REALLY helps, although this has been said already. Especially if U have AI or soemthing. I usually deactivate most instances that are like 200 pixels outside the view, and leave some on if needed.
  • 0
Vegeta! What does the scouter say about his powerlevel?!? It's ovER 9000!!!!!
I ownt read da script, script reads me.


Link To The Super Crew Topic / Link To Colonial Commando Topic
Platform Pathfinding Example Download it here!
Editable Early Version Level Editor(Nice @$$ stuff, check it out) Download it here!

#6 HaRRiKiRi

HaRRiKiRi

    GMC Member

  • GMC Member
  • 1364 posts

Posted 11 February 2006 - 09:26 AM

And making the room small is good too. In my RPG room is 640x480. So it dosnt slow the game down. And I don't use seperate objects for buttons, inventory and stuff like that. Like menu is one object. Upgrading skills is another object and so on. And I am making everything in scripts. So I don't need to change any code in objects.

And I load very sprite from files. There is no sprites in the games. So i loads very fast. And I gues it helps for game speed itself too.

I only don't know how to make deactivating system. If I make object deactivate when it is outside the view. It will deactivate then, but i don't know how to activate it again. Becose if it is deactivated it cannot check any variables. I wound want to know how to make that If is outside the room Deactiavet. If inside Activate again.

Edited by HaRRiKiRi, 11 February 2006 - 09:45 AM.

  • 0

#7 takua108

takua108

    GMC Member

  • GMC Member
  • 582 posts

Posted 11 February 2006 - 07:08 PM

...use a controller object?
  • 0

#8 lewa

lewa

    GMC Member

  • New Member
  • 587 posts

Posted 13 February 2006 - 06:07 PM

Well, its really a BUNCH of small things that make the overall speed faster.
Unless the object has to percisely bounce off other stuff, disable percise coll checking. Try to have the transparent background for sprites black, or at lest black with a red value of 1 (rgb=1,0,0).
Use srtictly code for stuff like.. dots that fade away etc. Dont use objects for petty stuff. Because then it has to calculate bbox stuff, sprites, paths, events, direction etc etc.

Also, make your code clean. Stuff like 'then' statements, or
if var=1{
destroy()
}
dont use unnececary blocks of code.

Discernment is needed in so many areas... So you just have to use your brain, and try your best to conserve processing power.
  • 0

Supercilious, I know. Sorry. I blame GIMP.

#9 nickydude

nickydude

    MadLad Designs

  • GMC Member
  • 626 posts
  • Version:GM:Studio

Posted 13 February 2006 - 06:28 PM

1/. Only put what is absolutley necessary in the players Step Event. For example, there's no use checking in the player's Step Event if all the aliens on the level have been killed, that's 30 time per second you're cheking! Place that collision detection in the aliens collision event with the bullet.

// Collision event between enemy & bullet
if instance_number(enemyparent)<1
{
//
}
2/. Use parents where possible. Instead of checking between the player's bullet and enemy01, the player's bullet and enemy02, the player's bullet and enemy03. . . . . . Just create a blank object for a parent [enemyparent] and make all the enemy's have the enemyparent. All you need to do now is check for one collision, between bullet and enemyparent! [see code is number 1]
  • 0

My Specs: Windows 7, 2047MB NVIDIA GeForce GTX 660,  Intel Core i5 3330 @ 3.00GHz, 8GB Ram.


#10 yahn

yahn

    GMC Member

  • New Member
  • 331 posts

Posted 14 February 2006 - 03:47 AM

i found that games not only load much faster, but also appear to run considerably faster when you leave your resources external from the exe. i can't really find an explanation for games running faster (loading faster is kind of obvious) but from the few projects i've worked on this has been the case.

some people say that its better to use an instance to act as an object rather than an array. in the game i'm working on its proving to be just the oposite. i found if you don't need things like collision checking or direction/speed its a lot faster to just use an array.

nickydude pointed out that you shouldn't do thigns in the step event that can be done using an alarm or in another event, its also important to note that you should never do anything in the draw event besides drawing.

if you need a variable for something in the draw event, calculate the value for that variable in the create event and then use that in the draw event. don't calculate the value for that variable in every draw event (unless its something that is going to change from step to step).

another thing you may not notice is constantly calculating the same value over and over again. for example a code like this:
if (object.x + 2 > x)
{
       x = object.x + 2;
       object2.x = object.x + 2;
       draw_text(x,y,string(object.x +  2));
}

should be written like this
var x2;
x2 = object.x + 2;

if (x2 > x)
{
       x = x2;
       object2.x = x2;
       draw_text(x,y,string(x2));
}

for something as simple as this it may not speed your game up. it may actually slow your game down. but for longer calculations it will surely show you improvements.
  • 0

#11 Timmo

Timmo

    GMC Member

  • New Member
  • 558 posts
  • Version:GM:HTML5

Posted 14 February 2006 - 04:24 AM

When you don't need anything, destroy it. Eg bullets, when they are outside room, destroy them.
  • 0

Posted Image Posted Image


#12 Cloud Tower

Cloud Tower

    Transition Master!

  • New Member
  • 286 posts

Posted 15 February 2006 - 07:49 PM

Use the Create event to draw the things on the screen, is faster than using a draw event, also set your room size to 1, 1 so like that it takes less memory, and freeze every object outside a view. :P
  • -1

#13 timewarp

timewarp

    GMC Member

  • New Member
  • 440 posts

Posted 15 February 2006 - 08:56 PM

@Cloud Tower
Neither of those suggestions work. Nothing can be drawn in the create event, only in the draw event. Even if you could draw something in the create event, it would have to be stationary and not animated. And making a room only one pixel like that is completely useless to everyone here, as that would be the size of the window, and the view would be limited to that 1x1 size.

Edited by timewarp, 15 February 2006 - 08:58 PM.

  • 0

#14 lalle_calle

lalle_calle

    GMC Member

  • Validating
  • 392 posts

Posted 15 February 2006 - 09:06 PM

And making the room small is good too. In my RPG room is 640x480. So it dosnt slow the game down. And I don't use seperate objects for buttons, inventory and stuff like that. Like menu is one object. Upgrading skills is another object and so on. And I am making everything in scripts. So I don't need to change any code in objects.

And I load very sprite from files. There is no sprites in the games. So i loads very fast. And I gues it helps for game speed itself too.

I only don't know how to make deactivating system. If I make object deactivate when it is outside the view. It will deactivate then, but i don't know how to activate it again. Becose if it is deactivated it cannot check any variables. I wound want to know how to make that If is outside the room Deactiavet. If inside Activate again.

<{POST_SNAPBACK}>



here is what you want put it in all the step events you are using
it makes the object unactive it will only execute this pice of code then exit
if room_width<x or room_height<y{exit;}

Edited by lalle_calle, 15 February 2006 - 09:06 PM.


#15 Cloud Tower

Cloud Tower

    Transition Master!

  • New Member
  • 286 posts

Posted 15 February 2006 - 09:50 PM

@Cloud Tower
Neither of those suggestions work. Nothing can be drawn in the create event, only in the draw event. Even if you could draw something in the create event, it would have to be stationary and not animated. And making a room only one pixel like that is completely useless to everyone here, as that would be the size of the window, and the view would be limited to that 1x1 size.

<{POST_SNAPBACK}>


What? I tried it and it worked, all you have to do is check off the box that displays 'Draw Background Color' and have no backgrounds in the room. ^_^

Edited by Cloud Tower, 15 February 2006 - 09:51 PM.

  • 0

#16 timewarp

timewarp

    GMC Member

  • New Member
  • 440 posts

Posted 15 February 2006 - 10:02 PM

Ok, so now you have a stationary and unanimated sprite in the middle of a black screen. If you were to try and move the object, it wouldn't work, as the create event only gets executed once. If it was executed in the step event, first of all, the screen doesn't refresh, and secondly, it would be slower, as any interpreted GML will undoubtebly run slower than the compiled and built-in functions. It really will not accomplish anything worthwile, too many pitfalls.
  • 0

#17 RhysAndrews

RhysAndrews

    Game Designer

  • GMC Member
  • 2013 posts
  • Version:GM:Studio

Posted 16 February 2006 - 07:35 AM

Also deactivating thisngs REALLY helps, although this has been said already. Especially if U have AI or soemthing. I usually deactivate most instances that are like 200 pixels outside the view, and leave some on if needed.


This can be hard to do, because you can't check if an instance is deactivated or not, so you'll continually have to reactivate the instance if it's in the view, not activate it ONCE when it comes into the room.. and that lags the game pretty badly.

I'd actually love to know a FAST and BENEFICIAL method of using deactivation. Because this method (that i wrote) actually gives a huge spike of lag every time it scans.

Init:

/*This scripts initiates a list of object IDs that the player must scan through;
If any of those IDs are not needed, they are deactivated, boosting overall performance.
If they are deactivated and inside the view, they will be reactivated.*/
deac_list = ds_list_create(); //Create the Deactivation List
with(objObstacle_water){ds_list_add(other.deac_list,id)} //Adds all the IDs of a certain object to the list
with(objObstacle_wall){ds_list_add(other.deac_list,id)} //Adds all the IDs of a certain object to the list
with(objObstacle_crate){ds_list_add(other.deac_list,id)} //Adds all the IDs of a certain object to the list
with(objDummy){ds_list_add(other.deac_list,id)} //Adds all the IDs of a certain object to the list
with(objDummy2){ds_list_add(other.deac_list,id)} //Adds all the IDs of a certain object to the list
with(objBasic_shooter){ds_list_add(other.deac_list,id)} //Adds all the IDs of a certain object to the list


Scan (every time this is executed i get a spike of lag. I usually set an on-going alarm to say 50 frames, scanning every 50 frames. The larger the bigger gaps of time between spikes of lag, yet the longer it takes for instances to become visible again when they come into view):

/*This scripts scans the deactivate list, deactivating/reactivating needed
instances..*/
var ins,border;
border=300
for(i1=0;i1<ds_list_size(deac_list);i1+=1){
    ins=ds_list_find_value(deac_list,i1)
    instance_activate_object(ins)
    if (ins.x < view_xview[0]-border || ins.x > view_xview[0]+view_wview[0]+border) || (ins.y < view_yview[0]-border || ins.y > view_yview[0]+view_hview[0]+border){
        ins.deacalpha=0
        instance_deactivate_object(ins)}
        else {instance_activate_object(ins)}
}


Alpha (Step event of all instances that are deactivated/reactivated; It makes them fade back in when going into the view instead of appearing out of nowhere):

/*This script is executed in step events (or draw events) of all obstacles
that are deactivated with the deactivation system. It simply fades the instances
in if their variable is set to 0 (which is done when they're activated).*/
if deacalpha<1 {deacalpha+=0.1 image_alpha=deacalpha}


Thanks
-Rhys

Edited by RhysAndrews, 16 February 2006 - 07:58 AM.

  • 0

banner4.jpg


#18 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7522 posts
  • Version:GM:Studio

Posted 16 February 2006 - 08:53 AM

Rhys,

Did you miss a part of the manual? You can activate and deactivate instances inside or outside a region. Your code can be replaced by this:

 instance_activate_all();
  instance_deactivate_region(view_xview[0],view_yview[0],
                        view_wview[0],view_hview[0],false,true);

And you don't actually need to fade in and out instances when they enter the region if you use borders around the view - they will be activated before you see them.

Border with could be implemented like this (assuming the largest sprite is 32x32):

 instance_activate_all();
  instance_deactivate_region(view_xview[0]-32,view_yview[0]-32,
                        view_wview[0]+32,view_hview[0]+32,false,true);

(Of course, if the sprite's origins are at 0,0 you don't really need a border at the right and the bottom of the view, but you get the idea).

I know it seems inefficient to first activate all, then deactivate a portion of it, but the built-in functions of Game Maker are by far faster at this than your scripted alternative.

Smarty
  • 0

#19 RhysAndrews

RhysAndrews

    Game Designer

  • GMC Member
  • 2013 posts
  • Version:GM:Studio

Posted 16 February 2006 - 09:06 AM

So I see. I used the alpha because i had 50 frames per scan, And unless i had a gigantic border the view-speed could beat the alarm.

I'll try that out, thanks
-Rhys

EDIT: Ah, now i remember why i didn't use region. You see from the scripts, i'm only deactivating static instances.. thinking about it i could use notme and make the object calling the region-script a parent for all objects NOT to be deactivated....

-Rhys

Edited by RhysAndrews, 16 February 2006 - 09:07 AM.

  • 0

banner4.jpg


#20 Bathy

Bathy

    GMC Member

  • New Member
  • 504 posts

Posted 16 February 2006 - 09:06 AM

@Cloud Tower
Neither of those suggestions work. Nothing can be drawn in the create event, only in the draw event. Even if you could draw something in the create event, it would have to be stationary and not animated. And making a room only one pixel like that is completely useless to everyone here, as that would be the size of the window, and the view would be limited to that 1x1 size.

<{POST_SNAPBACK}>


What? I tried it and it worked, all you have to do is check off the box that displays 'Draw Background Color' and have no backgrounds in the room. :)

<{POST_SNAPBACK}>

^_^
  • 0

#21 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7522 posts
  • Version:GM:Studio

Posted 16 February 2006 - 10:57 AM

So I see. I used the alpha because i had 50 frames per scan, And unless i had a gigantic border the view-speed could beat the alarm.

Because of the extreme lag you had to put it in a timer and execute it every x frames, but instance activation and deactivation should best be done every step.

As an extra piece of advice, put it in some object's END step event, to make sure all instance positions are updated before they are executed (of course this only works best when no other objects have end step events that change their positions).

EDIT: Ah, now i remember why i didn't use region. You see from the scripts, i'm only deactivating static instances.. thinking about it i could use notme and make the object calling the region-script a parent for all objects NOT to be deactivated....

No, the notme option applies to the current instance and not to it's object type.

Try this: create a (dummy) object called objStatic and make all static objects children for this object. Then use this script instead (with your own borders, of course):

instance_deactivate_object(objStatic);
instance_activate_region(view_xview[0]-32,view_yview[0]-32,
                       view_wview[0]+32,view_hview[0]+32,false,true);

To stay in the original topic ^_^ : Try to avoid loops (for, while, do ... until, repeat) as much as you can in continuously executed events such as the step and draw events.

Smarty
  • 0

#22 knight33

knight33

    GMC Member

  • New Member
  • 89 posts

Posted 16 February 2006 - 06:03 PM

1 trap I fell into was multiple particle systems.

Use as little as possible. Remember systems can have multiple emmiters! If you have a lot of enemies with their own PS' and change to 1, you will be shocked at the difference.
  • 0

#23 Cloud Tower

Cloud Tower

    Transition Master!

  • New Member
  • 286 posts

Posted 16 February 2006 - 08:05 PM

Example: Draw Event :skull:
  • 0

#24 RhysAndrews

RhysAndrews

    Game Designer

  • GMC Member
  • 2013 posts
  • Version:GM:Studio

Posted 16 February 2006 - 08:10 PM

Example: Draw Event  :skull:

<{POST_SNAPBACK}>


You also said to set room size to 1,1. Do that. See if your line still works.
The only reason that line gets drawn is because having a background colour / background clears the drawing every frame. Get an object that moves around by arrow keys and make it move around a room like the one in your example. He makes a trail of himself right across the room.

And like timewarp said, you can only have that line in the same place, because moving it will leave a mark behind it.

-Rhys
  • 0

banner4.jpg


#25 Cloud Tower

Cloud Tower

    Transition Master!

  • New Member
  • 286 posts

Posted 16 February 2006 - 08:19 PM

Example: Draw Event  :skull:

<{POST_SNAPBACK}>


You also said to set room size to 1,1. Do that. See if your line still works.
The only reason that line gets drawn is because having a background colour / background clears the drawing every frame. Get an object that moves around by arrow keys and make it move around a room like the one in your example. He makes a trail of himself right across the room.

And like timewarp said, you can only have that line in the same place, because moving it will leave a mark behind it.

-Rhys

<{POST_SNAPBACK}>


Yeah, and that's a bug. ;)
  • 0

#26 RhysAndrews

RhysAndrews

    Game Designer

  • GMC Member
  • 2013 posts
  • Version:GM:Studio

Posted 16 February 2006 - 08:24 PM

That doesn't prove your argument though; Your idea was still useless.
  • 0

banner4.jpg


#27 Cloud Tower

Cloud Tower

    Transition Master!

  • New Member
  • 286 posts

Posted 16 February 2006 - 08:31 PM

That doesn't prove your argument though; Your idea was still useless.

<{POST_SNAPBACK}>


So ignored it then, but take the instance deactivation as an advice. :skull:
  • 0

#28 RandomBlackMage

RandomBlackMage

    We all look alike

  • New Member
  • 325 posts

Posted 16 February 2006 - 09:59 PM

Please people, let's stay on topic here. This is for providing helpful advice, not trying to prove an obviously flawed theorem and then trying to pass it off as a bug.

Anyways, remember, each object doesn't have to serve only one purpose. If you've got an object that draws the HUD in your game, you can also use that same object to keep track of a player's stats and such. By doing this, you can save the processing power that GM uses for seperate objects, such as bounding boxes, collisions, and whatnot.
  • 0
Current Project: Necromancer - Posted Image Chapter 1 Full Demo scheduled for release around October.

#29 Adventus

Adventus

    GMC Member

  • New Member
  • 516 posts

Posted 17 February 2006 - 01:15 AM

One of the greatest methods i've used, is to use a ds_queue to hold all the complicated tasks and using a controller object to execute them. This method was particually useful for complicated AI routines.
eg

alarm[0] in object:
//does compliciated AI calculation
ds_queue_enqueue(global.objectexe,id)

controller object step:
exe=ds_queue_dequeue(global.objectexe);
if exe>0 {exe.alarm[0]=1};

This code allows the complicated routines to be executed one at a time, so there's no spikes in CPU load.
  • 0

#30 membrain

membrain

    GMC Member

  • GMC Member
  • 668 posts

Posted 18 February 2006 - 07:50 AM

One thing I noticed about GM that seems to hold back the speed of a game is everythings dependence on the FPS.

when the FPS goes down, (and it will) the game will slow down.

This is obvious,and to be expected. However there is an old technique used to sort of bypass this "flaw"
Something that is used in just about every commercial game to date.

speed*(16/fps)

by pluging this equation into all your movement and animation code, you can in effect cause all your objects to move/animate "independent" from the current FPS in your game.

So for example:

set the max game speed to 1000 (this lets the user's pc set the max FPS up to 1000)
then plug that small equation into all your movement/animation-speed code and test it.

throw 1000 instances of an object into the view and watch what happens.
If you draw the FPS on the screen you'll notice it takes a MASSIVE hit, but all the objects will still move across the screen at a constant "quick" speed.

*all the typical "lag" issues associated with commercial games will still apply, such as "skipping" and such*
  • 0

#31 leif902

leif902

    GreenMan Games

  • New Member
  • 748 posts

Posted 18 February 2006 - 03:42 PM

Though i think it's already been said, my main thing that I do in all tasking games is use NO global objects and use the "var" command as much as possible... Also (though again this has been said) i never check precice collison checking, i always try to aproximate and i use a mask...

also when using data structures, i tend to turn down the precision by a bit :mellow: I don't mind a little round off error... (infact, i've even used round off error to my advantage when programming AI! Flocking in particular...)

-Leif902

P.S. Membrain, i love that technique :D very nice, i'm going to start using that i think :ph34r:

EDIT: oh another thing, i never use arrays... use data structures for everything or a dll if you can manage it :)

Edited by leif902, 18 February 2006 - 03:43 PM.

  • 0
Sam Whited (Leif902)
YoYo Games Wiki | SamWhited.com (blog)

#32 Schreib

Schreib

    Valen Shadowbreath

  • GMC Member
  • 1458 posts
  • Version:Unknown

Posted 18 February 2006 - 04:04 PM

Can't you keep the graphics in the game at a minimum, and then from a file import the graphics to speed stuff up? So the sprites aren't used all the time. I think that would work.
  • 0
~ Tiefling | DeviantART gallery See my spacescapes!
GM Obfuscator | Protect your games from prying eyes. Get it now!
Motto: Noli turbare axiomates meos!

#33 knight33

knight33

    GMC Member

  • New Member
  • 89 posts

Posted 18 February 2006 - 05:33 PM

The only problem with that, Membrain, is the issues you get from things like collisions. Say your frame rate dipped to 1, an object may move 300 pixels instead of 10.

That's not the way professional games do it (at least I dont think). I think they do it by ignoring the drawing for frames (frame skips) but they still perform everything else.
  • 0

#34 RhysAndrews

RhysAndrews

    Game Designer

  • GMC Member
  • 2013 posts
  • Version:GM:Studio

Posted 18 February 2006 - 09:54 PM

Yeah, Knight33 is right. External Sprites, If i remember correctly, will only advantage the FPS enough if the sprites are large, and/or you have LOTS of them (like, hundreds).

Membrains concept made me remember a little thing i did before; It didn't make anything faster, but it looked really nice. I made the player always going at speed 1, yet as you move the room speed goes up. It made the player move VERY smoothly. Of course that wouldn't work in a full-scale game.

-Rhys
  • 0

banner4.jpg


#35 HaRRiKiRi

HaRRiKiRi

    GMC Member

  • GMC Member
  • 1364 posts

Posted 18 February 2006 - 10:03 PM

And use surfaces as much as possible. Blood for an exmaple. I made all my screen red of blood but there was NO frame drop. So if you want to make a game like crimsonland or Alien shooter then use surfaces and you won't have a FPS hit. And you won't need to make them dissapear too. So I will look better and run much faster then other tecniques.

Cloud Tower: Thats actully not a bug. It is the way GM runs. It redraws every frame. But if there is no background then it will not do it. And the old frame will be at the back of the new one.
  • 0

#36 RhysAndrews

RhysAndrews

    Game Designer

  • GMC Member
  • 2013 posts
  • Version:GM:Studio

Posted 19 February 2006 - 05:58 AM

And use surfaces as much as possible. Blood for an exmaple. I made all my screen red of blood but there was NO frame drop. So if you want to make a game like crimsonland or Alien shooter then use surfaces and you won't have a FPS hit. And you won't need to make them dissapear too. So I will look better and run much faster then other tecniques.

Cloud Tower: Thats actully not a bug. It is the way GM runs. It redraws every frame. But if there is no background then it will not do it. And the old frame will be at the back of the new one.

That's interesting. I know lots of surfaces will lag your game tons, But would you not only need one surface for blood? That could work well.

-Rhys
  • 0

banner4.jpg


#37 membrain

membrain

    GMC Member

  • GMC Member
  • 668 posts

Posted 19 February 2006 - 10:56 AM

@knight33:

Your absolutly right. Collision has potential to run into MASSIVE issues when this technique is in use. However, your example is kind of extreme.
I don't know anyone who would consider making a game that would run at an FPS in the single, or even low double digits...
As it is, the default FPS set by GM is 30.

This method is no "miracle," as I always say to anyone I introduce it to. However, it does make a huge impact on speed if used correctly.
Only real problem with this is that it does adjust the distance an object will travel per step, so if something causes a briefe spike in cpu cycle there is potential for some really strange things to happen.
such as object slows to a hault for a sec. or two sometimes (depending on how many objects are on screen)
and the opposite, objects will dart across the screen...
But, if the game is design to keep the FPS at no less then 16 there shouldn't really be any issues with this method.

For anyone who might not completly understand what this does, and example:

Say we have two pc's both very different.
One reaches a max of 80fps
the other... up to 800fps

time = 16 / 80 fps = 0.20 on slow PC
time = 16 / 800 fps = 0.02 on fast PC

_80 * 1 * 0.20 = 16 // 80=FPS, 1=speed, 0.20=TIME (16/80)
800 * 1 * 0.02 = 16 // 80=FPS, 1=speed, 0.02=TIME (16/800)

Basicaly time gives the duration of the last frame in ticks:
(1/16 second) units.

So when an object is moved, it's converted from moving in "pixels/step" to "quants/time" Keeping a steady rate of movement over a given duration of time/FPS. (meaning it WILL skip over pixels to "make up" speed.

Yes... There is potential to screw everything in your game up if not used right... But it is fun to play with, and it has (I feel) great potential to improve speed in a game.

Don't believe me... test it out and see for yourself =D

Edited by membrain, 19 February 2006 - 10:59 AM.

  • 0

#38 GearGOD

GearGOD

    Deus Verus

  • GMC Member
  • 2153 posts

Posted 19 February 2006 - 11:03 AM

Delta time doesn't improve speed at all. It makes the game run smoother on computers that are able to run it smoother.

And like timewarp said, you can only have that line in the same place, because moving it will leave a mark behind it.

-Rhys
--------------------------------------------

Yeah, and that's a bug.

No it isn't. It's what happens when you don't clear the drawing buffers - it's also what your whole silly idea relies on.
  • 0
Engineers are not programmers. Stop thinking that you can save a few bucks by writing code yourself instead of hiring a programmer. Your code sucks.

#39 membrain

membrain

    GMC Member

  • GMC Member
  • 668 posts

Posted 19 February 2006 - 12:11 PM

For sake of keeping this thread on topic this will be my last responce. (though I'm up for discussing it further in pm)

Keeping my responce short, run a test w/o what I'm suggesting. The FPS drops by a large amount, and all objects on the screen "visibly" slow down...
Now run that same test with the change I'm suggesting and objects "visibly" keep a constant speed reguardless of the current FPS.

It does make a difference.

EDIT:

yes... I just noticed I didn't really put that into my explanation.
The whole idea behind this is to keep objects moveing at a constant rate to help compinsate for fluctuations in frame rate... It doesn't actual do anything to put less "stress" on the cpu in a game, no.

Edited by membrain, 19 February 2006 - 12:40 PM.

  • 0

#40 GearGOD

GearGOD

    Deus Verus

  • GMC Member
  • 2153 posts

Posted 19 February 2006 - 12:33 PM

It makes motion relate directly to physical time instead of an internal counter. It doesn't make the game run faster.
  • 0
Engineers are not programmers. Stop thinking that you can save a few bucks by writing code yourself instead of hiring a programmer. Your code sucks.

#41 HaRRiKiRi

HaRRiKiRi

    GMC Member

  • GMC Member
  • 1364 posts

Posted 19 February 2006 - 12:42 PM

That's interesting. I know lots of surfaces will lag your game tons, But would you not only need one surface for blood? That could work well.


Well you do need only one surface. If you want to make it look very cool. You just need to make one surface that draws all thats is on floor and the floor it self. So you can make tons of tons of bodys and blood on the ground. And it will not drop even one fps in 640x480 room. I tested it. I made a test of 3 possible blood storing. First was the simple object way. At about 220 pools it droped by 1-2 FPS. Second was to store every blood in array and then make and ofr statement to draw em all. At 240 pools it droped for about 1-2 FPS. And the third was the surface way. I had more then 3000 pools and it didn't drop an FPS.
  • 0

#42 knight33

knight33

    GMC Member

  • New Member
  • 89 posts

Posted 20 February 2006 - 08:07 PM

Hm.....how do surfaces work exactly? Isn't everything drawn on 1 surface by default? My game runs very slowly but it is becuase i draw a whole crap load of primitives every step for my background

Posted Image

Is there any way I could speed that up by using surfaces? Excuse me for being an idiot about them, they're probably the only aspect of GM I haven't investigated yet.
  • 0

#43 Harry

Harry

    GMC Member

  • New Member
  • 758 posts

Posted 20 February 2006 - 11:22 PM

Just a quick question. Is there any way you can "de-load" Stuff out of memory with game maker. This could speed Up Games very much By having loading screens like in proffesional games. Then it deloads it when you exit that room. This would mainly be good for very big and complex games.
  • 0

#44 RandomBlackMage

RandomBlackMage

    We all look alike

  • New Member
  • 325 posts

Posted 21 February 2006 - 12:45 AM

Very much so. Say you loaded up a sprite, you could then use (sprite_delete(ind);). Or, if you loaded up an object, (object_delete(ind);).

Edit: Darn emoticons.

Edited by randomblackmage, 21 February 2006 - 12:46 AM.

  • 0
Current Project: Necromancer - Posted Image Chapter 1 Full Demo scheduled for release around October.

#45 Foxtails

Foxtails

    GMC Member

  • GMC Member
  • 17 posts

Posted 21 February 2006 - 02:32 AM

The pro games use a frame skipping technuiqe, since the step codes usually take very little time to execute, its the drawing and checking things that slows the system..
I did it before and it worked perfectly( I'll have to find where I wrote the script down sometime >.<)

But basically I use 'set_automatic_draw(true or false)' and 'current_time' , the current time tells you how many milliseconds passed- so you can calculate how many frames should be skipped by shutting off automatic draw for a certain amount of steps.
*I'd recomend NOT using 'fps' to detect the frame rate, its always a second too late*
Basically what I mean is try to detect if the frame rate dropped, then skip drawing that many frames.
(You'll lose frames but the speed of the game will still be normal-so characters wont move slow.)

***A nice trick is if you change the room speed and skip alot of frames you can make the game run over a 100 times faster with no errors! o.o

It'll take some time to get it right but you medium or expert users should be able to figure it out. :D
  • 0

#46 membrain

membrain

    GMC Member

  • GMC Member
  • 668 posts

Posted 21 February 2006 - 04:40 AM

I was thinking of trying that method out (bump up FPS and skip frames durring movement & such) it seems like it would work out fairly well.

And, the technique you mention about skipping frames based on "current_time" is interested, and If you ever find it, I think it would be cool if you posted it up... could be useful.
Just as a realy quick side note... The technique I mention does something along those lines... but instead of skipping frames it skips over possitions to make up for lag. So flipping that, and skipping frames instead of pixels would prolly be the optimal way to go.
  • 0

#47 GearGOD

GearGOD

    Deus Verus

  • GMC Member
  • 2153 posts

Posted 21 February 2006 - 06:22 AM

Both my Dynamic Lighting and Luminaire editables implement delta time. Check them to see how it works, what it does, and why it doesn't quite work in GM as it does in most engines.
  • 0
Engineers are not programmers. Stop thinking that you can save a few bucks by writing code yourself instead of hiring a programmer. Your code sucks.

#48 membrain

membrain

    GMC Member

  • GMC Member
  • 668 posts

Posted 21 February 2006 - 07:12 AM

your right there... it doesn't quite work with GM as it does in other engines... kind of a bummer, but ohwell.

EDIT:
A hillarious lil' fact... I'm stuck useing a 7yr old compaq till my new pc arrives (a week from now)

specs: AMD#500mhz: 64mb RAM: 8mb shared vid-card

And your dynamic light example ran at 13-10FPS, and all movement/animation looked smooth reguardless.

Though it took lightyears for it to load.

Edited by membrain, 21 February 2006 - 07:28 AM.

  • 0

#49 A.I.

A.I.

    GMC Member

  • New Member
  • 504 posts

Posted 21 February 2006 - 11:57 PM

So I see. I used the alpha because i had 50 frames per scan, And unless i had a gigantic border the view-speed could beat the alarm.

Because of the extreme lag you had to put it in a timer and execute it every x frames, but instance activation and deactivation should best be done every step.

...

To stay in the original topic :P : Try to avoid loops (for, while, do ... until, repeat) as much as you can in continuously executed events such as the step and draw events.

Smarty

<{POST_SNAPBACK}>


Also for active instances, perhaps if the distance of the object from the center of the view is greater than the view width, then dont draw the sprite.
  • 0

||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| βeta 33%
Check out my newest work in progress! Leave feedback. Offer assistance. What ever!

#50 Foxtails

Foxtails

    GMC Member

  • GMC Member
  • 17 posts

Posted 24 February 2006 - 05:39 AM

Hmm, my speed compensation script was for game maker 5.3, it acts differently in gm6.1..( it seems like gm5 could handle sprites faster, but gm6 handles transparency better)
I'll need to work on it a bit.

Anyway, other ways to speed up the game;
* The particle system is sometimes slower than just using alot of sprites.

* Alot of those solid blocks that do nothing still slow the game down, try using very large solid blocks when possible.

* Use small rooms linked together by a system to make sure the player starts on the correct side.

* Try to simplify things, use as few tiles and backgrounds as possible, and try to simplify objects( less checking of other objects and try to not use loops and repeats much.)

* TRY NOT to program abundant objects to do stuff( like coins and solid blocks that you'd use hundreds of in a room) so instead make an other object like the player or controller to cause the object to change,( like the coin sound and removal of coins or breakable objects.)

*Using instance deactivating and activating in an area works pretty well ( I used it to run a whole zelda 1 map with all enemies and solid blocks, but only nearby objects are activated when moving between screens, works with no slowdown.)
!! but to prevent errors you need to ;
*make moving objects that are near the deactivation area to stop moving
(simply use xprevious,yprevious if over a distance from the player( if player
exists).
*Make sure ALL controller objects are set to active( use the parent to a 'always active' object. Otherwise the game can't detect inactive objects)
  • 1