The Daily Click ::. Forums ::. Klik Coding Help ::. "Never" Condition
 

Post Reply  Post Oekaki 
 

Posted By Message

Sketchy

Cornwall UK

Registered
  06/11/2004
Points
  1970

VIP MemberWeekly Picture Me This Round 43 Winner!Weekly Picture Me This Round 47 WinnerPicture Me This Round 49 Winner!
18th June, 2010 at 23:12:22 -

Okay, so I've been having some trouble with slowdown in the game I'm making, and some more trouble identifying exactly what's causing it.

I suspected it was probably one particular part of my code - about 7-8 lines - that was causing the slowdown.
I decided to test the theory by adding a "never" condition at the top of each line, but to my surprise, it made absolutely no difference to performance - I was still only getting 25fps.
I then deleted the same 7-8 lines altogether - suddenly the framerate jumps t0 50fps

I was under the impression that if you put "never" at the top of a condition list, then MMF2 wouldn't bother checking any of the other conditions, but obviously this is not the case

 
n/a

Silveraura

God's God

Registered
  08/08/2002
Points
  6747

Game of the Week WinnerKlikCast StarAlien In Training!VIP Member360 OwnerWii OwnerSonic SpeedThe Cake is a LieComputerChristmas Tree!
I am an April Fool
18th June, 2010 at 23:15:42 -

MMF2 seems to apparently still check everything, it just wont fire the event if any single condition fires false. Never always fires false.

 
http://www.facebook.com/truediamondgame

Xgoff



Registered
  22/02/2009
Points
  135
19th June, 2010 at 01:57:08 -

i would hope it does lazy evaluation of conditions but it might possibly not

 
Image

aphant



Registered
  18/05/2008
Points
  1242
19th June, 2010 at 07:24:16 -

With my testing, "never" does absolutely nothing.

 

alastair john jack

BANNED

Registered
  01/10/2004
Points
  294

GOTW WINNER CUP 1!GOTW WINNER CUP 2!GOTW WINNER CUP 3!VIP MemberMushroomI am an April Fool
19th June, 2010 at 09:24:58 -

What type of events were they? It might help me speed up my game

 
lol

Sketchy

Cornwall UK

Registered
  06/11/2004
Points
  1970

VIP MemberWeekly Picture Me This Round 43 Winner!Weekly Picture Me This Round 47 WinnerPicture Me This Round 49 Winner!
19th June, 2010 at 13:23:10 -

There were various different kinds of event, but it turned out there was just one causing the slowdown - it was a condition checking whether an active is overlapping another active. Fine collision detection on large objects is *very* slow, apparently.
Since my objects were circular anyway, I just replaced the collision detection with a simple distance check (comparing it to the radius of the object) and now the framerate is back up to 50fps, with no visible side-effects

