|
Posted By
|
Message
|
siven
I EAT ROCKS
Registered
03/11/2008
Points
604
 
|
22nd August, 2011 at 22:06:55 -
so i use the always condition a lot, and just sudden thought about this out of the blue... a lot of people say the build in timing thing is stupid on mmf2 and you should use an extension, does the Always condition use that build in timer? if so, is that what could be causing some lag on my game? should i put all of the conditions that are simple "Always" and compact them into 1 condition? (obviously leave out conditions that happen like "Always"+"If animation A is playing")
[Game design makes my brain feel like its gonna explode.]
|
Pixelthief
Dedicated klik scientist
Registered
02/01/2002
Points
3419
      
|
22nd August, 2011 at 22:35:57 -
Having extra overhead for events where you could have compacted them down will use more processing, yes, but its a totally insignificant amount. So you could 'speed up a game' by compacting those events, but only nominally so. But there *are* ways that your events can be significantly sped up by using good coding practice. Remember that MMF2 reads conditions from top to bottom, and has "short circuiting"; if one event reads 'false', none of the rest will be read. So if you have collision events, overlapping, or other resource intensive events with lots of math, you might want to put them on the bottom if logically possible, that way something like a simple "is flag off" would be read first. Also, while compacting your "always" events will do basically nothing, the same is not true of fast loops. Fast loops have lots of overhead and the more times MMF2 has to read each line, your game slows down by a fair amount- if you have 1000 loops reading 100 lines of code, thats 1000000 string comparisons just for the "on loop name" condition alone, and that might be 5000000 or more characters compared, and so on. You can avoid that by scrunching together your code, and more importantly, putting loops into groups and activating/deactivating them as needed, see here:
http://create-games.com/article.asp?id=1937
Gridquest V2.00 is out!!
http://www.create-games.com/download.asp?id=7456
|
Sketchy
Cornwall UK
Registered
06/11/2004
Points
1971
|
22nd August, 2011 at 23:22:15 -
Having lots of "always" events is not bad practice - quite the opposite.
It allows you add separate comments to each line, making your code much easier to understand and edit. Any loss of performance is going to be very, very small.
n/a
|
Pixelthief
Dedicated klik scientist
Registered
02/01/2002
Points
3419
|
23rd August, 2011 at 03:58:59 -
You should get that fancy pants extension for putting comments into the events themselves 
Then again, so should I! But its enough work commenting my project just for per-line basis.
I went back to comment everything a few weeks ago, and after 2 days of work I was up to line 499 out of 3698. When the event list editor is printed to a file at standard settings, it took up 461 pages! At ~33 events a page, and with my lua code, thats about 17 KLOCS! But never mind that >.>
 Edited by Pixelthief
