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 / Poor Android performance when using LoadImage

Author
Message
Polaraul
9
Years of Service
User Offline
Joined: 13th Dec 2014
Location:
Posted: 4th Feb 2015 17:27
Link
I have about 10 such commands, one after the other. On Android this technique cuts the frame rate in half. Being relatively new to AppGameKit, this may just be my misunderstanding of the way the command works. Should I be doing this different?

Back to top
Profile PM
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 4th Feb 2015 17:58
Link
maybe the images are to big in size and not power of 2.
u can try SetGenerateMipmaps( 1 )
if each sprite use one image u can use LoadSprite



AGK 108 (B)19 + AppGameKit V2 Alpha .. : Windows 8.1 Pro 64 Bit : AMD Radeon R7 265 : Mac mini OS X 10.10 (Yosemite)
Back to top
Profile PM Email
paulrobson
10
Years of Service
User Offline
Joined: 22nd Nov 2014
Location: Norfolk, England
Posted: 4th Feb 2015 18:37
Link
Might work better if you put the images on one composite image and used LoadSubImage() , maybe ?
Back to top
Profile PM Email
Polaraul
9
Years of Service
User Offline
Joined: 13th Dec 2014
Location:
Posted: 4th Feb 2015 18:51
Link
Many thanks for all the suggestions and help. I changed the code to LoadSprite, but it made little difference. The images on average are about 10k in size and 800 x 800 pixels. They are all PNG's with a transparent background. I have stripped the code down to a bare minimum to demonstrate. The act of displaying these sprites cost 30fps!


Back to top
Profile PM
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 4th Feb 2015 19:10 Edited at: 4th Feb 2015 19:13
Link
u can print GetPixelsDrawn() on screen (Benchmarking commands),
maybe your device is to slow.
i guess a size of 800 will stretch intern to a 1024 texture size.
if u resize to 512 i think it look also good if it is stretch to screen size.
see also SetResolutionMode( mode )

in this example u paint ~12 screens in one frame.
for 60 fps u have 16 ms time.

AGK 108 (B)19 + AppGameKit V2 Alpha .. : Windows 8.1 Pro 64 Bit : AMD Radeon R7 265 : Mac mini OS X 10.10 (Yosemite)
Back to top
Profile PM Email
paulrobson
10
Years of Service
User Offline
Joined: 22nd Nov 2014
Location: Norfolk, England
Posted: 4th Feb 2015 19:18
Link
One of the problems is that whatever your PNG is, internally in the phone I think it is held as a bitmap, so you have 13 800x800 bitmaps which is quite a lot and it looks like they are all drawing full screen.

What sort of Android device are you using ?
Back to top
Profile PM Email
Polaraul
9
Years of Service
User Offline
Joined: 13th Dec 2014
Location:
Posted: 4th Feb 2015 20:29
Link
@Markus I resized the images to 512 by 512 and the frame rate did improve, but only by a few FPS.

@Paul I amusing a very lowly OneTouch Spop Phone and a Nexus 7 tablet, the FPS is the same on both.

It just seems a massive performance hit to display these sprites!
Back to top
Profile PM
unlikely
12
Years of Service
User Offline
Joined: 5th Mar 2012
Location: Ohio, USA
Posted: 4th Feb 2015 20:39 Edited at: 4th Feb 2015 20:41
Link
Looks like you are layering 13 full screen sprites. The fill rate required for this is almost surely going to be too much for most Android devices! Even if there are transparent pixels padding most of the image, the device won't be able to keep up if the sprites are full screen... layering transparent counts...

Using AppGameKit v2 T1 + T2
Systems: Primary: Mac OS X 10.10
Secondary: Windows 7
Back to top
Profile PM
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 4th Feb 2015 21:28
Link
It looks like you are coding your program to make the designing easier. That is, you make a full screen image to position a moustache in the right place.

If you apply a little more effort to the program then you can avoid this speed problem. Make all of your sprites the right size for the facial feature, position them appropriately and you'll save maybe 80%-90% of the Graphic memory you currently require.

