In my current project, which is a side-scrolling 2D project, I divide my “levels” up into “rooms”: essentially regions of the level, generally fairly small (perhaps the size of a large room, for example), taking up enough screen-space that you might be likely to have two to eight on-screen at once, at a guess. I’m not yet sure of how many “rooms” an average level might have, but, if I may guess again, I could see there being as many as fifty to one hundred.
I also want my levels to not be constructed of repetitions of the same thing over and over again, and so had been hoping to have each room be individually drawn. My original thought was to paint sections of level, comprising a handful of “rooms” at once, but changes in other aspects have led me to rather consider giving each “room” its own geometry, even if that’s just a single painted quad.
However, that seems like an awful lot of textures loaded at once, especially if I want a resolution that doesn’t incur much blurring.
Is it likely to be a problem, and if so, what avenues of recourse might I have? Will the standard automatic culling help? (My guess is that it won’t. :/)
I suppose that I could try some sort of dynamic loading in a separate thread, but I’d rather take a simpler solution if one’s to be had. Another thought might be building my “room” geometries of re-usable elements, but I worry that this might result in the sort of repetitiveness that I’m hoping to avoid…
So, any advice, anyone?
do you use preload-simple-textures & preload-textures setting?
i think loading or clearing textures when they are in sight or out of sight is not very complicated.
Hmm, no, I don’t believe that I knew about those settings before you mentioned them – thank you for pointing them out.
And indeed, it shouldn’t be too difficult to implement a dynamic loading system, but before I actually implement something I first want to find out whether it’s called for, and if so, what other options there might be.
First off, use LOD. It’s a technique for rising performance that lowers the visual quality of objects based on their distance to the camera (which should behave linear to its space on screen). Basically for the lowest level of detail, you’d use vertex colors instead of textures.
For the next higher level it might be a good idea to have a texture atlas - a big texture which represents a few textures merged into one. Google for it and you’ll get the idea. I think there was a command line tool in Panda that can create such texture atlases.
What might also help is loading the textures asynchronously, but the model stays untextured for a short time while the image file is being loaded.
Last thing you should read about’are mip maps. This is a technique where multiple resolutions of the same texture are saved all into one file - mainly dds. Panda can create mipmaps for you from any image, but if the processing becomes a bottleneck, precumputing different texture sized might help a bit.
All in all, I think you should first try to build that thing and only if you encounter a bottlenect, react to that specific one. Because each optimization takes lots of time and each has some side effects.
Hmm… I do know about LOD, mip-mapping etc., but I don’t see how they apply in my situation, which (as I think that I mentioned) is a side-scrolling 2D game: there shouldn’t be situations in which a given “room” is both far from the camera and nevertheless visible, as objects are moved away from the camera along the plane roughly perpendicular to the camera’s forward vector (the X-Z plane in my case).
You may be right (if I understand you correctly) about building the basic system (which I presume to be one without any attempt to pre-emptively approach this imagined problem) first, and only attempt any fixes later, but I’ll confess that quite so many textures of reasonable resolution – let us say 70 textures at 1024x1024 – seems like an awful lot, especially with two or three larger background textures and whatever object textures I have…