DrawImageRect, GrabImage and other questions
Monkey Forums/Monkey Programming/DrawImageRect, GrabImage and other questions
| ||
| Hello all, I have some questions regarding the manipulation of images. Until now I just ignored these aspects but my recent experience shown me I should be more careful. I am using Monkey to make 2 games: (http://www.monkeycoder.co.nz/Community/posts.php?topic=5671) and (http://www.monkeycoder.co.nz/Community/posts.php?topic=5798) for the iOS and Android devices. Question 1 Until now, on desktop, I did not combine the sprites. I used for every image I need a separate PNG/JPG file. I assume it will be more memory friendly to have an "atlas" loaded and grab the rectangle I need from there, right? Question 2 If yes, what it's the best practice: DrawImageRect or GrabImage Question 3 I will need to rotate my images so I have to use SetHandle. I assume I must set the handle to the atlas, right? Knowing each sprite pos and dimesnsion I should calculate the center of my sprite from the atlas image and set it, correct? Question 4 Reading the forums, I understand 'Diddy' handle this friendly so I had a look over: 'SpriteAtlas' sample. How do I generate those XML files? Thank you in advance guys, |
| ||
| If you are using handles anywhere other than the top left of sprites, GrabImage will make your life significantly easier, and any overhead will be very small. GrabImage will give every sprite you grab its own handle. If you are in doubt, use GrabImage. As for memory friendliness, you will certainly gain from using atlases or combining in some other way [e.g. if your sprites are all the same size you could simply put them in a rectangular grid] because every edge of your images should be a power of two, and combining will allow you to fill them up. I generally use a rectangular grid because you can create and view it easily in a paint program, and I don't use multiple-frame sprites. An atlas will give you some extra efficiency if you really need it, though. (I'm not sure whether a reduced number of images has additional benefits - maybe somebody can say? It can't hurt to keep them to a reasonable number anyway, for your own sake if not the computer's.) |
| ||
| Less images = less draw calls = higher frame rate. Diddy supports this I think: http://www.codeandweb.com/texturepacker |
| ||
| Thats my understanding too, Gerry. I made note of these 2 older threads: http://www.monkeycoder.co.nz/Community/posts.php?topic=1934 http://www.monkeycoder.co.nz/Community/posts.php?topic=4176 The handle is on the grabbed image, not the atlas itself. All of the common monkey frameworks will read sprite atlas xml data, usually from Texture Packer, or you can write your own(!). Afaik, part of the optimisation comes from the renderer (e.g. opengl) not having to change state when switching between image data, since its shared. I suppose the only other thing to say is dont over-optimise if you're making a game with just a few sprites, it might not matter to use an atlas there. [EDIT- Beaker beat me to it] |
| ||
| Ah, I knew I had heard of some rationale for not having too many images. Agree about not over-optimising. Ask yourself: if my game was twice as big would it still run fine on typical hardware? If so - and this will nearly always be the case - you obviously don't need every last bit of optimisation! Just pick the low-hanging fruit, i.e. do the things that are easy to do, and only worry about the hard things if you have problems. |
| ||
| After reading your answers I observed that "Heroes of Essran" can be made without combining the images into atlases. The game does not have many sprites but I only want to make this like an exercise. This is my next project to be launched so I will concentrate on it. I will use GrabImage and I will group my sprites in sheets like: buttons, gui, heroes, enemies, items, etc. It will be easy to group them because I have many rectangles using same dimensions. Thanks, |
   |