StringMap<Image> for texture atlas?
Monkey Forums/Monkey Programming/StringMap<Image> for texture atlas?
| ||
| Hello, I'm afraid I'm a bit unfamiliar with big-O notation, so I don't really have any idea how much slower O(log2) is than a normal direct reference to a variable whose name is known would be. Is a StringMap<Image> fast enough to be acceptable for use in large texture atlases? The largest I'd imagine one of these atlases being in theory would be 1024 keypairs, but most likely there will be less than 64 keypairs per atlas. This is for a mobile project, if that helps. The key lookup would occur every time an Image would be needed for a DrawImage function. (Would this even negate out the speed advantage from using a texture atlas on mobile devices?) Any general advice would be appreciated, especially from anyone who's maybe tested this themselves and/or profiled it... |
| ||
| The key lookup would occur every time an Image would be needed for a DrawImage function. Why do you need to do this? Retrieving a value from a Map isn't a problem, doing it repeatedly when you don't have to may well be. Why do you have to retrieve your images by key on every draw? |
| ||
| I haven't found the Maps to be slow, even if used a lot every frame. You use texture atlases to reduce render calls and minimize memory, so it has little to do with the CPU as far as I know. Here is a good video that explains that and shows Texture Packer in use: http://youtu.be/Qhq4COk_QyU?t=3m23s (3min explination) However it is very simple for you to just save a reference to the image, if this would ever be something you measure with a profiler and find to be a concern. I'd say watch for creating new objects during gameplay is a bigger thing. Not because is drags performance, but because it can later trigger the garbage collector - that can be seen as noticeable lag. Some say Pre-Optimization is the root of all... |
| ||
| Why do you need to do this? Retrieving a value from a Map isn't a problem, doing it repeatedly when you don't have to may well be. Why do you have to retrieve your images by key on every draw? I suppose this is true; I could define new Image variables as fields of the object that needs them, and set them to reference the value from the key I want in the object's ctor, but I figured this would negate out some of the convenience of having the texture packer's metadata available, which lends itself well to a Map (specifically, a Map<String,Image> where the string is the name the packer uses to refer to the texture, and the image is a GrabImage of the piece). Is the extra step of putting the values from a map into design-time Image variables a normal part of picking images out of an image atlas? I'd say watch for creating new objects during gameplay is a bigger thing. Not because is drags performance, but because it can later trigger the garbage collector - that can be seen as noticeable lag. Thanks, I've been keeping an eye out for it, too, since the pitfalls of that are already well-known here. I've seen topics on aggressive atlassing to reduce GPU thrash on the forums, but since I haven't done lots of DrawImage calls with different textures in my render order, I haven't run into much of a noticeable slowdown (the biggest ones seem to be with blitting large textures in general). My big concern would be running into a situation where a number of calls to Map.Get become non-negligible in the renderloop. |
| ||
| I can't say that I follow where you're getting your concepts of convenience/inconvenience from. In my libs I have an ImageAtlas class. This can load a TexturePacker JSON file and internally construct a String->Image map (there's a bit more to it, but that's mostly what it does). I can then simply call atlas.GetImage("subimagename") and get the relevant subimage. However, there's no need to call that retrieval function every time I render the image. Visual elements just get the image references they need, store them in local fields and then use those. I'm not clear on what convenient metadata you think is lost by doing this. |
| ||
| You're right, of course. There's no reason to not just pop the reference into a field variable -- It just took me a while to come to the same conclusion :) Now if only there were an overload of GrabImage that let us specify FrameWidth/FrameHeight...... |
   |