ID:276327
 
I have been having trouble with my Dev-C++ project. I have searched the forums but couldn't find an answer. Plus I don't know of any Dev-C++ forum to post on. I looked at the homepage but it did not have anything. Except an email, but I dont want to bother the maker with a coding question.

Ok my problem begins with my first error. Im compiling my code which has a .c file and a .rc file. In the .c file I have at the top.
#include "opengl.cpp"
// Error: 10 In file included from MDIDemo.c

MDIDemo.c is the current c file. What does this error mean exactly? I thought it ment that I all ready included this file. But I don't see how. Its not added to my project list.

On to the next couple errors. Which I think are related.
/*Errors
[Linker error] undefined reference to `CreateGLWindow'
[Linker error] undefined reference to `KillGLWindow'
[Linker error] undefined reference to `KillGLWindow'
[Linker error] undefined reference to `KillGLWindow'
[Linker error] undefined reference to `KillGLWindow'
[Linker error] undefined reference to `KillGLWindow'
[Linker error] undefined reference to `ReSizeGLScene'
[Linker error] undefined reference to `InitGL'
[Linker error] undefined reference to `KillGLWindow' */

Ok, the file im including. The opengl.cpp has functions in it. These functions are the ones in the errors above. In that .cpp file is a opengl.h file which contains uh the proto types(I thinks thats what they are called).
// opengl.h
GLvoid ReSizeGLScene(GLsizei width, GLsizei height) ;
int InitGL(GLvoid) ;
int DrawGLScene(GLvoid) ;
GLvoid KillGLWindow(GLvoid) ;
BOOL CreateGLWindow(char* title, int width, int height, int bits) ;


As you can see Im trying to use opengl. But I have been have a lot of trouble.

I desperatly need you peoples help. I don't know where else to turn.

Thanks byonders.
I would guess there is an error in the file you tried to include. At least, that's what the error looks like it means.
In response to Loduwijk
Loduwijk wrote:
I would guess there is an error in the file you tried to include. At least, that's what the error looks like it means.
Which error? The include one or the linkage one? Cause there is errors in the opengl.cpp file I include.
In response to Green Lime
Linking errors are usually caused when an included file returns an error, the compiler should give the errors you need to fix somewhere.
In response to Nadrew
Although I can't help you fix the error, check out Gamedev.net. Pretty good community next to Byond.
Why are you #including a CPP file? The usual method is to #include the header (.h) file. In this case, opengl.h.

As for the linker errors, you need to link to the OpenGL library. Look in your project options and find a button named Add Library Or Object (IIRC). Click it, find an OpenGL-related .a or .lib file, and include that. If that doesn't fix the problem, try a different file instead. Repeat until linker errors go away.
In response to Crispy
Crispy wrote:
Why are you #including a CPP file? The usual method is to #include the header (.h) file. In this case, opengl.h.

You think its better just too add it to my project? But when I do that I get a opengl.o cannot be found. Any clue on how to fix that?

As for the linker errors, you need to link to the OpenGL library. Look in your project options and find a button named Add Library Or Object (IIRC). Click it, find an OpenGL-related .a or .lib file, and include that. If that doesn't fix the problem, try a different file instead. Repeat until linker errors go away.

I included a lopengl32.a file. As for the linker errors. I dont see how the opengl library could be the problem. Its not related. At least last time I checked it wasn't. The functions being called aren't apart of the opengl library. O.o right?

*shrugs* I don't know crispy Im not up on all this C++/OpenGL stuff.
In response to Green Lime
Oh, I think I see what you're doing...

Add the .cpp file to your project, but include the .h file. Dev-C++ should then compile in the forward declarations in the .h file (avoiding any compiler errors), and compile and link in the .cpp file (avoiding any linker errors). In theory.
In response to Mecha Destroyer JD
Mecha Destroyer JD wrote:
ALthouhg I can't help you fix the error, check out Gamedev.net. Pretty good community next to Byond.

Agreed. Also, I dislike Dev-C++. It's caused me quite a few problems that I just don't encounter when using some of the pricier compilers(check out Borland)

Hiead
In response to Hiead
Hiead wrote:
Also, I dislike Dev-C++. It's caused me quite a few problems that I just don't encounter when using some of the pricier compilers

