Alternatives to MESA for Linux OpenGL

Started by
7 comments, last by Krippy2k 22 years, 8 months ago
Hi all. Getting ready to start working on OpenGL in Linux again. But I need a decent OpenGL 1.2 library if it exists Don''t even say Mesa. lol. After the fiasco I saw when trying to compile the Windows library(which they do not provide pre-compiled versions of) and was confronted with typo errors in their code which prevented it from compiling. And then once I fixed their typos I saw the rest of the mess. Somewhere around 15,000 compiler warnings on compile. Then finally more errors and I deleted it all. How can anybody release such a thing and call it stable? lol. Well... I guess it can''t be too unstable if it never runs... But it would probably be pretty hard to convince me to ever use software written that way even though it is primarily aimed at Linux I''m sure. If you''re going to try and make something cross-platform you normally make sure that it WORKS on the different platforms. Being able to compile it is certainly a prerequisite to working Are there any other choices? I will be looking around but in the meantime maybe somebody can point me in the right direction Thanks, Krippy
Advertisement
Mesa is great.
It is ported to many OSes and compilers so certainly can some port have errors. On linux is it a part of the OpenGL implementation but the others ports are mostly for interested and experinced programmers.

SGI has released the source to their OpenGL sample but I do not think that this is what you are looking for. If you are using a nvidia card so will you use their OpenGL libraries and not Mesa. A rpm with the SGI GLU 1.3 can be downloaded from the Mesa site to be used together with the nvidia libraries.
Hi. Thanks for the response

Yeah I think I will just have to give up my beef with Mesa and try it on Linux again. I have asked around alot of professionals and although I have come up with some alternatives none seem to fully support OpenGL 1.2 and the ones that come close have problems that force software rendering even when hardware support is available.

I am using NVidia drivers but I do not want to place that restriction on the final product.

Seeya
Krippy
I never had any problems with mesa.... shure... cumpiling it is a litle bit tricky but doing it the right way works GREAT!

may be all those typo errors weren''t really typo errors, just another thing missing out there...

try looking up for the correct way of doing it...
Krippy2k, I think that you missunderstood me.
If you are using nvidias OpenGL implementation do you not use Mesa at all. They are calling it "driver download" but it is really complete OpenGL libraries except for GLU. The package even has modified OpenGL headers so you do not have to include glext for extensions. This is still standard so something built with that package should also run on any other linux machine with Mesa or other standard OpenGL 1.2 implementation. Perhaps with the exception for static linked extensions but nvidia also supports glxGetProcAddress or whatever it was called.

Get the SGI GLU rpm from the Mesa site for the latest 1.3 GLU. Both GLU and OpenGL for linux is in higher versions than in MS OpenGL for Windows.
Obelix thanks for setting me straight. lol. I will try it.

--
Anon they were either typos or somebody changed one part of their code and didn''t bother to update the dependencies.

One for instance was accessing a member variable of a structure. The member of the structure was (I forget the name of the structure now I''ll just call it struc) struc.height and they were trying to access it with struc.Height. If there was something missing it was the Height variable out of the structure. lol. Maybe not an actual typo but if not it means they updated one thing and did not bother to update the other = scary when you''re dealing with lots of similar variable names. Things could easily get mixed up and cause a chemical meltdown. lol

They provide Win32 make files for NMAKE and that is how I compiled it.

There is no documentation that I can find on the ''correct'' way to compile it with MSVC, so I assumed the NMAKE files which are in the WIN32 folder is the correct way.

I was using the 3.4.2 ''Stable release''. I am now downloading the 3.5 developer release. I am interested in seeing if they fixed that problem yet or if they just release theoretically working code instead of proven working code.

Seeya
Krippy
The Mesa implementation is tricky, it''s sometimes slow...but it''s free.
Aren''t they all?
I don''t like Mesa. There were way to much people that had their fingers in there, the whole lib is a monster, a mess in the source, and slow. btw: there is no ''right'' way to compile it. The readme tells about the nmake way, but you can''t compile it that way (compile errors). Just as Krippy I had to fix typo''s, vital functions were commented out, several different source files had the same function name declared multiple times (with different function bodies !!) and so on. The compiled lib never worked. I will never use Mesa again, if you can call that ''use''. The NVidia drivers are very good, I think more 3D board manufacturers should write there own Linux drivers (esp. ATI). Even if they are scared about doing it for Linux, and even if they are unstable, it can''t possibly get worse than Mesa.

-JL

This topic is closed to new replies.

Advertisement