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 / Atlas Images, SubImages and Sprite Animation (project included - eventually)

Author
Message
Marl
12
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 10th Apr 2012 22:09 Edited at: 11th Apr 2012 00:07
There's been some discussion lately surrounding the use of Atlas Images, Sub Images and Sprite Animation, which got me thinking.

(always dangerous to get me thinking)

1) It is recommended that image sizes are Binary - i.e. a power of 2 - 2,4,8,16,32,64,128,256,512,1024,2048 etc.

But What about subimages? The smaller images stored within atlas textures. Technically they are not loaded per se, so does the same recommendation apply?

2) If you opt to use the Sprite Animation method, you don't use subimages, but the sprite frames must be a factor of the whole image size.

Binary numbers are terrible for factoring, they tend to only play well with their own kind and besides I have ten toes so there.

So what would happen if you used both? Yes, at the same time.

You load the Binary Image - to keep the poncy hardware happy, with it's new-age "I can't eat anything that's not a power of 2" attitude.

Then like a tenth century barbarian, you carve it up into odd chunks that the rest of us can work with.

Manly chunks that cut well and fit on proper plates.

In short, you use sprite animation on a Sub-Image.

Will the hardware still go crying to mummy?

So here's the plan.

Start with a 1024x1024 Image, but give it the subimage file needed to make it an atlas texture.

The subimage file includes all sorts of horrible numbers, which give modern hardware the willies, but which happen to factor well and give the programmer a lot more options.

Do you think that would work?

Well download the attached project and see for yourself.

Edit: Replaced Project with version 2 (.png and orientation check)

Attachments

Login to view attachments
Marl
12
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 10th Apr 2012 22:11 Edited at: 11th Apr 2012 00:05
It works well on windows, but what about all the other girly hardware out there

(no offence to girls - which I happen to like.. .. a lot )



Here's the meat and two veg of it.


Edit: Replaced Code block with version 2 code

Attachments

Login to view attachments
Rich Dersheimer
AGK Developer
14
Years of Service
User Offline
Joined: 1st Jul 2009
Location: Inside the box
Posted: 10th Apr 2012 22:46
I've had no problems using odd sized images in an atlas that's 1024 x 1024. And I've used the same atlas image for both sprite cells and sub-images.

But see my thread about how it seems to take longer to load in the sub-images, than to just use single frame sprite animations.
Marl
12
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 10th Apr 2012 23:36 Edited at: 10th Apr 2012 23:39
Quote: "I've had no problems using odd sized images in an atlas that's 1024 x 1024."


Me neither, but this idea is more about being able to use odd sized frames with the sprite animation method - animating the subimage rather than the image.

Quote: "But see my thread about how it seems to take longer"


Yeah, I saw that. I've not really noticed it, but possibly don't load as many images as yourself.

Always worth knowing though in case I do start to see an impact.

** Update

I'm replacing the project above with one that works in both orientations - the original was landscape only.

Also my Android phone was reluctant to load the image in the original project.

I originally used a jpg to keep the size down, but have now replaced this with a .png and it works fine.

Also the new version shows the full image as well to test that it was loaded ok.

Attachments

Login to view attachments
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 10th Apr 2012 23:49
The only downside from using odd sized sprites loaded from a subimage is that you have to set UVBorder to 0 else you get half a pixel cut out.

I came across a problem using SetSpriteShape to Polygon when using Sub images.

Currently I scrapped the idea of subimages, though I really wanted to use them cos they save a lot of memory space when you have hundreds of smaller sprites.
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 11th Apr 2012 01:04
The main image should be a power of 2, but the sub images can be any size as AppGameKit uses UV coords to reference them from the main image, which the hardware is happy with.

You can use a main image that isn't a power of 2 if you don't mind some extra memory usage and the inability to wrap the UVs such as in seamless textures.
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 11th Apr 2012 09:33 Edited at: 11th Apr 2012 09:34
In case of subimages it makes NO sense not to have the main image as ^2. subimages can be any size, because obviously art comes in all strange sizes!

If I don't use UVBorder set to 0 I get pixels cut out from odd sized subimage sprites. It seems that AGk is doing a 0.5 adjustment to offset for UVscrolling (I am obviously not using UVscrolling with subimages).

Why is this happening only vertically and not horizontally?

Login to post a reply

Server time is: 2024-05-08 14:53:51
Your offset time is: 2024-05-08 14:53:51