eglGetProcAddress cannot be used to retrieve
entry points of core functions. Instead, we
use [DllImport] for core functions and function
pointers for extension functions.
Squashed commit of the following:
commit 0b84aa6ef78dfa3600b81fc412eb192f2a87e40c
Author: thefiddler <stapostol@gmail.com>
Date: Sat Mar 15 02:24:58 2014 +0100
[Examples] Rolled back changes to Example browser
commit 1acfbaac3d17184debdbbe872c58ac07d1b37c0a
Author: thefiddler <stapostol@gmail.com>
Date: Sat Mar 15 02:20:57 2014 +0100
[Examples] Rolled back WinForms example
commit 835d9d6035a890bd3426566929fbfd25c493eca0
Author: thefiddler <stapostol@gmail.com>
Date: Sat Mar 15 01:15:01 2014 +0100
[Examples] Rolled back erroneous GLControl mods
commit 056418014f0e835e83fb85b54b8749519a555364
Author: thefiddler <stapostol@gmail.com>
Date: Fri Mar 14 23:11:11 2014 +0100
[Rewrite] Remove calli prototypes
When a function is called indirectly via a function pointer, its
prototype is not required (the prototype is added as a callsite at the
calli invocation.) Removing these prototypes reduces binary size by
roughly 400KB.
commit 353a16ec2836c597150d2fab28581e7c264b2b39
Author: thefiddler <stapostol@gmail.com>
Date: Fri Mar 14 22:31:25 2014 +0100
[Rewrite] Call DllImports directly
When a function does not have an allocated slot (i.e. slot = -1), then
we will call its DllImport signature directly.
commit 9a5313e4b7afb10b698d255e4b5637887bf71cf3
Author: thefiddler <stapostol@gmail.com>
Date: Fri Mar 14 22:30:04 2014 +0100
[Bind] Do not allocate slots for DllImports
commit 6ac5342409363cac0e59f9dc669948b319bd20a9
Author: thefiddler <stapostol@gmail.com>
Date: Fri Mar 14 22:29:07 2014 +0100
[Bind] Added option to use DllImports
This is necessary for the core functionality of OpenGL ES, where
eglGetProcAddress returns null or garbage (the latter on Android.)
Instead of inheriting and overriding StreamWriter methods, it now
forwards its parameters to an internal StreamWriter, after applying the
necessary formatting changes.
This shields us from the StreamWriter implementation differences
between .Net and Mono.
This patch makes the following code work as expected:
```csharp
var gw = new GameWindow();
gw.TargetRenderFrequency = 60;
gw.Run();
```
Fixes issue #69
IGraphicsContext.VSync property is obsolete, but we have to call it in
the GraphicsContext.VSync implementation, so disable the obsolete
warning for this one use.
Wrap new generated binding calls with using ErrorHelper. Sets up a try
to call the method in and a finally block to call Dispose on the
ErrorHelper. Currently hardcoded to only work for the graphics modules.
GLHelper.cs contains a number of overloads that cannot be resolved by
VB.Net. We cannot remove them, as that will break
backward-compatibility, but we can hide them by moving them after the
autogenerated overloads in GL.cs.
Terrible hack, but it appears to work.
Issue originally reported at http://www.opentk.com/node/3554 as "OpenTK
1.1, VB.net and ambiguous functions."
Updated the Matrix4d CreateFromQuaternion methods to actually create
Matrix4d. They now mirror the Matrix4 CreateFromQuaternion methods,
just using doubles and the -d classes.
Previously, Matrix4d.CreateFromQuaterion actually created a Matrix4
from a single-precision Quaterion.
Using a bitfield does not save storage space in this case, and also
stops pattern matching from working (switch() statement in C# or match
… with expressions in F#.)
joyGetDevCaps() is an extremely slow call that allocates memory.
WinMMJoystick is now caching its results for a significant speedup in
Joystick.GetCapabilities() and GetState().
The cache is updated whenever a joystick device is removed. WIP to
handle device added notifications.
This protects against a potential denial-of-service issue during mode
selection, where the platform backend will try to reduce AA level until
a supported mode is found.
When refreshing the AvailableDevices list, it is important to set the
original resolution on any DisplayDevices that were previously available
to allow the RestoreResolution() method to work correctly.
Creating a GraphicsContext with null parameters is not a guarantee that
we will get a dummy context that does not call any OpenGL functions. We
need to explicitly define and construct a dummy context that is safe to
use inside the designer.
Affects issue #49
