avariant's picture

32-bit => 64-bit Linux

One of my testers is getting only a "black" screen where the GLControl should be. (Clear color should be gray ;) )

He is using 64bit Fedora Core 8. His version info:

mono --version
Mono JIT compiler version 1.2.5.1 (tarball)
Copyright (C) 2002-2007 Novell, Inc and Contributors. www.mono-project.com
TLS: __thread
GC: Included Boehm (with typed GC)
SIGSEGV: normal
Architecture: amd64
Disabled: none

I've successfully run openTK on vmware Fedora Core 8 with mono version 1.2.4. The big difference is the 64 bit; I'm using only 32-bit.

From your posts, Fiddler, it's evident you do most of your development on 64 bit Vista / Linux, so it's doubtful that openTK has a problem with 64 bit architecture. However, is it possible for there to be conflicts if the application was built on 32bit Windows XP, in trying to interact with the OpenTK dll?

I know this is a long shot, but my knowledge in this area is slim. Does anything at all come to mind? The application is built using "Any CPU", so no "x86" specific targeting. Graphics card is GF 8800 GT. Not much info here, so I'm not expecting a miracle. Just hoping. :)


Comments

Comment viewing options

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

I have had some minor problems with textures on Mono 1.2.5 x64, which were not present in 1.2.4 or 1.2.6 - this may, or may not be related. I suspect that the MakeCurrent call fails for some reason, but we need more debug information.

Try building a debug version from Windows:

C:\opentk-0.9.0\Build> Build.exe vs
C:\opentk-0.9.0\Build> OpenTK.sln

Build OpenTK through Visual Studio (Debug mode), and send the resulting OpenTK.dll to your tester. You will also need to update your project to redirect debug output to a file:

using System.Diagnostics;
...
Debug.Listeners.Clear();
Debug.Listeners.Add(new TextWriterTraceListener("debug.log"));
Debug.Listeners.Add(new ConsoleTraceListener());
Debug.AutoFlush = true;

Post the resulting debug.log here, it should prove very helpful. OpenTK reports quite a bit of debug information, but this is suppressed in release builds. We are mainly looking for X11 errors.

avariant's picture

I built a debug version as you suggested. Here is the output:


mono Meridian.exe
Preparing visual for System.Windows.Forms (compatibility mode)
Chose visual id (39), screen (0), depth (24), class (TrueColor)
Creating opengl context.
Context is direct, not shared.
New opengl context created. (id: 21615256)
Making context 21615256 current on thread -1431408160 (Display: 14758400, Screen: 0, Window: 39846152)... done!
GL.LoadAll(): 1103 OpenGL extensions loaded in 100 milliseconds.
Preparing visual for System.Windows.Forms (compatibility mode)
Chose visual id (39), screen (0), depth (24), class (TrueColor)
Creating opengl context.
Context is direct, not shared.
New opengl context created. (id: 26595880)
Making context 26595880 current on thread -1431408160 (Display: 14758400, Screen: 0, Window: 39846152)... done!
GL.LoadAll(): 1103 OpenGL extensions loaded in 13 milliseconds.
Making context 26595880 current on thread -1431408160 (Display: 14758400, Screen: 0, Window: 39846152)... done!
Making context 26595880 current on thread -1431408160 (Display: 14758400, Screen: 0, Window: 39846152)... done!
Making context 26595880 current on thread -1431408160 (Display: 14758400, Screen: 0, Window: 39846152)... done!
Making context 26595880 current on thread -1431408160 (Display: 14758400, Screen: 0, Window: 39846152)... done!
Making context 26595880 current on thread -1431408160 (Display: 14758400, Screen: 0, Window: 39846152)... done!
Making context 26595880 current on thread -1431408160 (Display: 14758400, Screen: 0, Window: 39846152)... done!
Making context 26595880 current on thread -1431408160 (Display: 14758400, Screen: 0, Window: 39846152)... done!

This is nearly exactly the output I get from Fedora Core 8 on VMWare, mono 1.2.4, except I get "visual id(34)" and a different number of extensions loaded.

The tester posted an image. It is supposed to be a cube textured with a black/white checker board, 2 checkers in all axis. The scene has two point lights in it. With lighting enabled, the cube is black. With lighting disabled, this is what he gets:

avariant's picture

In case it's relevant, here is the texture loading code I use

