FreeOrion

After I got revision 3955 to compile and run on my Mac mini I saw that the game does not display starlanes.

As the game uses Ogre for 3D combat and Ogre claims to require only OpenGL 1.2 I simply assumed the rest of the game would limit itself to 1.2, too.

I looked over the code and it seems that almost everything is OpenGL 1.0 or 1.1.

The only part that requires 2.0 seems to be ShaderProgram.cpp which looks mostly cosmetic.
(for some reason this seems to work on my machine, despite OpenGL 1.4)

The only part that requires 1.5 seems to be the drawing of starlanes in MapWnd.cpp and this looks like it should be easy to support 1.4 (or even 1.2).

Is it worth my time to try to make this change or are there plans to add lots of OpenGL >=1.5 stuff to the 2D part of the interface?

There are numerous uses of rendering buffers (GL 1.5 or later) in the map rendering.

Additionally, the 3D combat system will require shaders (GL 2.0 or later).

You can make a version of the client that renders using GL 1.2 only, but we don't have enough contributors to be able to maintain multiple rendering codes, so your changes aren't likely to be committed to SVN.

I found out that there is no need to modify the rendering code at all. The intel versions of MacOS X all come with a 2.0/2.1 software renderer that is used as a fallback.

I modified GetGLVersion() in HumanClient.app to always report a minimum version of 2.0 for MacOS X intel systems.

It looks like everything works.

Maybe this could be made into a configurable option "[ ] assume OpenGL 2.0".

Why is there a need to assume anything / change code? If GL 2.0 is provided, what difference does it matter what GetGLVersion finds, and why would GetGLVersion find something less than 2.0?

The result of GetGLVersion matters because several parts of the UI code check the GL version before they do anything.

My system definitely renders GL 2.0 stuff, even if the reported GL version is only 1.4.

If I understand the documentation correctly MacOSX supports three types of GL renderer:
a) hardware without fallback (<2.0 for old systems)
b) hardware with fallback (2.0/2.1, but seems to report GL version the hardware supports)
c) pure software (2.0/2.1, probably much slower)

I have yet to find out where FO creates its pixel buffer (inside OGRE?).
That is probably the only location where it is possible to ask for a pure software renderer.

There are checks for setting options defaults, but it should be possible to override those defaults by enabling / disabling settings in the options screen.


There is a an OGRE GL RenderSystem plugin that probably has something to do with it...

The first thing MapWnd::InitSystemRenderingBuffers() and MapWnd::InitStarlaneRenderingBuffers() do is to test the GL version and return for version<1.5. This leaves nothing to do for the rendering code.

Maybe the tests should be removed? The game is almost unusable without starlanes and starlanes require rendering buffers.

I'd rather have missing lanes than crashes because the game attempts to use unsupported GL features.

I just committed some fallback starlane rendering code that should kick in when vertex buffers are unavailable... Give it a try?

Your fallback code draws the basic starlanes but no supply lines, no fleet supply lines and no fleet movement.

Before I discovered the possibility to cheat with the GL version I started to write fallback code myself.

Since InitStarlaneRenderingBuffers already collects the necessary data in temporary variables I created a template class derived from GLBuffer (GLClientBuffer<???>) that can store the collected data. I also moved all the GL version dependent stuff into class methods.

Here are the results of a quick comparison of the three variants:



I think the same method could be used to render the galaxy gas, too, but I have no idea how much performance that would cost.

Well, yes... It wasn't intended to be the final version / to do everything.


I'd rather have a portable solution than one that only works for OSX or that assumes there will be a software fallback GL implementation available.


I like the overall idea. Would you be able to finish these changes?

The useAs2DVertexBuffer and useAsRGBAColorBuffer functions could use some reworking though, as (I think?) they make assumptions about the type or size of the contents of the c_data vector that doesn't get validated with the template type or what's actually been stored.

Might it be better to do a non-template versions of the float and unsigned char version of these classes, each of which only provide "useAs" functions that are compatible with their internal type...?

Also, why do you have the asBase function, rather than just doing public inheritance?

I have various other minor comments regarding the code, but they're not important yet...


Galaxy gas rendering can always be turned off the options if it gives poor frame rates.

I think I can complete the changes.

I switched to protected inheritance as a quick and dirty way make the compiler produce errors for each use of the class in the "old" way. I should have switched back to public after making all the changes.

At first I will clean up GLClientBuffer and create appropriate subclasses. Maybe I will move it out of The MapWnd class.

This may take a few days.

I finished the first version of the fallback code.

Starlanes are drawn with supply lines, fleet supply lines and ship movement
Galaxy gas works (with 15-30 fps)
Starfields work (with 5 fps)
Optimized system rendering works

I have removed GLBuffer and replaced it with a small class hierarchy in its own source file.

With Fog Of War turned off everything should now work for GL<1.5.

I made a few additional changes.

Starfields caused a huge drop of performance, so i created smaller textures.
For gl<2.0 starfields are now rendered with only two 512x256 and 256x512 textures
and have almost no effect on performance (~5 fps).

For galaxy gas I made scaled down textures that are used for gl<2.0,too.
This change gains about 1-2 fps.

I have attached the new textures, the modified source files and my current Xcode project file.

I did not make smaller versions for the colored galaxy gas. Are those used at all?

I'd rather not deal with the extra code complexity, file duplication, and potentially artist effort, necessary to have separate smaller textures for different GL versions, just to improve performance of optional rendering features...

If starfields or gas slow down rendering too much on some systems, they can be just turned off. (I often just turn them off anyway, even when not FPS-limiting...)

Then feel free to ignore that suggestion.
While I think the code complexity is negligible the artist involvement may become a problem when/if the textures are redone at a later point in time.

While i did this experiment I found a small problem that might actually cause crashes on some systems.
The fog of war uses a shader (gl 2.0+) and if switched on it is used without actually checking the gl version.
It is currently used in SidePanel.cpp and MapWnd.cpp.

The smallest change necessary would be to test for gl >=2.0 directly in the rendering code.
However, if the ShaderProgram class might get used in other places it could be better to incorporate that test into ShaderProgram.