
Reality check: running OpenTK Windows.Form / GLControl demo with mono under Ubuntu7.10
Posted Saturday, 29 December, 2007 - 21:59 by objarni inDoes not work out-of-the box. I'm on an i86 dual boot computer, WinXP/Ubuntu7.10.
I attached the output from command line runs of my project:
mono Dogfight2008.exe >error.txt
The exe-file was built with Visual Studio 2005. I used the .NET binary distribution of OpenTK.dll, version 0.3.13.
I also attached the output of 'mono --version >monoversion.txt'. (apparently ubuntu7.10 comes with mono1.2.4)
Additional steps tried, making no difference:
- Tried updating all packages, no additional repositories
- Added repositories called gutsy-proposed and gutsy-backports, updated everything
- Several reboots of course :)
To me it seems the call to 'ShadeModel' simply crashes with a null-reference exception. Maybe shade model changes aren't implemented in OpenTK? (I can try and remove this actually not-so-necessary call tomorrow and report back..)
My next attempt will be to download/install mono 1.2.6 into ubuntu7.10, a project which might break my package db, since mono1.2.6 is not in any of the ordinary repositories (have to download each and every package manually). Before I do that risky business, I'll wait until you tell I haven't missed some really simple thing.
| Attachment | Size |
|---|---|
| error.txt | 3.14 KB |
| monoversion.txt | 255 bytes |
| error4.txt | 4.89 KB |
| GLUtil.cs_.txt | 3.16 KB |
| GLControlUtil.cs_.txt | 1.26 KB |
| Debug.4.zip | 47.08 KB |
| error4debug.txt | 4.89 KB |


Comments
From the stack trace this
From the stack trace this looks like the main form raises the resize event before the GLControl has a chance to initialize itself (GL.Viewport is called before the context is created). This is a wild guess, but maybe you have hooked the main form's resize event instead of the GLControl's?
Thanks I'll check that out.
Thanks I'll check that out. But why does it work in Windows and not Linux?
In short I've done what you
In short I've done what you suggested, plus a few other things to make my MainForm even more "clean".
Since I cannot attach files in this reply message, I'll attach files to the first message above.
Windows: still works, and did so in every step I took.
Linux: still breaks, with different error from before though. (attaching error4.txt which is the latest error report, with all cleaning up done)
I've written a short story about how I do things in MainForm.cs:
How I do things in my MainForm.cs file
My GLControl is called glControl.
I assume that glControl has been initialized by the time
the main form Load event is triggered.
Since I do GL/GLControl initilization/mechanical work in two separate files called
GLUtil.cs and GLControlUtil.cs, I will attach them.
MainForm constructor
I don't touch glControl at all here. Code:
MainForm_Load
Here I initialize GL (background color, material parameters, lighting etc.).
I also add the Application_Idle event handler.
I touch the glControl by calling HandleResize from within the
GlControlUtil.Init() method:
Application_Idle
The idle event handler touches glControl via an Invalidate() call:
glControl_Resize
I simply call the same resize method as in MainForm_Load():
Does "mono --debug
Does "mono --debug DogFight2008.exe" give anything more? Also, can you attach a binary, so I can check it here?
I've attached Debug.4.zip to
I've attached Debug.4.zip to the original message. Had to remove OpenTK.dll (version 0.3.13) from the archive because of the 256kb attached file limit.
command line: "mono Dogfight2008.exe >error4.txt" (error4.txt attached also)
Oh sorry missed the --debug
Oh sorry missed the --debug flag! Will try that now and attach output ..
Attached as 'error4debug.txt'.
Thanks. I just tested on
Thanks. I just tested on Vista / .Net 3.5, Ubuntu 7.04 / Mono 1.2.5 and Ubuntu 7.10 / Mono 1.2.6 and it works correctly on all three (x64 versions). There was a problem with the text on Ubuntu 7.04 / Mono 1.2.6 preview 2 (x32), but no crashes.
Unfortunately, I don't have any older Mono installations to try, but it seems likely that this is a Mono problem. It is unfortunate that Ubuntu ships with an outdated Mono version by default, and offers no way to upgrade easily (politics getting in the way of usability I'm afraid), but I'll try to think of a fix.
Do you by any chance run on 16bit color? This might cause problems, although it probably isn't the case.
Thanks for your support. I
Thanks for your support.
I don't specify pixel format mode anywhere, just basic GLControl dropped on a Windows.Form. I don't know how to check what pixel format I'm in under ubuntu, but I'll hazard it's 32-bit (the background image looks crisp).
I know next release of Ubuntu will include mono1.2.6, so I'll target finishing my game until then ;)
But it would be nice to be able to test in linux before that; maybe I'll have to install another distro which make it easier to install mono 1.2.6. How did you install mono 1.2.6 on ubuntu7.10?
Am I right in assuming that
Am I right in assuming that the glControl is properly initialized (context created and all) when MainForm_Load() is executed? Is there an even more "orthodox" way of building a Windows.Forms/GLControl program?
[Installing Mono] Installing
[Installing Mono]
Installing mono is actually quite easy. I just download the mono and gdiplus tarballs, and run:
first on gdiplus then on mono.
The configure script will complain on some missing stuff, just
sudo apt-get installeach one until it no longer complains. You may want to install libjpeg-dev, libtiff-dev and libpng-dev first, to add support for these formats (I think there was a '2' somewhere, maybe libtiff2-dev).There also is a generic x86 installer on the mono downloads page, but I haven't tried that.
[GLControl]
It should be ready by the time the OnLoad event is called.
Take a look at the source, it's quite small. It hooks the HandleCreated event and calls the CreateControl() method in the constructor to force the creation of the handle. Inside the CreateHandle event, it creates the context and initializes the GL, Glu classes. In your case, it seems that the handle isn't created in time, but I don't really know why. As far as I know, the only thing affecting handle creation is the Visible property (if set to false, child handles aren't created automatically).