Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Performance questions

Author
Message
nz0
AGK Developer
16
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 21st Jun 2013 07:42
I would disagree (again) sorry AL !

1. AL is right though, about the lack of a short circuit evaluation.
Nest your if checks according to most likely to be false (i.e. not execute the inner checks).

2. A spriteX check and a SpriteY check will be cheaper than a collision check (in most cases).

I wouldn't worry massively about logic execution speed. You'd have to go some to exhaust the CPU on this kind of action, but it's still good programming technique to be efficient.
By far the biggest killer is fillrate and drawing in general.

3. I see you are setting the alpha to 0 on the sprite rather than making it invisible (or even delete it if it is more appropriate).
Not only is the sprite still going to be sent to the renderer but it will be checked again on future frames. You should consider a method like this:

Instead of having your coin sprites in an array of integers, use a UDT like:



When you create the coins, you can manage them much better like this. Also, you can have many other properties which make this method pretty much indispensable.
When you process your coins for collisions for instance, your outer check looks at MyCoins[x].Active first, THEN try position or collision checks. Obviously you set the Active property on or off, depending on the coin's status

Funnell7
12
Years of Service
User Offline
Joined: 8th Sep 2011
Location: UK, England
Posted: 21st Jun 2013 11:36 Edited at: 21st Jun 2013 11:36
Thanks AL and nz0, I'm sure UDT's are the way to go, but there is something about them I just don't like I think I need to get over that!

For now though, rather than changing the Alpha, I will set the sprite invisible, thats a simple change and makes perfect sense, thanks!!
Hodgey
14
Years of Service
User Offline
Joined: 10th Oct 2009
Location: Australia
Posted: 21st Jun 2013 12:26
Quote: "2. A spriteX check and a SpriteY check will be cheaper than a collision check (in most cases)."

I think what AL was saying in regards to this was that the collision function does this before the actual collision detection. So you'd check for it to be valid and then the collision function would detect for validity and hence you've doubled up. At least it'd be thorough.

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 21st Jun 2013 16:52
It is also possible that 'under the hood' AppGameKit keeps track of the X and Y positions of sprites and doesn't need to do anything other than reference the class member once they have picked the right sprite.

So, in that respect, I very well may have been wrong. I had not thought that part through when I posted.

But, as long as you are in Tier 1, you should nest your 'if' statements to simulate good logic parsing.

Also, you can save some computation cycles (and they do add up over time) by storing the 'CurrentViewX + 480' and 'CurrentViewY + 320' in some global values (eg. EndCurrViewX and EndCurrViewY) in the same place where CurrentViewX and CurrentViewY are set/reset. I suspect you might use the 'end' values frequently. Storing them in globals instead of always recalculating (especially inside a loop in which you know absolutely that the CurretViewX/Y values don't change) saves several computation steps. Instead of doing a fetch (to get the first value) and an addition (and maybe a store to temporary), you only do a single fetch. (Yes, I expose my longevity in the field by being bit and cycle conscious. But, if you do enough optimizations that way, you can save quite a bit of time and computational effort.)

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
TDavid
11
Years of Service
User Offline
Joined: 7th Feb 2013
Location:
Posted: 23rd Jun 2013 17:37
I compiled my app with 1.0814 and my app runs 7 fps slower than with the latest stable version.

That's a 17% decrease in performance. I expected the 12% exe size increase since the 3D functions imposed their fat ass on us spriters, but the performance decrease is a bit steep.

Did it happen to you as well? What could be the reason for such an unpleasant performance drop?
Dar13
15
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 23rd Jun 2013 18:05
@AncientLady T1 checks both statements in an if-statement that has an AND command?

WTLD has been put on indefinite hold.
A new project is under initial development now.
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 23rd Jun 2013 18:59
Dar13, yes it does.

At least it did, I haven't checked to see if they fixed that.

I was going nuts on a project because it was failing on an 'if' statement in the logic after the 'AND' that should not have been reached.

Once I knew what the issue was, I had to go through lots of code to break up any 'if's that should stop after the first part.

In this example (made up just now), it would cause a failure in the app because the sprite does not exist and the GetSpriteX call still occurs:


And I just verified that it still fails in v10814.

It would be necessary to do this code, to keep it from failing:


Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
nz0
AGK Developer
16
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 24th Jun 2013 07:21
Yep, I think this is a biggie that needs to be fixed.
Quite a lot of built up overhead on this and not to mention the laborious nature of having to code around it.

Login to post a reply

Server time is: 2024-04-27 20:37:59
Your offset time is: 2024-04-27 20:37:59