(iOS) OpenTK vs OpenTK-1.0

[RayBatts]

On iOS, is there a specific reason that we're using the older OpenTK assembly?

http://docs.xamarin.com/ios/releases/MonoTouch_5/MonoTouch_5.3#OpenTK

The docs say that the API isn't backwards compatible, but with us moving fully to GLES 2.0 I don't see a reason not to make the switch. Moving to this new OpenTK-1.0 will allow us access to some newer Oes extensions that should allow us to make some more optimizations. (Such as glGenVertexArrays).

Locally I tested swapping the two out and making the necessary API changes to match the new assembly. I didn't notice any differences in a couple of test scenes I ran, but wanted to run it by everyone else before making a PR.

[totallyeviljake]

will it allow us to implement Texture2D.GetData ??? :)

[RayBatts]

@totallyeviljake - Don't quote me on this, but I don't think it's impossible to implement Texture2D.GetData with the current OpenTK assembly we're using. Although it looks like a huge pain since the "easy" gl call for this doesn't exist in GLES: http://stackoverflow.com/questions/11863416/read-texture-bytes-with-glreadpixels. A lot of the FBO code is pretty fragile as it is.

[KonajuGames]

I had done the same changes a while back, but it was the same time as we
were getting ready for a 3.0 code freeze. The 3.0 release has dragged on a
bit longer than intended, and we were going to switch to OpenTK-1.0 once
3.0 was out.

Android implements the Texture2D.GetData work-around. Though it is
definitely not recommended for anything that might be time sensitive, like
games.

[totallyeviljake]

Android implements the Texture2D.GetData work-around

ah, okay, so that's likely why our sprite collision code is so slow. We pull GetData on the sprites, do the intersection and then do the alpha check on the collision rectangle. This is fast in Win7, warp speed on Win8, but hiccupy on android. Can't say on iOS yet as we can't run it there... I would take hiccupy on iOS over not working though ... do you think the GetData from Android would work on iOS?

[KonajuGames]

It may work. It is using regular OpenGL ES 2.0 calls. You will have to
try it and see.

I would definitely recommend storing collision data in a separate data
structure optimized for collision testing.

[totallyeviljake]

well,my first attempt failed:

[ERROR] FATAL UNHANDLED EXCEPTION: Microsoft.Xna.Framework.Graphics.MonoGameGLException: GL.GetError() returned InvalidOperation
at Microsoft.Xna.Framework.Graphics.GraphicsExtensions.CheckGLError () [0x00027] in /Users/admin/svnroot/core/TotallyEvil/games/Mono/MonoGame/develop3d/MonoGame.Framework/Graphics/GraphicsExtensions.cs:626
at Microsoft.Xna.Framework.Graphics.GraphicsDevice.ApplyState (Boolean applyShaders) [0x00060] in /Users/admin/svnroot/core/TotallyEvil/games/Mono/MonoGame/develop3d/MonoGame.Framework/Graphics/GraphicsDevice.cs:1650
at Microsoft.Xna.Framework.Graphics.GraphicsDevice.Clear (ClearOptions options, Vector4 color, Single depth, Int32 stencil) [0x0003c] in /Users/admin/svnroot/core/TotallyEvil/games/Mono/MonoGame/develop3d/MonoGame.Framework/Graphics/GraphicsDevice.cs:912
at Microsoft.Xna.Framework.Graphics.GraphicsDevice.Clear (Color color) [0x0000a] in /Users/admin/svnroot/core/TotallyEvil/games/Mono/MonoGame/develop3d/MonoGame.Framework/Graphics/GraphicsDevice.cs:855
at cocos2d.DrawManager.BeginDraw () [0x00005] in /Users/admin/svnroot/core/TotallyEvil/games/XNA/cocos2d/Platform/DrawManager.cs:326

DrawManager line 326: graphicsDevice.Clear(color.Black)

[totallyeviljake]

I think this might be related to npot textures. It only happens when we are drawing text to a RenderTarget2D. ... the other screens work fine for me. At least it's working in the GetData call now. :) progress ...

[totallyeviljake]

Getting farther. I was able to actually play the game, but during the GetData() for sprite collisions, I got a GLError():