using GL = OpenTK.OpenGL.GL;
using GLU = OpenTK.OpenGL.Glu;
using GLEnum = OpenTK.OpenGL.Enums;
 
...
 
 
GL.Enable(GLEnum.EnableCap.Texture2d);
texture = new uint[1];
 
Bitmap bmp = new Bitmap(value.Width, value.Height, System.Drawing.Imaging.PixelFormat.Format24bppRgb);
Graphics g = Graphics.FromImage(bmp);
g.DrawImage(value, 0, 0);
g.Dispose();
Rectangle rect = new Rectangle(0, 0, bmp.Width, bmp.Height);
 
//Create a BitmapData object, and lock the bits of the image.
System.Drawing.Imaging.BitmapData bmpData = bmp.LockBits(rect,
	System.Drawing.Imaging.ImageLockMode.ReadOnly,
	System.Drawing.Imaging.PixelFormat.Format24bppRgb);
 
GL.GenTextures(1, texture);
GL.BindTexture(GLEnum.TextureTarget.Texture2d, texture[0]);
//Bind the texture to GL_TEXTURE_2D.
GL.TexImage2D(GLEnum.TextureTarget.Texture2d, 0, 
    GLEnum.PixelInternalFormat.Rgb8, bmp.Width, bmp.Height,
    0, GLEnum.PixelFormat.Bgr, GLEnum.PixelType.UnsignedByte, bmpData.Scan0);
 
GL.TexParameter(GLEnum.TextureTarget.Texture2d,
	GLEnum.TextureParameterName.TextureMinFilter,
	(float)GLEnum.TextureMinFilter.Linear);		// Linear Filtering
GL.TexParameter(GLEnum.TextureTarget.Texture2d,
	GLEnum.TextureParameterName.TextureMagFilter,
	(float)GLEnum.TextureMagFilter.Linear);		// Linear Filtering
 
//Unlock the bits.
bmp.UnlockBits(bmpData);
//Get rid of the image.
bmp.Dispose();
the Fiddler's picture

It looks as if the bitmap is corrupted and the likely culprit is the LockBits line.

One suggestion is to try different PixelFormats (Format32bppRgba and GLEnum.PixelFormat.Bgra). Does the "Textures" example in "Examples.exe" (ships with OpenTK) display the same corruption?

While this may sound unreasonable, Mono 1.2.6 is the first version that is actually stable when running OpenTK. I understand that you cannot require your users to compile and update Mono just to run a program, but it's not as big a problem as it sounds: the new round of distros is shipping soon (Ubuntu 8.04, Fedora 9, OpenSUSE 11), and they'll come with Mono 1.2.6 or Mono 1.9 by default. OpenTK 1.0 will probably target either Mono 1.2.6, 1.9 or 2.0 (necessary for OSX support).

avariant's picture

It seems unlikely that it is a pixel format problem because the application generates all its own images, and they are always 24bpp RGB.

I've not had him test the examples program, but I can do that. I've also suggested that he upgrade to 1.2.6. I think Fedora offers that... not 100% sure. At the very least, I know there is the generic novell implementation available.

the Fiddler's picture

It seems unlikely that it is a pixel format problem because the application generates all its own images, and they are always 24bpp RGB.
I was referring to a possible bug in the Mono runtime. I've encountered problems using System.Drawing.Bitmaps in 1.2.5 that were not present in 1.2.4 or 1.2.6 - this may or may not be related.

avariant's picture

Ah ok, I understand. Are you aware of an alternative method of setting bitmap data? SetPixel is much to slow, and I can't think of a different way. I don't really have a problem saying that the software is not compatible with 1.2.5, especially if that's the simple truth!

the Fiddler's picture

Are you aware of an alternative method of setting bitmap data? SetPixel is much to slow, and I can't think of a different way.
As far as I know Get/SetPixel() and LockBits() are the only ways.

Judging from the image, it looks as if LockBits are returning a 32bit pixel format instead of 24 bit. It might be possible to provide a workaround by checking the runtime version and loading the texture as 32bit BGRA on 1.2.5, but I don't think it's worth it. If you can, have your tester run the Textures example in Examples.exe - if the same occurs there, it's safe to say it's a Mono bug and that Mono 1.2.5 is not supported.

praveendm's picture

Hey!!

I'm facing similar issue. Any fix for this?

Kindly help.