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 / Need help. LoadSubImage and LoadImage works differently

Author
Message
Effishen
10
Years of Service
User Offline
Joined: 13th Jun 2014
Location:
Posted: 13th Jun 2014 22:44
Link
Hello AppGameKit community!

I have been working on a prototype game and need some help.

This is the bunch of codes that I used to set game resolution :

SetDisplayAspect( 0.66 )
SetVirtualResolution ( 960, 1440 )
SetResolutionMode(1)
SetOrientationAllowed ( 1, 1, 0, 0 )
SetIntendedDeviceSize( 960, 1440 )

I have a sprite that works beautifully on both PC and AppGameKit Player.
I had so many of the following lines for that sprite :

AddSpriteAnimationFrame (sprite1, LoadImage( "images/anim1.png" ) )
..
..
etc

Then it dawned on me that the load times is incredibly long, so I decided to use Atlas image.
I have successfully converted all the above lines into this :

atlas1 = LoadImage("images/atlas.png")
AddSpriteAnimationFrame (sprite1, LoadSubImage(atlas1, "anim1.png" ) )
..
..

And when I click on the green 'play' button to test on my PC, it works wonderfully. (size, everything is exactly the same as before)

But when I ran it on AppGameKit player, sprite1 became very tiny!

Can someone help me solve this please?

Many many thanks

Effishen
Back to top
Profile PM Email
Markus
Valued Member
21
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 14th Jun 2014 11:23
Link
try remark SetIntendedDeviceSize

AGK 108 (B)19 : Windows 8.1 Pro 64 Bit : AMD Radeon R7 265
Back to top
Profile PM Email
Effishen
10
Years of Service
User Offline
Joined: 13th Jun 2014
Location:
Posted: 14th Jun 2014 11:31
Link
actually the problem began without SetIntendedDeviceSize, I added that to see if it will affect anything. It still became tiny when I test on AppGameKit Player

Any other suggestions?

Effishen
Back to top
Profile PM Email
Effishen
10
Years of Service
User Offline
Joined: 13th Jun 2014
Location:
Posted: 15th Jun 2014 20:33
Link
I forgot to mention that the Atlas I used is actually 3680x3680 (due to the massive amount of animations)

I fiddled with it, and took 6 of them out of the massive Atlas and created another Atlas via LoadImage. Since each png is 230x230, I chose to use an Atlas of 690x690.

Modified 6 lines of the 'AddSpriteAnimationFrame's and as it turns out, the 6 frames when played back on AppGameKit Player is of the correct size!

I've read a lot of threads on this forum and everybody is recommending to limit the Atlas to be 1024x1024, but I can't seem to find the actual reason behind it, other than 'it uses a lot of memory'

1.) Is what I am experiencing an intended behaviour of my 3680x3680 Atlas?

2.) I can't logically split the animations into groups of 16 (to fit into 1024x1024 spec), can you help advise me of another method (if there is any) ?

3.) Another question that is related yet unrelated, between 256 LoadImage calls of small 230x230 images vs 16 calls of 1024x1024 images, which would be faster?

Many thanks for all help!

Effishen
Back to top
Profile PM Email
Marl
13
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 15th Jun 2014 23:00 Edited at: 15th Jun 2014 23:01
Link
Firstly;

If you're using SetVirtualResolution(), you shouldn't use SetDisplayAspect() - these do the same thing with different display methods so both are not needed.

Have you combined the smaller images into one large file ?

It's hard to tell from the code if "anim1.png" is;
1) a subimage of "atlas.png" ( defined in "atlas subimages.txt" )
2) a separate file

The first option is the one you want.

Either way, there is nothing in the indicated code which sets the sprite size - which is the most likely cause of any issue with Size.

While sprites do default to adopting the image size when defining them, its a good idea to set the size as well yourself - particularly with animation frames and atlas images - where the sprite size an image size may be different.

If all your frames are the same size, you can use setSpriteAnimation() to pull frames from a tileset image without needing to use an atlas image.
Back to top
Profile PM Email
Effishen
10
Years of Service
User Offline
Joined: 13th Jun 2014
Location:
Posted: 16th Jun 2014 21:01
Link
Hello Marl

Thanks for the tip. I started using SetDisplayAspect, then discovered the awesomeness of SetVirtualResolution much later.

I'm not sure if you saw the post previous to your post, because of my status my post was held back and only got posted after yours.

Looks like other than my splitting of a 3680x3680 atlas into 1024x1024 atlas, using SetSpriteSize worked marvellously too.

I've went without SetSpriteSize for all my sprites and they worked beautifully until I implemented Atlases. Looks like you caught the culprit (difference in sizes of sprite & image)


Another question that is related yet unrelated, between 256 LoadImage calls of small 230x230 images vs 16 calls of 1024x1024 images, which do you know will be faster?

Effishen
Back to top
Profile PM Email
Effishen
10
Years of Service
User Offline
Joined: 13th Jun 2014
Location:
Posted: 16th Jun 2014 21:27
Link
I just redid some tests - looks like although SetSpriteSize fixes the size problem, I realise that loading image sizes as huge as 3480x3480 actually causes my phone to physically resize it down to a certain smaller size (still unsure what, from my tests, it looks like my phone can take file sizes slightly above 1024x1024, have not found out what is the upper limit), then SetSpriteSize will resize THAT back into its original size - which causes blur images.

Is there a limit in AppGameKit for Atlases before it shrinks it down? Or is that limitation with my phone?

The phone being tested with is a Note 3 (QUALCOMM)

Effishen
Back to top
Profile PM Email
Marl
13
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 18th Jun 2014 05:58
Link
Quote: "I'm not sure if you saw the post previous to your post, because of my status my post was held back and only got posted after yours."

No I didn't , so let me answer that one first;
Quote: "I've read a lot of threads on this forum and everybody is recommending to limit the Atlas to be 1024x1024, but I can't seem to find the actual reason behind it, other than 'it uses a lot of memory'"

It's a hardware limitation on some devices with a variety of results, some scale the images, others simply don't load them. So it is a recommendation for the sake of maximum compatibility.
Quote: " I can't logically split the animations into groups of 16 (to fit into 1024x1024 spec), can you help advise me of another method (if there is any) ?"

If all the images are 230 x 230, you can use a combination of atlas textures and animation tiles.
You can Tile the 230x230 images in a 1024x1024 image in a 4x4 grid - leaving a gap on the right and bottom (A lot of devices handle images with power of 2 sizes much better).
Next, create a subimages file for the image with an entry something like;
animagrid:0:0:920:920
Then you can load the subimage "animagrid" and it will be a 920x920 image, which means you can use SetspriteAnimation( sprite , 230 , 230 , 16 ) and setspriteframe() rather than load a subimage for each one.

Since several sprites are then sharing an image, you can set one sprite up, clone it and you only have to change the frame number and position.

Quote: "between 256 LoadImage calls of small 230x230 images vs 16 calls of 1024x1024 images, which do you know will be faster?"

The 16 calls will be faster...
...but will need to be uncompressed into larger blocks of memory
Back to top
Profile PM Email
Effishen
10
Years of Service
User Offline
Joined: 13th Jun 2014
Location:
Posted: 18th Jun 2014 21:55
Link
Thank you Marl.

Appreciate the quick response and excellent information!

Effishen
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2025-05-25 01:28:14
Your offset time is: 2025-05-25 01:28:14