objarni's picture

Reality check: running OpenTK Windows.Form / GLControl demo with mono under Ubuntu7.10

Does 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.

AttachmentSize
error.txt3.14 KB
monoversion.txt255 bytes
error4.txt4.89 KB
GLUtil.cs_.txt3.16 KB
GLControlUtil.cs_.txt1.26 KB
Debug.4.zip47.08 KB
error4debug.txt4.89 KB

Comments

Comment viewing options

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

Oh do I feel silly :)

I forgot to place OpenTK.dll.config besides OpenTK.dll! It works now, with some minor graphical artifacts in the font rendering, and I actually get more FPS in ubuntu than WinXP! Happy surprise.

Has anybody investigated the possibility of embedding OpenTK.dll.config into OpenTK.dll? That would avoid this mistake (for others sake -- I will not do it again ;)

Inertia's picture

more FPS in ubuntu than WinXP!
Huh? What's the difference like?

Good to hear the problem was trivial, the way you described it in IRC it sounded pretty bad ;)

Anonymous's picture

what is difference between Tao and OpenTK?
thanks

Inertia's picture

Your question is answered in http://www.opentk.com/node/189

Asking more than once will not give better results, actually most likely worse results.

objarni's picture

[FPS issue]
No, the FPS drop is still there in WinXP (75->37.5 drop when going from windows approx. 600x400 window to maximized approx. 1200x900).

I'll report the exact numbers tonight. I got the feeling VSync was automatically turned off in ubuntu, got frame rates above 100 and my LCD monitors does not support that. The good thing was there was no difference between "small window" and "big window".

[OpenTK.dll.config issue]
Ideally I would like OpenTK.dll to either (a) complain in Windows also or even better (b) embed it into OpenTK.dll if it is technically possible.

(a) could be implemented as an annoying MessageBox that is display only #if DEBUG, for example. :)

objarni's picture

[FPS Drop]
I built in release mode using Visual Studio 2005. Used a Windows.Form containing a single GLControl with
VSync==true. In glControl_Paint() I do GL.Clear() followed by GL.SwapBuffers(),
nothing else:

 GL.Clear(ClearBufferMask.ColorBufferBit | ClearBufferMask.DepthBufferBit);
 glControl.SwapBuffers();

WindowsXP, GLControl sized c:a 700x400: 75 fps
WindowsXP, GLControl sized c:a 1200x950: 37.5 fps
Ubuntu7.10, GLControl sized c:a 700x400: 210 fps
Ubuntu7.10, GLControl sized c:a 1200x950: 75 fps

I think at least two things are interesting to note:

1. VSync does not seem to make any difference in mono/ubuntu. I guess it is up to the graphics driver if the VSync property of GLControl is respected..? (my lcd monitor has a maximum refresh rate of 75).

2. The big fps drops due to larger window on both platforms. Since it is so fast in ubuntu/mono it's not a real problem for my game so far, but 37 fps is not fun in Windows. I measured the Clear() and SwapBuffers() [ adding GL.Finish() after both to remove any delayed execution ], and got the following results for both window sizes:

700x400
Clear 2ms
Swapbuffers 10 ms
1200x950
Clear 9 ms
SwapBuffers 30 ms

.. so the big milliseconds thief is SwapBuffers. Question is, what happens under the hood in SwapBuffers() in GLControl on the Windows platform..? I get the feeling some really slow GDI/GDI+ blit/copy or something.

(for the record, In ubuntu the numbers were:
700x400
Clear 2ms
SwapBuffers 1.5 ms
1200x950
Clear 6 ms
SwapBuffers 6 ms)

the Fiddler's picture

I'm googling to see if anything related shows up, but so far no good. The only thing I was able to find was the "DoubleBuffered" property (it's protected, you'll have to inherit from GLControl to use it), which seems to carry a performance penalty if set to true. I haven't been able to find anything else, but performance does seem abnormally low. The 7300 does have dedicated memory, doesn't it?

How does the bundled GLControl example work on your machine? (the one with the spinning cube - it should be obviously jerky if it falls below 75fps).

objarni's picture

I tried the "WinForms 2: GLControl game loop" example from the list, with a spinning cube. One 360 degree turnaround took about 6 seconds in small window, and over 15 seconds in a maximized window. Assuming the rotation amount per frame is constant, that is frame-dependent rendering, it seems like a drop 75->25 or something.

IIRC the 7300 has 128 mb dedicated gfx ram, and up to 512 mb shared with primary memory.

objarni's picture

Have you checked out the GRControl.cs library..? It is a single GL-in-Windows.Forms.Control for Windows only. Just checked the source a little, GRControl is inherited directly from the Windows.Forms.Control class instead of UserControl.

I'm testing an example cube, it feels more responsive. Maybe get some ideas from that?

the Fiddler's picture

Link?

Edit: nevermind, found it, but as far as I can see there isn't anything that looks more efficient (to the contrary, actually).

Can you try this dll to see if it works any better? http://users.ntua.gr/el03128/projects/OpenTK/opentk-0.3.14-wip1.zip