Sign in to follow this  
HugosHoH

Unreliable Linux GL

Recommended Posts

HugosHoH    100
Until recently and to my surprise I realised why all game compnaies, IHVs, and many other related applications are not targeted for linux. I wanted to port a demo I'm working on using OpenGL and OpenAL, and the code is very standard and simple C++ code...pretty portable. It runs just perfect in Windows. After a long long and hard time struggling to fix some compile-time errors and ugly warnings result from library specifications...include directories...trouble with Makefile...and adding more stanadard C headers...anyway...I could not compile the source with GCC since it was not willing to recognize void type and only in one module...the error was as stupid as "anonymous/incomplete type...," whereas it works with other modules. anyway again...I switched to latest free Intel C++ compiler, and it just worked fine...I could link the program and....run it. To my astonishment it worked fine...the sound was ok...not the same quality of Windows or not even close to, both ports use the same module and API though. Now the problem was with OpenGL, it renders with no texturing why? I have no clue guys...and it uses a simple texturing, it was giving an error bad enumeration, and the drivers are supposed to be the latest, even much recent and updated than he Windows ones. I tried to run the glDebugger, and it was not able to lunch it or even the demos that comes with it. Now tell me guys why and how does linux relate to gaming? I would rather consider it as only-text-mode alternative to run at the backend for serving...and wishing it will never behave weirdo..it does not crash I agree but it gives unreliable and unstable results... Feedback please.

Share this post


Link to post
Share on other sites
Null and Void    1088
So, there are bugs in your program, but you have given us no method to help you solve them. I can virtually guarantee there is not a problem with your OpenGL implementation's texturing and GCC is merely being pedantic.

Is it possible for you to post a minimal recreation of the problem code and the error that GCC is reporting? If you can pin down the OpenGL function call that triggers the bad enumeration error, it would be much easier to tell you exactly what it meant. I can't say I've heard of glDebugger much less used it myself, so unfortunately I can't give you any tips to making it work.

Share this post


Link to post
Share on other sites
HugosHoH    100
As I said the code is portable, and it works just fine in Windows. It did compile under Lunix and I ran it but with no texturing while still using the same OpenGL code. Is OpenGL texturing under linux has a special consideration or any thing to do before get it to work?

Share this post


Link to post
Share on other sites
CodeMunkie    805
You really haven't given any information. As Null and Void stated, without posting the relevant source code, there is little anyone can do to help you. That said, all things being equal, there is no reason why your code should fail on Linux. There is no glDoSpecialThingForLinux() call that you have to make (well, there is a difference in the way you create a rendering context, but surely you are using a library such as SDL to do that for you). It should "just work", but until you give more info all I can say is your code is broken.

Share this post


Link to post
Share on other sites
Dragon88    246
I use both OpenGL and OpenAL daily on linux. I have never had any linux-specific issues with OpenGL, and OpenAL performs and behaves better on linux than upon windows for me. I have had OpenAL code run flawlessly on (multile installations of) Linux, and fail in 3 different ways on 3 different windows boxes.

I think you just are doing things wrong in ways that happen to work with the windows drivers, but don't with the linux drivers.

Share this post


Link to post
Share on other sites
HugosHoH    100
I don't think so...Windows drivers are very capable to say the least. And things should be the same for both. I'm using GLUT, pretty portable.

Posting code would not be a good idea since there are several large modules involved, not to mention the non-OpenGL code.

Maybe my installation is broken. Cause I have issues running Maya 8, it just cashes upon start. gDebugger does not function at all. Some games run fine and others crash the whole system. Give me a break...stability? reliability?

BTW my linux distro is OpenSUSE 10.3

Help appreciated.

Share this post


Link to post
Share on other sites
Quote:
Original post by HugosHoH
Windows drivers are very capable to say the least.


That really depends on who made them.

