Big images (again)
Monkey Targets Forums/Android/Big images (again)
| ||
| Hi folks, I know this conversation has come up before, but I'd love to hear some views. Our new (WIP) app has some big images (e.g. several are 6144x208 pixels). Certain Android devices just seem to struggle with images of this size, and instead of the intended images just display white blocks. The 6144x208 images are used for animating sprites - they contain 32 frames. I know Monkey has the capbility of reading these sprites from a different shape image. So I could reshape the 6144x208 image into a 1536x816 image, containing 4 rows of 8 frames. Is there any advantage to doing this? Is it more or less likely that Android devices will continue to barf if I resize my big images in this way? |
| ||
| On Android everything above 1024 x 1024px is unsure to load. While most already support 2048 (or even 4096) many older devices still have this limitation. On the iOS side you can go with a minimum of 2048. |
| ||
| For best compatibility you should use a maximum texture size of 1024x1024 or an equivalent non-square resolution. You may need to trim some frames from your animation, reduce your sprite size or use a good packer/loader to optimise the space used. |
| ||
| ok, thanks for the tips, guys is there any difference what size i make the texture, i.e. is 1024x1024 "better" than, say, 8192x128? or does it make no difference? |
| ||
| OpenGL ES 1 Standard is officially max. 1024x1024 - as i remember But it is possible that some devices can handle larger sizes. OpenGL ES 2+ should have no problems with 2048x2048 (=16mb @rgba 8 bit) |
| ||
| I had a problem like that with a target I think it was the GLFW(Desktop now) when I first got monkey. it had to do with the limited number of frames when loading directly as frames due to memory limitations. The problem was solved by using atlas and using GrabImage. I don't know if that would solve your problem but maybe. if you are seeing some frames from the image while not others, it should solve your problem. If not or if you are using GrabImage already just ignore this silly programmer. |
| ||
| is there any difference what size i make the texture, i.e. is 1024x1024 "better" than, say, 8192x128? or does it make no difference? You are limited to what the devices maximum texture pixel size is. A texture of 8192x128 would still cause problems if the device can only handle 1024x1024 correctly. As Jesse has already mentioned, an image atlas (also know as a sprite sheet) at 1024x1024 would solve the problem providing that all your animation frames will fit. As far as I am currently aware, GrabImage (and the mojo Image class) requires that your animation frames are all the same width and hight, and must be in a linear order. So if your animation frames don't quite tally to the size of the texture then you will have problems.As muddy_shoes says, if you use a texture/sprite packer you can fit more onto a image atlas with optimisations, these being removal of pixels that will not be drawn, in other words the alpha pixels that would be around the edges of a sprite and rotations to maximise available space. The problem then is getting the frames location, rotation and size. There are a number of image atlas/sprite sheet generators available that create both the image atlas and a file that can be parsed to get the locations, rotation and size. You could then store this information in an array and use DrawImageRect to render them. One performance tip. Try to reduce the number of draw operations from different images in memory. Basically when you come to drawing enemies/backgrounds you should try to fit as many as you can into one image atlas to avoid a performance hit when gl buffer has to be flushed for the change. There was a post by Gabriel over on the general discussion section where this cropped up over a year ago. |
| ||
| Thanks for the useful background. 1024x1024 max it is, then. Sounds like I should start to pack as many things as possible into a sprite sheet/ atlas for performance reasons, too. |
| ||
| Last question - is there any easy way to "reshape" a sprite sheet? Say I have a linear sheet - 32 animation frames of a sprite, each 192x204 pixels (hence 6144x204 is the entire resolution). If I wanted to reshape the sheet to make 4 "rows" of 8 sprites, that gives an image 1536x816. Manipulating all the sprites to change the size is a pain. Is there an automated way to do this, perhaps a tool I could use? |
| ||
| Note that your images should be powers of two on each dimension. I don't know of any tool, though I'd be surprised if there is not something that can do stuff like that. Learning the scripting language might take longer than processing the image, though. That's a big sprite-sheet - do you have many of them? If it's just a few I'd just grit my teeth and boot up Paint Shop Pro, |
| ||
| @Gerry Quinn: From what I can gather, this requirement is no long the case with modern PC graphics hardware. But using power of two images, the graphics pipeline can take advantage of optimizations related to efficiencies in working with powers of two. If I wanted to reshape the sheet to make 4 "rows" of 8 sprites, that gives an image 1536x816. Manipulating all the sprites to change the size is a pain. Is there an automated way to do this, perhaps a tool I could use? I don't think that there are any or many tools to do this automatically, but there are tools that will allow you to extract sprites from images that can the be repacked.A few tools to have a look at. Shoebox. darkFunction Editor May be what you are looking for. And I believe it's cross platform but sprite packing is very primitive. Texture Packer Sprite Sheet Packer Image Atlas Packer |
| ||
| it can be done in Gimp pretty easy. What I usually do is view->show grid, view->snap to grid, image->configure grid, set the grid to the size of the tiles, select the rectangle select tool, select the tiles you want to move. cut and paste. The snap to grid makes it easy to select and align the tiles. |
| ||
| Great pointers. Thanks :-) |
   |