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
TDavid
11
Years of Service
User Offline
Joined: 7th Feb 2013
Location:
Posted: 27th May 2013 11:47
Link
Hello,

Yesterday I tested my app with the 1.07 agk player on my 1000ghz android device and I had the bad surprise to watch it running at 18 fps instead of 60.

I'm doing my best to remove as much transparent images as possible (I used 3 layers of png to make random landscapes, a three other layers for player feedback and UI and I think that's the main issue) but I need to save as many CPU cycles as I can. I don't know a thing about how openGL and AppGameKit work, so I have a bunch of questions if you don't mind.

1) Will my app run better as an apk than on the player?

2) What is better for performance: use a 1024*1024 png as a background image or tile 32 pngs of 32*32? (The background image has transparency set to 0 and will obvisously be covered by 3 layers of transparent images

3) Will it improve performance if I scale up small images instead of using large images?

4)What is better for performance: using a 6 frames animation of a fading image, or using the transparency functions to have a single frame image fade 6 times?

5)To make my life simpler, every animated sprite that have to be played often have an empty frame at the end, so that when I used the playsprite function, it would disappear at the end of its animation. Would it be a lot better for performance if I used setspritevisible to make it invisible instead?

6) One of my AI uses physics to locate the player. I have between 150 and 200 static boxes, and I use a raycast to check if there's no box between the AI and the player. Is it better for performance if I remove all physics and make a function that would check the map for obstacles (the map consists in zeroes and ones in an array)?

Thanks for your time.
Back to top
Profile PM
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 27th May 2013 13:00
Link
there are some useful Benchmarking commands you can print at screen on runtime.
i read the pixel fillrate is important.
1. i think it would make no difference.
2. its faster painting one pic, if you use some pics overlap for background maybe you can make a single pic.
3. u need less memory but if the size on screen is the same i think you don't get a better performance.
4. i use setspritealpha
5. invisible is better because it will not painted.
6. physics slow down only at movement and collision check, with physicdebug on you can see if the physics sprites goto sleep mode.

you can get more performance if you disable the clear background each frame.

18 fps sounds very low, maybe u use some long repeating for next loops in game each frame.

EnableClearColor
SetResolutionMode
SetGenerateMipmaps
Back to top
Profile PM Email
TDavid
11
Years of Service
User Offline
Joined: 7th Feb 2013
Location:
Posted: 27th May 2013 13:48
Link
Thank you for your answers. They are most helpful.

My next loops only repeat 5 times at most. I'll look into it again later. I don't have access to my computer for 4 hours.

I think the problem stems from the map my app generates. First there's the background image. Then a layer with randomly placed walls. Then under each wall a layer with grass. That makes a minimum of 1000 transparent images, each one overlapping 3 or more others. The generated map doesn't change during gameplay. The best option would be to transform my map into one big image after it is generated by the app but I don't even know if it's doable with the basic functions. Is it?

I used the physic engine to save time. I'll try disabling it and see if I get some extra fps.

5 sprites have their depth level changed quite often, could that eat many cpu cycles?

I hope I find a faulty loop or a way to merge my background map because I still have more sprite to draw onscreen.
Back to top
Profile PM
Mobiius
Valued Member
21
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 27th May 2013 14:15
Link
Quote: "1000ghz android device "

You have a 1 terrahertz android device??? Damn you're lucky!

I live for video games! (And beers, and football, and cars!)
See what I live for here: [url]http:\\www.TeamDefiant.co.uk[/url]
Back to top
Profile PM Email Website
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 27th May 2013 15:18
Link
i think you make a tileset based game.
yes, don't create sprites/blocks if they fully overlap from
other sprites.
if possible fill the background also with blocks if you see
only a few gaps.
you must find a block count limit where the frame rate is ok.
Back to top
Profile PM Email
Funnell7
12
Years of Service
User Offline
Joined: 8th Sep 2011
Location: UK, England
Posted: 27th May 2013 15:24
Link
Quote: " you can get more performance if you disable the clear background each frame."


