Mailaender's picture

OpenRA: Tao to OpenTK migration

Currently http://openra.res0l.net uses a self-patched version of Tao for correct 64-bit support which seems not actively maintained anymore for years. OpenRA uses Tao for FreeType, SDL, Cg, OpenGL and OpenAL. http://www.opentk.com/project/about says it supports FreeType, but I can't find something like Tao.FreeType. Also Cg seems to be missing and OpenTK.Compatibilty seems incomplete for OpenAL because I get many errors like

`OpenTK.Audio.Alc' does not contain a definition for `alcOpenDevice'
The name `Al' does not exist in the current context

By the way: would there be much benefit switching from Tao to OpenTK? Will this fix existing rendering issues with OpenGL at Intel cards (that's why they added Cg support).


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
puklaus's picture

" Also Cg seems to be missing and OpenTK.Compatibilty seems incomplete for OpenAL because I get many errors like

`OpenTK.Audio.Alc' does not contain a definition for `alcOpenDevice'
The name `Al' does not exist in the current context"

You can use CG through Tao library's cg wrapper.

About OpenAL, I thought it works just fine like it has worked years, but now I run otk examples, tried openal test and it throws exception. I will check what is problem there...
[EDIT]: It was just because of missing openal32.dll, alut.dll and wrap_aol.dll. AOL example works fine.
Check newest otk exaples sources, these works.

"By the way: would there be much benefit switching from Tao to OpenTK?"

I think most important is that your code is much more cleaner, when using otk (and its enums).
And you get crossplatform support easily (tao should support multiplatform too but I never got it to work on ei. linux (and will it on osx?), but OTK works right away on all platforms).
And if using otk compatibilty dll with own software, you can easily remove projects from there what you dont need, it easily comes over 3MB -> 1MB. (that's what I did) (and better convert all tao calls to otk calls, when have some time in the future).

Mailaender's picture

I also thought switching from Tao → OpenTK would be a good idea because Tao is unmaintained and important x64 patches are commited to https://github.com/mono/tao for years now, but no bug-fix release on that one. However http://sourceforge.net/projects/opentk/files/latest/download is from 2010. Has development stalled here, too? Tao should be fully cross-platform: OpenRA runs on Linux, Windows and Mac.

Inertia's picture

OpenTK 1.1 is in the pipeline, but real world slows things down. Do not be confused by the amount of "HELP!" in this forum, people _only_ come here reporting issues, not to report that everything runs fine ;) OpenTK 1.0 is stable for production.

Mailaender's picture

Okay, I will start then to port the renderer to OpenTK at https://github.com/Mailaender/OpenRA/tree/opentk It works nicely. I am only having trouble with mostly everything from Tao that contains *ARB.

Mailaender's picture

How do I translate

// Vertex shader
string vertexCode;
using (var file = new StreamReader(FileSystem.Open("glsl{0}{1}.vert".F(Path.DirectorySeparatorChar, type))))
vertexCode = file.ReadToEnd();
 
int v = Gl.glCreateShaderObjectARB(Gl.GL_VERTEX_SHADER_ARB);
ErrorHandler.CheckGlError();
Gl.glShaderSourceARB(v,1,new string[]{vertexCode},null);
ErrorHandler.CheckGlError();
GL.Arb.CompileShader(v);
ErrorHandler.CheckGlError();

completely to OpenTK?

Inertia's picture

You can find ARB extensions in the class GL.Arb, There's also GL.Ext etc. Not sure what that ErrorHandler class really does. The OpenTK example launcher has several examples that use GLSL, maybe that can help you further.

Mailaender's picture

The ErrorHandler is self-made stuff. I managed to convert everything except:

int v = Gl.glCreateShaderObjectARB(Gl.GL_VERTEX_SHADER_ARB);

because

GL.Arb.CreateShaderObject

requires ArbShaderObjects which does not seem to fit here.

Inertia's picture

This is by design of the GL spec files we parse. We need to clean those enums by hand and this is usually not done for anything but core functions.
You can always use the All enum and just cast that to what the functions expect.

Mailaender's picture

There is no alternative for Tao.FreeType or Tao.Cg, correct?

By the way there is a upstream contribution from OpenRA for Tao at https://github.com/mono/tao/commit/358f61adc4184875a6eaafa06f89b63afbec0... which fixes Tao.FreeType for x64. Do you still maintain the tao framework? Will there be an official bug-fix release?