holland01
commented
8 years ago The overhead has now been reduced pretty significantly; so this doesn't need to be remain open at the moment.
Closed holland01 closed 8 years ago
holland01
commented
8 years ago The overhead has now been reduced pretty significantly; so this doesn't need to be remain open at the moment.
On an Intel HD 4600, the GL driver has a limit for tex dimensions (width or height) of ~16000. The routine which loads the main images on q3tourney2.bsp has a canvas height which exceeds 24000, considering that the maximum y-image lands on about 2048 pixels.
One means of avoiding this is to use an unordered std hash map as an optional underlying mechanism for texture accesses; this would eliminate the need to allocate the 87 images, many of which are already taken care of via effect shaders, which obviously introduces a) significant redundancy, and b) allocates unnecessary VRAM as well as RAM.
Another mechanism for circumventing this issue (which could be paired, in a sense, with the above as well) would be limiting atlas dimensions to a certain size (say, 4096 for width and height individually), and using separate texture handles for a group of textures. If we have an array of texture indices, for example, each of which is supposed to, in theory, map to some image in the same group, you could use multiple atlasses and texture handles to represent the same group of textures in addition to maintaining the intended indexing scheme. i.e., the user wouldn't need to know that the underlying implementation used different texture handles, because indices which didn't exist for one atlas would map to textures within a different atlas. The same goes for "binding" by index.