This is the place to save temporary content that is not categorized yet.
New LICENSE file
Yonibear's texture atlas ideas to improve OpenAnno performance
Modern graphics cards rely on large batches of vertices to be drawn at once. In FIFE, we are doing more or less the opposite. Instances are drawn with the Immediate Mode (glBegin/glEnd), and texture switches may occur between any two images. This is the reason why the OpenGL backend is currently limited by the driver overhead.
Even when we group images with identical states into vertex arrays, we won't get sufficiently large batches to saturate the vertex pipeline. This problem is very common in modern 3D programming, and the solution is called "Texture Atlases". Basically this means to pack several images into a single texture, so that larger chunks of images can be drawn with a single call. The texture coordinates of the actual image in the atlas have to be added to the vertex arrays.
To kill two birds with one stone, texture atlases can be used to compress images and save both texture size and bandwidth. Since typical isometric tiles consume a diamond-shaped surface, they waste up to 50% of their size with transparent void.
Currently, images are displayed by drawing their bounding box as a GL_QUAD. In a texture atlas, we already need custom vertices to select the correct texture. If we extend this system to allow multiple polygons per image, images can be assembled from random chunks in the atlas. For example, diamond tiles could be packed closely, which saves 50% of texture space. A more complex algorithm could slice up the non-transparent parts of an raw image and pack the pieces more closely on the atlas. This is interesting for animations too, because image parts appearing in more than one animation step can be reused.
Generally, a compromise has to be made between vertex count and texture space consumption here. Since the amount of algorithms is close to infinite, and the correct choice of the compression mode highly depends on the data, the packing step should be done by an external application. A simple but still quite effective atlas generator will be implemented with this proposal, together with a format that stores the generated vertex data and texture location information.
Runtime atlas generation
The effectives of the atlas completely relies on the right images being packed in one single atlas. The more images are drawn from an atlas at a single place, the fewer draw calls must be used. That means it is important to group the images in one atlas, that will appear together in the game. For some games, this decision can be easily made by the designer. But for other games have a too large set of tiles that can appear together, so this depends on the map. For these games, it might be interesting to assemble the atlases at runtime.
The atlas interface will support both ways, by providing an interface for assembling it at runtime, which is then used by the atlas description loader too. During development, it might be interesting for artists to preview their graphics without integrating them into an atlas. For this purpose, a loader can be implemented that automatically places raw images into a single-image atlas, so we don't need to take special care of that case.
One downside of texture atlases is that colors from unrelated textures may "bleed in" when a linear filtering mode is enabled. Nearest filtering is acceptable when the images appear on the screen with exactly the same size they are stored in. But when the application tries to zoom, this will result in heavy artifacts. For this purpose, OpenGL offers the possibility to provide custom mipmaps. Mipmaps are pre-calculated resized textures. They form a chain, with each mipmap step containing the half size of the previous base image.
These mipmaps would have to be calculated by the atlas generation tool, by resizing each packed image alone before it is copied into the atlas. Mipmaps will provide decent zooming quality, as long as the application restricts to zooming in halving steps. As a positive side effect of this solution, the SDL renderer can offer zooming too by using the mipmaps.
The idea of the texture atlas is based on the characteristics of 3D accelerators, where processing stream data is cheap and changing states is expensive. In a 2D software renderer, we find the opposite situation. CPUs are targeted for random data access, but have mediocre stream throughput. This is why the SDL renderers performance would nothing but suffer if it implemented the atlas the same way. So the first step for the SDL implementation of the atlas would be to unfold the images into single surfaces, so each can be drawn with one blit again.
This may consume some loading time, but the SDL renderer is just a fallback for fast systems with slow/broken OpenGL anyway. At least some texture space is still saved on hard disk.
Profiling python extensions
// in python client instanceMoved = instance.registerTrigger("instanceMoved", listenerObject) enteredArea = instanceMoved.registerTrigger("enteredArea", listenerObject) // in instance EnteredAreaTrigger* eat = new EnteredAreaTrigger(); triggercontroller.registerTrigger(eat); return eat //in trigger controller m_triggers.push_back(trigger); //in instanceMoved trigger m_triggers.push_back(trigger); ... // in trigger controller pollTriggers(); // each round //in trigger listener.fireTrigger(); //in python fireTrigger is overridden in listener
Although FIFE already provides a bunch of features which allows to create games, there might be some features which are still missing.
All FIFE users are invited to create and maintain a list, so that potential developers can grab them and - hopefully - turn requests into new engine features.
NOTE: As ATM there are very few developers active, everybody should be aware of that this is only a list - not a scheduled plan on when all the features are ready to go. It mainly has the purpose to give an orientation for both new developers and the users what FIFE is capable of - and what is still missing.
Just take care to set the ticket type to "enhancement", so everybody can find them with custom ticket queries.