I know it is considered beneficial to keep track of various states yourself. This includes currently bound texture, blending mode, texture mode, depth testing mode, etc. Would it also be beneficial to keep track of my matrices?
Here is my train of thought… I am currently writing a nice GL wrapper class that manages window creation/destruction and wraps other GL calls (primitive drawing, matrix ops). I’m doing this because one day, I might decide to port this to another graphics library (DirectX, PS2, who knows). My view frustum culling stuff, currently uses glGetFloatv() to retrieve both the modelview and projection matrices from OpenGL so that it can “do its magic”. Would it be better if I keep copies of these matrices myself? I could easily do this in my wrapper class. Also doing this would allow me to only call glLoadMatrix() and glMultMatrix() when absolutely necessary (just before rendering) I could simply set a dirty flag when my wrapper functions are called. Do the hardware drivers already keep copies of the matrices in system ram? If not, why? Thanks in advance!
Oh, and this question is directed primarily at you, Matt because I’m currently only targeting GeForce cards
[This message has been edited by BwB (edited 03-17-2001).]
Yes if your wrapper class will be used for applications that need to squeeze every ounce of performance from the system. Yes if you’re probably going to port to other graphics libraries and won’t then be able to rely on the “magic” of OpenGL.
Otherwise, I would recommend you devote your time to higher priority tasks before writing your own matrix math routines.
Well, I’m quite happy to report that with my simple test (a single, untextured quad) in windowed mode not having to call glGetFloat() to get my projection and modelview matrices each frame gave me a 20fps increase (from 360 to 380) in fullscreen mode I didnt get any increase (not surprised there though, I think I’m topped out at 1070fps).
but lets say i want to add transformations to my editor.
i did it that way, when the user want to rotate a brush, he drags the mouse, and the app rotates it using the opengl transformation, i also keep track of the degrees the brush is rotated, than i load the identity matrix and rotate and translate the matrix, than i get the matrix, and manually transform the vertex array to its new position.
this is a good way of using the glGetFloat right? i mean, if its not in the rendering loop, is it ok to use it?
There is no good or bad way. Something is bad if it becomes a bottleneck in your application. So if using glGet* is easier for you and your application get 360 fps instead of 380 without the glGet, then who cares!!! Use glGet.
but if without glGet, you can get 20fps to 40 fps, then it something I would consider.
Though it is always a good thing to plan ahead and since we know that glGet will slow down the app, then you do better not use it if speed is required.
Originally posted by Gorg: …So if using glGet* is easier for you and your application get 360 fps instead of 380 without the glGet, then who cares!!! Use glGet.
I care Why? Because technically I’m not rendering ANYTHING yet (one quad). When I add in my 10000+ scene polys, collisiion detection, ai, scripting, and verious other game logic, that glGetFloat() just might mean the difference between 20fps and 40fps. Personally I’d like to keep the frame rate as high as I can now rather than trying to optimize it later (if I wanted to optimize later I would just optimize the engine I already have).
okapota: If you are manually transforming the vertex array anyways why not just keep track of the matrix yourself? See my post entitled “Vectors and Matrices (not really a question)” for some good vector & matrix code In an editor though I supose it does really matter though, editing isnt a mission critical operation.
I agree with you : for High performance software you should not use glGet, but my point was that you cannot assume that something will be your bottleneck. You can only see it through profiling.
True, there are some don’t dos and some dos, but 99% of the time you cannot just look at your code and say : oh! that is why it is not fast enough.
I agree completely. If it takes only a small amount of time to completely eliminate a potential bottleneck, why not? Like I said, if its not in mission critical situations then this point is rather moot anyways.
Umm… I dont know how to descrive fullscreen mode… The mode that isnt in a window, that takes up the entire screen when the video card has complete control over the entire display (well you can almost never get complete control under windows, unless your a Voodoo2 passthrough board )