Markus, what do you mean by this? Could you post an example? Thanks...
Back to top
Profile PM Email
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 27th May 2013 16:03 Edited at: 27th May 2013 16:07
Link
@Funnell7
clearing the background and painting complete over it is nonsense.
with EnableClearColor(0) you can disable it.
its on by default and the clear screen begin after the back buffer > front buffer swap in the sync() command
if this flag is set.
Back to top
Profile PM Email
MarcoBruti
12
Years of Service
User Offline
Joined: 20th Nov 2011
Location: Caput Mundi
Posted: 27th May 2013 16:33
Link
Check the number of sprites you are using.
In my app Retrobikerunner, I use about 512 sprites to draw the lane and the border (each row is 8 sprites and there are 64 rows), plus the sprites for the trees, the signs, the bike, the ostacles, pickup etc.
The sprites are of different size in order to simulate perspective.
My device is 800Mhz (Galaxy Gio). Your device is more powerful, but if you exceed too much the sprite number, FSP goes down.
I keep about 20-30 FPS on my device, it is acceptable, but increasing the number of sprites, FPS go below 10.
Back to top
Profile PM Email Website
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 27th May 2013 17:06
Link
1) On Android, there might not be a huge difference - if any at all. But on iOS, iPads and iPhones, if you decided to support them fully, then the difference between the iOS broadcast and the iOS app is huge, monstrously huge in fact. So maybe it's worth deciding whether or not to go fully native as a standard.

2) I think the big 1024 image would be quicker, just because of alpha transparency - see a big image only has to worry about what is underneath, but lots of smaller images might mean lots more alpha depth checks, with what is underneath but maybe also what is around the sprite. If the sprites are side by side, maybe the render will have to take those edges into account, meaning a lot of unnecessary alpha checks.

Alpha transparency as I said, is probably the biggest performance drain - reducing the amount of that is always gonna be time well spent.

3) Depends on if your using alpha transparency. If you are, then it probably won't make a huge difference, because it'll be checking the destination pixels regardless. If your not using transparency, then it might improve performance, as it would only need to check the original image and overwrite the destination pixels - no need to read the destination pixels if they're just being overwritten. Note that you'd have to disable transparency (or not enable it in the first place), to get proper benefits from this. Also, the min and mag filter settings probably play a part - setting them to 0 should improve performance, but I guess that depends on the look your going for - some people like pixelation

4) Probably not much - except that fading the sprite rather than animating the fade would mean that you could use single frame images, which means a smaller memory footprint - not just the image, but the ancilary information for animation as well. It makes sense to fade with code - hell, that way you can adapt it for timer based movement if you need to - or make it a slower transition... fading with code is just a better system all round I think.

5) Yes, again, especially if your using alpha transparency. I actually set my un-needed sprites to invisible and move them off the screen, just to avoid any weirdness with collision etc. I'd say you should consider making your own animation system - maybe even your own entity system too, to control your sprites and allow them to be re-used neatly. This would be slower than just using AGK's sprite animation on a sprite by sprite basis - but in the long run it would make it easier to optimize your sprites, because without it you might end up having to use slower commands to do things like disable a sprite. Personally, I always like to have a big array full of all the information I need - I update that and the relevant sprites get updated. It takes planning and time, but it's time well spent - consider how easy you want it to be to generate a sprite particle effect, or a bullet, or spawn an enemy, or destroy an enemy. Sometimes it's good to stand back, and pretend the picture is bigger than it really is - then your peripheral vision is ready for the next challenge .

6) Well with the built in physics - it's all in place, it's all working. It might not be the fastest solution, but just because your map is controlled with an easy and understandable format, doesn't mean it'll be easy to check for exact collision. I mean, you'd be able to get a point collision check working incredibly quickly, a quick as AppGameKit can possibly be - basically just an array check based on a divided cell location that relates to the array index. Using the array might also be really good for path finding - like if the enemy can't see the player, they could head towards the last known position, using some sort of array based path finding (using a flood fill technique maybe) - AI can make or break a project, stick to the technique that you understand the best, and can adapt to suit your own needs. It might be an idea to do a range check - if the player is more than 10 map grids away from the enemy, and the enemy can't see the player based on a line-of-sight check, then they need to follow the path - otherwise they head towards the player.
With an array line of sight check, you'd use brute force to find the collision - like imagine storing the position of a bullet, starting at the enemy position, and heading towards the player position. The accuracy would depend on how far the bullet travels each time. A step size of 1.0 for example might not be ideal, it would miss a lot of angles - could easily go right through the corner of a cell. A step size of 0.1 would mean a reasonably accurate check, but then that's 10 times as many checks, multiply it by the number of enemies, and you end up with a fairly time hungry operation.
On the other hand, the physics collision is already in place and probably works really well. It's accurate, it can adapt to things like rotation (hiding behind doors for example!). You could add your own line to line collision check, or box to line, circle to line, all those standards - but at the end of the day you'd just be mimicking what Box2D already does.


