Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

879978 Posts in 33014 Topics- by 24385 Members - Latest Member: jhewitt

May 25, 2013, 12:09:34 PM
TIGSource ForumsDeveloperTechnical (Moderators: Glaiel-Gamer, ThemsAllTook)Need help with color operations in Open GL
Pages: 1 [2]
Print
Author Topic: Need help with color operations in Open GL  (Read 1725 times)
garlandobloom
Level 0
***



View Profile WWW Email
« Reply #15 on: May 14, 2012, 11:25:26 AM »

Well I still have not been able to implement Shaders effectively. I don't really need any help understanding GLSL. I just cannot get the Shader functions to work in my OpenGL setup. The GLCreateShader command throws a compiler error that it is an undefined function.

I'm running OpenGL through SDL, I don't know if that's the problem. If anyone has any tips on how to get anything beyond the fixed function pipeline to be recognized. Or why it might not be, then that would be extremely helpful. If not, just doing the blend that I want using fixed functions will be perfectly acceptable.

I previously had to do some wierd function declarations just to get VSync operations working. I feel something may be terribly wrong with my setup. I'm hoping someone with more experience can help. I'm kinda a dumb programmer.
Logged

Polly
Level 2
**


View Profile
« Reply #16 on: May 14, 2012, 12:23:21 PM »

The GLCreateShader command throws a compiler error that it is an undefined function.

In Windows you need to allocate functions that require extensions manually using wglGetProcAddress ( thanks to Microsoft Sad ). Or you could simply use a library that does this for you such as GLEW or GLee.
Logged
Claw
Level 4
****



View Profile WWW Email
« Reply #17 on: May 14, 2012, 12:32:07 PM »

The GLCreateShader command throws a compiler error that it is an undefined function.

In Windows you need to allocate functions that require extensions manually using wglGetProcAddress ( thanks to Microsoft Sad ). Or you could simply use a library that does this for you such as GLEW or GLee.

Yeah this is what you're after. It's probably the most annoying thing about OpenGL when getting everything set up for the first time, but after this hurdle it's fine. Just link in GLee or GLew and include the header for the library instead of normal OpenGL includes and you're set.

I use GLee and it works like a charm.
Logged

garlandobloom
Level 0
***



View Profile WWW Email
« Reply #18 on: May 14, 2012, 12:56:38 PM »

Thank you so much! Smiley I can't believe I went this long without knowing about this!

Microsoft taking a crap all over developers doesn't surprise me.

I think I may write up an article about getting Shaders working, since every one I've read fails to mention the fact that their code doesn't compile without linking to something else. If I do, I'll post it here.
Logged

Polly
Level 2
**


View Profile
« Reply #19 on: May 14, 2012, 01:13:50 PM »

Microsoft taking a crap all over developers doesn't surprise me.

Well, OpenGL is a competing "product" to Microsoft's own Direct3D .. so it could have been worse ( no support at all for example ). But as Claw mentioned, it's not a big deal. Simply a matter of for example including GLEW.h instead of the GL.h that comes with the Microsoft SDK ( and calling glewInit ).

I think I may write up an article about getting Shaders working, since every one I've read fails to mention the fact that their code doesn't compile without linking to something else.

The reason tutorials usually don't mention that is because it's Windows specific. If you're developing for Mac / Linux / iOS / Android / Vita etc. you can call glCreateShader without any problems.
Logged
garlandobloom
Level 0
***



View Profile WWW Email
« Reply #20 on: May 15, 2012, 12:48:20 PM »

So, I'm getting a compilation error when I include GLee. Google says I probably just need to include stdio.h, but I figured I'd post about it just in case. Can't test it right now/don't have internet on my dev computer.

I'm including GLee.c and GLee.h into my project files and just compiling them natively from source rather than linking to the GLee.lib file that is included with the latest distribution of GLee. This is mainly because I got a bunch of compilation errors for glXGetProcAddressARB when I linked to the lib, and the readme suggests just compiling from source in that case:

Quote
One more note:
The binary version might complain about missing glXGetProcAddressARB
on the linker stage, but if you get this error, use the source
version and email me (lousyphreak [at] gmx.at).

I'm running GCC version 3.4.5 with SDL version 1.2.15 and my IDE is Code::Blocks svn 7932 although I also get the error when compiling through a previous version of Code::Blocks with the same GCC version.

Here's the error, btw:

obj\Debug\GLee.o||In function `_GLeeGetExtensions':|
G:\Matthew\Duet CPP\Duet Editor\GLee.c|20227|undefined reference to `sprintf_s'|
Logged

mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #21 on: May 15, 2012, 09:09:37 PM »

EDIT: I DIDN'T READ CLEARLY, PROBABLY EVERYTHING IN THE POST BELOW IS WRONG.

So, I'm getting a compilation error when I include GLee. Google says I probably just need to include stdio.h, but I figured I'd post about it just in case. Can't test it right now/don't have internet on my dev computer.

