Ok, longest forum post ever: is FIFE is suitable for JA2.
The most important question--and one that I can't answer--is whether FIFE could be reasonably integrated with the JA2 codebase. I suspect this might be very complicated. If you're looking for a few "quick fixes" to make JA2 look better, then it would almost certainly be easier to just hack the existing JA2 code.
As those of you who have browsed FIFE's code have probably realized, FIFE is not just a rendering engine. It also does audio, events, scene management, pathfinding, provides a scripting environment, xml resource formats, editing tools, and much, much more. In short, it aims to be a complete toolset for making games.
As near as I can tell, you are looking for just a rendering engine that can be plugged into the backend of JA2. FIFE's rendering engine is housed in the Video and View modules.
The good news is that FIFE is very modular, and these 2 modules can certainly be separated from the rest of FIFE (you would need to make some adjustments to View, since it "views" our Model module, and you would need to make it View JA2's internal representation of game data).
But FIFE doesn't have a particularly "fancy" rendering engine. Our renderer is a flexible, extensible, adequate platform on which the rest of FIFE can rest. It's certainly better than JA2's current engine, but based on some of the questions that have been asked, it seems that your looking for something really "cutting edge" in the graphics department. Creating a cutting-edge rendering engine is not FIFE's goal. I don't know if such a cutting edge 2d rendering engine exists. If it does, it might be a better fit for you than FIFE.
As to the technical questions:
FIFE uses SDL surfaces or OpenGL textures. Is there a performance difference between these modes? I suppose the SDL surfaces are in software mode. Have you experienced any trouble switching from software mode (SDL) to hardware mode (OpenGL), like running out of video memory (on smaller graphics boards)?
In an accelerated environment, OpenGL will typically give much better performance than SDL. Both implementations currently support an identical feature set, so switching between the two is purely a matter of performance. The renderer must be chosen at launch; it cannot be changed "on the fly" during game play.
I suppose the SDL and OpenGL implementations are supposed to be interchangeable. Thus you use only the very basic capabilities of OpenGL (i refer especially to OpenGL's immediate mode). Have you thought about using newer stuff
that may increase performance (if there is a performance issue at all), or is it impossible, because you would give up compatibility between SDL and OpenGL?
OpenGL optimization would desirable, but we don't have an OpenGL guru on the team. The OpenGL backend hasn't been worked on much since it was first written (a couple years ago). A new guy recently joined the team who expressed some interest in the OpenGL code though, so we might see more work on that front soon.
You always use rgba textures, right? Do you support palettes or is it something that the user code has to deal with?
Palettes aren't in yet, but they're on my personal short list of tasks. A game currently being developed with FIFE has requested this, and it's clearly a very important feature for many games.
I'm asking this, because JA2 uses only palettized images. There is a huge amount of these images and they are usually very small. So, using OpenGL, we would have a LOT of textures and always switching between them (binding) could have a negative impact on performance. In your example projects/techdemos, how many object are you drawing (in average) per frame? How large are these objects/images in average?
Probably the best way to answer these questions is to fire up FIFE and test it out for yourself. FIFE has fine performance in the situations we have encountered so far. I have no doubt that if performance becomes a problem, we can find ways to substantially improve it.
A way to get out of this binding hell is to use texture atlases, but FIFE doesn't support textures atlases, right? Looking into the code, i suppose it would be possible if there were some access to texture coordinates from outside the GLImage::render method.
Texture atlas behavior may be possible using our SubImage code. I'd have to take a closer look.
Does FIFE support any kind of lighting or shading, or is it again somthing for the user code? FIFE does not support multitexturing (shader programs). Is it planned to support multitexturing (shader programs) anytime in the future?
Not at this time. This might change if a developer joins the team who's interested in working on OpenGL magic, but is not part of any current plans.
How is visibility/draw order of objects determined? Does the user has to do it? Is there any kind of Z-Buffer support?
Z-order is handled by the engine, and is determined by the location of instances in relation to the Camera. It fails for pathologically shaped objects, but I think this is true for most 2d engines. Such objects can be handled by judicious splitting into multiple smaller ones. I don't know how pathological JA2 objects can be, but I doubt the JA2 team had more sophisticated z-ordering algorithms than us, so existing JA2 data should be ok.
Let me know if you have any more questions.
Author
Topic: FIFE suitable to modernize Jagged Alliance 2 - 1.13 open source? (Read 17296 times)