Anyway, hope some of my ramblings helped you

I got a fever, and the only prescription, is more memes.
Back to top
Profile PM Email
TDavid
11
Years of Service
User Offline
Joined: 7th Feb 2013
Location:
Posted: 27th May 2013 21:51
Link
Thank you, (most of) you were really helpful.

I already had a picture of what I wanted to achieve and the game actually looks like what I wanted it to. unfortunately with shadows, grass and trees overlapping each other my phone can't handle it. I'm especially angry at the way I included 45° shadows in my images because they enlarge the picture needlessly, and now the engine has to deal with huge transparent sprite overlapping many others. I can't get rid of them because it would mean throwing all my sprites away, and I can't afford that.

I have a plan to replace a third of my transparent tiles with non transparent ones without graphic loss, but it'll require a lot more coding. I'll report about the change you proposed.

Thanks again.
Back to top
Profile PM
Funnell7
12
Years of Service
User Offline
Joined: 8th Sep 2011
Location: UK, England
Posted: 27th May 2013 23:22
Link
Markus, thanks! I'll be honest though, the whole back/front buffer is abit too advanced for me so I don't really know what you are talking about. But if I have understood you correctly, basically if I have a background which covers the entire screen (which I do) and if I'm not using any Print commands or anything which relies on the 'ClearColor' (which I don't) then I can disable it and that would increase performance, is that right?

Any idea on the performance increase? Is it significant?

As always, many thanks!
Back to top
Profile PM Email
AgentSam
12
Years of Service
User Offline
Joined: 14th Mar 2012
Location: Virtual Space
Posted: 28th May 2013 04:07 Edited at: 28th May 2013 05:59
Link
Quote: "Any idea on the performance increase? Is it significant?"


It's almost impossible to guess what the performance difference will be.

But the difference should be greater, the slower your device is!

I've thrown together a small TIER1 benchmark for you. It's based on the Benchmarking demo included with AppGameKit, but allows you to use keyboard controls to change a few settings on the fly. This should help you see if "EnableClearColor" makes any difference. The benchmark has built-in keyboard help, so it should be easy to figure out.

(But it's sort of difficult to use on a touch screen without a keyboard! Sorry. You might need to add UI controls to the code...)

And I recommend grabbing the attached zip.. because there are a few media files included, so the source alone is pretty useless.



Cheers,
AgentSam

Attachments

Login to view attachments
Back to top
Profile PM
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 28th May 2013 12:33
Link
@Funnell7
generally you can memory the time before and after a function block.
this needs a hi resolution timer.
with this results you can see what you must optimize at first.
also you can look at your source code and think about what your
computer must do, you get a feeling how long he needs, you can
see if something done often unnecessary.
example: the same calculation in a loop which maybe can done before the loop once.
Back to top
Profile PM Email
TDavid
11
Years of Service
User Offline
Joined: 7th Feb 2013
Location:
Posted: 28th May 2013 13:13
Link
I did a couple optimizations before the OP and increased frame rate from 18 to 24. ( I replaced a heavily managed sprite function with a simple animated sprite and removed 4 screenwide UI alerts). I also set the sync rate to 30 with the necessary changes to gameplay speed.

The sprite count is 957. Then I tried Markus' quick tips using the screenfps function. I tried the three settings separatly:

No setting : 24 fps.
EnableClearColor(0) : 24 fps
SetResolutionMode(0) : 24-25 fps
SetGenerateMipmaps(0): 24 fps
SetGenerateMipmaps(1): 23 fps (?)

I thought mipmaps were supposed to increase rendering speed so I didn't use it in the following test. With these two settings together:
EnableClearColor(0)
SetResolutionMode(0)
-> 24 fps

I don't have that many sprites, I read people talking about 1200 sprites in their app. That may explain the fact that the mipmap setting actually slowed down rendering. The fact that the numbers didn't change could mean that the game is slowed down by a faulty loop. I'll look into it in priority. I have a huge number of overlapping transparent sprites at the moment and these results may also mean that this issue is to big to be counter-balanced by these settings alone. If my next-loop hunt returns nothing I'll need to deal with this poor design choice quickly.
Back to top
Profile PM
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 28th May 2013 14:41
Link
the result is different on each device/os version and its not wrong
to optimize all you can. at my device the command EnableClearColor
make much difference in fps.
the SetResolutionMode i use because i will see not a scaled graphic.
i think mipmaps are useful if you use zoom sometimes and want see hires graphics and far away you need only a smaller pic.
if you want 5 frames more in this example there is something that
need 6,66 ms, thats a very short time
30 fps = 33,3333 ms each frame max.
25 fps = 40 ms
Back to top
Profile PM Email
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 28th May 2013 22:44
Link
There are three main things that could cause a slow down like this

1) CPU usage, mainly caused by things like large complex loops or lots of physics

