nLite & vLite my friend. Not only can you remain legal, but you get a much better set of options that with your pirated CD. It can even do hands free installs so that next time someone has a problem, then can just re-do the whole thing themselves.....
I imagine that if your mothers family is half scotch, it might just be the liquidity in the gene's that prevents them putting a floating dot over the i. If they were half scottish however, they'd spell it whisky.
OFC if you have to port the game between 4 architectures, (directx,ps3,xdx,wii) it would be beneficial to seperate out the rendering code, which in turn makes it easier to port to openGL right?
Most devs worth their salt will wrap the raw API calls yes. I think the point you're missing though, is that from whichever API you approach the problem from, the wrapper layer always ends up looking very similar to D3D 10 - since it pretty accurately reflects what's available on modern GPU's.
The OpenGL 3.0 spec was supposed to end up looking a lot like a modern graphics architecture as well, but unfortunately, they back tracked at the last minute. The result is a pretty broken, fairly nasty API, where there are literally a 101 ways to draw a triangle. Every other API has just 1 method - and that's always the fastest available. If you've been using OpenGL for 10+ years, you probably have the experience to know which functions are redundant, and which functions are badly supported. If you're new to OpenGL, then god help you! The extension registry is roughyl twice the size of the new testament - That's a hell of a lot of man pages to trawl through.....
Minus immediate mode. Minus compiled vertex arrays. Minus glFogCoordEXT. Minus Fixed Function. Minus glEvaluators. Minus the selection buffer. Minus the accumulation buffer. Minus gluNurbs. etc etc etc
And that's really my point. The code paths used on consoles will not provide any of that legacy crap listed above - so to call them openGL-esque is a complete lie. I'd call them 'similar to what we want openGL to look like', but they are nowhere near being OpenGL3.0 conformant.
Now then, strip openGL of all that legacy cruft, and nicely re-organise the remaining API calls. What you'll have is an API that looks similar to both the console graphics API's and D3D 10....
In fairness ATI really isn't at fault here. OpenGL 3.0 was such a botched spec release, that most of us graphics devs (especially those who'd like to see GL regain some dominance) would like to see the Khronos group lined up against the wall and shot.
Assume for sake of discussion that game companies using DirectX is a bad thing.
It's OK. No console developers are writing code using DirectX (barring those targetting windows) - We have XDX for the xbox, but's thats not the same thing at all.
Also I'm not sure where this myth about openGL being used on consoles has come from, because the truth is very different. We are actually writing rendering code in SDK's specific to Wii and PS3. There is no OpenGL support. (There are some really crappy openGL wrappers that are too in-efficient to be useful if that's what you mean?)
Uhm. PS2/PS3 and the Wii do not support OpenGL, so not sure how you figure that's even an issue? (There is a truly awful OpenGL ES wrapper for PS3, but nobody sane would ever use it....)
In actual fact, porting between GL3.0 and DX10 isn't that hard. It's all SM3.0/SM4.0 shaders that just need to be ported. Everything else is more or less createBuffer/createTexture etc. Porting legacy OpenGL code is a royal PITA though. There just aren't any equivalents for immediate mode/display lists/fixed function etc. Sadly, it's easier to port a DX10 app to GL than it is to go the other way around...
The Khronos Group claims that OpenGL 3.0 has a 'rough feature parity' with Direct3D 10
If by that you mean, kinda has the same functionality but it's hidden under piles of legacy crap, then yes ok... But let's just call a spade a spade - It's OpenGL 2.2, not OpenGL3.0. If you spend an hour or two with D3D 10 it becomes apparent pretty that there's a pretty big gulf between the two API's.
My biggest gripe with OpenGL at the moment is that any monkey can write code using it normally following the red books as a guide. The amount of code I've got to strip out of our codebase that's all been done with fixed function immediate mode is just not very funny. I bet you any money that the GL3.0 red book will still devote large chapters to the stuff you shouldn't be using.
Sadly, if you want to write high performance openGL code, then your only real option is to refer the DX10 documentation. Find the required methods in those docs, then hunt through the GL extension registry until you find something similar. Having done that, write your lovely NV specific code. Then write an ATI specific codepath. Then write the Intel code path. It's time consuming, error prone and a real pita.
If only Khronos had done what they'd been promising for the last 2 years and turned OpenGL3.0 into the API that we've all been asking for.... I'll get excited again when the GL3.1 spec + drivers come out, and am sure to be disappointed once more, but I live in hope....
Sorry for the rant. Anyhow, thanks ATI for finally getting GL3.0 support into your drivers. Much appreciated. It's only been 6 months since the spec was released....
I'm pretty sure they were going to do an rm -rf* on all data anyway, as part of the ongoing write-downs....
Back to a more serious note. The summary does hint it would have taken them down for a week, so I assume they have some form of backup and recovery in place...
We don't need GI quite as much as you'd imagine (in terms of the renderer generating it - faking it's another matter entirely). Since we have live action plates to comp with, the compositor will normally generate a sphere map from plates containing fairly prominent white spheres shot on location (to get the ambient light) and shiny spheres (to get the reflection), which may be used as an env map in the ambient/specular passes. Since it all goes through a final comp, there's less need for it to be mathematically accurate - the compositor will simply fake the lighting with nuke or shake in post. Even if we enabled GI on everything, the compositor's still going to be spending time fixing it. It's very rare that live action plates (with no CG) don't get modified in post to make the images look more natural - and that's really the problem: We don't want realistic images - we want images that look real... Those two goals are somewhat different, and most of the time GI takes a lot of CPU power, and doesn't give us the effect we wan't.....
True, but the thing everyone forgets is that artist time increases exponentially with modeling complexity. Artists can't physically create enough data for it to be of real benefit. Given that renderman subdivides all polys to pixel sized chunks, and an entire filmFX team still can't produce enough data to make raytracing more cost effective than reyes, I fail to see how a games team is going to do it...
Architectural rendering is about the only scenario where you may get to that level of complexity.
I think it's exactly the opposite. 'FilmFX' world isn't using raytracing because it hasn't been used in games. Games drive this tech, and if we get fast hardware for raytracing then movies will use it exclusively.
You'd have a point if it wasn't for the fact that dedicated ray tracing hardware has been around for decades as standalone hardware, and dedicated PCI cards.
The FilmFX industry already has dedicated hardware accelerated ray tracing, has had it for some time, and finds no use for it. I still find it laughable that everyone gets so excited about HW ray tracing, because quite frankly, it's a dead end.....
Slashdot Mirror
nLite & vLite my friend. Not only can you remain legal, but you get a much better set of options that with your pirated CD. It can even do hands free installs so that next time someone has a problem, then can just re-do the whole thing themselves.....
It's ok, i think they'll understand a Glaswegian kiss when they see one....
I imagine that if your mothers family is half scotch, it might just be the liquidity in the gene's that prevents them putting a floating dot over the i. If they were half scottish however, they'd spell it whisky.
Yeah, the lady sitting next to me on the bus this morning was on it at about 8.30...
Not anymore. The latest figure indicate that it's been beaten into second place by this tipple...
She also said that any Scotch aged more the 12 years is too woody
Glenfiddich 18
Lagavulin 16
There are a few decent blends out there. Monkey Shoulder for example...
You sir have bet on the right horse. Lagavulin for the win.
You should try Laugavulin... One of the tastiest scotch's imho.
Brain Hemorrhage
1 Pint of Guiness + shot of Baileys.
The baileys curdles into an un-pleasant looking 'BRRRAAAAIAIIIIIINNNSSS' like horror at the bottom of your pint.
It's the By-Products, not the whisky itself. Also of note, there is no 'e' in Scotch Whisky. The 'e' only applies to irish & american whiskeys...
There is however and 'e' in Pee, which I'm assuming is the By-Product they are reffering too.
OFC if you have to port the game between 4 architectures, (directx,ps3,xdx,wii) it would be beneficial to seperate out the rendering code, which in turn makes it easier to port to openGL right?
Most devs worth their salt will wrap the raw API calls yes. I think the point you're missing though, is that from whichever API you approach the problem from, the wrapper layer always ends up looking very similar to D3D 10 - since it pretty accurately reflects what's available on modern GPU's.
The OpenGL 3.0 spec was supposed to end up looking a lot like a modern graphics architecture as well, but unfortunately, they back tracked at the last minute. The result is a pretty broken, fairly nasty API, where there are literally a 101 ways to draw a triangle. Every other API has just 1 method - and that's always the fastest available. If you've been using OpenGL for 10+ years, you probably have the experience to know which functions are redundant, and which functions are badly supported. If you're new to OpenGL, then god help you! The extension registry is roughyl twice the size of the new testament - That's a hell of a lot of man pages to trawl through.....
Minus immediate mode. Minus compiled vertex arrays. Minus glFogCoordEXT. Minus Fixed Function. Minus glEvaluators. Minus the selection buffer. Minus the accumulation buffer. Minus gluNurbs. etc etc etc
And that's really my point. The code paths used on consoles will not provide any of that legacy crap listed above - so to call them openGL-esque is a complete lie. I'd call them 'similar to what we want openGL to look like', but they are nowhere near being OpenGL3.0 conformant.
Now then, strip openGL of all that legacy cruft, and nicely re-organise the remaining API calls. What you'll have is an API that looks similar to both the console graphics API's and D3D 10....
In fairness ATI really isn't at fault here. OpenGL 3.0 was such a botched spec release, that most of us graphics devs (especially those who'd like to see GL regain some dominance) would like to see the Khronos group lined up against the wall and shot.
Assume for sake of discussion that game companies using DirectX is a bad thing.
It's OK. No console developers are writing code using DirectX (barring those targetting windows) - We have XDX for the xbox, but's thats not the same thing at all.
Also I'm not sure where this myth about openGL being used on consoles has come from, because the truth is very different. We are actually writing rendering code in SDK's specific to Wii and PS3. There is no OpenGL support. (There are some really crappy openGL wrappers that are too in-efficient to be useful if that's what you mean?)
Uhm. PS2/PS3 and the Wii do not support OpenGL, so not sure how you figure that's even an issue? (There is a truly awful OpenGL ES wrapper for PS3, but nobody sane would ever use it....)
In actual fact, porting between GL3.0 and DX10 isn't that hard. It's all SM3.0/SM4.0 shaders that just need to be ported. Everything else is more or less createBuffer/createTexture etc. Porting legacy OpenGL code is a royal PITA though. There just aren't any equivalents for immediate mode/display lists/fixed function etc. Sadly, it's easier to port a DX10 app to GL than it is to go the other way around...
The Khronos Group claims that OpenGL 3.0 has a 'rough feature parity' with Direct3D 10
If by that you mean, kinda has the same functionality but it's hidden under piles of legacy crap, then yes ok... But let's just call a spade a spade - It's OpenGL 2.2, not OpenGL3.0. If you spend an hour or two with D3D 10 it becomes apparent pretty that there's a pretty big gulf between the two API's.
My biggest gripe with OpenGL at the moment is that any monkey can write code using it normally following the red books as a guide. The amount of code I've got to strip out of our codebase that's all been done with fixed function immediate mode is just not very funny. I bet you any money that the GL3.0 red book will still devote large chapters to the stuff you shouldn't be using.
Sadly, if you want to write high performance openGL code, then your only real option is to refer the DX10 documentation. Find the required methods in those docs, then hunt through the GL extension registry until you find something similar. Having done that, write your lovely NV specific code. Then write an ATI specific codepath. Then write the Intel code path. It's time consuming, error prone and a real pita.
If only Khronos had done what they'd been promising for the last 2 years and turned OpenGL3.0 into the API that we've all been asking for.... I'll get excited again when the GL3.1 spec + drivers come out, and am sure to be disappointed once more, but I live in hope....
Sorry for the rant. Anyhow, thanks ATI for finally getting GL3.0 support into your drivers. Much appreciated. It's only been 6 months since the spec was released....
I'm pretty sure they were going to do an rm -rf* on all data anyway, as part of the ongoing write-downs....
Back to a more serious note. The summary does hint it would have taken them down for a week, so I assume they have some form of backup and recovery in place...
We don't need GI quite as much as you'd imagine (in terms of the renderer generating it - faking it's another matter entirely). Since we have live action plates to comp with, the compositor will normally generate a sphere map from plates containing fairly prominent white spheres shot on location (to get the ambient light) and shiny spheres (to get the reflection), which may be used as an env map in the ambient/specular passes. Since it all goes through a final comp, there's less need for it to be mathematically accurate - the compositor will simply fake the lighting with nuke or shake in post. Even if we enabled GI on everything, the compositor's still going to be spending time fixing it. It's very rare that live action plates (with no CG) don't get modified in post to make the images look more natural - and that's really the problem: We don't want realistic images - we want images that look real. .. Those two goals are somewhat different, and most of the time GI takes a lot of CPU power, and doesn't give us the effect we wan't.....
True, but the thing everyone forgets is that artist time increases exponentially with modeling complexity. Artists can't physically create enough data for it to be of real benefit. Given that renderman subdivides all polys to pixel sized chunks, and an entire filmFX team still can't produce enough data to make raytracing more cost effective than reyes, I fail to see how a games team is going to do it... Architectural rendering is about the only scenario where you may get to that level of complexity.
You Already can
I think it's exactly the opposite. 'FilmFX' world isn't using raytracing because it hasn't been used in games. Games drive this tech, and if we get fast hardware for raytracing then movies will use it exclusively.
You'd have a point if it wasn't for the fact that dedicated ray tracing hardware has been around for decades as standalone hardware, and dedicated PCI cards.
The FilmFX industry already has dedicated hardware accelerated ray tracing, has had it for some time, and finds no use for it. I still find it laughable that everyone gets so excited about HW ray tracing, because quite frankly, it's a dead end.....
Damn. I just bought a mac, but now I learn that IE isn't available for it, I'm going to have to put it on e-bay.... ;)
Personally, I'm thinking about FPGAs which produce circuits at relatively low bandwidth but that are highly tuned to the task at hand.
Hardware-Accelerated Shaders Using FPGAs
There's one other caveat. That scalability fails to apply when you take into account that memory read's are not free.