Quidquid latine dictum sit, altum sonatur
Back to top
Profile PM Email
Polaraul
9
Years of Service
User Offline
Joined: 13th Dec 2014
Location:
Posted: 4th Feb 2015 21:30
Link
@unlikely I think this is probably the case, as my images are mostly transparency. I did it this way as I didn't want to cut up the images into smaller images and manually work out the positions for the sprites. It may be back to the drawing board for this one though.
Back to top
Profile PM
Polaraul
9
Years of Service
User Offline
Joined: 13th Dec 2014
Location:
Posted: 4th Feb 2015 21:45
Link
@Batvink This is the case, but in some cases it is not always about applying more effort. Time is a luxury, sometimes a luxury that we don't always have. Specially in some environments.

I was kind of hoping that I could port to AppGameKit near enough the same logic and assets that the original HTML5 JavaScript version used, however, seems this may not be the case.
Back to top
Profile PM
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 4th Feb 2015 21:48
Link
Maybe effort was the wrong word, I apologise.

One extra line per item would do it, you can get your coordinates from a full face image in your graphics package:

SetSpritePosition(6, 400, 600)

Quidquid latine dictum sit, altum sonatur
Back to top
Profile PM Email
Polaraul
9
Years of Service
User Offline
Joined: 13th Dec 2014
Location:
Posted: 4th Feb 2015 22:18
Link
@Batvink No problem at all. This is my first port using AppGameKit, and so far I have hit a lot of unexpected issues, so perhaps I am a little frayed around the edges!

I have to ask though, but is this type of performance an AppGameKit thing? Would all the current languages, Unity, Monkey-x etc have this type of performance? Or is this something unique to the way AppGameKit deals with sprites.

Thank you for your help though
Back to top
Profile PM
paulrobson
10
Years of Service
User Offline
Joined: 22nd Nov 2014
Location: Norfolk, England
Posted: 4th Feb 2015 22:48
Link
It's pretty much down to the hardware, not AGK.
Back to top
Profile PM Email
unlikely
12
Years of Service
User Offline
Joined: 5th Mar 2012
Location: Ohio, USA
Posted: 4th Feb 2015 23:11 Edited at: 5th Feb 2015 02:10
Link
Yep, pretty much any lower-end graphics hardware (such as that found in Android devices) is going to have trouble with high fill rate operation. It's not the language, it's the hardware (as paulrobson says.) There may be cases where the engine you are using (e.g. Unity) does automatic culling of transparent pixels on the display geometry so they aren't "rendered", for example, which could give the impression of better performance in your application.

But yeah, best to do as BatVink was suggesting and crop your images tightly and position them at the correct coordinates. Or, even better yet on mobile, load all of your character parts from spritesheets and use LoadSubImage ( iParentIndex, sImageFilename ) to slice it up!

Using AppGameKit v2 T1 + T2
Systems: Primary: Mac OS X 10.10
Secondary: Windows 7

Attachments

Login to view attachments
Back to top
Profile PM
Polaraul
9
Years of Service
User Offline
Joined: 13th Dec 2014
Location:
Posted: 4th Feb 2015 23:26
Link
@unlikely I think that is it, I just assumed that AppGameKit was culling the transparent pixels.
Back to top
Profile PM
paulrobson
10
Years of Service
User Offline
Joined: 22nd Nov 2014
Location: Norfolk, England
Posted: 5th Feb 2015 07:23
Link
It would be a bit of an odd thing to do. Most systems I know (2D ones anyway) work like AppGameKit viz. you have a collection of images, possibly all joined up together that are pretty closely cropped to the actual graphic.

If there are a lot of these, then it would be easy enough to write a python script that trimmed them and dumped the offset position to a text file (or generated a BASIC file to #include or whatever). Is this one graphic subdivided into layers or something ?
Back to top
Profile PM Email
Impetus73
13
Years of Service
User Offline
Joined: 28th Aug 2011
Location: Volda, Norway
Posted: 5th Feb 2015 08:40
Link
All the transparent pixels, are also processed, and this means the screen has to be rendered 13 times, each loop. I never use more than 2x screen size, in active sprites areal at a time, when i sum all the small sprites.

----------------
AGK programmer
Did Amiga / AMOS programming in the 90's.
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-11-25 16:50:11
Your offset time is: 2024-11-25 16:50:11