game-editor.com

Having made many different styles of games with ge, i have learned a lot about the inner workings of the program. I found one of my game titles was experiencing terrible slowdown, but it seemed to be based on time and not on the number of actors or their activities.

I realize now that ge can spring bad memory leaks, a situation where every second it allocates another 12k of memory, and does so eternally until your cpu is at 99%. Use windows task manager and monitor ge's memory usage while playing to see if your game(s) have a leak.

While i have been unable to stop the leak, i have found ways to AVOID letting the leak ruin your game. (remember that post about crashes and errors i made?).

The 'collision map' that ge creates for actors has a problem when lots of clones check for lots of collisions. While massive bullets coming from your ship don't cause the memory leak, an enemy checking for collisions over and over can.

I had an enemy looking for the 'turn' markers to turn on the path; and the more turns it touched, the more the game leaked.
I have now replaced the collision with a draw actor, simply asking if the enemy is within 3 pixels of the turn actor, and i can now play through the game fully with no screen tearing or slowdown at all



IF YOU DON'T READ THE ABOVE, MAKE SURE TO READ THIS:

If you do not need a collision, do NOT have one! Disable collisions for ANY actor that won't be using them!

In this case, draw actor checks, even distance(!), are much more stable than using collisions, not to mention(and its documented in the source) that collision checks eat a lot of cpu anyway!

Also, try not to use 'collision>anyside>ANY ACTOR', it is quite likely to ruin your game. Just stop and think about what you're asking the program to do there; Its wasteful, illogical, and certainly not the way a professional would handle collisions in his game. You might not care about the player's cpu, but, i assure you, your player does! If player could afford a faster computer, player would buy a faster computer! You have to treat user's cpu cycles like gold!



Note: (realize i'm not slamming ge)
If you have been experiencing problems with collisions, or with physical response, and they give you doubts about GE, i invite you to check the collisions in other popular game maker software, even some 'pro' kits, and you'll see that its not easy to make good collisions.

My game 'Orbs of Death' (viewtopic.php?f=6&t=5513) could NEVER have been made with GM , because its collision engine(while seemingly leakproof) is unrealistic, unpredicable, and terribly jerky in terms of gameplay.

Sounds very helpful. I guess most of us know it's nearly impossible to create a single collision system which suits every game designer's requirements at once.
I was thinking about developing my own collision system, which does use the collision event though (specific sides on specific actors).
Would that be much of a problem? Note: The Physical response action I would create myself, it would basically only contain two float variables (and lots of IFs *hides from Fuzzy*).

Kalladdolf wrote: (and lots of IFs *hides from Fuzzy*).

lolololol

The problem with what you're suggesting is that ge already has a collision method, and by using collisions at all, you are activating that method.

So anything you add is simply running on top of that method, and adding even more strain on the cpu. In order to avoid problems, you would need to eliminate the collision alltogether, because if there are no collisions, ge will not run the collision map.

Unfortunately, the only other way to detect pixelperfect collisions would be by making your own pixel array (doom to a cpu),
so the best thing i can suggest is to play around with it and find something that works for you. Collisions are still necessary, for some things.

If you are wanting to improve the collision response, i think the best thing would be to create x y specific motions, i. e. colliding on the left side of a block causes physical response in your xvelocity, but not your yvelocity. it would be nice to limit pr to only one axis like that.

In my new game, the memory leak is active, but the game takes about 45 minutes to complete, and you can finish the game long before the leak becomes a problem.

I'll try all ways I can think of anyway.

Kalladdolf wrote:I'll try all ways I can think of anyway.

That is an excellent attitude.

And May I say, its certainly possible to make your own collision detection in GE. A worthy goal. You dont necessarily need a collision map.

I was able to replace the core collisions in the game with scripting, and the problems have ceased.

Now i still have lots of collisions, but the main actors don't collide anymore.

The game runs great and doesn't leak at all.

If that collission issue really is what makes my games lag on my laptop, this calls for a celebration!

thanx for your contibution! This will really help thpse with no other options, i have yet to have a memory leak, I think...
just realized im the one on every recently posted topic thing on the forum index

*slowly backs away from computer*

I really just know...

DST wrote:I was able to replace the core collisions in the game with scripting, and the problems have ceased.

I wonder whats that scripting...

a tower stores target cloneindex in the array targetid[];
creep x, y, and health are stored in creepx[], creepy[], and creeph[];

so in draw actor

if (abs(x-creepx[targetid[cloneindex]])<4 && abs(y-creepy[targetid[cloneindex]])<4){
creeph[targetid[cloneindex]]-=damages[cloneindex];
}

Health?damage?
Oh this code replace collision event when calculate damage huh?
I think to replace physical response...

well, i prefer to use arrays for these things because they're much easier to call in functions or from other actors.

As far as usage, its no harder to use health[cloneindex] than it is to use health(actor variable), i mean, either way ge is storing the variable in an array or struct.

Also, it frees up health to use as a temp storage, for instance, if you have to recalculate a health bonus, you can say something like:

Code: Select all

health=healths[cloneindex];
healths[cloneindex]*=1.5;

then use health[cloneindex] as the working variable, because.....when the effects of the health boost wear off, you've got health right there to reset the variable again.

Code: Select all

healths[cloneindex]=health;

and what's best, is to call it for other functions; (in this case, using global integer "last").

actor>mousebuttodown>

Code: Select all

last=cloneindex;

and in the health display meter:
(whatever your script, drawn or animation or textNumber)

Code: Select all

textNumber=healths[last];

So now one status meter will instantly display status for any actor you've clicked on, and instantly update when you click on a different actor.

DST wrote:So now one status meter will instantly display status for any actor you've clicked on, and instantly update when you click on a different actor.

With no IFs!

now combine this with the clone usage, and you can create and entire status bar out of only three actors.

actor 1, text actor "meter".
actor 2, menu control, "menu".
actor 3, canvas actor, "bars".

So textactor has clones

Code: Select all

switch(cloneindex){
case 0:
textnumber=healths[last];
break;
case 1:
textnumber=manas[last];
break;
case 2:
textnumber=healthmaxs[last];
break;
case 3:
textnumber=manamaxs[last];
break;
case 3:
textnumber=attacks[last];
break;
case 5:
textNumber=defenses[last];
break;
case 6:
textNumber=other stats[last];
break;
}

then textactor.2 would be directly to the right of textactor 1, with a / in between(just don't enter any switch case for the cloneindexes of the textactors that are slashes or static words, like 'damage' or 'name').

and then, a code for the canvas(note the 0 in moveto is the start of the draw; it would either to the right or left of the textactor that's displaying the stat in number format, in most games.)

Code: Select all

erase(255,255,255,1);
setpen(255,0,0,0,10);
moveto(0, 10);
lineto((healths[last]*20)/healthmaxs[last], 10);
moveto(0, 20);
lineto((manas[last]*20)/manasmax[last], 20);

Now it draws the actor's health and mana next to the textnumbers.

Make all of those actors a child of menu, and give menu the background graphic for the menu. Now you can disable menu's visibility state, or move it offscreen, and the rest of the actors follow.


And once you've got a simple working menu, that you can easily add more stuff to by clones and case switches, you can spend more time making it a GOOD menu, making it pleasing to look at, make it solid and there when you want it....

"If it is a struggle simply to make something work at all, what time will you have to polish it, to make it pleasing, to make it what you really want it to be? This requires 3 things: planning, planning, and more planning. If you write code that is simple right now but not expandable for the future, then you'll never get around to any kind of polishing."

IFs ???