I'm including GLee.c and GLee.h into my project files and just compiling them natively from source rather than linking to the GLee.lib file that is included with the latest distribution of GLee. This is mainly because I got a bunch of compilation errors for glXGetProcAddressARB when I linked to the lib, and the readme suggests just compiling from source in that case:

Quote
One more note:
The binary version might complain about missing glXGetProcAddressARB
on the linker stage, but if you get this error, use the source
version and email me (lousyphreak [at] gmx.at).

I'm running GCC version 3.4.5 with SDL version 1.2.15 and my IDE is Code::Blocks svn 7932 although I also get the error when compiling through a previous version of Code::Blocks with the same GCC version.

Here's the error, btw:

obj\Debug\GLee.o||In function `_GLeeGetExtensions':|
G:\Matthew\Duet CPP\Duet Editor\GLee.c|20227|undefined reference to `sprintf_s'|
Wait. GLX? Didn't you say you're compiling on Windows?

GLX is the Linux opengl extensions. GLEE should be taking your commands and then translating them into calls to either GLX (on Linux) or wgl (on Windows) or whatever Apple uses, depending on OS. If You're seeing anything about GLX at all, then the fact you're running GCC is probably confusing it and making it think you're on Windows. You probably need to define Windows or WINDOWS or _WINDOWS or some crap.

You say you're running with GCC, you mean like, mingw, or cygwin? Or does Code::Blocks pack in its own GCC or something.
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #22 on: May 15, 2012, 09:40:19 PM »

Uh, let me try again.

So I think the note in the faq about the "glXGetProcAddressARB" error implies it's something that's never supposed to happen, and that if you contact the developer they'll figure out why it's happening and try to get it fixed. Maybe this is something about the compiler you're using.

Personally, I've never used binary versions of glee, I just toss glee.c and glee.h into my program. Of course when you did that you got that sprintf_s error.

How much C/C++ are you familiar with? sprintf_s is a standard c function (on windows). If you don't see it, that implies you aren't bringing in the standard windows library. You need to figure out where that lives and get it linked in. The fact you're using GCC may be an issue here as sprintf_s may not be in the GCC standard libraries (because sprintf_s is a microsoft extension). You may be able to get Glee to use plain sprintf instead of sprintf_s. If you can describe your situation a little better maybe someone can help, surely you're not the only person to use Code::Blocks with Glee. I don't know what to tell you though since I don't have any of this software in front of me.
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
71104
Level 0
*


View Profile WWW Email
« Reply #23 on: May 16, 2012, 03:10:54 AM »

If you are shooting for maximum compatibility with the broadest possible audience, than shooting for OpenGL 1.5 would probably be the best bet.

If you are shooting for a crowd that is more familiar with games on the PC, than OpenGL 2.0 and up is a fairly safe target. The majority of individuals who take PC games even slightly seriously are going to have a dedicated GPU in their machine. Even if a motherboard has an on-board Intel GPU, as long as it is running its graphics through a dedicated 3D card, the more recent versions of OpenGL with shader support should run fine.

Some sites collect stats about OpenGL support by graphics hardware, this one for example: http://feedback.wildfiregames.com/report/opengl/
Smiley



Quote
The biggest danger for trying to run GLSL shaders is in older laptops. The majority of desktop systems are going to be fine. I'm still targeting OpenGL 1.5 for some of my projects. But this is more a choice of ease-of-use than features.

That seems exaggeration to me, OpenGL 1.x doesn't have shaders and is not even officially documented on opengl.org any more. Where do you find a reliable function reference?
Logged
Polly
Level 2
**


View Profile
« Reply #24 on: May 16, 2012, 04:04:13 AM »

Statistics from Steam.



OpenGL 1.3 ≈ DirectX 8.0
OpenGL 1.5 ≈ DirectX 9.0a
OpenGL 2.1 ≈ DirectX 9.0c
OpenGL 3.3 ≈ DirectX 10.0
OpenGL 4.2 ≈ DirectX 11

OpenGL 1.x doesn't have shaders and is not even officially documented on opengl.org any more. Where do you find a reliable function reference?

The 2.1 reference mentions which OpenGL version is required for each function.
Logged
garlandobloom
Level 0
***



View Profile WWW Email
« Reply #25 on: May 16, 2012, 10:13:18 AM »

Oh god. This topic has blown up a bit. Anyways @mcc as for the glX error. No I am not actually getting that error, it was a different error. I just guessed at it because I had that FAQ handy and my misreading was what caused me to decide to just throw the GLee.c and GLee.h files into my project.

However I am still getting the sprintf_s error if I compile anything that uses the GLee library functions, GLeeInit() in particular. I am working on Windows. I just updated all my software. So I'm running the latest MingW and SDL and Code::Blocks. So that is not the issue. I'm not including windows.h but GLee includes it after checking that I'm running on windows. However the sprintf_s appears to be part of Microsofts C definition, and not a standard ANSI C command. So I assume I'm just not linking to something that I should be.

There is some concern in my mind for remaining fairly easily cross-platform if not immediately so. So I would rather not require anyone to download MSVC runtime libraries or anything like that if possible.

[EDIT:]