2) GPU throughput, the number of sprites it has to manage. AppGameKit can handle thousands of sprites but if each one has its own image this can cause the GPU to stop drawing after every sprite to change image. The most efficient way is to have a few 1024x1024 atlas textures that contain all the images you want to use, the GPU can then draw all sprites that share the same atlas texture together. Using SetSortTextures(1) will also help if you do this.

3) GPU fill rate, the number of pixels the GPU has to draw to the screen. For example having 10 full screen sprites on a 1280x800 display means the GPU has to draw 1280*800*10 = 10 million pixels every frame. Turning off sprite transparency on those sprites that don't need it can help here as opaque pixels are drawn faster than transparent ones (even if they are fully transparent). Devices that use Tegra 2 suffer the most here as they can only draw a couple of full screen transparent sprites before slowing down due to fill rate.
Back to top
Profile PM Email
Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
Posted: 28th May 2013 23:03
Link
One thing i noticed while making my appup game that is tile based! is that if you use uniqe collision SHAPEs on all sprites on screen so will it slow down alot on mobiles.
I simply used a dummy sprite i added SHAPEs to where the static tiles where positioned.

Increased the framerate by 10-16 fps in that game at least

And if you dont use any of the image manipulation functions so could you also turn of this!
SetImageSavePixels( 0 )

This will make your app use less memory but be slower when you copy images etc at realtime.

Android 2.3 , ZTE Skate , 480x800 , 800 mhz , Samsung Galaxy Y , 240x320 , 832 mhz , Sony ericson arc 480x854 , 1 ghz
Android 4.0 , Dmtech 3g 9738B , 1024x768 , 9.7 inches , 1.2 ghz
Back to top
Profile PM Website
AgentSam
12
Years of Service
User Offline
Joined: 14th Mar 2012
Location: Virtual Space
Posted: 29th May 2013 00:14 Edited at: 29th May 2013 00:14
Link
Paul,

I'm adding your comments above to my own private AppGameKit coding tips library, but I didn't quite understand one part of what you said:

Quote: " ... can cause the GPU to stop drawing after every sprite to change image. "


What exactly do you mean by that? Can you rephrase what you mean.

Cheers,
AgentSam
Back to top
Profile PM
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 29th May 2013 00:30 Edited at: 29th May 2013 00:31
Link
Quote: "What exactly do you mean by that? Can you rephrase what you mean."


When drawing sprites with OpenGL you must first set all the GPU states you want to use to draw it, for example alpha blending, the images it uses, any shaders, etc. If every sprite contains a different image we must set the states for the first sprite, then call the OpenGL draw command, then change states, then draw the next sprite, and so on. If we have a bunch of sprites that all share an image, like an atlas texture, then we can set the states once and tell it to draw all those sprites in one call. Drawing in a single call is faster than making several draw calls.
Back to top
Profile PM Email
AgentSam
12
Years of Service
User Offline
Joined: 14th Mar 2012
Location: Virtual Space
Posted: 29th May 2013 01:14 Edited at: 29th May 2013 01:14
Link
Quote: "... then call the OpenGL draw command, then change states, then draw the next sprite, and so on."


@Paul:

