done by mistx
logo done by mistx :: pouët.net is brought to you by mandarine




Current ( >= 3.3) OpenGL - some questions.
category: code

  previous page
go to page of 2  
@w23

the #version directive inside GLSL shaders is defining the GLSL version used, but it's true that if you get a 3.30 context you can assume that GLSL 330 is supported as well in hardware. It doesn't prevents you to use different versions of GLSL for different shaders (which is in fact good, if I use a specific hardware feature of GLSL 330 in only one shader, I'd like that other shaders keep compiling on older hardware without any significant development effort for instance, and then I'm free to use a backward compatible and simpler method for the incriminated shader/codepath). So you can have all kind of versions of shaders on the run, it's only the GLSL parser's/compiler's issue.

btw, I really enjoy the fact that GLSL 330 has implicit int<->float cast like HLSL :) I use/abuse it nowadays. :)

@KeyJ gl_VertexID is supported in all GLSL versions according to this documentation page. Thanks for the info about context creation.. :)
added on the 2012-01-23 16:20:27 by nystep  
nystep
May I ask if someone who has an actual AMD card like to test if glCreateShaderProgramv is implemented and functional in the latest drivers?
added on the 2012-01-23 16:43:25 by nystep  
nystep
@nystep
on osx, when you have a 2.1 context and you write "#version 1.30" or greater, you get nice errors like "NO, I CAN'T! STOP IT!".
added on the 2012-01-23 18:09:22 by w23  
w23
I also want to know what nystep asked for (especially without calling wglCreateContextAttribsARB). Does it work on current AMD drivers?
added on the 2012-01-23 21:39:34 by las  
las
Recent news from the mercury research labs:

Code:

[...]
call _wglMakeCurrent@8

%ifdef DEBUG
push GL_VERSION
call _glGetString@4
DBG 'VERSION:'
push eax
DBG_STR
DBG ''
%endif
[...]



NVIDIA (290.53 beta).
Quote:

VERSION:
4.2.0


ATI/AMD (Catalyst 11.12 / HD 6670).
Quote:

VERSION:
4.2.11318 Compatibility Profile Context


<3 to manx who sacrificed time testing this on ATI/AMD.
added on the 2012-01-23 22:02:50 by las  
las
a bit off-topic, but... you guys claiming that the overdraw in the diagonal pixels of a screen (which would count for less than 0.2% of pixels, or less than 2.0% of wasted fillrate assuming 16x16 pixel tiles) does really matter at all for the baste majority off cases/demos? you must be kidding...

size wise, drawing two tris might be smaller than one tri, or not, depending on too many factors, including the content of the rest of the intro code. this reminds me that i remember having people spending weeks optimizing 4k intro frameworks without any "intro", having only the framework without any other context, which is useless. you better have alternative implementations for usual operations and try them all AFTER you have nearly completed your intro and have context (try "edit" and "static", both, none is better per-se). aaaanyway, i shut up now.
added on the 2012-01-24 06:20:26 by iq  
iq
I consider this the iq version of "make a demo about it" :).

@Iq:
Quote:
...majority off cases/demos

Nope. :)

Quote:
you better have alternative implementations for usual operations

ACK.

goto _topic
added on the 2012-01-24 08:00:45 by las  
las

  previous page
go to page of 2  

post a new reply
You need to be logged in to post a new reply :: register here





pouët.net 0.9-3d89cb1 © 2000-2013 mandarine - hosted on scene.org
send comments and bug reports to webmaster@pouet.net - contribute on GitHub
page created in 0.019360 seconds.