It shouldn't matter if the CPU switches threads after you call wglMakeCurrent so long as all your rendering is done from the appropriate threads. (The threads you created the context in and called...
Type: Posts; User: Deiussum
It shouldn't matter if the CPU switches threads after you call wglMakeCurrent so long as all your rendering is done from the appropriate threads. (The threads you created the context in and called...
If you are using Windows, you should be able to just call wglMakeCurrent before doing any rendering. Do each of these threads render to their own window/control? And do you call your OpenGL calls...
Exactly, and that is layed out in memory as
Again, read my code. I am essentially dumping it as
pfv[0] pfv[1] pfv[2] pfv[3]
pfv[4] pfv[5] pfv[6] pfv[7]
pfv[8] pfv[9] pfv[10] pfv[11]...
The red book is showing the matrices in the way they are usually represented in Linear Algebra books, not the way they are represented in memory. Look closely at the OpenGL portion of code I posted...
I did actually take a look at the struct before posting my first suggestion. It is:
typedef struct _D3DMATRIX {
union {
struct {
float _11, _12, _13, _14;
...
Actually, you can create a normal Win32 app from a main function, it just isn't too commonly seen. If you look at the source for glut or just about any other cross-platform windowing API for...
Heheh, well... there is nothing about either opengl32.lib or opengl.lib that make them unusable in either type of project. Libraries don't, and shouldn't, care anything about the entry point of a...
You sure about that? I added the following functions to an app I'm working on that uses both D3D and OpenGL
void DumpMatrix(float *pfv)
{
for (int c=0;c<16;c++)
{
...
The real problem is that you started your project as a Console project, but your code assumes a WinApp project.
Remember the following and you should be fine.
Console projects = main entry...
I'm working on an app that does the opposite right now, takes an OpenGL style matrix and creates a Dx9 matrix from it. I'm using C++ and was able to copy my array directly into the D3DMATRIX.m array...
I'm using XOrg and the 2.4.26 kernel. It's also a pretty fresh install of Slackware. I reformatted recently when I rebuilt some of my hardware.
I tried sending a bug report once, but got a...
Yep... that's basically what I did too, except I used make xconfig, and after make dep, I did a make bzImage, copied bzImage to /boot, edited my lilo.conf so that I had another boot option to use...
Looks like you've run into one of the classic limitations of glut. :) You could either use something else (like the freeglut mentioned in the post above), or you might also consider...
You mean is there something like glFloodFill()? I'm afraid not. You could probably do your own flood fill routine to use in a texture or to use in glDrawPixels, but it probably isn't a very good way...
Where'd you download the source code? gl/device.h isn't a standard OpenGL header, so it's probably located somewhere at the place you got your source code.
You don't give much detail, but my guess is that you are trying to use GL_POLYGON to draw a single concave polygon. You can only draw convex polygons with GL_POLYGON. Try breaking it up into...
Didn't seem to work. About 5 minutes after rebooting with the recompiled kernel, starting my OpenGL app caused me to reboot. I tried compiling it again removing all of the other framebuffer modules...
Thanks, I'll try that out and see how it goes.
Ever since I installed the nVidia linux driver version 1.0-6111, I've been having some weird issues.
I've noticed some of the following things occuring, but they do not occur consistently. They...
Are you sure about that? There are even different stack limits for the projection and modelview stacks. If I recall correctly, the projection matrix is only guaranteed a stack depth of 2, and the...
Maybe I'm not quite sure what you are getting at... You have a face normal, which basically means that everywhere on that polygon will have the exact same normal, including your "center of the...
It doesn't make that much difference. It's just been said in this thread a couple of places already that it was the first vertex that was used, and I was clarifying that it isn't always, as should...
Windowing systems are generally event driven. That means that you only get code executed for those windows when that window receives events. One of those events is the drawing event. In Windows a...
If you re-read the bit pasted from the spec above, you'll note that it is actually the vertex that spawned the item that OpenGL uses to calculate the overall color. That is, the last vertex, not the...
If you already found the face normal, then just use that for the appropriate vertex (or even all of them) and let OpenGL calculate the color for you...