Okay, So here are some the relevent warnings and errors, this is if I link it with the GLee.lib instead of including the source in my project. If I include the source, I don't get the warnings, but I still get the error about an undefined reference to 'sprintf_s'

Code:
||Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized|
g:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.6.2\..\..\..\GLee.lib(.\Release\GLee.obj):(.text[___GLeeGetExtStrPlat]+0x29)||undefined reference to `_imp__wglGetCurrentDC@0'|
g:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.6.2\..\..\..\GLee.lib(.\Release\GLee.obj):(.text[___GLeeGetExtensions]+0xd9)||undefined reference to `sprintf_s'|
||=== Build finished: 2 errors, 25 warnings (0 minutes, 13 seconds) ===|

These are my linker commands: -lmingw32 -lSDLmain -lSDL -lSDL_image -lSDL_ttf -lSDL_mixer -lglu32 -lopengl32 -lGLee

Reading a bit about sprintf_s here, it appears that it is merely a "safer" Microsoft created version of the standard sprintf function. So would it be reasonable for me to just modify GLee to use sprintf? Or should I be doing something else. Microsoft just says to include stdio.h, but GLee already includes it, and the function is not defined in the GCC distributed version of the header.

Hmm.. from looking about, I should apparently just replace the offending line with snprintf and it will still have a "safer" functionality than simply using sprintf. Meaning that it will prevent buffer overflows if the string is too large or improperly formatted. However, as pointed out here, it doesn't produce the same string truncating functionality as the Microsoft version, and merely terminates the program if a overflow occurs.

So, I guess I will just try replacing it with snprintf and see if that fixes the error.

The relevant function in GLee.c is reproduced below:

Code:
GLboolean __GLeeGetExtensions(ExtensionList* extList)
{
       const char * platExtStr;
       const char * glExtStr;
       char * extStr;
       char * p;
       int totalExtStrLen = 0;
       int addASpace;

       /* read the platform specific extension string */
       platExtStr=__GLeeGetExtStrPlat();
       if (!platExtStr) platExtStr="";
       else totalExtStrLen = strlen(platExtStr);

       glExtStr=(const char *)glGetString(GL_EXTENSIONS);
       if (glExtStr==0)
{
__GLeeWriteError("glGetString(GL_EXTENSIONS) failed.");
return GL_FALSE;
}

       /* If the last character of platExtStr is not a space, we need to add one when we concatenate the extension strings*/
       addASpace = 0;
       if ( totalExtStrLen )
       {
           if ( platExtStr[ totalExtStrLen-1 ] != ' ')
               {
                       addASpace = 1;
                       totalExtStrLen++;
               }
       }

       /* allocate the extension string */
       totalExtStrLen += strlen(glExtStr);
       extStr=(char *)malloc( totalExtStrLen+1 ); /* allow for a null terminator */

       /* concatenate the two extension strings */
       sprintf_s(extStr,totalExtStrLen+1,addASpace?"%s %s":"%s%s",platExtStr,glExtStr);

       /* extract the extensions */
       for (p = extStr + totalExtStrLen; p > extStr; --p) {
               if (*p == ' ') {
                       __GLeeExtList_add(extList,p+1);
                       *p = 0;
               }
       }
       __GLeeExtList_add(extList,extStr);
       free((void *)extStr);
       return GL_TRUE;
 }
« Last Edit: May 16, 2012, 02:52:55 PM by garlandobloom » Logged

mcc
Level 10
*****


glitch


View Profile WWW Email
« Reply #26 on: May 16, 2012, 06:17:37 PM »

These are my linker commands: -lmingw32 -lSDLmain -lSDL -lSDL_image -lSDL_ttf -lSDL_mixer -lglu32 -lopengl32 -lGLee
Don't you want those in the opposite order? I thought with gcc an -lLibrary makes its symbols available to any library listed to the left of it. So -lmingw32 should be rightmost?

sprintf_s is indeed a Microsoft variant of sprintf. However I expect MingW and Code::Blocks to support minimal windows.h functionality and would be very surprised they don't compile out of the box. I am myself compiling GLee with mingw and I don't have this problem, although if I just randomly stick a sprintf_s into my code this does not work.

Also, my copy of GLee.cpp does not contain the code you quote. What version of Glee.cpp are you using...?

I think you should find a code::blocks forum. This is a
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
garlandobloom
Level 0
***



View Profile WWW Email
« Reply #27 on: May 16, 2012, 06:51:17 PM »

You may be right about the linker commands. I was under the impression that the order was not important there.

As for what GLee I am using, it came from the Sourceforge repository here: http://sourceforge.net/projects/glee/

I will try some of the earlier versions and fiddle around a bit and see what I come up with.

EDIT: Actually yes, from a google search it does appear that link order matters. So apparently I have just been lucky that this has not been an issue so far. Tongue I will see if simply reordering them properly fixes the error. Since it does appear to be a link time error.
« Last Edit: May 16, 2012, 07:00:53 PM by garlandobloom » Logged

Pages: 1 [2]
Print
Jump to:  

Theme orange-lt created by panic