BlueMonkMN's picture


Incorporating OpenTK into Scrolling Game Development Kit 2 is going quite nicely. I saw about a 100% performance improvement over DirectX when using large numbers of sprites, presumably due to the fact that sprites and tiles can be transformed by specifying corner points rather than having to change the whole view matrix to include the transformation and the position every time a sprite or tile is drawn.

I can compile and run games based on OpenTK using SGDK2 now. Just waiting for the text drawing implementation. One other question has come up, though. Because the IDE can have multiple GLControl objects active at once, I'm calling MakeCurrent in the paint event of the containing form out of concern that if I called it on every call made to OpenTK there would be some unwanted overhead. Recently that got me into some trouble because there are other events that make calls to OpenTK, namely the resize event of the control. My question is, would it be safe to just call MakeCurrent on every call that comes into my Display object (which is derived from GLControl) or would that in fact incur a lot of overhead?

I'm not sure if that's what I want to do, but I am still getting occasional errors like "Failed to make context 327682 current. Error: 0" and I can't track them down. I'm not sure if I'm doing something wrong with keeping the right context current or if there's something going wrong internally in OpenTK.

Edit: I also occasionally get a NullReferenceException on this line in WglHelper.cs (from OpenTK code):

extensions = Wgl.Arb.GetExtensionsString(context.DeviceContext).Split(" ".ToCharArray(), StringSplitOptions.RemoveEmptyEntries);

because Wgl.Arb.GetExtensionsString(context.DeviceContext) returns null. All of these errors happen very unpredictably.

Edit2: Oh yeah, I'm also waiting for full screen support, not just the improved text drawing implementation. Meanwhile, I managed to upgrade one of the old DirectX projects to OpenTK. Here's the compiled result:
(It's pretty small when it's not running in full screen, but it's an interesting project.)


Comment viewing options

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

MakeCurrent has quite a lot of overhead, so you'll want to minimize calls to this function. You can GraphicsContext.CurrentContext to check if you really need to call it.

MakeCurrent may fail if the window handle (of GLControl) is invalid, or if you try to make the same context current on different threads. I'm not aware of any other circumstances that could make it fail. Try checking out the latest version from SVN - wglMakeCurrent was missing a SetLastError attribute, which will help locate the problem.

I'm going to look into the NRE in Wgl.Arb.GetExtensionsString. The implementation is a little hackish, and could be made more robust.

GLControl won't gain the ability to run fullscreen. You'll have to do this yourself by setting the WS_POPUP style on the containing (works on Linux/MacOS too, so no worries) and maximizing it. You should the call this.RecreateHandle() inside the Display object, to switch to real fullscreen mode.

You can already use fonts - quality will improve in the future, but the changes will be internal. Is there a specific show-stopper?

BlueMonkMN's picture

How do I drop the screen resolution to a lower level?

Yes, I already am using fonts. But I can't word wrap or measure text so some pieces of text are a mess.

BlueMonkMN's picture

Yay, I got full screen support working with 0.9.1!
What's the status of the font support? I think I can't output word-wrapped text without some more support from the layers below.

the Fiddler's picture

Font support is rather minimal. You can output text strings and newlines are interpreted as such, but that's all.

There's quite a lot of work left to do on that front.

BlueMonkMN's picture

In that case I'm thinking of distributing my own version of OpenTK with a temporary implementation until the real implementation is done (my implementation would use MeasureCharacterRanges to implement the "wordWarp" (wordWrap is apparently misspelled ;) ) parameter of the text output functions, and provide a way to measure a the size of the resulting text). Is there any problem with that? Should I put special version info in the compiled file to make it more easily identifiable?

the Fiddler's picture

There is no restriction as long as you uphold the MIT/X11 license terms (check Documentation/License.txt), so go ahead :)

I completed font testing on Monday and indeed MeasureCharacterRanges is the way to go, performance and quality-wise. If you implement this, do send the code and I'll commit it to SVN. This way it will also be easier to keep in sync with other updates.