[ERROR] FATAL UNHANDLED EXCEPTION: Microsoft.Xna.Framework.Graphics.MonoGameGLException: GL.GetError() returned InvalidOperation
at Microsoft.Xna.Framework.Graphics.GraphicsExtensions.CheckGLError () [0x00027] in /Users/admin/svnroot/core/TotallyEvil/games/Mono/MonoGame/develop3d/MonoGame.Framework/Graphics/GraphicsExtensions.cs:626
at Microsoft.Xna.Framework.Graphics.Texture2D.GetTextureData (Int32 ThreadPriorityLevel) [0x0000c] in /Users/admin/svnroot/core/TotallyEvil/games/Mono/MonoGame/develop3d/MonoGame.Framework/Graphics/Texture2D.cs:941
at Microsoft.Xna.Framework.Graphics.Texture2D.GetData[Color](Int32 level, Nullable`1 rect, Microsoft.Xna.Framework.Color[] data, Int32 startIndex, Int32 elementCount) [0x00134] in /Users/admin/svnroot/core/TotallyEvil/games/Mono/MonoGame/develop3d/MonoGame.Framework/Graphics/Texture2D.cs:453
at Microsoft.Xna.Framework.Graphics.Texture2D.GetData[Color](Microsoft.Xna.Framework.Color[] data) [0x00000] in /Users/admin/svnroot/core/TotallyEvil/games/Mono/MonoGame/develop3d/MonoGame.Framework/Graphics/Texture2D.cs:602

I've hijacked Ray's issue report. Sorry. There is a CodePlex discussion for this missing GetData() method.

[Nezz]

I think it's time to move to OpenTK-1.0.

[tomspilman]

Agreed. I think @dellis1972 has a branch with an initial conversion started, but we found that while it is better there are some differences between OpenTK on iOS vs Android:

// On iOS
GL.GetUniformLocation(int, string);
GL.GetUniformLocation(uint, string);

// On Android
GL.GetUniformLocation(int, StringBuilder);
GL.GetUniformLocation(uint, StringBuilder);

Which is really annoying. We're following up with Xamarin to figure out why this is occurring, but I think we could work around this too and at least reduce the places where we have differences.

[tomspilman]

Actually it is @slygamer that has the OpenTK1.0 code.

[Nezz]

On iOS, I only had to replace a couple of refs with outs.

[KonajuGames]

There are quite a few inconsistencies between OpenTK-1.0 on Android and iOS
that makes for a mess of defines again. These are being rectified by
Xamarin. I would suggest holding off until the changes are released.

[Nezz]

I don't think updating would have any serious benefits we need ASAP, so I agree.

[KonajuGames]

One year on, and OpenTK-1.0 on Android and iOS are still very different and a mess of inconsistencies between use of the All enum and specific enums, and parameter types of functions. I've just spent a while trying to get iOS and Android on OpenTK-1.0 and I'm giving up. As an example, Android has a PixelType enum that only contains three 16-bit formats (4444, 5551, 565), leaving out UnsignedByte. There are many other issues that it's just not worth it yet.

[thefiddler]

Apparently, mono/opentk for Android and iOS are pulling OpenGL ES definitions from different sources (Android and Apple ES headers, respectively), hence the API differences. This is in contrast to upstream opentk/opentk, which has historically relied on the official Khronos specification.

I do not know why Novell/Xamarin decided to switch from the Khronos spec to downstream headers. It may be that the fragmentation danger was not visible at the point when OpenTK was forked.

In any case, the process of merging mono/opentk and opentk/opentk is currently underway, so this issue might be worth revisiting in a few weeks.

[tgjones]

so this issue might be worth revisiting in a few weeks.

A "few weeks" have passed now... Is this still an issue?

[tomspilman]

So more than a year later... what is the state of the merge between mono/opentk and opentk/opentk ?

When can we unify our OpenTK code paths on mobile and desktop?

@dellis1972 @thefiddler @Frassle @KonajuGames ?

[tgjones]

I think this is superseded by #4399.

[KonajuGames]

Yes. It has been using 1.0 for a while now. Closing.