Jump to content
  • Advertisement
Sign in to follow this  
HugosHoH

Unreliable Linux GL

This topic is 3762 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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
Advertisement
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
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
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
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
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
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
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
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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!