Gridquest V2.00 is out!!
http://www.create-games.com/download.asp?id=7456
|
siven
I EAT ROCKS
Registered
03/11/2008
Points
604
|
23rd August, 2011 at 04:31:55 -
oh ok! so its not bad that i split it all up. and thanks for the tip! i think im gonna go re-arrange my events, hopefully it wont mess anything up while im re-arranging, better back it up...
[Game design makes my brain feel like its gonna explode.]
|
Fordom
Nordanrikets konung
Registered
12/02/2009
Points
190
|
23rd August, 2011 at 19:40:13 -
I emailed this question to Clickteam and they said that always events (and all other duplicate events) will be comacted into one when building the application.
This forum is full of trolls and disinfo agents.
|
siven
I EAT ROCKS
Registered
03/11/2008
Points
604
|
23rd August, 2011 at 21:19:22 -
are there other events that do that as well? cuz sometimes i experience some lag issues while running the game with F8 that i dont see happening when i run it after i build the application.
[Game design makes my brain feel like its gonna explode.]
|
Pixelthief
Dedicated klik scientist
Registered
02/01/2002
Points
3419
|
23rd August, 2011 at 21:52:15 -
Really. I was always sort of curious what kind of compiler optimization techniques MMF2 uses, and its not exactly surprising to see duplicate events being compacted. But I wonder what sort of things you can do to build for that. I doubt any loop conditions would get compacted since they have string comparisons, but maybe clickteam was kind enough to check for redundant string conditions.
But what exactly is your application doing? Is it doing anything particularly strenuous in terms of math, loops, or complicated algorithms? MMF2 processes fast enough that unless you're doing something severely intense (as I often am, darn it) it shouldn't be slowing down due to processing. The odds are that your slowdown is coming from a graphical component, or due to hiccups on your computer- you should make sure that its neither a graphical problem nor a "your-computer-only" problem.
Until you start trying to iterate over a 1000x1000x1000 array, MMF2 is way more likely to slow down because you've got too much graphics on screen than due to processing. But if you are doing processing stuff, theres a bunch of good tricks to use to speed it up, and if its graphical, theres HWA and many efficient ways to 'cheat' graphics onscreen to speed stuff up.
If you're on Windows, just hit "ctrl-alt-delete" and look at your Task Manager, which should show you the CPU load & memory usage. Unless those are off the charts, its probably graphical.
Edited by Pixelthief
Gridquest V2.00 is out!!
http://www.create-games.com/download.asp?id=7456
|
siven
I EAT ROCKS
Registered
03/11/2008
Points
604
|
23rd August, 2011 at 22:27:11 -
Sometimes others are experiencing similar lag, but only once in a great while, and if you hit F2 and refresh it sometimes it fixes it, sometimes you have to completely reboot the game. I am in fact experiencing CPU spikes at certain times in the game. someone else told me it could be because of "bad coding" but i simply cannot find what ive done wrong, ive tried changing the order of all my event, putting ones that happen least at the bottom, having events that turn on and off groups of events, but im still having this problem. i cannot figure out what is going on. i noticed my zombies cause lag when theres more than one of them on screen, sometimes it lags when im overlapping a weapon, sometimes it lags all the time for no reason it seems, i just dont understand whats going on. i suppose its probably because im still "somewhat" new to this, and its my biggest project yet. though ive been avoiding doing this for quite some time, seeing as i really dont like people having my coding, i think i have no option at this point other than to post the mfa and see if any of you guys can figure out what ive done wrong. i took out all of my fastloop conditions, so theres no fastloops anymore, everyone was saying fastloops will slow the game, so i figured might as well not even use them if i dont have to.
So here it is... the mfa for my project. if anyone can figure this out, i would be more than grateful. like i said, i havnt bother posting it yet because im afraid of someone trying to jack my project (silly... right?) sorry for the 32 mb download size, not sure why its so big. theres no music, no sound effects or anything, maybe just too many lines of coding? idk, im at the point where i dont know anything anymore  anyway, here it is...
http://www.mediafire.com/?afiu9g91x41yitt
[Game design makes my brain feel like its gonna explode.]
|
Pixelthief
Dedicated klik scientist
Registered
02/01/2002
Points
3419
|
23rd August, 2011 at 22:57:59 -
Its a bit tricky to tell from that, mostly as (if this helps reassure you) I played around with it till I managed to die, and it never slowed down at all. Nice graphics, by the way! But if I had to guess what your issue is- you're definitely not leaking memory, your memory usage was just fine. If its a CPU usage problem, it might be because you're testing for collisions against very large objects.
Think of it this way. When MMF2 wants to test an event that says "is player overlapping weapon", then it has to look at every single weapon and check if you're overlapping that one. Its efficient because first it culls out all the objects where you aren't even in its box, and thats very simple to do- it checks if your X/Y coordinates are beyond its X/Y bounds, and if so, it doesn't compare. But for the other objects, it has to do "fine collision", where every single pixel in that object is compared to every single matching pixel in your player.
So if you have a "collectible pickup field" object thats 83x111 pixels large, with "fine collision" checked, it has to check 9213 pixels of collision for each object in the worst case. If you have 100 different weapons all overlapping you at the same time, that would be 921300 pixels, and so on. Now i'm just basing this off what you said about people slowing down "overlapping a weapon", or when zombies are onscreen. But if thats the case, your problem is probably too many collision checks at the same time, which is very expensive.
This might not be your problem for sure, so you might want to investigate before you start addressing it since it would be a fair bit of work, but there are good ways to drastically reduce the amount of CPU used in collisions.
One good trick is to give your weapons a second animation, which is nothing but a box the size of what you want their collision to be. It can be a plain 100% black box of whatever size. Then, untick the "fine collision" option on both your weapons and your pickup field. When this feature is on, it checks to see if the sprite is overlapping or not, but when its off, it only checks if the rectangular box boundaries are overlapping each other (think of it as including all that transparent space around your object). The trick here is to set all your weapons to this blank black box animation at the top of your code, before and higher up than any collision events. That way, when the code reads those collisions, it will do it using its box animation. Then, at the bottom of your code, after all the collisions, set your weapons to their 'real' animation.
Now you've already got a bunch of different animations they're being set to, so you might just need to rearrange some code. But you can do the same thing with your enemies, player, etc- so that the game is only checking for a box as its collision detection, instead of checking every single pixel. Just make sure to uncheck "use fine collision". It will still work even if you don't put in that "invisible animation", but you probably don't want stuff to collide with the transparent corners of your player.
But uh, just play around with stuff and make sure that its collision detection that is using up all that CPU. For example, try making a bunch of these items, but deactivating all the collision code while you test it. If the slowdown persists, it can't be the collision stuff. If it goes away, you've found your culprit. Anyway, hope this helps!
Gridquest V2.00 is out!!
http://www.create-games.com/download.asp?id=7456
|
siven
I EAT ROCKS
Registered
03/11/2008
Points
604
|
24th August, 2011 at 02:35:54 -
Thanks so much for the help! i have a bunch of stuff to try when i get home... since you didnt get any lag, and theres others who haven't had lag either, i wonder if the game just requires a bit of a stronger pc to run smoothly. it also makes me question my processor and my video card. i have an ati radeon 4850 that after doing some research ive recently found out that the 4850 has a lot of problems. also, im thinking my processor may be dying/ overheating, causing cpu spikes, in turn causing lag on the game, andevery other game for that matter. i just a few days ago dusted and cleaned my system and it helped but didnt fix it. im going to see what i can do about this. i just thought of this but the only time my little brothers computer had trouble running it was when it was getting really hot. thanks for helping me out! and im glad you like the graphics lol :]
[Game design makes my brain feel like its gonna explode.]
|
Pixelthief
Dedicated klik scientist
Registered
02/01/2002
Points
3419
|
24th August, 2011 at 02:45:40 -
It could easily be a problem with overheating, especially if you're on a laptop, but even if its a desktop. My laptop here used to slow down horrid after being on a while, but now I have a cooling pad underneath it, and a desk fan pointing directly at it. Well good luck!
Gridquest V2.00 is out!!
http://www.create-games.com/download.asp?id=7456
|
siven
I EAT ROCKS
Registered
03/11/2008
Points
604
|
24th August, 2011 at 04:38:17 -
its a desktop that used to be a full tower but when my motherboard died i put it in my stepdads mid tower that has less fans. plus my video card puts out alot of heat in that very cramped tower. im thinking thats the problem now.
[Game design makes my brain feel like its gonna explode.]
|
Silveraura
God's God
Registered
08/08/2002
Points
6747
      