True, but in this case you get what you pay for. =)

Dev-C++ is hands down the best free Windows C/C++ compiler out there, and once you get used to its little quirks they're not a problem.

Plus, any code you write in Dev-C++ is more likely to be portable (assuming the libraries you've used are portable) than code written in, say, Microsoft Visual C++. And portability is good.
In response to Crispy
Yeah, I use Dev-C++ and everything I've made with it works in Linux without any changes to the source, it's nice.
In response to Crispy
Dev-C++ is hands down the best free Windows C/C++ compiler out there, and once you get used to its little quirks they're not a problem.

After using it for my game project I seriously don't think they could be called little quirks unless you're doing little projects. I had all sorts of problems with "ghost" bugs which lingered around after being fixed. It has downright terrible detection of what object code needs to be recompiled and often doesn't compile everything right. By crunch time I spent so much time during the recompilation process since the game source was large combined with the fact that I had to clear all the old object code to force it into recompoiling everything so I could saftly have a fresh exectuable. You certainly get what you pay for and it just isn't worth the hassle :P. Save up the money for a real compiler and IDE.

Plus, any code you write in Dev-C++ is more likely to be portable (assuming the libraries you've used are portable) than code written in, say, Microsoft Visual C++. And portability is good.

There really isn't much of an issue so long as you stay away from using commands that begin with an underscore as they are nonstandard. Having code which runs on several platforms is nice but this never works out nice with GUIs as they tend to end up being crappy on all the OSes :P.
In response to Theodis
Theodis wrote:
After using it for my game project I seriously don't think they could be called little quirks unless you're doing little projects. I had all sorts of problems with "ghost" bugs which lingered around after being fixed. It has downright terrible detection of what object code needs to be recompiled and often doesn't compile everything right. By crunch time I spent so much time during the recompilation process since the game source was large combined with the fact that I had to clear all the old object code to force it into recompoiling everything so I could saftly have a fresh exectuable. You certainly get what you pay for and it just isn't worth the hassle :P. Save up the money for a real compiler and IDE.

Game, Set, and Match(XD been playing Mario Tennis). Right on.

There really isn't much of an issue[referring to portability] so long as you stay away from using commands that begin with an underscore as they are nonstandard. Having code which runs on several platforms is nice but this never works out nice with GUIs as they tend to end up being crappy on all the OSes :P.

I totally agree. _xyz() == EVIL(I usually forget to use the underscore and come up with errors)

Hiead
In response to Theodis
Theodis wrote:
After using it for my game project I seriously don't think they could be called little quirks unless you're doing little projects.

I guess many of my projects could be considered "little" - but I've never encountered widespread problems like you describe. Mighta happened once or twice, but nothing a Build All won't fix.

Plus, any code you write in Dev-C++ is more likely to be portable (assuming the libraries you've used are portable) than code written in, say, Microsoft Visual C++. And portability is good.

There really isn't much of an issue so long as you stay away from using commands that begin with an underscore as they are nonstandard.

Last time I checked, MSVC++ was Windows-only. =) And code written for it never seems to work on other compilers in my experience.

I've downloaded code written for MSVC++ and tried to compile it on Dev-C++. More often that not I get cryptic error messages that I have no idea how to solve; and not ones relating to functions starting with underscores.

I haven't tried doing this for a while - I would probably do a lot better in fixing them if I tried it now, as I've actually been using C++ for a bit (e.g. I had absolutely no idea what a void pointer was at that time - "pointer to void? WTF mate?") - but it certainly shows that MSVC++ and Dev-C++ have annoying incompatibilities.

Having code which runs on several platforms is nice but this never works out nice with GUIs as they tend to end up being crappy on all the OSes :P.

Depends. If you mean things like Java's Swing API, then I agree; Swing implements its own "look and feel" which is completely non-standard and difficult to use, and looks crap EVERYWHERE.

On the other hand, wxWidgets is implemented on top of the OS's own controls, so it looks right on every platform; and its design encourages programmers to make sizer-based layouts that resize gracefully given the minor variations in control size and appearance that occur on all the different platforms. All the advantages of programming an OS-specific GUI (plus a few more - sizers rule) but without the OS-specific part.