Ok. Good background info. But, is there really a possibility, that the GPU on some devices will actually "stop drawing", when a scene render involves multiple such GPU state changes? (That's the part I was referring to as needing further details, in my earlier post.)

And if so, which devices are known to exhibit this behavior? o_O

Cheers,
AgentSam
Back to top
Profile PM
Mobiius
Valued Member
21
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 29th May 2013 17:24
Link
He means the app will freeze temporarily whilst it changes states, causing your app to stutter.

This is my current project, check it out! [href]forum.thegamecreators.com/?m=forum_view&t=204576&b=8[/href]
This is my website, check it out! [href]http:\\www.TeamDefiant.co.uk[/href]
Back to top
Profile PM Email Website
Marl
12
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 29th May 2013 18:18
Link
I honestly don't think Paul was being that literal.

"if each one has its own image this can cause the GPU to stop drawing after every sprite to change image."

Simply means that there will be more image changes which will add processing time. It doesn't mean the GPU will actually STOP rendering your scene or cause jumps.
Back to top
Profile PM Email
TDavid
11
Years of Service
User Offline
Joined: 7th Feb 2013
Location:
Posted: 29th May 2013 18:29
Link
I tested huge road background + small wall tiles against small road tiles + small wall tiles and the former was 3 fps faster than the latter (transparency off for every image). The second one had 150 more sprites, though. My situation is a bit unusual with 900 sprites but this information might be useful to someone so I post it here.

The huge background should take more memory but as far as rendering speed is concerned, reducing the number of sprites seems to be of utmost importance.
Back to top
Profile PM
AgentSam
12
Years of Service
User Offline
Joined: 14th Mar 2012
Location: Virtual Space
Posted: 29th May 2013 18:47
Link
@Mobiius and Marl:

My brain sort of went into a state of infinite-loop when I read something that doesn't make any sense. Happens sometimes.
But I got out of the loop, thanks to your comments.

Cheers,
AgentSam
Back to top
Profile PM
nz0
AGK Developer
16
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 29th May 2013 22:03
Link
@TDavid: Let's have a look at a screenshot of your game.
Also, what resolution are you running at?

You might want to check the device GPU out (it's not just the CPU which dictates performance)

My eyes rolled when I saw
Quote: "
used 3 layers of png to make random landscapes, a three other layers for player feedback and UI
"


You are almost certainly right to suspect this as the issue.
I posted a list of performance enhancements for android (specifically rubbish, overpriced, big screen devices - ahem) which will help you, but probably not get your frame rate back.

Put it this way, I am UNABLE to have a backdrop and a modest amount of transparent sprites on top of it and maintain framerate on one of my android devices.. Just about got it functional with every trick in the book. In fact now, I have to do a LOT of work making a new background system.

As has been said, some devices can only draw 1.5 screens of pixels per frame. With a background, that gives you 0.5 screens (480x320)? of sprites and other things - not a lot!

As for the number of sprites: I can kill my XOOM with 2 sprites at 960x640.

My Robotron remake
My I,Robot remake WIP
Back to top
Profile PM Email Website
TDavid
11
Years of Service
User Offline
Joined: 7th Feb 2013
Location:
Posted: 30th May 2013 12:19
Link
My phone is a motorola defy. According to wikipedia, "The Defy CPU/GPU is TI OMAP3 architecture OMAP3630 and the PowerVR SGX530". I'm totally ignorant when it comes to phone hardware but since it's quite an old phone, I think my app will run on a respectable range of phones if I manage to get it run at 30 fps.

By the way, my app runs at 800*480.

The reason why I didn't care about image size nor number of layer is that I never expected a 2D games to stutter on modern phone. Most 2D games run flawlessly on low end computers with integrated graphic cards.

In the end, I really didn't care about optimization. My game loads 85 sprites and the 20 animated ones run at 24 fps, which means they all have many frames drawn. And most of my images are of different sizes, which means that if I try to make an atlas out of them I suspect it will probably increase the fill rate!

Well, at least it looked cute.

This post should be stickied as "What not to do when making your app".
Back to top
Profile PM
nz0
AGK Developer
16
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 30th May 2013 21:58
Link
I found my old thread - http://forum.thegamecreators.com/?m=forum_view&t=201096&b=41

I think if you're shifting big sprites about and not using atlas sheets, coupled with large (or any) alpha, this is the killer.
What's more, alpha sprites (on top of) alpha sprites (on top of) yet more sprites...

I'm sitting on my 18 month old game as I can't release it on android yet. I've got a load more work to do to make a background chopping system, as I simply can't use a background.

This is my game which currently is too much for a £300 XOOM to run..

http://www.youtube.com/watch?v=ZstzSM0JmBA

My Robotron remake
My I,Robot remake WIP
Back to top
Profile PM Email Website
AgentSam
12
Years of Service
User Offline
Joined: 14th Mar 2012
Location: Virtual Space
Posted: 30th May 2013 22:17
Link
@nz0:

I loved the original Super Pipeline, and this remake is true to it.
It looks great and action packed, just like the original.
I hope you get it released.

Cheers,
AgentSam

PS. Was this a TIER1 or a TIER2 project?
Back to top
Profile PM
nz0
AGK Developer
16
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 30th May 2013 22:28
Link
Thanks - it's T1.

I have done all 16 original levels and all the cutscenes.
I can't not have a background, so I've got the artist to make new backgrounds from tiles which will allow me to only need to fill 60-70% of the background.

I will release it, but I'm on another project now so will return to it again.

My Robotron remake
My I,Robot remake WIP
Back to top
Profile PM Email Website
TDavid
11
Years of Service
User Offline
Joined: 7th Feb 2013
Location:
Posted: 31st May 2013 01:43
Link
Thanks for your precious input. I set up an atlas for ground sprites and revamped my level generator according to your advices and it increased my fps from 24 to 34. I now have 750 sprites drawn onscreen, down from 950, and the difference is barely noticeable.

There's still room for improvement since I have yet to make atlases for every other sprites but the worst is behind me.

I'll post a video of my app here when it's done, right now there are too many placeholders and the UI is not done yet (I even had to remove some, doh!).
Back to top
Profile PM
AgentSam
12
Years of Service
User Offline
Joined: 14th Mar 2012
Location: Virtual Space
Posted: 31st May 2013 05:26
Link
@Nz0:

Man, I like your videos on youtube - watched quite a few.
You and Ken seemed to have a lot of fun fishing!

Also, I'm interested in Refender, it looks really awesome.
The info on youtube is rather brief. Any more info on it?
What's it made with, etc.

Cheers,
AgentSam
Back to top
Profile PM
nz0
AGK Developer
16
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 1st Jun 2013 01:42 Edited at: 1st Jun 2013 01:43
Link
There's a WIP thread in the showcase: http://forum.thegamecreators.com/?m=forum_view&t=204427&b=48

I haven't put an updated video up for a while but it's a lot more advanced now.

It's made with AppGameKit T1.

You can download the latest demo version here

My Robotron remake
My I,Robot remake WIP
Back to top
Profile PM Email Website
AgentSam
12
Years of Service
User Offline
Joined: 14th Mar 2012
Location: Virtual Space
Posted: 1st Jun 2013 02:09
Link
Quote: "There's a WIP thread in the showcase..."


Roger. I'll comment there in the future.

Cheers,
AgentSam
Back to top
Profile PM
Funnell7
12
Years of Service
User Offline
Joined: 8th Sep 2011
Location: UK, England
Posted: 5th Jun 2013 02:15
Link
I have another performance question if I may (sorry for hijacking this post... again)! In my platform game I have ALOT of sprite collision checks (coins, enemies, spikes, platforms, hearts etc etc), and I do this every frame. Would it be a performance boost if I were to check for collisions only on objects which are currently in view?

I'm thinking that in order to do this, I would have to check the objects X/Y via GetSpriteX/Y anyway so am not sure if this would be any quicker than just checking the collision?

Thanks!
Back to top
Profile PM Email
nz0
AGK Developer
16
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 5th Jun 2013 02:38
Link
Checking the position is always going to be quicker than checking for collision.

I use an exclusion function (isSpriteVisible) - you can guess what it's doing - which is an initial condition before I check for collisions.

It may/may not be required, but I figured it was cheap enough (cheaper than a collision check anyway)

Besides, I keep track of my sprites usually in a UDT array, which contains the co-ords of the sprite. Quick and simple to check if they are on screen first.

I'm assuming your game is multi screen, hence the question..

My Robotron remake
My I,Robot remake WIP
Back to top
Profile PM Email Website
Funnell7
12
Years of Service
User Offline
Joined: 8th Sep 2011
Location: UK, England
Posted: 5th Jun 2013 03:08
Link
Quote: "Checking the position is always going to be quicker than checking for collision."


This says it all! Thanks nz0, I'll add a 'isSpriteVisible' check!

Yes, I have multiple screens and currently I'm checking for collisions even when my character isn't anywhere near the object (the view follows my character), which kinda crossed my mind as abit silly, hence the question! Thanks again!!
Back to top
Profile PM Email
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 5th Jun 2013 04:27
Link
nz0, I am assuming that your isSpriteVisible function is a home built one (using position and display area and such) since it isn't an AppGameKit function.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
Funnell7
12
Years of Service
User Offline
Joined: 8th Sep 2011
Location: UK, England
Posted: 5th Jun 2013 11:45
Link
Quote: "I am assuming that your isSpriteVisible function is a home built one "


That was my assumption too... I'd love it if there was a command already that checked the sprite was on screen, but I don't believe that exists... I was just going to create a function which checks to see if the sprites X/Y is GT/LT the ViewOffsets X/Y...
Back to top
Profile PM Email
nz0
AGK Developer
16
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 5th Jun 2013 20:34
Link
Yes, it's just a simple function.

I think DBP had a useful isObjectVisible() function built in.

My Robotron remake
My I,Robot remake WIP
Back to top
Profile PM Email Website
Dar13
15
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 6th Jun 2013 00:41
Link
Quote: " I think DBP had a useful isObjectVisible() function built in."

Unfortunately it was broken more often than it was useful IIRC. But yes, functions like that are quite nice.

WTLD has been put on indefinite hold.
A new project is under initial development now.
Back to top
Profile PM Email
baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 6th Jun 2013 01:23 Edited at: 6th Jun 2013 01:26
Link
Untested "isSpriteVisible" function:


Edit: added the return value


this.mess = abs(sin(times#))
Back to top
Profile PM Email
TDavid
11
Years of Service
User Offline
Joined: 7th Feb 2013
Location:
Posted: 7th Jun 2013 19:36
Link
I have another performance question which will probably sound stupid but I'd rather sound stupid for a day than being ignorant until I'm dead.

Are "get" functions like getspritevisible() or getspritealphacolor() more CPU intensive than managing the actual value in an array/global variable?

For instance, I have a sprite which transparency changes often during gameplay. Until now I used an array to store the transparency of this sprite. Would it be any different CPU wise if, instead of getting this value from the transparency array, I used getspritealphacolor()?
Back to top
Profile PM
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 7th Jun 2013 20:19
Link
You are definitely better off managing the values in arrays than repeatedly calling the get<attribute> function.

Accessing/storing a value in an array is fairly quick.

Using the functions creates stack entries and function evaluations and stack handling on the return (very loose description) and definitely takes more CPU time.

I am always surprised when I see people continually using function calls and math to get a value every Sync cycle when the value from the function never changes. Things like 'x = somval + (GetDeviceWidth() / 2)'. It would save much time to instead, after setting display parameters, simply set a global variable to 'GetDeviceWidth() / 2' and use that variable thereafter.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
nz0
AGK Developer
16
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 7th Jun 2013 20:49
Link
There are benefits to both methods I feel.

I pretty much routinely manage my sprites using a UDT array (in some cases it's essential).

You could argue from the performance angle around the efficiency of looking up sprite co-ords in your UDT array vs the engine's GetSpriteX() and on a 1-to-1 comparison, the engine would be faster (for T1 anyway).

AL is right about the persistance of obvious values. I checked my code for optimisation in a particular area and found that I could persist a value outside of a nest of loops at n*64 (for the duration of the loops).

I had to work out on a calculator how much this saved, but it turned out to be about 1.3 million calculations per frame, just by pre-calcing this value.

It's definately worth taking a leaf out of the "old" ways we used to have to code (fighting for cycles all the time) as it's so easy to get complacent and code "lazy".

Back to your original question. I think the benefits of maintaining your sprite properties yourself are totally dependent upon the scale of what you are doing. Tracking 5000 sprites is not going to be efficient or manageable without arrays/UDTs. Likewise, if you are only going to set it once - does it matter? - especially during initialisation, which doesn't matter.

Definately ask the questions though! Many other people will surely benefit.

My Robotron remake
My I,Robot remake WIP
Back to top
Profile PM Email Website
TDavid
11
Years of Service
User Offline
Joined: 7th Feb 2013
Location:
Posted: 9th Jun 2013 13:15
Link
I try not to use "blue" functions as much as I can but these "get" functions suddenly seemed straightforward enough to make me wonder if I was not doing it the "hard way" needlessly.

Thanks again for you help, both of you. My main issue is the fill rate but it doesn't hurt to keep things as clean as possible.
Back to top
Profile PM
Dar13
15
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 10th Jun 2013 07:45
Link
Yes calling a "get" function can increase overhead, but don't go about over-engineering a workaround to it or else the inherent overhead that T1 has would negate any gain.

Quote: "It's definately worth taking a leaf out of the "old" ways we used to have to code (fighting for cycles all the time) as it's so easy to get complacent and code "lazy"."

But there is such a thing as premature optimization which is a bad thing.

WTLD has been put on indefinite hold.
A new project is under initial development now.
Back to top
Profile PM Email
TDavid
11
Years of Service
User Offline
Joined: 7th Feb 2013
Location:
Posted: 10th Jun 2013 21:10
Link
Okay here is what I learnt when optimizing my app. I post it here because it might be useful for begginers.

As many enlightened people said here, every pixel of every sprite that is not set invisible nor offscreen will be drawn, regardless of depth priorities. So the best tip is to keep the number of fully transparent pixel to a minimum. Fully transparent pixels count as regular pixels, except they're useless.

As the help file states, it's better to disable alpha color on a sprite when possible. A sprite with alpha color enabled counts as two sprites with alpha disabled performance wise.

A high number of sprites can counterbalance the benefits of a carefully managed fill rate. In my app, 50 static sprites were less efficient that one single sprite 3 times bigger.

Don't be afraid of the particle functions. I added 8 static particle emitters with twice the original life length and I only lost 1 fps. Totally worth it.

Atlasing half my images added around 4 frames per second, enabling setsorttextures() added one on top of that. I had to optimize my images to do so, but it's still a consequence of atlasing.
Back to top
Profile PM
nz0
AGK Developer
16
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 11th Jun 2013 01:49
Link
@dar13: Yes, agreed. Look at that code a couple of weeks later and wonder what the hell is going on

@TDavid: Fill rate is indeed the issue on many android devices. With the fill vs sprite count (and all those other things) it's a fine balancing act. Glad to see (although I feel your pain!) someone else feeding back on "performance" and optimisation ideas.

I was quite impressed with the built in particles, however no good for me in my current game, as you can't affect the particles "manually" after they have been emitted. When I was culling performance issues on my last game, I was suprised how low a hit particles were, even on a poor android platform.

My Robotron remake
My I,Robot remake WIP
Back to top
Profile PM Email Website
Funnell7
12
Years of Service
User Offline
Joined: 8th Sep 2011
Location: UK, England
Posted: 20th Jun 2013 23:47 Edited at: 20th Jun 2013 23:49
Link
Before I go ahead and make a huge change, I was wondering whether the below would have a decent performance boost. What do you think? Is it worth me making this change?

Imagine a platform game where the ViewOffset follows the player. There are approximately 100 coins scattered around the level, current I do this every cycle;



Basically I'm checking for a collision on every coin, every cycle (seems daft).

My new potential method is this;



Now I'm only checking for a collision if the Coin is in view, but in doing so, I am having to call GetSprite to locate the Coin Position every cycle. Would this be any quicker do you think?

Many thanks!!
Back to top
Profile PM Email
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 21st Jun 2013 00:11
Link
I suspect that your original code will work faster. The internal bits will already get the information about the sprite before it does the collision check. And it will still do so in your second example. But in your second example, you are now do two extra calls.

So, the first code does exactly 100 function calls. The second does at a mininum 200 calls and then again as many calls as there are coins in the current view. Since the Tier 1 logic doesn't stop parsing an if statement when the minimum info is needed, it will always call both GetSpriteX/Y functions. (In a good parser, it would stop parsing if the coin's X was less than CurrentViewX.)

I would suspect you are better off not making the change.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-04-27 23:26:29
Your offset time is: 2024-04-27 23:26:29