Gunter's picture

OpenGL ES 1.1

Hi,

We develop an iPhone App here with Monotouch and to speed up development we mainly develop under Windows. A problem has been the differences between OpenGL ES 1.1/20 and the full version which OpenTk under Windows is using (normally).

I saw the experimental support of ES 1.1 (we have to use 1.1 because we also target older iPhones) and decided to play around a little. Soon it was clear you need native libraries for OpenGl ES. After a little googling i found an OpenGL ES 1.1 emulator at malideveloper.com. They also have an OpenGL ES 2.0 emulator. License seems to be ok for me.

So i tried to get the emulator to work with OpenTk. It is not completely finished yet, but it seems it could work. Only a few changes were necessary so far. The emulator comes with libGLESv1_CM.dll and libEGL.dll so you have to change the former in Helper.cs. Strangely all of the entry points in libGLESv1_CM.dll were like _glAlphaFuncx@8 so i had to change the pinvokes in Core.cs.

Other things changed were targeting x86 in the OpenTK .Net project (the GL emulator libs are 32bit), an additional attribute in SelectGraphicsMode (EglGraphicsMode.cs):

Egl.RENDERABLE_TYPE, Egl.OPENGL_ES_BIT,

and a strange bug in GraphicsContext, the debug output:

Debug.Print("GraphicsMode: {0}", mode);

was triggering a second call into the constructor which didn't work on an embedded context (properties with side-effects tsk tsk :). I just commented the line out.

and defining EXPERIMENTAL in the project settings of course.

I am not 100% sure yet the emulator is Ok, it seems to be more limited then the iPhone ES implementation (only 2^x size textures for example).

Anyone interested in further progress on this topic or patches?

Regards,
Gunter


Comments

Comment viewing options

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

OpenGL ES 1.1 is not a priority right now but any help to get it up and running is welcome. A few remarks:

Quote:

Strangely all of the entry points in libGLESv1_CM.dll were like _glAlphaFuncx@8 so i had to change the pinvokes in Core.cs.

ES 1.1 contains both floating-point and fixed-point versions of the various functions: glAlphaFuncx is the fixed-point version of glAlphaFunc. These are separate functions (and both are available in OpenTK) and, needless to say, you shouldn't change the entry point of the latter to call the former.

It seems that this emulator is exposing only the fixed-point subset of ES 1.1, which is not compatible with the iPhone.

Solution: try a different 1.1 emulator. I would suggest Vincent which used to work with OpenTK out of the box (but it's been a while since I last tested). Imagination Technologies also provide a good emulator but this might still need some work to cooperate with OpenTK.

Quote:

a strange bug in GraphicsContext, the debug output:

Debug.Print("GraphicsMode: {0}", mode);

was triggering a second call into the constructor which didn't work on an embedded context (properties with side-effects tsk tsk :). I just commented the line out.

GraphicsMode may have to create a temporary OpenGL context in some cases but I don't think this is the case in the EGL code path. Which property is triggering this issue?

Also, which version of OpenTK are you working with (1.0 beta-3)?

Gunter's picture

Thanks for the hint with Vincent, I'll try it out. And yes, i was using 1.0 beta-3.

The entry points from the emulator at malideveloper.com all had the form

_procname@n

no matter if float or fixed, the n presumably the number of bytes on the stack. But this was only the case for libGLESv1_CM.dll. I have no idea why they chose a different file name and different symbols. libEGL.dll was normal.

The error i had in GraphicsContext was because

Debug.Print("GraphicsMode: {0}", mode);

called GraphicsMode.ToString which in turn called the property index which in turn called implementation.SelectGraphicsMode which seemed to trigger another call into GraphicContext (deep inside SelectGraphicsModeARB).

Sorry for my comment on the properties with side-effects but i almost got crazy while catching this bug until i disabled property evaluation in the Visual Studio debugger :).

Thanks for providing this fine OpenGL library and i would be happy to contribute with some feedback for OpenGL ES in the future.

Regards,
Gunter

Gunter's picture

I tried the Imagination emulator now and it almost worked out of the box.

Only things i changed are:

- Make the OpenTK project targeting x86
- Define IMAGINATION
- Changed the constant in Helper.cs to:

#if MALI
const string Library = "libGLESv1_CM.dll";
#elif IMAGINATION
const string Library = "libgles_cm.dll";
#endif

- Comment out in GraphicsContext.cs:

Debug.Print("GraphicsMode: {0}", mode);

There is only one strange thing: Some Open-GL calls seem to blocked first, and when they finally start to work my application window suddenly gets garbled (no title bar etc.). I already tried disabling Aero, it didn't help. I can't really describe it, i could upload a binary if you want to see it.

But it rather seems to be some strange interaction between the emulator and the graphics driver (Nvidida 196.21).

Regards,
Gunter

the Fiddler's picture
Quote:

The error i had in GraphicsContext was because

Debug.Print("GraphicsMode: {0}", mode);

called GraphicsMode.ToString which in turn called the property index which in turn called implementation.SelectGraphicsMode which seemed to trigger another call into GraphicContext (deep inside SelectGraphicsModeARB).

Sorry for my comment on the properties with side-effects but i almost got crazy while catching this bug until i disabled property evaluation in the Visual Studio debugger :).

It's true that the GraphicsMode implementation sucks, it drives me crazy whenever I try to debug something in that part of the code. Could you please file a bug report for this issue? Removing the debug line hides the symptoms but the real bug is still there.

OpenTK.Examples contains an ES 1.1 sample, does the window also get garbled when running that?

Gunter's picture

I tried the example and it didn't garble the window. I also tried my app on my notebook (with ATI chipset) and it was ok there. So i guess it is really a driver/emulator issue. Probably i try an older driver on my desktop.

Thanks for the help,
Gunter