Sorry your browser is not supported!

Hi. I wondered if anyone could help explain to me the image size limitations on mobile devices.

As I understand it, many older graphics cards and mobile devices will struggle with textures of over 1024 x 1024 px. I experienced this problem on my old XP laptop before AppGameKit upgraded to using OpenGL 2.0 so I couldn't test on it any more.

Anyhow what I wanted to know is whether this limitation will affect AppGameKit images or only sprites created using them?

Let me give an example. Say I had a very large (let's say 4096 x 4096 px) image called MyLargeImage.jpg. Could I load this as an image in AppGameKit, break it down into 16 1024x1024px images using the memblock commands, and then create 16 sprites each linked to one of these smaller images?

The code might look something like this.


I was thinking that as this would avoid me ever having to actually render the oversized image, that might be OK, but I'm not sure whether images are affected by the problem as well.

Any help with this would be greatly appreciated. Thanks .

IIRC the padding and downsizing happens to images when they're loaded. So your giant 4096*4096 would be downsized (can't remember what to though - might be device dependent). If your serious about that image size, I recommend breaking it up before hand for two reasons. 1st, if the downsizing is applied to loaded images the it will become quite small. Two, if I'm wrong about the loading images part then it'll take what, 67mb+ of contiguous memory?

I do not have a direct answer to your question. I think it depends on whether or not the image is loaded into RAM or graphical memory. It is the graphics hardware that have limitations. I suspect that simply loading an image would not be a problem. It's when you try to render them or when applying them to sprites. But it would be easy to test this as I think the only Android device that can handle a 4k image right now is the Nvidia Shield. So make an APK and most users here can easily test it for you.

Ah that would explain a lot. The reason I asked is because I've been unable to produce the error where the sprite fails to display and therefore was unable to test how this differed between the image and the sprite, but if it's being downsized at load time, then that would explain why it doesn't fail. It would also foil my cunning plan for dynamically breaking down images!


Actually, I was thinking of 8192 x 8192, but on second thoughts, maybe not!! At the moment, I get away with that size because it is already broken down into much smaller pieces and I only load the ones I need at any one time. I guess what I'll do is to keep the giant image across lots of image files, load all the ones that the image I want to generate from it overlap with, extract the data, and then unload the sections again.

Thanks for the help .

EDIT
@Digital Awakening (our posts crossed)


Exactly. I seem to remember though that there is a command that allows you to opt not to store image data in its compressed form in memory, which is useful if you never edit it. This suggests to me that there is a copy stored in the graphical memory too.


In that case I think Hodgey must be right about downsizing at load time. I just tested a simple AppGameKit app that rendered by 8192 x 8192 image on my Asus Transformer Tab (using the AppGameKit player). As that cannot be possible on the graphics card, it must be that it is being downsized.

EDIT 2
Indeed the command I was thinking of is SetImageSavePixels. The documentation for the command makes it pretty clear that the image is stored in the GPU now I look at it.

Why on earth are you loading an 8192 by 8192 image? Is that a massive atlas texture with dozens of smaller images within it?

Look - OpenGL implementations restrict the image size. Unless you are sure which machines you will run on 1024x1024 is sure to be safe. Otherwise the behaviour will platform-specific.

The image is the entire campaign map. At the moment, I have the 1024 x 1024 version of the whole thing for the campaign view. Then for each "province" on the map which can be contested, I have an image province at full size broken down into chunks of 1024 x 1024 or less in size. The problem is that as the provinces are not rectangular, but the images of course have to be, there is a lot of overlap. What I wanted to do is have the one image and procedurally extract the portions I need for any given province at run time, thereby preventing any waisted memory. I can still do this, but as I said above, I'll have to break the big image down into 1024 x 1024 chunks to prevent AppGameKit resizing the image at load time.


Indeed, as it turns out, although if the LoadImage command only loaded the images into memory, and not into graphics memory, then that would of course not be the case. But yes, as LoadImage seems to put the image directly into the graphics memory, then I'll have to stick with 1024 x 1024.

Thanks for the help everyone.