Make sure that everything is set up right, and (since it's a big issue with *unix), make sure you have a flawless OpenGL system with hardware acceleration.

Quote:

glxinfo | grep rendering


Should tell if you do.

FlyingIsFun1217

Share this post


Link to post
Share on other sites
HugosHoH    100
It does show the ATI GL drivers, 2.1, with all extensions supported.

Could be that I link statically to GL functions? I'm not loading the extensions using GetProcAddress or dlsym.

Share this post


Link to post
Share on other sites
keltar    133
Quote:
I'm not loading the extensions using GetProcAddress or dlsym.

It's a bad idea. Try to use glew or something other.

There is a lot of debugging tools, use them. Bugle is capable to catch every GL-error, launch your program with it (something like "LD_PRELOAD=/usr/lib/libbugle.so" gldb ./your_program", if you have bugle installed).

Share this post


Link to post
Share on other sites
Valeranth    100
Quote:
Original post by HugosHoH
I wanted to port a demo I'm working on using OpenGL and OpenAL, and the code is very standard and simple C++ code...pretty portable. It runs just perfect in Windows.


Quote:
Original post by HugosHoH
After a long long and hard time struggling to fix some compile-time errors and ugly warnings result from library specifications...include directories.


I guess it wasnt as portable and perfect as you thought..

Quote:
Original post by HugosHoH
..trouble with Makefile...

Oh, yes.. The companys exclude millions of people becouse the makefiles are so hard...

Quote:
Original post by HugosHoH
I could not compile the source with GCC


Quote:
Original post by HugosHoH
I switched to latest free Intel C++ compiler, and it just worked fine...


Maybe becouse its a c++ program and GCC is a C compiler?

Quote:
Original post by HugosHoH
To my astonishment it worked fine...the sound was ok...not the same quality of Windows or not even close to, both ports use the same module and API though.


This could be create by any number of bugs, yet you provide us with no code...

Quote:
Original post by HugosHoH
Now the problem was with OpenGL, it renders with no texturing why? I have no clue guys...and it uses a simple texturing, it was giving an error bad enumeration, and the drivers are supposed to be the latest, even much recent and updated than he Windows ones.


Bad Enumeration = error, so your judging your expericenses based off poorly programed code.. Also did you make sure you have 3d rendering enabled?

Quote:
Original post by HugosHoH
Now tell me guys why and how does linux relate to gaming? I would rather consider it as only-text-mode alternative to run at the backend for serving...and wishing it will never behave weirdo..it does not crash I agree but it gives unreliable and unstable results...


How long did you spend on linux before coming to this conclusion? And how many poorly coded apps did you run before deciding that linux is complete crap and it should only be used for backend...

Quote:
Original post by HugosHoH
Feedback please.

Share this post


Link to post
Share on other sites
Ozzy-yzzO    103
Hello,

I'm also thinking that the problem is coming from the program itself, check your code, extensions exposed by the GL driver and so on.. As it can't behave exactly the same under your linux distro and win32.

Btw, if you're using C++ there are a few more dramatic issues that will come to your noze just like this -> http://www.trilithium.com/johan/2005/06/static-libstdc/

which simply makes uncompatible executables from one distro to another using a != version or subversion of the libstdc++ ;-(
Of course, it's user dependent to fix the problem by manually installing the correct package. :))

Another one which is concerning OpenGL is the damn misuses of Opengl and the *new* 3D desktop effects fashion (see Ubuntu for instance), they are just wrecking X11 applications that are using the canonical X11 window scheme and Opengl .. :(

Finally, you are really encouraged to provide your project with sources and ready for compilation just because the Linux and most Unices environements are *not* designed to share executables binaries. As a conclusion this is *not* only the idea behind the "cool" OpenSource stuff but you're just forced to do so! ;-)

I really think that these issues are the dead end where Linux IS when talking about commercial development.


Share this post


Link to post
Share on other sites
Valeranth    100
Quote:
Original post by Ozzy-yzzO
Hello,

I'm also thinking that the problem is coming from the program itself, check your code, extensions exposed by the GL driver and so on.. As it can't behave exactly the same under your linux distro and win32.

Btw, if you're using C++ there are a few more dramatic issues that will come to your noze just like this -> http://www.trilithium.com/johan/2005/06/static-libstdc/

which simply makes uncompatible executables from one distro to another using a != version or subversion of the libstdc++ ;-(
Of course, it's user dependent to fix the problem by manually installing the correct package. :))

Another one which is concerning OpenGL is the damn misuses of Opengl and the *new* 3D desktop effects fashion (see Ubuntu for instance), they are just wrecking X11 applications that are using the canonical X11 window scheme and Opengl .. :(

Finally, you are really encouraged to provide your project with sources and ready for compilation just because the Linux and most Unices environements are *not* designed to share executables binaries. As a conclusion this is *not* only the idea behind the "cool" OpenSource stuff but you're just forced to do so! ;-)

I really think that these issues are the dead end where Linux IS when talking about commercial development.


I've never heard that linux is designed to make sharing executables harder.. I call BS... infact I can install and run binarys not only ment for other OS's is raticly diffrent managers, but with diffrent arch's.. so this is def unfounded BS.. And the dead fall with linux in commercial is not anything to do with portiblilty but with the fact that the support is not what most users are used to or would be satifyed with..

Share this post


Link to post
Share on other sites
HugosHoH    100
To correct Valeranth:

1 - gcc compiles C++ through g++

2 - It was not my code, it was thrid party libraries code, specifically OpenAL by Creative Labs which I doubt their code not portable enough.

3 - Makefile is not hard, it's flexible.

4 - How long spent on linux? Hmmm 8 years?????!!!!

Share this post


Link to post
Share on other sites
HuntsMan    368
Well if you're using ATI, that means problems because their Linux driver just suck, they're as buggy as hell.

And that's not a problem of Linux, just that ATI doesn't have good drivers for Linux. If you use a nvidia card, you'll have no problems.

Share this post


Link to post
Share on other sites
Khaos Dragon    196
Quote:
Original post by HuntsMan
Well if you're using ATI, that means problems because their Linux driver just suck, they're as buggy as hell.

And that's not a problem of Linux, just that ATI doesn't have good drivers for Linux. If you use a nvidia card, you'll have no problems.


I can second this, nvidia and intel both seem to have good drivers for linux as far as non bugginess goes. I've had terrible experiences with ATI on linux.

Share this post


Link to post
Share on other sites
Sign in to follow this