game lagging trouble

[j2graves]

I need help keeping my game from lagging.

first off, the game lags a little while the main actor is colliding with the ground.
second of all, I needed to make the NPCs not recieve events while out of vision to reduce lag. I did so. however, the instant one comes into view, lag starts up.
third, graphics are all .png, and music is all .ogg so that isn't the trouble. what is?
fourth, the game tends to lag when ANY actor with ANY script concerning motion comes into view.

please help, it's already lagging and I've only made the first level! =C

[Chai]

Do you make a game for a PC version?

If so, try to use a Activation Region.
This will help you.

[Kalladdolf]

Try reducing the size of your view. Lower resolutions help. I'm also doing that with my project.

[j2graves]

seems it mainly occors when an actor which collides with the ground comes on screen =P

[DST]

I hope you weren't expecting a simple answer, like 'turn x option off'. I don't have any simple answers, but if you have the time, you might find this an interesting read.

No single actor should be slowing anything down. If one actor does, then there's something really wrong with it's script.

I'm not sure this is related to your problem, but it may help your overall understanding of speed when dealing with collisions:

When you use the event "Collision" You are turning on a script that constantly checks for collisions between any actors of that type.

Thus, when you say actor>collision>bullet, your actor will have to keep track of every single bullet and look for collisions.
Even though the box2d script is very efficient, and weeds out most unlikelies, what happens when you have

playershot>collision>enemy

Now you might have 300 shots all checking for collisions with 300 enemies. And they don't turn off, they'll be looking the entire game!

One solution to this is to reduce the number of actor types, and use flags to describe the actors. Try having only one bullet.

Bullet>CreateActor>

Code: Select all

side=creator.side;

Ship>collision>bullet>

Code: Select all

if(collide.side!=side){}

and
Enemy>collision>bullet>

Code: Select all

if(collide.side!=side){}

Now you can get away with only one bullet actor, used for both enemy and friendly fire. The final result is fewer collision loops GE has to run internally.

Whether or not this will speed up your game depends on many factors, but even if it doesn't it still makes coding much much easier!

So given a single actor causing game slowdown, yes, if that actor has collisions with 56,000 different objects, that actor coming into active view could be slowing the game down, all by itself.

The same thing can be true for the size of the colliding object (you may have to ask Mak for more information) but in my collision script, once i've determined that two objects are close enough, i find the overlapping xmax/xmin ymax/ymin area, then compare the pixel data value, looking for one pixel where both of them have an actual color (transp<1)).

I'm not sure how GE decides how much of the pixel array to check for, but two very large colliding objects, if they're in a collision that's shallow in one direction but deep in the other (imagine two giant L's colliding, where they have a very large overlap value xy speaking, while only the tip of one is touching the other), may have to look thru a LOT of pixels to find the collision point.

That's a lot of pixels to look through for such a tiny collision area.

