On Thu, Oct 28, 2010 at 11:27 AM, Tristam MacDonald <[email protected]> wrote: > On Thu, Oct 28, 2010 at 11:21 AM, Casey Duncan <[email protected]> > wrote: >> >> One thing to bear in mind with shaders is that they will greatly >> diminish portability. > > I don't know that 'portability' is a good term for it - shaders certainly > will raise your minimum requirements for simple games, however.
meaning the number of "platforms" that will run your game/app. >> Many portable graphics chipsets in the wild have >> little or no support for them. > > My experience is that those chipsets have not enough fixed-function power to > do anything significant with - I ended up at the performance ceiling of my > Intel chipset even for a moderately complex fixed-function game. > > Also worth mentioning that some integrated chipsets (i.e. Intel's X3100 > present in older MacBooks), are actually *faster* using shaders... fair enough. >> And, like programming for the browser >> in javascript, there are very annoying bugs that vary from chipset to >> chipset. > > Most of these are however in low-end Intel integrated chipsets, and very old > Radeon discrete parts, so raising your minimum spec takes care of those as > well. On the software side, driver bugs bite fixed-function at least as > often (and usually more often) as they do shaders. I agree that raising the minimum platform requirements is a fine solution. Just wanted to point out that it may be necessary. >> Also, some implementations of shaders are done in software >> (e.g., older MacBooks/iBooks) thus performance can vary a lot. > > The GMA 950 in the original MacBook and most older netbooks does have > hardware support for pixel shaders - only vertex shaders are emulated in > software. Since pixel shaders usually comprise the bulk of the work, this > isn't actually as bad as it sounds. > > However, if you want to get into shaders, you want to use GLSL (preferably > OpenGL 2+), so that rules out the GMA 950 anyway. Right, there are lots of GMA 950 machines out there, but as you say getting any decent measure of performance from them is problematic. >> One way to get good portability, and still take advantage of newer >> OpenGL features, is to make everything work against the OpenGL ES >> feature set, which is a sort of lowest common denominator. Then layer >> on shaders and whatnot in a way that they can degrade gracefully when >> they aren't available or fully implemented. > > Sadly, it doesn't work like that. OpenGL ES has only been bridged over to > core OpenGL in the latest versions (effectively versions 4+), and these > versions are bridged to ES2.0, which has *no* fixed-function support. > > ES1.0 does have fixed function support, but it has no shader support and is > not forward-compatible with ES 2.0. I guess I was generalizing too much. My point was to start with things like VBOs and whatnot using fixed-function texturing and lighting (if necessary). Wholly avoid stuff like immediate mode and display lists, though I have to admit that I still like the latter ;^) What generally sucks about OpenGL support is that many cards/chipsets claim to support specific versions, yet do not necessarily fully implement them. Makes the whole thing a lot more frustrating that it needs to be IMO. But that's what happens when you channel a standards-committee through a marketing dept. -Casey -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