|
28th August, 2011 at 01:41:14 -
Originally Posted by Fordom
I emailed this question to Clickteam and they said that always events (and all other duplicate events) will be comacted into one when building the application.
I some how doubt this is entirely true. Otherwise the order in which different "always" events fired, would be dramatically effected. It may not seem like much of an inconvenience to people who aren't actually focused on the logic flow in their program, and just randomly throw events in as they need them, moving them around simply for visual appeal, however the order in which any event, including the always event, can dramatically impact the outcome of the game.
For example:
ALWAYS: Set counter1 to MouseX AND Set counter2 to MouseY
ALWAYS: Set objectX to counter1 AND Set objectY to counter2
vs
ALWAYS: Set objectX to counter1 AND Set objectY to counter2
ALWAYS: Set counter1 to MouseX AND Set counter2 to MouseY
At a glance, both would appear to do the exact same thing... but upon closer examination... you'll find that the bottom will always display the object one frame behind the position it's actually supposed to be, because the position is updated after the object is actually placed.
Again, it might seem like a small issue... but it can quickly snowball if you're completely oblivious to it, and can really help explain just about every single issue or complication anyone has regarding glitches in their games and dismissing it as a glitch in MMF2 which it's really quite the opposite, MMF2 is doing exactly what it should be doing.
Edited by Silveraura
http://www.facebook.com/truediamondgame
|
|
|
|
Advertisement
Post Reply