For some reason my lighting code always causes errors in gl.h. I’ve asked good ol’ gl man and he seems somewhat stumped as well. I’ve reviewed several examples and compared them to mine (and read through a bit of the red book itself) and I’m yet to see the problem here. This is my lighting class cpp file:
Any help would be appreciated however talk to me like a 3 year old. I have never done lighting before (that I can recall at the moment) and so my knowledge of it is still VERY primitive.
What should my lighting class contain? What kindof functions? I would like to get shadows goin on eventually as well. Thanks again
Why the h.ll you want to make your life worse? Lignthing functions are simple enough & usually you only need glEnable| |Disable(GL_LIGHT0| |LIGHTING) and max no of light is 8 I tried to do somthing similiar at first, but noticed that it’s not worth that. By the way, for serious ligntning you dont use OGL ligghts anyway, there are thing like vertex programs, projected textures+lightmaps If you really want to make all those function calls shorter use inline functions & macros
just a newbie but I thought I would repeat things I have seen before that might be helpful.
When are you calling make light? Is it after creating your device context?
Also you you have to reennable lighting after you change the lights around?
It’s loooong time since I worked with standart OGL lightning, but as far as I remember all enables were at init() function, & I think positions can be changed even in render f if you wish.
You MUST include windows.h because GL/gl.h REQUIRES it, at least on the Windows platform. The reason is because GL/gl.h uses macros that are defined in windows.h (or a file included from there). OK, it does not require the file itself, but some macros that are defined in there.
However, if you have a REALLY good reason not to include it you can define those macros yourself. Look in the GLUT header for hints on how to do so.
include “lighting.h” AFTER the gl.h and glu.h headers… Your “lighting.h” has types from gl.h, thus you will get errors since the types have not been defined before you use them.
No. If you look inside literally any header you will see include guards in the beginning of the file. <GL/gl.h> have them, so does his <lighting.h>.
#ifndef _LIGHTING_H #define _LIGHTING_H
…
#endif
Tell me if you don’t know how/why they work.
I just want to say some words about the leading underscore. Two leading underscores in an identifier is reserved for the compiler and libraries for the compiler. A single leading underscore with a following capital letter in the global namespace (though I’m not 100% sure about the capital letter) is also reserved for the compiler and it’s libraries. So basically you should not use any names with leading underscores in the global namespace. That include goard above is in the global namespace and is therefore somewhat against the specification. I would suggest not using underscores at all.