ENIGMA Forums
Contributing to ENIGMA => Proposals => Topic started by: Josh @ Dreamland on September 13, 2012, 10:43:25 am
-
The way I see it, there are two good ways to do sprite sheets.
1) Have a sprite sheet resource, and have sprites optionally refer to a sprite sheet.
2) Re-use the directory system.
3) Let ENIGMA just cram them together based on which fit together the best; the user can tell ENIGMA not to put the sprite in a sheet.
4) Use option 1, but provide an "Automatic" in addition to a "None" which lets ENIGMA decide.
I'm undecided on this one. I don't think I need to elaborate very much on it, as the concept is very simple. For those who are unclear, a sprite sheet is a big texture containing all the sprites. It is useful in that it saves render time due to not having to bind a new texture every time a sprite is drawn (only when sprites are on a new sheet).
The question is, how do we want the user to be able to specify that? Is it prudent to keep sprite sheets as a separate resource, or would it be too much work on the user's part?
This needs handled eventually if we want ENIGMA to make happy on mobile devices which just don't have the memory for 32,000 little tiny PO2 textures.
-
Could you clarify why you feel a sprite sheet resource is more useful than a subimaged sprite? Why does this have an advantage over ENIGMA simply plopping all subimages of a single sprite into one texture (or why is that infeasible)?
-
A sprite sheet would contain m subimages from n sprites, m >= n. Maybe the user wants one sprite sheet per sprite, maybe they want the entire world on one sheet (and maybe it's efficient to do so!).
I believe the better word for what I am describing is a "texture map." I am not sure if they are genuinely synonymous, but I figured more people here would know what a sprite sheet looked like. What I'm really referring to looks something like this:
(http://i1186.photobucket.com/albums/z366/brotacus/terrain-1.png)
-
Texture sheet like that reminds me of level baking. I wonder if ENIGMA could help with baking at all. ie instead of using separate sprites (textures) you just use one texture sheet and change around the texture positions.
-
That's the idea.
-
Hmm I wonder what possibilities are actually open with it. I found that instead of a square texture sheet it's better to put all the textures in a row on one line.
-
This is something I also was talking about like 2 years ago. GM now has the possibility for the dev to set the texture page. I belive you can leave it default (automatic in which it just packs everything in as small number of textures possible) or if the user know which sprites/backgrounds are used in which order then they can choose a sheet. I think its also possible to choose the texture size (so you can pack everything in 512x512 in a low end machine or in 4096x4096 for a more higher end machine. So my opinion doesn't match any single answer. My idea is:
Don't have a sprite sheet resource (though cool idea worth pursuing) and just have a dropdown list or a textbox in sprite/background settings where you set, if any, the texture sheet to use. Then have a few functions to load/unload them manually or automatically when one of the images on the texture is used.
-
What appears in the dropdown list?
-
Texture page numbers. That is if we want to offer an arbitrary number. Like 9 pages. Of course having a textbox were you can just write any number you want would be better.
-
The major points to having a resource for it would be
1) To allow the user to have a say in the placement within the texture map
2) To allow the user to fetch the texID of the texture map
3) To solidify the concept to something more precise than a page number
4) To demonstrate to the user how much space is wasted
-
Good point. Though autopacker is a must. And I actually don't want to copy GM. Just mentioned what they were doing.
-
Duly noted. The autopacker is coded and done with; we'll just reuse the one used to pack font glyphs.
Another benefit to a resource that I did not list earlier: An option can be given to separate sprite images by M pixels and dilate sprite edges by N pixels. (In addition to other benefits which may stem from having the map in front of you in a UI)