Power of 2 Graphics?
Monkey Forums/Monkey Programming/Power of 2 Graphics?
| ||
| Does it matter if I load graphics that are not power of 2 in size? If I have a 360px x 36px graphic, does it allocate space in memory for the next size up in power of 2, ie 512x512? If so, should I be packing as many images/sprites as possible into single 512x512 sheets? |
| ||
| If so, should I be packing as many images/sprites as possible into single 512x512 sheets? this is your best option and highly recommended. |
| ||
| OpenGL ES 2.0 does not have this restriction. Regardless, you should always be using sprite sheets wherever possible to reduce the number of texture binds required. |
| ||
| So, would you recommend using a single LoadImage, then DrawImageRect, or GrabImage and DrawImage? |
| ||
| So, would you recommend using a single LoadImage, then DrawImageRect, or GrabImage and DrawImage? Either is fine, although using GrabImage may make your life easier in the long run as you can store the Images in an array/map/list rather than keeping track of sprite rectangles. GrabImage creates a new Image object, but it reuses the surface from the original Image (it doesn't copy or reload the image data). This means that any DrawImage commands using those grabbed images will not cause multiple texture binds (in OpenGL, at least). Batched draws = fast! |
| ||
| I'm in the process of converting my individual images to sprite sheets, is there a maximum size for a sprite sheet? I am trying to create one that is about 1600x1600 in size, and I'm worried that it will be so large that it may break on some devices. |
| ||
| Stick to 1024x1024. Also, use a program to do that. It's much easier than doing it manually. This could be a good free choice: http://spritesheetpacker.codeplex.com/ along with this: http://monkeycoder.co.nz/Community/posts.php?topic=1714 Also, it's highly recommended to use power of two. There's lots of stuff that can go wrong otherwise: bad filtering (blurry images), certain weird devices that can't handle NPOT properly, bad memory alignment (slow memory acces), etc. It's really easy to just avoid those potential problems from the start. Also, some low end devices could choke with more than 1024 x 1024. |
| ||
| 1024 is kind-of a bummer for the way I have things working now, but I think it would be smart to conform to it anyway. The software I use makes it really easy to put my sprites together on one sheet, get coords, etc. I'm using Fireworks CS5. I changed everything to use NEAREST instead of LINEAR when drawing bitmaps, so scaling hasn't been a problem - ie blurry images, etc. The interesting thing that I wanted to point out here is that after putting everything into a huge sprite sheet (that I'm making smaller now), my game runs WAY better on Android. The stuttering has decreased to the point that it's non-existent. I'm using GrabImage on the main spritesheet, and DrawImage, not the LoadImage/DrawRect. EDIT: Plus I got these great results on Android even after upping my FPS from 30 to 50. 30 was about as fast as I could get previously and not have stuttering. |
| ||
| The interesting thing that I wanted to point out here is that after putting everything into a huge sprite sheet (that I'm making smaller now), my game runs WAY better on Android. The stuttering has decreased to the point that it's non-existent. As I said, putting all your images on one texture will cut out all those OpenGL texture binds you were doing before. Note that if you change the matrix or any blend functions it'll flush the vertex buffer (uploads all your Draw commands to the GPU). |
| ||
| On every render I do a Push/Pop Matrix in order to scale - is that the same thing? Is SetAlpha a Blend? |
| ||
| It's probably alright, because although you're doing multiple flushes, you're only doing the one texture bind (which is relatively slow). |
   |