does fedora8 [and/or other-distributions] contain OpenGL - or a clone?
If it doesn't require a huge quantity of work, I plan to port my 3D simulation/game
engine from windoze to fedora8 Linux. My code totally assumes and requires OpenGL 2.0 and GLSL shaders. My code does everything via IBOs/VBOs and GLSL shaders, and nothing via "the old ways", so it is utterly pointless to attempt a port without OpenGL2 + GLSL shaders --- or an OpenGL2/GLSL clone that works. What is the status of OpenGL2+ and GLSL shaders on modern Linux? |
|
low-level phreak
Quote:
|
If all you need is just something to do the rendering, and already have it ported, then GLX should be sufficient.
Give it a try and post back, and we can take it from there. I'll ask one of my friends to post on here if he has any ideas, as he has been known to write a lot of OpenGL stuff in the past, but has commented on the lack of resources and help within the linux community. He will have more idea of what you require. |
send help
Quote:
Perhaps this means *I* must make a simple nvidia-drivers+OpenGL+GLSL+Linux program work properly, and post it somewhere. I'd much rather find out where someone else has done this already, though. Let them take the credit! :-) |
Look for the Red book and Blue book, apparently they have a lot of information that you need to read.
Also the site below contains more info that will be useful. http://nehe.gamedev.net/ |
onward and --- into a 3D spiral out of control ???
Quote:
I found one section in a book named "the OpenGL superbible 3rd edition" that looks like it has some hints for me. And I found a couple very old articles from kilgard that might help. Of course, I do have a huge program I wrote 20 years ago on top of XWindows and xlib - a software development environment with compiler/debugger/GuiDesigner, so I can get some first order hints from that. But that old program contains zero OpenGL, so the role of GLX seems very important in my current OpenGL project. Somehow I need to make sure the appropriate headers and libraries get included and linked in --- because I see files from many organizations (some of which are not complementary). Just for example, here are some file-groups: ##### nvidia ##### /usr/include/nvidia/GL/gl.h ----- include this instead of other gl.h ??? /usr/include/nvidia/GL/glext.h ----- include this instead of other glext.h ??? /usr/include/nvidia/GL/glx.h ----- include this instead of other glx.h ??? /usr/include/nvidia/GL/glxext.h ----- include this instead of other glxext.h ??? /usr/include/nvidia/cuda/cuda.h ----- include this for GPGPU in video-card ??? /usr/include/nvidia/cuda/cudaGL.h ----- include this for GPGPU via OpenGL ??? ##### OpenGL == KhronosGroup ##### /usr/include/GL/glext.h ----- do not include this due to nvidia version ??? /usr/include/GL/glxext.h ----- do not include this due to nvidia version ??? ##### XFree86 ##### /usr/include/GL/glxint.h ----- include to make XWindows bind to OpenGL ??? /usr/include/GL/glxmd.h ----- include to make XWindows bind to OpenGL ??? /usr/include/GL/glxproto.h ----- include to make XWindows bind to OpenGL ??? /usr/include/GL/glxtokens.h ----- include to make XWindows bind to OpenGL ??? ##### SiliconGraphics ##### /usr/include/GL/internal/glcore.h ----- ????? /usr/include/GL/glu.h ----- ????? do not include unless we want GLUT ??? /usr/include/GL/GLwDrawA.h ----- ???? ignore this ?? /usr/include/GL/GLwDrawAP.h ----- ????? ignore this ?? /usr/include/GL/GLwMDrawA.h ----- ????? ignore this ?? /usr/include/GL/GLwMDrawAP.h ----- ????? ignore this ?? ##### precision insight ##### /usr/include/GL/internal/dri_interface.h ----- ????? ignore this ?? /usr/include/GL/xmesa_x.h --- for building normal ----- ????? ignore this ?? /usr/include/GL/xmesa_xf86.h --- for building server ----- ????? ignore this ?? ##### Mesa3D == OpenGL clone ##### /usr/include/GL/gl.h ----- ????? ignore this ?? /usr/include/GL/gl_mangle.h ----- ????? ignore this ?? /usr/include/GL/glu_mangle.h ----- ????? ignore this ?? /usr/include/GL/glx.h ----- ????? ignore this ?? /usr/include/GL/glx_mangle.h ----- ????? ignore this ?? /usr/include/GL/osmesa.h ----- ????? ignore this ?? /usr/include/GL/xmesa.h ----- ????? ignore this ?? ---------- Well, those are the .h include files that I noticed off hand. Who knows how many more may be lurking in some other directories and subdirectories? Surely not me! And this completely ignores the problem --- ???where??? are all the appropriate pieces that need to be linked into the executable during the build process????? Got me batman. Nonetheless, perhaps somebody out there in nvidia linux land can immediately stare at my guesses above --- and set me straight! To clarify what I think I understand: 1: XWindows includes and libs are from XFree86. 2: OpenGL includes and libs are from nvidia. 3: Mesa files are for computers with video cards that come without OpenGL files. 4: SiliconGraphics files are for unknown-to-me. 5: PrecisionInsight has some product that interacts with Mesa - sometimes. ---------- I shall continue my reading, experimenting, and reporting to this forum. Thanks for any advice and information any of you choose to give. |
You could try finding them with either locate or find.
Either: Code:
find / -iname *.h | grep GL http://www.nvnews.net/vbulletin/forumdisplay.php?f=14 http://forums.nvidia.com/index.php?showforum=23 They may be able to suggest something else. --- Silicon Graphics is probably a reference to SGI workstations which are/were high end (read expensive ;) ) graphics editing workstation back in the day. I have no idea what the state of affairs is with regard the company nowadays, but they still have a website. OpenGL libs and includes could be from Nvidia, if you have a Nvidia card. From ATI if you have one of their cards. Mesa3d I havent come across in a long time, since i used 3dfx cards, and as such you probably know/understand more about their drivers than I do. DRI tends to be used by ATI and Intel Graphic card users. |
As voodoo states, your bets bet is nehe (look at the bottom of each tutorial for all the different implementations of libraries and OS's).
It's been a while but here's the includes of the first example I could find: Code:
#include <GL/gl.h> Code:
EXTRAS="-Wall" Oh, these are some of the references I found on my fed8...(using $ locate GL | grep -v home | grep -v python | grep ".h") Code:
/usr/include/GL/gl.h |
first results
Since I promised to report my experiences, here are my first results.
I wrote a super short program to display a 3D cube (the old gross way, no VBOs), and got that to work with very little effort. It contains the following includes: #include <stdio.h> #include <stdlib.h> #include <nvidia/GL/gl.h> // file is "/usr/include/nvidia/GL/gl.h" #include <nvidia/GL/glx.h> // file is "/usr/include/nvidia/GL/glx.h" #include <nvidia/GL/glext.h> // file is "/usr/include/nvidia/GL/glext.h" #include <nvidia/GL/glxext.h> // file is "/usr/include/nvidia/GL/glxext.h" However, this tells me/us very little so far. But hey, it is something. I am programming in the eclipse environment for the first time, so I don't really know what I'm doing. For example, I'm not sure exactly what libraries it is linking into the project. In one of the 999 settings dialogs, under linker, I entered "X11" and "GL" under the "Libraries (-I)" heading, and I entered "/usr/lib/nvidia" under the "Library search path (-L)" heading. However, I don't know whether those settings are doing anything, and I certainly don't know whether it includes or links-in files from its default paths (whatever they are) in preference to these settings (if it finds files in both). For that matter, I wonder how it knows which of the several linkable library files in "/usr/lib/nvidia/" to link into my executable. I guess I'll figure these things out as I go along. When I tried to compile my whole 3D engine, I ran into zillions of syntax errors. Most of them I understand, and will be trivial to fix. A few I am scratching my head about, and may take some research to extract. At least I have already tested the Linux/XWindows/xlib alternatives to the windoze specific code in my engine. Turns out that was the easy part, I suspect. More reports as I plow through the muck. I know the report most of you want to hear is "how much slower (or faster :-) perhaps) does the engine run on Linux". Though I will be happy with any result between -20% to +100%, I will not be so happy if the speed is more than 25% slower. We shall see. Probably we all should place our bets. :-) My bet: "the Linux version will run 12% slower", due to the speed of the nvidia linux drivers/OpenGL vs nvidia windoze drivers/OpenGL. Your turn. |
Max
What about taking a look at the source for glxgears? glxgears is the "standard" 3d test app for Linux (at least Fedora). A quick look at their code should go a long way. |
glxgears make the world turn
Quote:
Can you provide me a link (or the file)? Thanks. |
Max
I had to figure out what package glxgears comes from. It is in glx-utils. Do you know about srpms? All the Fedora rpms have matching source rpms (srpms). You can get the srpms through yum. You just have to set the enable=0 to enable=1 in your /etc/yum.repos.d/fedora.repo file. Here is the section I am talking about: Quote:
|
Quote:
Unfortunately, when i search my entire filesystem for "glx-utils" and "glxgears" with the "find" command, it outputs only the "glxgears" binary executable - nothing else. I have not been able to find glxgears anywhere on the internet, though I have encountered many people discussing how they compiled and ran glxgears. But the glx-utils packages I have found so far do not include glxgears source code. And the "add/remove software" utility on fedora8 does not list a separate package called "glx-utils development" or similar. I hate to ask "where is it hiding"... but where is it hiding? Thanks. |
By default the srpms repos are shut off. You have to turn them on as described in post #13. Most (not all) of the graphical ways to install stuff on Fedora are just front ends for yum (which in turn is just a front end for rpm, kinda).
|
Ok, this is one of those times Fedora is being strange. 99% of the time the rpm and the srpm have the same name. Apparently this is one of the exceptions. The package (supposedly) is mesa-7.0.2-2.fc8.src.rpm. I do not know why.
It can be directly found on this page: http://download.fedora.redhat.com/pu...dates/8/SRPMS/ Which is where yum would draw it from. |
Well... I was going to tell you to look here if your ever after any source, but guess what, no glx-utils! (p.s. this is the mirror list).
Also came across this, but here's glx-utils, but you might not want to search for that anymore? Also I notice that's not the source (i'd clicked through), therefore look here for mesa dl's... get the 'demos' package, then it's here 'progs/xdemos/glxgears.c' ! This forum doesn't inform you when someone else has posted whilst you were composing... |
rubadub
It happens all the time. Hi, back. Thread The reason I push the srpms so hard is that there are often fixes (sometimes not pretty) contained in the spec file of the rpm. This can make getting a particular app running on that specific distro much easier (saves a lot of hair from being pulled out). |
from glxgears to wide character data-types
Thanks, I have the glxgears source now. In the meanwhile, I mostly have a core OpenGL program working okay with only GLX and xlib anyway. However, now I am caught in the midst of a quandry about wide-character types. I'm gonna post that question as a new thread to not confuse things too much, but do answer this new thread and problem, cuz you've been very helpful. Much appreciated. :-)
|
All times are GMT -5. The time now is 11:15 AM. |