Quick question for people here... I'm playing with some engine development but I want to start using some of the cool new toys, but I'm not sure what people have as a standard gfx card these days.
So what have you got. Any comments feel free to make them below.
What version of OpenGL does your GFX card support?
-
dreadlorde
- Posts: 268
- Joined: Tue Nov 24, 2009 2:20 am
- Contact:
Re: What version of OpenGL does your GFX card support?
OpenGL vendor string: NVIDIA CorporationArchAngel wrote:Quick question for people here... I'm playing with some engine development but I want to start using some of the cool new toys, but I'm not sure what people have as a standard gfx card these days.
So what have you got. Any comments feel free to make them below.
OpenGL renderer string: GeForce GTS 450/PCI/SSE2
OpenGL version string: 4.1.0 NVIDIA 275.09.07
Running on Gentoo. I would also like to try out the new OpenGL features. Never seem to get around to it, though. Turning on hardware tesselation in the Unigine demo was exciting
.While it could take some time before OpenGL 3 and 4 become common, I suspect it may happen sooner than one might expect. I have a Windows 7 "budget" notebook with AMD Mobility. It has OpenGL 2.1 and Quake style games are playable on lower settings. Of course, there are still a lot of machines out there that can't do 3D FPS games at all, but I think in a year or two that may no longer be the case.
-
behind_you
- Posts: 237
- Joined: Sat Feb 05, 2011 6:57 am
- Location: Tripoli, Libya
3.3.0 NVIDIA 275.09.07
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
That's kinda what I'm thinking I just don't know how far I want to go. I've gotta admit I'm not sold on full on 3 and above, the lack of an inbuilt matrix stack seems a bit much... surely this means pushing Matrix processing on to the CPU? I thought most Matrix stuff was done on GPU with previous versions of OpenGL... I know I can go hybrid, but that's a recipe for disaster in nearly all circumstances.mh wrote:3.3 and I say go for it; out with the old and all that.
The main thing I was looking at was an alternative for MipMap generation for PNG files, I'd rather go with core support for OpenGL 3, over GLU but who am I alienating by doing that.
not much difference between gl versions when its all shaders anyway.
if its gl2, use ftransform, otherwise not. easy...
no version of gl has provided a hardware matrix stack, only the final matricies themselves - there's not much difference between glLoadMatrix and glUniformMatrix4fv, certainly there isn't as far as the hardware cares. glMultMatrix, and all the functions which are defined as basically wrappers to it are all basically quite slow. Even with gl2 you ought to just call glLoadMatrix instead of messing around with that stuff.
Matrix stacks are just a convienience that can be replaced with a software library, one that can have its operations inlined and optimised by your compiler so you don't have so much maths done every single time. also easier to cache, and more reliable over multiple separate models.
pre-assign attribute locations at shader creation time. if its gl2 and you want to use ftransform, attribute 0 is defined as the gl_Vertex attribute every time, otherwise its gl3 or you don't care about ftransform, in which case just use whatever attribute indexes you want. There's no point in retaining much more of the fixed-function pipeline, which is the exact reason gl3 core contexts are meant to throw an error when you try.
if its gl2, use ftransform, otherwise not. easy...
no version of gl has provided a hardware matrix stack, only the final matricies themselves - there's not much difference between glLoadMatrix and glUniformMatrix4fv, certainly there isn't as far as the hardware cares. glMultMatrix, and all the functions which are defined as basically wrappers to it are all basically quite slow. Even with gl2 you ought to just call glLoadMatrix instead of messing around with that stuff.
Matrix stacks are just a convienience that can be replaced with a software library, one that can have its operations inlined and optimised by your compiler so you don't have so much maths done every single time. also easier to cache, and more reliable over multiple separate models.
pre-assign attribute locations at shader creation time. if its gl2 and you want to use ftransform, attribute 0 is defined as the gl_Vertex attribute every time, otherwise its gl3 or you don't care about ftransform, in which case just use whatever attribute indexes you want. There's no point in retaining much more of the fixed-function pipeline, which is the exact reason gl3 core contexts are meant to throw an error when you try.