If you use large level pieces, or pieces that are entire levels in one png, this could be a problem. (Though Ge may have safeguards against this, i don't really know).



As far as activation regions are concerned, (and you may have to ask Mak about this too), I believe that the intent was not to reduce cpu, but to reduce memory usage.

Since GE uses bitmap animations, instead of vector animations (like 3d rotate etc), it trades cpu for memory; Less cpu, but much more animation data.

This is why GE can handle 10x more actors onscreen than ActionScript does. (given the same level of coding experience).
Notice how cpu cores are maxing out in speed, moving instead to multicores because it's getting harder to make them faster in clock cycles; Whereas RAM and Hard drive space just keep getting faster and cheaper and bigger.



The format of your images is irrelevant, since GE uses the same compression on all of them (though technically, a 10 color gif has less information to encode, it also looks crappier, which is one of the things compression is there to avoid), so GE treats all games like they were 32 bit color, and any further compression advantage you gain by using highly compressed files is only because the images actually look worse to start with. The overall size still matters (but that's xy size, not kb size), and transparency can also be an issue (it doesn't like having a fullscreen image drawn transparently over everything else). This has nothing to do with filesize, rather it has to do with the cpu needed to blend the colors for display. It affects all games and platforms that cannot use GPU's to pretty much the same degree.

Use the old school way. If you have an explosion that needs a lot of transparency, you can always remove the transparency (antialiasing) and simply double the animation frames and the speed to give the same effect; Remember all you have to do is convince a human eye that it looks the same. And human eyes can be very easy to fool.

Animation can be compressed by comparing the static quality with the dynamic quality; The faster something moves, or the shorter its lifespan, the less detailed it needs to be. The fewer frames and clunkier the animation, the more detail it needs.
(that's where sword swipes come from! Showing the sword's movement using only 1 frame of animation.)



When it comes to sound, i've found that all compressed sound formats are way clunkier than we were led to believe before, both on games and on computers in general.
MP3's even are very hard to control, as it takes time to seek through the compressed data. This is one problem that leads to looping issues with music, where there is a tiny break between loops. And this is not specific to GE, its a universal compression issue.

Remember when you create a 640x480 PNG image, how large does it get? 600k (on the high end)? maybe 1 meg if its all rainbows?
But a music track can easily be 6 times that size! You can always open a new thread, on a new soundchannel, but that's an extra thread! that's more cpu too.

I'm sorry to say, that most compressed music formats just aren't as fast as we'd like them to be. That's why you may notice, on some complex professional games, that they've used their own music format, optimized for specific purposes.

GTA3 (yes i refer to gta often because all the GTA's are great models of efficiency), i noticed, loads all its normal sound effects into one .raw chunk of wav data, all the things people say on the street, gun sounds, sirens. All the things that appear often and on short notice.

Putting them all in one file reduces headers and seek time (from 1000's to ONE!) and being uncompressed raw data allows them to be read fast! So a .wav is much faster than an ogg but uses more memory. How much memory is ok depends on your game and your activation regions, but honestly, most of our computers having 1 gig or more of ram means ram is not likely to be a bottleneck with ge games, ever. Download size would still be an issue, though, so.....

For GE? Start with the old school model. Make the music in efficient LOOPS to reduce their size.

Have a 4 minute song? Do you really need that? Couldn't you make the same song 2 minutes with just more condensed structure? I mean, if its electronically based music, the whole point is not constant variation (as with guitar), but rather making one very beautiful loop that the user doesn't mind hearing over and over. Remember that as a computer guru, you can command a whole orchestra with a few button presses!

It has been my experience that music almost always slows down GE games. The bare minimum i've found, that doesn't slow the game down at all, is using a 99kbps ogg on 22,050 hz (in game properties).

Yes, you'll lose your stereo effects, and your stereo space. The music doesn't sound as good, but it still matches the TV quality sound of the systems of the past.

Why can't GE play game music as well as an Xbox, you ask?

Remember, an Xbox has its OWN CD PLAYER. It can startup the builtin decoder (that all cdplayers have) to play the sounds without the data ever touching the cpu, just like your computer cdrom can play cd's on its own using the audio jack in the front for output. And on PC's, the sound may be smooth on professional games, and they play fast, but rest assured they put a lot of work into customizing their sound threads to do that. (notice how your mp3 player, winamp, wmp, etc. cannot switch tracks any faster than the radio stations in GTA do).


And, if not now, then soon, if you continue to progress, you will get to a point where you will realize that adding a custom sound thread in the ge source really isn't difficult at all. It's all made out of the same numbers and algorithms that everything else is;

int i; is universal. C, C++, Java, and so many others....they all use it this way. They all use int name[size]; for arrays. Its not that different.

[j2graves]

thank you for that, that's something to think about in further production.

however, the colliding actors are not that big. the tiles are 50x50 (but the entire image with each of the tiles IS bigger if that matters.)
however, the actor that seems to be causing lag is rather small. it is in an attachment.

[Fuzzy]

Do you have the background actor of your game set to no collision?

[j2graves]

I don't have a background yet

[DST]

Also, don't ever use the line 'collision>any side>ANY ACTOR'.

Its super slow. Always use specific collisions.

[DST]

If you really want help, you should post your game so someone can actually investigate. Otherwise we're just taking shots in the dark. I hope at this point, trust isn't an issue on the GE forum.

[j2graves]

I'm trying to keep it a surprise
don't worry, got a pretty experienced member who's in on the whole thing.