Incidentally, I tried putting the event in a group, and disabling it (like in Pixelthief's method for making fastloops more efficient) - didn't help at all. MMF2 was obviously still evaluating all the conditions, even in the disabled group.

 
n/a

nim



Registered
  17/05/2002
Points
  7233
19th June, 2010 at 14:30:02 -


Originally Posted by Sketchy
Incidentally, I tried putting the event in a group, and disabling it (like in Pixelthief's method for making fastloops more efficient) - didn't help at all. MMF2 was obviously still evaluating all the conditions, even in the disabled group.



That's interesting about fine collision detection on large objects and especially about the fast loop grouping technique. I'd heard of that method before and always thought it worked (without actually having tried it myself). What I heard was that it helps if you have a lot of fast loops (i.e. not the amount of loops in them, but the fast loops themselves).

 
//

Sketchy

Cornwall UK

Registered
  06/11/2004
Points
  1970

VIP MemberWeekly Picture Me This Round 43 Winner!Weekly Picture Me This Round 47 WinnerPicture Me This Round 49 Winner!
19th June, 2010 at 15:56:30 -

I believe it does help with fastloops, but the event I was trying to disable doesn't involve them. It was just something I thought might help, but it didn't seem to.
I haven't tried testing it in a more controlled example yet though.

The collision detection problem is definitely real though. Obviously the bigger the objects, the worse it is. I tried to do destructible terrain, with a Surface object the size of the frame (2000x2000) - it was perfectly fine until I added collision detection between the surface object and an active, and then the framerate dropped to 1-2fps.

 
n/a

alastair john jack

BANNED

Registered
  01/10/2004
Points
  294

GOTW WINNER CUP 1!GOTW WINNER CUP 2!GOTW WINNER CUP 3!VIP MemberMushroomI am an April Fool
19th June, 2010 at 16:24:20 -

I think I have a lot of collision checking, maybe that's slowing down my game, but mine aren't very large.



Edited by alastair john jack

 
lol

Sketchy

Cornwall UK

Registered
  06/11/2004
Points
  1970

VIP MemberWeekly Picture Me This Round 43 Winner!Weekly Picture Me This Round 47 WinnerPicture Me This Round 49 Winner!
19th June, 2010 at 17:30:36 -

It's easy enough to test: just untick the box for "use fine detection" in the properties panel, and see if it helps at all. You should always untick that box unless you really need fine collision detection, but I doubt most people bother.

If you think about it, the number of pixels that need to be checked increases exponentially (a 500x500 square contains 100 times as many pixels as a 50x50 square) so small objects probably aren't a problem.

 
n/a

Xgoff



Registered
  22/02/2009
Points
  135
19th June, 2010 at 20:35:40 -

yeah, fine collision detection is pretty much going to be quadratic if they just do it the easy way

i'm not sure how it could be sped up on their end, unless it's possible to use quadtrees or something to represent the collision masks, so they could test chunks of the masks in many cases rather than pixels... this would end up using a fair amount of memory though

 
Image

Bibin

At least 9001

Registered
  01/07/2005
Points
  308

Silver Cup WinnerGOTW Winner!Has Donated, Thank You!VIP Member
19th June, 2010 at 23:09:28 -


Originally Posted by Sketchy
It's easy enough to test: just untick the box for "use fine detection" in the properties panel, and see if it helps at all. You should always untick that box unless you really need fine collision detection, but I doubt most people bother.

If you think about it, the number of pixels that need to be checked increases exponentially (a 500x500 square contains 100 times as many pixels as a 50x50 square) so small objects probably aren't a problem.



When I uncheck that box, I get things registering collisions many pixels outside their boundaries.

 
n/a

Sketchy

Cornwall UK

Registered
  06/11/2004
Points
  1970

VIP MemberWeekly Picture Me This Round 43 Winner!Weekly Picture Me This Round 47 WinnerPicture Me This Round 49 Winner!
19th June, 2010 at 23:46:49 -

It should just use bounding-box collision detection if you disable fine collision detection.
Obviously that will mean a lot of false-positives if your objects aren't vaguely rectangular in shape.
I haven't tried it, but I suspect that bounding-box collision detection is used even if only one of the objects involved has fine collision detection disabled (possibly an old bug that has since been fixed?).

Anyway, I was just suggesting it as a way of testing how much it's affecting your game's performance, since AJJ asked.

Edited by Sketchy

 
n/a

alastair john jack

BANNED

Registered
  01/10/2004
Points
  294

GOTW WINNER CUP 1!GOTW WINNER CUP 2!GOTW WINNER CUP 3!VIP MemberMushroomI am an April Fool
20th June, 2010 at 07:59:59 -

I found out that allowing for custom controls seems to cause the game to slow down dramatically. Framerate goes from 25 to 50 when I remove them. yay!

 
lol

Xgoff



Registered
  22/02/2009
Points
  135
20th June, 2010 at 08:07:55 -

i... have no idea why something like that should cause any framerate hit at all

 
Image
   

Post Reply



 



Advertisement

Worth A Click