Elysian Shadows

Then one of two things is going on. You've either got something sneaky going on in code that is not posted or you need to clean your build and rebuild the entire project with that fix. That is most certainly the fix for THAT particular problem. You have to understand that a perspective projection sc...

You're actually rendering outside the view volume, which is what both the perspective and orthographic projection define. If you're using GLU, it generates a right handed coordinate frame and the OpenGL pipeline is setup for a right handed system. In this system, the camera looks along (0, 0, -1) in...

I should have been more specific...

You should test against the Z-Buffer, but not write to it in the transparency pass. So Z-writes should be off.

You're not forced into drawing everything into the z-buffer all the time.

For the transparent faces, just turn z-buffering off and render the transparent faces back to front. Thats all.

Well I'm sorry if my post seemed pissy, it's just been starting to get on my nerves...
I guess a lack of emoticons makes it easy for a post to be taken too seriously

You've probably gathered that I wasn't simply talking about this post. I'm not THAT psycho.

You know what? You really need to work on your attitude because it sucks and is rather irritating. You told him that he's never right then at the same time you go and get all pissy because someone poked fun at you for segfaulting pong. Oh no! Take it in jest and move on. Instead of learning from you...

Well, this isn't really the fault of Visual Studio. You're just in DLL hell and getting into the finer points of software deployment in general :] Either way, it can't read a DLL it needs. Either the DLL in question does not have read access (not installed correctly), the DLL version does not match ...

Given most compilers, if you actually look, it USUALLY generates the exact same code.

If the switch is pretty tightly packed and sequential, then the compiler MAY create a jump table which ends up being a smidge faster. What one compiler does another may not.

"You invented the flux capacitor."

Exactly. The more practical application here is to store data that isn't an "image". Anything like split screens, portals, and things of that nature don't require RTT. Bump mapping as well does not require RTT, as a matter of fact this would be a nasty waste of memory and bandwidth. More c...

Means rendering to something other than the default back buffer, like say...a texture for example :] (Some API's and extensions do make the distinction between a "renderable texture" and a "render target"...there IS a difference). Their uses are far too many to even mention here....

No, absolutely not.

It just means that if you're pushing on pointers to heap allocated memory that you have to MANUALLY go through and explicitly delete the memory because it is not implicitly deleted by std:: containers.

I'd say for those objects that are persistent (eg: xxxxxMachine, xxxxEngine, xxxxFactory), then there's absolutely no problem whatsoever having a global pointer to the instance. A good and safe bet is to just define an externally linked pointer at the end of the class definition. Then you need a con...

No, it doesnt matter how you get them in there. The std:: containers only see pointers. The implementation doesn't care beyond that. So it can't presume anything about them other than that they're pointers.....to something. So the clear methods, the pop methods and so forth don't invoke delete/free....

Unfortunately in this case pop_back will not suffice. pop_back will not invoke delete on memory allocated on the heap, which in this case it is. If it were a case where he were just pushing on copies of whatever it is then this would be fine. In this case you have satisfied the runtime error, but no...