Sorry your browser is not supported!

This is my question for anyone who cares to answer or comment about my question. I would also like to know a timetable for such enhancements/updates??

There's shader support, but not specifically for CG. However you can use cg to write shaders...I think not really sure how it works.

It would certainly be nice if we could use CG shaders as there are many available online.

If anyone knows any WYSIWYG tools for making asm shaders, that would be very useful as well.

@Rob K

"If anyone knows any WYSIWYG tools for making asm shaders, that would be very useful as well."

I think this might help. http://developer.nvidia.com/view.asp?IO=nvasm
I haven't used it myself so I don't know how good it is.
There is also RenderMonkey which can create shaders in asm or HLSL(the microsoft equivalent of cg). You can find it hear at:
http://mirror.ati.com/developer/sdk/radeonSDK/html/Tools/RenderMonkey.html

there's also the 2 vertex & pixel MFC samples that come within Dx9 SDK can alter them.

personally i hope they add .fx support for Dx9 with the extra commands for them, but god knows what they're really upto. Last time i asked mike he was pretty tight lipped about what was going on and gave me the run around and i've read some contrary points from people on DBDN so really i guess we'll have to wait and see.

i wish they would release a "we hope to include" list for each patch - kinda tick it off once it is actually done.
that way we can see what is planned and what is being done.

as for nvasm, erm it is an odd tool - and not really a WYSIWYG tool, its actually more of a debugger for testing code first.
RenderMonkey from what i understand only exports 1.4 which is pretty much useless in Pro as is (even with the update it is still a useless version for compatibility means)

you can use the Cg Plugin for Max5 or Maya 4.5 to export in a WYSIWUG fashion, only you'll require a card capable of running it - and to be honest i can't stop max from getting "cannot find *.pso" errors all the time, they still work they just can't find those files and i can't find them on my systems either (bloody annoying)

Cg itself only exports to .nvv (GLShader) or .fx (HLSL), there might be a setup for exporting to asm but i've not had a play with the actual compiler itself yet.

The biggest problem that I have is that almost ALL of the shader examples I have found are VS 1.1 (no problem) / PS 1.4 (aggh! - GF3 only supports 1.1)

hey did you try out the example i posted below in pixel shader constants or whatever.
i tried it for myself but got a few basic errors (god knows why but i can never use for...next statements first time lol)
but it should work and thats a pixel shader 1.1 example

the MFC Pixel Shader example in Dx9 is create, because you sit there and type in the shader code and you have 2 images & colour points to work with - so you can see your shader in working order before you export it

@Raven

"as for nvasm, erm it is an odd tool - and not really a WYSIWYG tool, its actually more of a debugger for testing code first."

Its not just a debugger. It can assemble pixel or vertex shaders or at least the directx 8.1 ones(excluding ps 1.4).

"RenderMonkey from what i understand only exports 1.4 which is pretty much useless in Pro as is (even with the update it is still a useless version for compatibility means)"

You understand wrong. It can export to VS 1.1, 2.0, 2.0sw and PS 1.1, 1.2, 1.3, 1.4, 2.0, 2.0sw. It is actually a pretty excellent tool. My only cavet is that it stores your shaders that you make in XML. I'd rather I had an option to precompile my files instead of being forced to compile them at runtime so that is why I recommended NVASM which can solve that little problem. Develop and preview it with RenderMonkey; compile it with NVASM.

Simple as that.

well assemble is a bit of moot point, it can build the ASM into the .fx format if thats what you mean - other than that it doesn't assemble.
vs 1.1,2.0,2.0sw? ps 1.1,1.2,1.3,1.4,2.0,2.0sw?

why doesn't it support vs 1.0,1.2,1.3,1.4? and how can it support Software Shaders when they're identical to Hardware version, the Software actually just means your running DirectX in Reference mod

it would seem wierd that it would't even support Radeon's own VS format, stranger still that it'd support 2.0 when Radeon's don't support them even slightly :S
but hey whatever i'm sure theres some sense in it somewhere.

personally i'm going to stick to devving in asm for standard shaders and C++ for Cg Shaders.

@Raven

"it can build the ASM into the .fx format if thats what you mean"

No it isn't what I mean. What I mean is that it can assemble it into object code that can be loaded and ran without it having to be compiled at run time. Anyway, I can't see how you could think that it would build it into a .fx file considering that this tool was created long before that file format was even invented!

"why doesn't it support vs 1.0,1.2,1.3,1.4?"

Huh? They aren't supported because they don't exsist and you just made them up. Honestly, where do you get your info? There are no such things as vs 1.0, 1.2, 1.3, and 1.4. I dare you to prove otherwise.

"and how can it support Software Shaders when they're identical to Hardware version"

Easy. It justs runs directx in reference mode as you said. Why they have included it I don't know. You would have to ask them. All I know is that it is there.

"it would seem wierd that it would't even support Radeon's own VS format,"

ATI's Radeons do not have their own VS format. They do, however, have their own Pixel Shader format: 1.4. Is that what you mean?

" stranger still that it'd support 2.0 when Radeon's don't support them even slightly :S"

I won't even bother with this non-sense. I argued before with you about this. If you didn't get it then you aren't going to get it
now.

"personally i'm going to stick to devving in asm for standard shaders and C++ for Cg Shaders."

Aren't they the same thing? What do you mean by "standard"? What is standard about them and how does that diffentiate them from Cg shaders? Both asm and Cg shaders both compile to the same code so I don't understand what you are saying here.

they don't exist? funny the DirectX 9 SDK Documentation seems to think otherwise (funny that)

that aside, the SDK also comes with EffectEdit - which is Mircosofts version of RenderMonkey (which isn't a beta) and has the full source so you can make your own if you want.

as for arguing about what the Radeons can and can't process is actually a very good point right now because i've been having ALOT of trouble getting half the things that everyone seems to think work with Radeons working 100% without DirectX reverting into Reference mode... and this is on a 9800mobile so, i'd like to know what it is technically suppose to be able to do.
I'm looking forward to trading this new notebook in for the GeForceFX Go! one later this month to be quite frank, i've never had so much bloody grief graphically than with this stupid Radeon and i don't care if the FX Go! one does cost $200 more - atleast i know it'll do what it says it does on the box.

ASM and Cg are not even close to the same, Cg is a C varient on Renderman Shader Language - which is refreshingly nice to use
the ASM shaders are what you can use standardly, and kinda what the HLSL is...
its far better to type something like

if( Dot3(ShaderVec3.a,ShaderVec3.b)==MUL(Shader.Diffuse,Light.Color) )
{
whatever();
}

and such to asm or HLSL... i mean it can export to standard .FX - but you can also use it natively as .cg which i think is bloody nice, especially as it actually subsides DirectX or OpenGL meaning you can use it identically in both rather than recoding for each.

@Raven

"they don't exist? funny the DirectX 9 SDK Documentation seems to think otherwise (funny that)"

Funny, it doesn't. They directx 9 sdk documentation makes NO mention whatsoever of vs 1.0, 1.2, 1.3, or 1.4. I'd advise you to look again. Or, better yet, check out this link straight from microsoft:

http://msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28000410

"that aside, the SDK also comes with EffectEdit "

Which isn't anywhere near as good as RenderMonkey. I know. I've used it before and it sucks in comparison.

"as for arguing about what the Radeons can and can't process is actually a very good point right now because i've been having ALOT of trouble getting half the things that everyone seems to think work with Radeons working 100% without DirectX reverting into Reference mode... and this is on a 9800mobile so, i'd like to know what it is technically suppose to be able to do."

9800 mobile? I couldn't find any mention of that on ATI's site. Check and see for you self.http://mirror.ati.com/products/builtmobile.html
I can't help you if I don't what card you are running so sorry. However, I believe I heard something about one of the earlier radeon 9x00s only supporting PS 1.4. I don't remember where I heard it but it might have been in one of their tech docs on their developers site.

"ASM and Cg are not even close to the same, Cg is a C varient on Renderman Shader Language "

I know this. It is not what I was asking. I was wondering what you meant when you said you would develop standard shaders in asm and C++ shaders in CG. The difference between shaders written in asm and shaders written in Cg is minimal when they are compiled. They both turn into object code so I was wondering what, other than syntax, is so different from the two that one you use for "standard" shaders and one you use for, I can only assume, "non-standard" shaders? I suppose what I am getting at is what is the difference between standard and non-standard shaders?

I think what you mean is standard shaders are written in asm and non-standard shaders are written in their C++ equivalent. This wasn't clear in your orginal post because you made it sound like there was a difference performance wise(or in what they are able to do) between standard and "non-standard" shaders. If this is true, I still can't understand why you would continue to dev in asm when you can do the exact same shader in C with virtually no performance improvement. But, anyway, forget it. It's not important.

"the ASM shaders are what you can use standardly, and kinda what the HLSL is..."

HLSL is simaliar to ASM? HLSL is virtually identical to Cg, not ASM.

" mean it can export to standard .FX "

I assume you are referring to CgFX?

"but you can also use it natively as .cg which i think is bloody nice, especially as it actually subsides DirectX or OpenGL meaning you can use it identically in both rather than recoding for each."

I agree. It is pretty useful.

EffectEdit might be a little barer than RenderMonkey, but there is no differencing in coding and seeing what you've done - its just the project windows that makes the difference, which as the source to EffectEdit is right there in the SDK its simple enough to make with that feature.

infact i wouldn't put it past ATi that they didn't use the bloody thing as a base from DirectX 8.1

as for which Radeon, its a 9800 - and its in a laptop, i'm assuming its a mobile (because thats the prefix they generally give thier notebook chips) ... but i don't really give a crap it said it fully supported currecnt shaders, yet it bloody doesn't atleast not natively. Quite frankly i want to get rid of it as soon as possible.

just a final point ASM Shaders and FX HLSL are utilised COMPLETELY DIFFERENT to Cg CgFX Shaders - although you can compile the shaders to a specific format, you don't have to compile them - you can actually use them directly using the Cg Toolkit SDK.
Thats what makes them so versitile and different to the standard Shader setup.

and although it may seem that HLSL are like Cg Shaders, but i'd suggest you look again - because you code them differently (especially as you still need to understand the ASM version to use HLSL) but also Cg bypasses DirectX/OpenGLs and directly accesses the Hardware Layers. They're faster than standard DirectX Shaders, and the current OpenGL Shader support is pretty poor as is anyway.

In my limited experience, RenderMonkey was easier to use and the documentation is better. But I'll let the experts discuss this.

@Neophyte

Have you any ideas how to do a refraction effect in an ASM shader?

There is no such graphics card as a mobile 9800. The latest ati chip is the desktop 9800, released in the past 2 months, and this is their fastest. They never release identically numbered chips for mobile devices straight away. If I remember correctly, I think the fastest mobile chip MAY be the mobile 9600, but this could be completely wrong, and may not have been released yet. There is definately a mobile 9000, and I think at the moment, this is their fastest mobile chip currently being sold.

David

well my drivers say 9800pro if it isn't a 9800 then why would it be using thier drivers... and as for it only being out a few months, pull the other one, Alex has had a 9800pro since last November, perhaps its a new chip as far as the UK is conserned but it sure as hell isn't stateside.

That aside i dont' care now because in my hands i have one of the first 10 retail GeForceFX 5900 256Mb and i can't wait to get home and plug the bugger in

and Rob, use a View Matrix to get the veiw you want then use the Projection Matrix for the output - use a vs to then import the Veiw Matrix Data, Dot with the Light Vector, Then export to the Projection.

most of the SDKs actually have alot of demos which show exactly howto achieve this.

@Raven

"EffectEdit might be a little barer than RenderMonkey, but there is no differencing in coding and seeing what you've done"

There is a difference, besides the syntax highlighting and capacity to dev both asm and hlsl shaders and the(soon to be) extendable framework for custom shader dev tools, and that is the artist tweakable parameters. Personally, I think this is invaluable when it comes to experimenting with shaders and beats the hell out of having to recompile and view your shader everytime you want to tweak a variable, but thats just me.

As for writing my own, no thanks. I have better things to do in my time than monkey around with modding effect edit when I know that, at the end of the day, all of the work I did was done for me, and better, with RenderMonkey.

"infact i wouldn't put it past ATi that they didn't use the bloody thing as a base from DirectX 8.1"

I doubt it.

"as for which Radeon, its a 9800 - and its in a laptop, i'm assuming its a mobile (because thats the prefix they generally give thier notebook chips) ... but i don't really give a crap it said it fully supported currecnt shaders, yet it bloody doesn't atleast not natively. Quite frankly i want to get rid of it as soon as possible."

As davidt said, its not. It couldn't be. They haven't made it yet. Did you check that link I gave you previously? It goes to ATI's mobile graphics card page and the 9800 isn't listed. The highest version is the mobile 9600. But I guess this is a moot point considering you got a new GFX card.

"just a final point ASM Shaders and FX HLSL are utilised COMPLETELY DIFFERENT to Cg CgFX Shaders - although you can compile the shaders to a specific format, you don't have to compile them "

No they are not utilized differetly at least not in any major way like you're thinking. You still need to compile shaders at runtime if you don't pre-compile them otherwise you can't use them.
From the Cg_Toolkit pdf in the Cg toolkit sdk:

You'll find this under Using the Cg runtime library->Introducing the Cg runtime.

"and although it may seem that HLSL are like Cg Shaders, but i'd suggest you look again - because you code them differently (especially as you still need to understand the ASM version to use HLSL)"

The difference between HLSL and Cg is minimal. There are a few minor syntax differences such as the names of keywords but that is about it. They both use a C-like syntax and they both use semantics like POSITION or TEXCOORD0. I've looked at both and, other than a few cosmetic differences,they are one and the same. The only real difference is that Cg can be compiled into opengl shader object code, via the cg compiler or runtime library, while HLSL can't. As for needing to understand ASM to use HLSL, no you don't. I'm curious to know as to what part of HLSL is it that you need to understand ASM to use because I haven't seen any part of it that would suggest that knowledge of ASM was a prerequiste. Helpful maybe but not necessary.

"but also Cg bypasses DirectX/OpenGLs and directly accesses the Hardware Layers. They're faster than standard DirectX Shaders,"

No it doesn't bypass the 3d APIs and no it isn't faster than HLSL shaders. See my above comments as to why.

You certainly have a lot of bizzare ideas when it comes to shaders Raven. I'm beginning to think that you don't have a whole lot of experience using them at all or at least writing any on your own. Where do you get all of this misinformation from?

"and the current OpenGL Shader support is pretty poor as is anyway."

When it comes to using next gen shaders you could say that again.

well that would be interesting saying i don't have much experience considering i'm the one who is developing the majority of nVidia's Shader demos right now ... it seems that you don't have much experience actually only going on the written text exclusively of what is going on, i've been part of the Cg development since its early stages march last year - and i know exactly how it is working.

there is no compliation apart from at runtime so that it is in machine code for direct use in the graphics card, they are used completely different though and there is far more difference between HLSL and Cg ... it makes me wonder if you've actually used either even slightly past looking at the syntax in the help.

you still need to code in the asm functions within HLSL, as it is hardly the same as Cg - because HLSL is a runtime version of ASM shaders there is zero difference, whereas the Cg is interfaced ... anyone who's ever even done the simplest of Shaders with them will know that because you also require different passive controls for sending and receiving the data you use.

in HLSL you'd do something like

#define vec4_Position 1.0,1.0,1.0,0.0
#define vec4_Normal 1.0,1.0,1.0

whereas in Cg you'd do

typedef vertex_t
{
vec4 position;
vec4 normal;
}

vertex_t Object=NULL;
Object.Position={1.0,1.0,1.0,1.0,},;
Object.Normal={1.0,1.0,1.0,};

in this mannor you can have multiple mesh on the go at once rather than a single mesh and you don't need to use preset names...
it is a completely different language and i'd suggest you take the time to learn it.

@Raven

"and Rob, use a View Matrix to get the veiw you want then use the Projection Matrix for the output - use a vs to then import the Veiw Matrix Data, Dot with the Light Vector, Then export to the Projection."

That wouldn't work. What he is asking for is refraction which is light being distorted like when a person stands in waist deep water their lower torso doesn't line up with their upper torso. You would need to calculate the refracted vector and you haven't done that.

@Rob K

"Have you any ideas how to do a refraction effect in an ASM shader?"

Ideas? Yes. A specific example in ASM? Sadly, no. I do, however, have a refraction shader in Cg that I borrowed from the Cg tutorial. It is possible to reverse engineer it but it would take me some time. If you want to give it a go here are the shaders.

The Vertex Shader:


The standard library routine "refract" is basically identical to this:


The etaRatio is basically the relative index of refraction. It determines the amount of distortion of light in a given material.
A general guideline for different material properties is:
Material Index of Refraction
Vacuum = 1.0
Water = 1.3333
Glass = 1.5
Plastic = 1.5
Diamond = 2.417

If your material is close to one of these then you could always use one of these values instead of the actual refraction value.

The Pixel Shader:


I don't know how great your knowledge of Cg is but these are the shaders which would create a refraction effect. I'm sorry it isn't in asm, but I couldn't find any shaders that were in asm and did refraction. In fact, I could find any refraction shaders except in my book. I didn't search long though so a more detailed search would probably turn up something.

If your coding skills are up to it you could possibly convert it too asm though it would take a lot of work. My brain is completely exhausted right now so I can't think of any thing else to say. If you have any questions just post'em and maybe later I'll be able to help when the mental fog that has descended on my mind has gone away.

I'll see if I can convert it into asm, a water shader for DBP would be really useful. That would be pretty difficult though. Anyhow, thanks for looking that info up for me

@Raven

"well that would be interesting saying i don't have much experience considering i'm the one who is developing the majority of nVidia's Shader demos right now "

Really?

there are 14 DirectX Shader Demos within the nVidia Cg SDK which are mine (^_^)
... and it would be simpler than pie to convert what Neo has nabbed (especially as there is actually an ASM vs.1.0 version which is mine incidently with that code being from my partner in crime, within the browser itself)

although yes its not just a simple case of take one matrix and projecting it across the object ... it is a simple case of a few dot production movements of the pixels and then using a standard wrap code to fit the surface - you flip the width and length of the vector used and you can create a nice fresnel effect

and before you ask i am currently tinkering with converting the entire demo to DBpro, along with another example i've worked on ... should prove useful - as long as people are willing to actually understand it rather than copy the code (cause you need to actually understand these effects to use them in any given situation)

and what bull exactly did i give you about DT and Alcohol, as i've never used Alcohol i've never said anything about it at all - only thing i have said about it was recently with the TZ Copy protection with it having a button that supports it to write. which is true.
as for DT you'll believe what you want ... i was just telling you an extra use for it, if you don't want to believe its there then thats upto you.

@Raven

You are referring to TZ 1.5.4, I was talking about TZEP 2. Looks like you were looking at completely the wrong software. TZEP 2 is completely different.

i don't really care, same difference to me not like i'm going to be using it - not sure why a later version would drop the support though.

Agghh! - (tearing hair out!)

The support is not dropped, I know that you aren't going to use it, but if you'd just even clicked on the link you'd have realised that they were two different things entirely.

Anyhow (calming down), this is O/T.

@Raven

"well that would be interesting saying i don't have much experience considering i'm the one who is developing the majority of nVidia's Shader demos right now "

HAHAHHAHAHAHAHAHAHAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAHHHAHAHAHAH
::wipes tears from eyes::
This coming from the guy who claims there is such a thing as vertex shader 1.2, 1.3, and 1.4! Priceless!

"... it seems that you don't have much experience actually only going on the written text exclusively of what is going on"

<sarcasm>Yes me correcting the pleathora of mistakes and outright lies you make does make me look like I don't know anything</sarcasm>

" i've been part of the Cg development since its early stages march last year"

I don't know why considering all the outrageous stuff you have said so far but I think I actually believe you on this one. Beats me why though.

"and i know exactly how it is working."

This on the other hand I don't believe.

"there is no compliation apart from at runtime so that it is in machine code for direct use in the graphics card"

Yes there is a compliation apart from at runtime. You can pre-comp your shader. Its not required but you can do it for both Cg and HLSL. I that I already showed you this.

" they are used completely different though and there is far more difference between HLSL and Cg"

Pop Quiz:
One of these examples is made in HLSL and one of these examples in made in Cg. Can you tell the difference?

ExampleOne:


ExampleTwo:


So tell me Raven what is this huge difference that I seem to be missing hmmm?

"it makes me wonder if you've actually used either even slightly past looking at the syntax in the help."

Funny. I was thinking the exact same thing about you.

"you still need to code in the asm functions within HLSL, as it is hardly the same as Cg "

You've never used HLSL have you.

"because HLSL is a runtime version of ASM shaders there is zero difference"

Thats news to me. Mind providing a link proving that HLSL is just a "runtime version of ASM Shaders"(i guess that pre-compile option for the vsa and psa compilers is just a figment of my imagination eh?). As to there being zero difference the only possible instance in which this would be true is when they are both compiled. But then there is zero difference between Cg,HLSL,and ASM then because they are all in object code.

"whereas the Cg is interfaced "

What do you mean by interfaced? Please clarify.

"anyone who's ever even done the simplest of Shaders with them will know that because you also require different passive controls for sending and receiving the data you use."

Huh? Different passive controls? Like what? Do you really expect me to believe this?

" in HLSL you'd do something like

#define vec4_Position 1.0,1.0,1.0,0.0
#define vec4_Normal 1.0,1.0,1.0

whereas in Cg you'd do

typedef vertex_t
{
vec4 position;
vec4 normal;
}

vertex_t Object=NULL;
Object.Position={1.0,1.0,1.0,1.0,},;
Object.Normal={1.0,1.0,1.0,};"

Actually both Cg and HLSL can use both of the methods that you used. I know that the cg compiler accepts #define statements and that HLSL uses output structures as well. So, once again, no they are not that different.

"in this mannor you can have multiple mesh on the go at once rather than a single mesh and you don't need to use preset names..."

How? There is nothing in your code that allows you to do that. The closest I can see to there being your ability to use multiple meshes would be with defining the vertex_t Object however you like but there is nothing there for you to declare it dynamically. Even then what difference would it make if you could? You aren't tesselateing the mesh or changing it in anyway so it isn't any different than you first left it. Maybe if you weren't lecturing me on how little I know you would see that you aren't so hot yourself.

"it is a completely different language and i'd suggest you take the time to learn it."

The irony.

@Rob K

"Anyhow, thanks for looking that info up for me "

Anytime.

@Raven

"there are 14 DirectX Shader Demos within the nVidia Cg SDK which are mine (^_^)"

Yeah. Right. Mine nameing which ones?

" and it would be simpler than pie to convert what Neo has nabbed"

If it is so simple then you wouldn't have any problem providing an example or two would you?

Somehow I don't think you'll be so forthcoming, but I'm prepared to be proven wrong.

"(especially as there is actually an ASM vs.1.0 version which is mine incidently with that code being from my partner in crime, within the browser itself) "

How can it be yours if it belongs to your partner in crime? And as for this ASM version why don't you show us it and quit beating around the bush. If you really developed it than that wouldn't be a problem would it?

"although yes its not just a simple case of take one matrix and projecting it across the object "

Then why did you say that it was?

"it is a simple case of a few dot production movements of the pixels and then using a standard wrap code to fit the surface - you flip the width and length of the vector used and you can create a nice fresnel effect "

No it isn't. I'm growing tried of correcting you Raven. It is clear you have never even looked upon the code to do a fresnal reflection. You brandish dot product this and dot product that around but what I wonder is do you even know what a dot product is? Do you know the mathematical formula behind it? I think you have seen enough lighting equations to know that a dot product is intergral to them, but I don't think you know why.

I have code for a fresnal reflection and I can tell you that it is not a simply case of a few dot product movements of the pixels(Which pixels? Where would you get them from?) and I have no idea where you came up with this flipping of the width and length of a vector. That is just bizarre. Where did you come up with this? Ughhh! Nevermind. You never answer that question anyway.

@Rob K

"Agghh! - (tearing hair out!)"

I feel your pain.

"there are 14 DirectX Shader Demos within the nVidia Cg SDK which are mine "

I'd quite like to know which ones too, unless it is a trade secret which conveniently you cannot reveal.

tell you what how about you guys just look at the source code, becuase programming is like a fingerprint. (that said try actually counting how many of the Cg ones are actually for Dx lol)

as for your examples, question is why do you not see a difference between the two language ... just because you can use Cg to mimic HLSL access doesn't mean it fits the other way.

you can have multiple vertex streams by importing them using the Cg interface or have you not yet read that deeply into them, obviously tha Tutorial book you have isn't too grand on them - but i wouldn't be surprised that it doesn't explain them properly.



you can use that to input several declarations
in 1.2 they're looking to upgrade this so that rather than a gap in the code from decl[length] to decl[stream,length]

the idea is to input a blank stream and then declare them in the shader as seperate steam data

as for the fresnel code it is created like so ->
dot product between the WorldSpace and VeiwSpace matrix
this give you your original reflection from the cameras perspective, you then normalise the WorldSpace and dot product it again against the normalised length, this gives you your refraction.
then square that because it would be too intense otherwise... (you don't want the refraction to be the same depth as the reflection)

now we can't use these as flat states... so what we do is we have to get the curvature from the eyes perspective so we make a temp register to hold this data, and we subtract the pov perspective matrix from the eye position - we then dot that length against the eye length to give a "fisheye" effect which will bend and textures to a surfaces length but as it is the effect would be too strong not only that it oftenly ends up as a negative value, so we Positive only Square the value to get the length we need on a positive value (otherwise it'd case a face flip) multiply this by the eye length which now gives you the blend value.

now to get this to conform just right all we have to do is find out the dot length of the eye and add it by itself then subtract from the eye length before multipling by the normal.

finally we mov all the values into the veiw matrix and we're done ... or we would be except for frensel effect
so we move a negative version of the dot of the eye by normal and we'll then be using that in the second reflection pass.

now multple the world space normal by the reflection constant (1.55 is the standard) and finally comes the second pass which adds the fresnel to the standard reflection refraction.

now this time what we're doing is replacing the Eye Length with the Vector position and the Normal by the Reflection Vector we just calculated ... this produces the final dot which we add to itself and then multipling and adding a negative version against the eye length. finally we export

couldn't be simpler

Is it absolutely necessary to do all of those steps?

well it isn't exactly a simple effect lol, i mean you're trying to recreate what people have done through raytrace maths for the past 20years ... just A-level maths really thankfully shaders make it alot simpler

if you want i could write it out as you would mathematically, you could then actually probably go about recreating in DBpro itself - but its not something that hasn't been done before, if i remember Shivan made a Raytrace Renderer within DB Standard which was pretty impressive

Shaders are a wonderful technology!

Don't you guys think that your time would be better spent actually coding them rather than having pissing contests about them on these boards?

@Raven

"tell you what how about you guys just look at the source code, becuase programming is like a fingerprint"

BS. You can't tell a thing from looking at source code who wrote it. Even if it were true shaders are too small for any real visiable difference in style to become apparent and on top of that I have never seen you code in C so I wouldn't know what your style was in the first place. Again, I reitirate, which of these demos are yours? And did you create them from scratch or were you handed a piece of paper and told "type this"? I find it more than a little hard to believe that you invented 14 directx shaders.

"as for your examples, question is why do you not see a difference between the two language "

Because there isn't any.

"... just because you can use Cg to mimic HLSL access doesn't mean it fits the other way."

Now here is where you slip up. My code made HLSL mimic Cg not the other way around. So you inadvertently just refuted you own premise. Remember it was you who used Cg like this:


And I who made HLSL look like this:


ExampleOne was the HLSL example. For proof why don't you take a stroll on over to MSDN here http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndrive/html/directx04152003.asp and scroll down a little ways. You'll find it under the paragraph title of As Simple As It Gets. ExampleTwo was, as you can now guess, made in Cg. You can find it in their Cg Toolkit download under(if you used the default installation path) /Program Files/NVidia corporation/cg/examples/ simple_dx8ps/dot_light. Since I was anticipating that you would deny that one was HLSL I used examples from sources where you could not deny the accuracy of the examples. I just didn't think you would mistake my HLSL example for Cg. It appears fortune favors the industrious. But, anyway...

"you can have multiple vertex streams by importing them using the Cg interface "

By "Cg interface" I'm assuming you mean the Cg runtime, no?

"or have you not yet read that deeply into them,"

If I knew what you ment by Cg interface I might be able to answer that question. "Interface" is obviously your word because I haven't heard it before with regards to Cg.

"obviously tha Tutorial book you have isn't too grand on them"

Obviously it isn't to grand on "them"(there is more than one interface? Why didn't you say "interfaces" then?) which leads me to suspect that "them" don't exsist or you mean something else.

" but i wouldn't be surprised that it doesn't explain them properly"

Ahhh. I see. So now it is a secret that only Raven and noone at Nvidia knows(The Cg Tutorial was written by the guys at NVidia).


"

you can use that to input several declarations in 1.2 they're looking to upgrade this so that rather than a gap in the code from decl[length] to decl[stream,length]

the idea is to input a blank stream and then declare them in the shader as seperate steam data "

Finally, I have figured out what you were referring to when you said "interface"! What you mean is the Cg runtime, which is what I thought you meant in the first place.

From the Cg runtime Help File:


The source of the confusion, it appears, stems from the fact that I'm arguing that Cg and HLSL the languages are almost identical and I am correct. You appear to be arguing that their implementations are part of the language and therefore vastly different.

Let me start off by saying that the Cg Runtime is not, nor will it ever be, part of the Cg language. Saying that is a part of the language is a lot like saying that the road is a part of the Car that drives on it. True, the road(in this case the runtime) is what the Car(Cg) runs on, but it is not a part of it. The Cg runtime was written in C++. NOT Cg. Therefore, while it may be used with Cg it is not a part of it and is therefore not really pertinent to this discussion. Even, if it was it wouldn't matter. In fact it would prove my point that the two languages are almost identical.

All you have to do is slap a ".cg" on the end of an HLSL file and you can use it with the Cg runtime. All the runtime is is an API(side note: It just occured to me why you were using the word "interface". API = application programmers interface. Doh! I didn't think of that because I have always heard the cg runtime refered to as well the cg runtime. That and every time I heard you say "interface" I thought you were talking about something you wrote in your shader like the uniform type qualifier or something.)that sits on top of a 3D API like DirectX 9 for example.

The Cg runtime utilizes the 3D api that it was built for. If you will check you will notice that there is a different Cg runtime for each 3D api. I think that it would be reasonable to conclude that anything Cg can do HLSL could as well since they both have to go through the same API in the end. This is in contrast to your previous statement that Cg somehow bypasses the 3D api and goes straight to the graphics card making it significantly faster(Which it doesn't). Anyone who used this "interface" would know that since the different builds for each 3d api are named something rather obvious like cgD3D8.dll or cgD3D9.dll. If Cg didn't utilize the 3D apis then why do these exist Raven? What would be the point?

Since they both must go through the same API, and both have almost identical syntax, Cg and HLSL are unarguablely quite similar if not identical. The only real difference, as I've stated before, is that Cg can be used with OpenGL via the Cg runtime for OpenGL or pre-compiled with the Cg compiler whereas HLSL is for DirectX only.

QED. End of Argument.

As for fresnal code...I'll get to that, and no doubt your subsequent posts, later. Right now I have a little late night coding to do.

@Yarbles

"Don't you guys think that your time would be better spent actually coding them rather than having pissing contests about them on these boards?"

No. Pissing contests are more fun.

But, seriously, this wouldn't be the first time me and Raven have butt heads over shaders and it probably won't be the last. Our "pissing contests" are actually pretty educational and I hope anyone who is reading this will learn a thing or two about shaders or at least be amused.

Well, I'm certainly finding it an interesting experience. I don't mind arguments where there is a lot of factual stuff on both sides too much.

@Neophyte

Late night coding never works for me. I'm fine until 11 PM, after that, all hell breaks loose

ya know i'm tired of trying to get you to see, firstly your posting examples which aren't identical sections of code and even so they're being done differently.

just because there are similar syntax they're still different and more importantly you can use then ALOT differently.
Cg is alot like Renderman Shaders Language - if you want to understand how that is used rather than how HLSL is used perhaps you might actually have a better grasp of what the languages does.

The Interface appliaction of language within C++ is JUST as important as the actual language code itself ... you're aruging that these are just runtime compilers but the fact of the matter is they don't compile on runtime unless you use that interface - and infact you have to compile all of your code anyway prior to use even if you're using ASM Shaders you're still compiling them first from ANSI to Machine - so your point about compiling them really is an entire misnomer wouldn't you agree?

it is clear you just won't accept how these things work, and you want to think in arcaic terms to thier implimentation - if you want to think like that then fair enough do that, you loose out on the performance increase and you also loose out on the depth the language is there to provide.

finally as for the code, i didn't just write the bloody shader files, although the Cg in themselves also have trademark hints to whomever wrote them - but i also wrote the C code that accompanies them with Robert James.
if you think that each persons coding styles is identical, and you can't tell them from how they code then christ you've never coded with another sole in your entire life have you?

have you even looked around the forums for programming or even around here to see how each person programs ... it is very oftenly a unique affair, just because on person made cose which looks similar to say Lee DBpro code - there are still things about it that will look unique.
This isn't just about programming but every god damn'd aspect in life, if someone repairs your car - a mechanic in the same garage would be able to tell you how did it and probably be able to tell if a problem happened because of it.

stop having you nose in the books all the bloody time and get some actual field experience, each time you post it does become more and more apparent you don't seem to have a clue what is going on your just taking from examples you see hoping that noone will notice you don't have a bloody clue, hoping that the text will back you up.

IT WON'T ... all your showing is you know howto read and take in overviews - my 5yo cusion can do that, doesn't mean he know howto use a language but he can repeat a manual quite well.

"Lee DBpro code"

I hope that he didn't code the examples. Some of them are a complete mess. Full of gotos and a weird objectno. system.

"get some actual field experience"

Isn't that slightly hypocritical Raven? - several times you have said how a certain DBP command works based on the manual, when in real life it works nothing like that.

i don't try the commands each patch
i started on Trial 1.00.0 and was using the Trials upto 1.03.0 - they seemed to work differently than the patched retail versions.

and yeah that code you see is mostly Lee's, hense the Author LB-DBS at the top of most of them. Your right they are a mess but hey thats obviously just his style, we all have our own styles.

But if that is how he codes in DB code... what about the DBP compiler (eek!)

Still, at least they are unifying it, which should make bug fixing easier.

OK, I see that another one of my topics has caused this argument again. And guess what, as far as I see noone has answered my question in the topic. And thats all I wanted to know, I read on http://www.darkbasicplanet.com/ that patch 5 was to use Direct X 9 features and was just hoping for some clarification if CG was going to be supported in DBPro.

@Raven

"ya know i'm tired of trying to get you to see,"

Same here only vice versa.

"firstly your posting examples which aren't identical sections of code"

I know that. Although I considered it, I figured that if I posted identical sections of code you would just say that they are both cg and not HLSL. I figuared if I used an example from microsoft and one from Nvidia you couldn't deny that they were accurate and are almost identical. Apparently I was being over optimistic.

"and even so they're being done differently."

No they aren't. Oh, yes, they do different things but their syntax is identical. Perhaps a little refresher will help jog your memory.
The HLSL code:


The Cg code:


Both of these have output stuctures and binding semantics like positon. Its just that my Cg example is one half of a lighting shader and my HLSL example is just a very simple test concept that doesn't really do anything of note. But perhaps I'm missing your elusive point. Please, why don't you point out to me out of these two examples what exactly is so different about them(syntax wise, I know one does more than the other, that much is painfully obvious). Heck, I'll even be nice to you and let you take another example from somewhere else and offer that as proof that Cg is "ALOT different" than HLSL.

"just because there are similar syntax they're still different"

This is getting ridculous. Look, if case you haven't figured it out already, the are basically the same. If you write a working shader in HLSL and try to compile it with the Cg compiler you will succeed. It is simple as that. They are not vastly different and you know that. If they were vastly different then you wouldn't be able to compile it.

"and more importantly you can use then ALOT differently."

There is nothing inherent in either language that allows it to be used in a way that the other language could not. HLSL code will compile in a Cg compiler and Cg code will compile in a HLSL compiler. HLSL code will work with the Cg runtime and Cg code will almost always work with DirectX 9 commands like D3DXAssembleShaderFromFile.

PROVE ME WRONG.

"Cg is alot like Renderman Shaders Language - if you want to understand how that is used rather than how HLSL is used perhaps you might actually have a better grasp of what the languages does."

In syntax they are alike but so is HLSL. Are you saying that Cg is a software shader language because that is what the Renderman Shading Language is? You can't be serious, can you?

"The Interface appliaction of language within C++ is JUST as important as the actual language code itself"

No, it isn't. You can use Cg without the Cg runtime as I've demonstrated before. As nice as the Cg runtime is, it is not by any strech of the imagination nescarry to use Cg.

"you're aruging that these are just runtime compilers "

Basically, yes they are. There is more too them then that, but that is there primary function and the purpose of there exsistence. If you don't believe me look at the reference I gave you to the Cg runtime help file. It explains it in there.

"but the fact of the matter is they don't compile on runtime unless you use that interface "

This isn't true. You can compile a Cg shader during runtime with the microsoft fxc compiler. Their syntax is bascially identical remember? What works in one will work in the other.

"and infact you have to compile all of your code anyway prior to use even if you're using ASM Shaders you're still compiling them first from ANSI to Machine "

I'm well aware of that. In fact I told you this before. Why are you repeating what I said? Oh and it can compile Unicode as well as ANSI.

"so your point about compiling them really is an entire misnomer wouldn't you agree?"

If I had any idea where your mad train of thought was going I could probably answer that question. How exactly is my point about compiling(where did I make this point?) them an entire "misnomer."
You are making little sense here.

"it is clear you just won't accept how these things work,"

The irony. It overwhelms me.

"and you want to think in arcaic terms to thier implimentation"

Huh? How am I thinking in archaic terms? How is the Cg runtime an Archaic term? How is the directx 9 API an Archaic term? I think you have this backwards.

"if you want to think like that then fair enough do that, "

Ok. Question is will you think that(ie Correctly)?

"you loose out on the performance increase"

What performance increase? As I have shown you before they both go through the API and Cg does not "directly access the hardware layer."
The only performance increase you will get is with the fp30 profile on Nvidia hardware. Remember how I always prefaced my comparisons of Cg to HLSL with "basically"? There is one major difference between the two to my knowledge and that is the support of the fixed data type. The fixed data type is exculsive to Nvidia hardware and is for their CineFX hardware fragment shaders. The microsoft fxc compiler doesn't support the fixed data type. So there you have it. Your alleged vast performace increase really only applies to 4th generation Nvidia hardware pixel shaders. Hardly something I would lose any sleep over if I were you.

"and you also loose out on the depth the language is there to provide."

What exactly is it that I'm doing that would make me miss out on the depth of the language hmmm? Or is this just some rhetorical device of yours? As far as I can see the "depth of the language" is exactly as deep as HLSL considering they are pretty much one and the same.

"finally as for the code, i didn't just write the bloody shader files,"

<sarcasm>Sure you did, Raven. I believe you.</sarcasm>

"although the Cg in themselves also have trademark hints to whomever wrote them "

Like what? Care to elaborate or are you just going to ignore this question like all of the other valid ones that I pose to you? Or maybe you are just stalling for time desperately trying to invent some distinction in the code where there is none. Funny, how you still haven't said which ones you wrote or given any reasonable method to determine their ownership.

"but i also wrote the C code that accompanies them with Robert James."

Ahh. A name. Finally we are getting somewhere. Sadly, you still haven't given me a way to determine if you wrote them or not.

"if you think that each persons coding styles is identical"

I never said that. Go back and read what I said. I said that a persons coding style is not a finger print. There are differences but there are also overlapping simularities as well. If you worked with another person on a large project there style might become appartent to you but it doesn't mean that if you line up a series of files that they will be able to determine the author with any sense of accurary. Programming languages are generally too restrictive in syntax to allow for any sense of "style" to become overly developed and apparent.

The exeception to this is with comments. Since comments aren't necessarily bound by any rules of grammer other that what it takes for the compiler to skip over them(with this I am refering to // or /* */ like in C or ; in ASM) an individualistic style can become apparrent. It is amazing what amusing comments or scatological references can do to the individiuality of a piece of code.

But, that aside, this exception doesn't really apply to shaders for they are not long enough or commented enough for any real stlye to become apparrent.

"and you can't tell them from how they code then christ you've never coded with another sole in your entire life have you?"

Now here you are correct. I have never coded with another person's shoe before in my life. But seriously, if this is so obvious to you then why don't you just point out the differences that seperate your code from your partners? You do recognize your own code don't you? If you do then you should have no trouble at all. I on the other hand have no Idea what your code looks like since I've never seen you code in C in my life.

"have you even looked around the forums for programming or even around here to see how each person programs "

Yes. Occasionally.

"it is very oftenly a unique affair,"

That is because DBPRO is using a basic syntax which allows for a lot of lee way with how you can code things. A C-style syntax, however, doesn't give you a whole lot of lee way and since we are talking about Cg this is a rather moot point.

"just because on person made cose which looks similar to say Lee DBpro code - there are still things about it that will look unique."

Unique. Yes. To that person alone? I think not. Still, it is nice that you finally recognize that there is some overlap between styles. It makes my next point easier to grasp. It is impossible to tell with any sense of accurarcy who coded a paticular piece of code. You may be able to narrow it down to a paticular pool of possible programmers but you will never know exactly. Programming is not a fingerprint! NO ONE has a completely 100% unique style. There is always someone somewhere who will have a style identical to theirs. It is just not possiable given the restrictions of the language to have a 100% unique style that you can tell from someone elses.

" This isn't just about programming but every god damn'd aspect in life,"

Since when did this become about "every god damn'd aspect in life"? And how would you know this?

"if someone repairs your car - a mechanic in the same garage would be able to tell you how did it and probably be able to tell if a problem happened because of it."

Keyword. Same. Accepting for a moment that this is true(which it might be in some cases but I can tell you for a fact that it isn't in all or even nearly the majority. In fact it probably only happens in rare instances and only with cetain kinds of repairs) how would I know what someone elses style was if I was not in the same "garage" so to speak? If you just took your car and got it fixed by one mechanic then showed the repair to another mechanic in another state do you really think he would be able to tell who repaired it? What makes your analogy even possiablely true is that the mechanics are in the same garage and have gotten to know how each other work. I am not in the same "garage" as you Raven so how would I know how you work like? Please answer this point before you make another affirmation that "programming is like a fingerprint" or something like that. You'll just be wasting both our times.

"stop having you nose in the books all the bloody time and get some actual field experience,"

So now I have my nose in books all the time, eh? Raven, you don't know a thing about me so don't pretend to. While we our on the topic of books, heres a thought, pick one up and actually learn the language. If you did that then you wouldn't be caught with your pants down trying defend some ridiculous notion you picked up off the net somewhere like "Vertex shaders 1.2,1.3,1.4."

Hearsay != Knowledge.

"each time you post it does become more and more apparent you don't seem to have a clue what is going on "

What exactly is it about my posts that makes it apparrent that i don't know what is going on? Is it when you prove how wrong I was about...oh...wait...you haven't actually proved me wrong yet on anything have you? Need I even list the number of misconceptions and falsehoods you posted to me that I proved wrong? The Sad part of all this is you just can't see the irony of you lecturing me on how little I know when it is I who has to correct YOU about YOUR misconceptions. Do yourself a favor Raven and take one big look at yourself before you begin to critize.

"your just taking from examples you see hoping that noone will notice you don't have a bloody clue,"

Where exactly did I take examples? Was it with the vertex shaders that were in Cg and HLSL? I took those for a reason and I already explained it to you. It was so you couldn't deny the accuracy of the examples. You have a habit of deny the crap out of anything I post to you Raven just like you are doing now. Not that you ever take examples and hope that nobody finds out you are bluffing *cough*directx 9 sdk help files and vertex shaders 1.2,1.3,1.4*cough*

"hoping that the text will back you up."

I don't hope. I know. Unless you would like to cite an example of text i provided that didn't back me up? No? Didn't think so.

"IT WON'T ... all your showing is you know howto read and take in overviews "

An excellent skill. Might I suggest you learn it? It would be less embarassing for you to be contradicted by the overviews all the time.

"my 5yo cusion can do that,"

So why can't you?

"doesn't mean he know howto use a language "

True. But he is 5 and I am most certainly not. My compacity to learn from said manuel and then apply the CORRECT knowledge is vastly superior.

"but he can repeat a manual quite well."

Good. Maybe he can read you this one.
http://developer.nvidia.com/view.asp?IO=cg_specification

@Elemenop

"OK, I see that another one of my topics has caused this argument again. And guess what, as far as I see noone has answered my question in the topic. And thats all I wanted to know, I read on http://www.darkbasicplanet.com/ that patch 5 was to use Direct X 9 features and was just hoping for some clarification if CG was going to be supported in DBPro."

Sorry for side tracking the thread but Raven just gets under my skin. Anyway, the answer to your question is that there is no answer. No one really knows(except for Lee or Mike) what will be in patch 5. I read that at darkbasicplanet as well but I would take it with a grain of salt. What I can tell you is that eventually those will be included. When, I don't know and I think that no one really does.

Personally, although I would really,really like to use Cg I would hate it if DBPRO switched over to DirectX 9 now. So few people have a graphics card capable of utilizing its features that that would utterly kill what chance small developers like me would have of getting a decent sized pool of potential customers. This would ruin my commerical plans and I am sad to say would force me to find another product to fit my needs. I think that considering the incrediabley small installed base of users who can utilize DX 9 fully(the cheapest graphics card that supports it is over $100 with the majority of cards in the $200 - $400 range) it would be safe to bet that directx 9 will not be in patch 5 or many of the people who use DBPro will no longer be able to test any of the apps that they develop on their computers.

So all I can say is take news about future patches that you hear with a grain of salt or if you really want to know email lee or mike about. Maybe they will tell you.

I hope this answers your questions.

I don't mind DirectX 9 in Patch 5, after all, the game will only require DX9 to be installed, it will not require DX9 specific graphics cards unless you use relevant features.

@Rob K

"I don't mind DirectX 9 in Patch 5, after all, the game will only require DX9 to be installed, it will not require DX9 specific graphics cards unless you use relevant features."

I hope your right else I'm screwed.

Getting a little fed up of all this, I sent an email to NVidia two days ago:

Here is an extract from their reply which I received this morning (email [email protected]):

"NVidia's Cg language and Microsoft's HLSL language are very close in terms of syntax. As for the compilers, they are identical in terms of function and purpose, however tests have shown that the Cg compiler has been able to produce better optimised code in many situations."

Obviously that last bit is slightly biased (no surprise there!).

It was tempting to ask them about their cheating in 3DMark03 - but I felt that that would have just meant by email being deleted.

Neo, run a CG and a HLSL you develop to do identical operations - lets say Phong Shading (as i know you can take both of those from both help files for Cg and the D3Dx) ... first try to compile HLSL in the Cg - it won't compile first time.

Second take screenshots of the results and tell me if they are the same or different.

ofcourse if you use the Create Shader From File function in DirectX using Cg it'll appear as HLSL, i mean i don't see how much more bloody daft a statement could've been made - and the point in compiling the code is so that it'll work AS HLSL without the interface. But again i suppose you know better than me about this eh.

Cg wasn't created to 100% replace HLSL, it was created as an alternative but rather than being a plugin language it is a COMPLETE language of its own heavily based around C and RSL. And yes RSL is a Software Shader Languages, Cg is a Hardware one because you can compile to ASM and use in OpenGL/DirectX or compile(convert) to HLSL and use in DirectX or use in standard Cg format which will run faster on nVidia based cards (for obvious reasons) but also give you Software abilities on other cards which do not support the advanced shaders...

so you use a Light Shader on a GeForce4 Ti 4800 or Radeon 9800pro and the Cg inteface will take over this because there is no Hardware detected and run through the CPU as a Software Shader.
HLSL will NOT do this, do does it even have the language to handle the Light/Time/Shadow Shaders.

not to mention the difference between Cg and HLSL is another fact that HLSL is 100% C++ whereas Cg can use both C & C++ programming means. and if you don't knwo the difference between C & C++ by now then i feel very sorry for you.

you want me to prove you wrong then you can quite frankly kiss my ass, because my little test if you run through it will actually have you proving YOURSELF wrong - which is think is far more satisfying.

n00b question, but what the hell is a "time" shader?

its a way of controlling the animation properties of other shaders.
effectively you could do something like a particle effect, which is 100% Shader driven with them ... which makes them bloody fast...

but you can also do some other such things with them like if you've seen C&C Generals - now if you play it on a GeForceFx you'll notice tha the explosions and Rocket effects looks pretty amazing right?

well thats due to time shaders, using 2 seperate pixel shaders with a single vertex shader so that it can billow out realistic smoke in a particle effect and the gradually over a given time blend one pixel shader to another so the smoke will go from white to black without loosing the billowing effect

there's a movie on the nVidia website called Truck which shows how they were used to make a truck rust and a weeds grow, etc... they are extremely useful - especially as they work independantly of the games timed events, and directly to the displayed pipeline ... so you don't get events which happen before or after when they're suppose to because of incorrect syncing.

"Neo, run a CG and a HLSL you develop to do identical operations - lets say Phong Shading (as i know you can take both of those from both help files for Cg and the D3Dx)"

Sure.

"... first try to compile HLSL in the Cg - it won't compile first time."

Yes it will. I noticed you said "first time." I take that it compiled a second time though didn't it? If you think you have found a HLSL shader that will compile under HLSL but not Cg then post it and remove all doubt. This will save both of us a lot of time.

"Second take screenshots of the results and tell me if they are the same or different."

They are the same.

"ofcourse if you use the Create Shader From File function in DirectX using Cg it'll appear as HLSL,"

And do you know why that is? It is because their syntax is near identical as I have been arguing all this time.

" i mean i don't see how much more bloody daft a statement could've been made "

What exactly is "bloody daft" about it? The fact that it is correct and that caught you off guard?

"and the point in compiling the code is so that it'll work AS HLSL without the interface."

Bingo. Now we are on the same page.

"But again i suppose you know better than me about this eh."

I'll let you be the judge of that.

"Cg wasn't created to 100% replace HLSL"

True.

"it was created as an alternative but rather than being a plugin language it is a COMPLETE language of its own "

Define "COMPLETE." If by complete in that it does exactly what it was suppose to do then yes it is "complete." Just like HLSL.

"heavily based around C and RSL."

And the PixelFlow Shading Language(1998) and the Standford Real-Time shading language(2001), but that is another topic.

"Cg is a Hardware one because you can compile to ASM and use in OpenGL/DirectX or compile(convert) to HLSL and use in DirectX or use in standard Cg format which will run faster on nVidia based cards (for obvious reasons)"

Now here is where you are gravely mistaken. Cg is never "compiled" into ASM or HLSL. These are just programming languages that do the exact same thing that Cg does so what would be the point? It is, however, compiled to machine code. I figured that was what you were saying when you said compile to ASM but then I noticed you say that it converts to HLSL or just stays in the Cg format(by this I'm assuming you mean a text file with a Cg shader on it?). It seems you are under the impression that Cg can be used in non-compiled(ie text) form. I don't know if that is what you mean for sure or you mean something else so instead of arguing a point which you may not even hold I'll just ask for clarification.

" but also give you Software abilities on other cards which do not support the advanced shaders..."

You mean like compiling your vertex shaders to vs_2_sw(pixel shaders to ps_2_sw) during runtime? So can Microsoft's fxc compiler for HLSL or do you mean something else?

" so you use a Light Shader on a GeForce4 Ti 4800 or Radeon 9800pro and the Cg inteface will take over this because there is no Hardware detected"

Aren't time shaders fully capable of being implemented on those cards? Why would no hardware be detected or are you just using these as examples because they are the first cards you thought of? Anyway, the Cg interface(aka runtime) doesn't have any functions that would allow it to do this.

"HLSL will NOT do this, do does it even have the language to handle the Light/Time/Shadow Shaders."

Huh? There are many examples on the web of light shaders written in HLSL as well as Shadow shaders. As for time I don't see why not since you can just pass the time variable to the shader from your application.

"not to mention the difference between Cg and HLSL is another fact that HLSL is 100% C++"

No, it isn't. Does HLSL have access to pointers? Since it doesn't then how can it be "100% C++"? You are forgeting that both Cg and HLSL are based on C/C++ but they are not completely bound by their syntax. Are semantics like DEPTH or COLOR in C/C++?

"whereas Cg can use both C & C++ programming means."

And this is different how from HLSL? Look, you obviously think their is some great big difference in syntax between Cg and HLSL so why don't you just post some code that proves this? If it is so manifestly obvious to you than you should have no trouble WHATSOEVER posting something anything to prove your point. God only knows how many times I've done this so why don't you put your money where your mouth is and show me something. Random assertions just aren't going to cut it and frankly I'm fed up with taking the time to show you examples of what I mean when you just dismiss them out of hand without a second thought.

"you want me to prove you wrong then you can quite frankly kiss my ass, because my little test if you run through it will actually have you proving YOURSELF wrong - which is think is far more satisfying."

Guess you won't be getting any satisfaction any time soon because I had no problem whatsoever compiling the code and running it. But, as I said before, why don't you post what you have so I can see for myself how "wrong" I allegedly am, because all of my tests work just fine.

As a parting note I'll leave you this to consider as I have other things to attend to:

http://www.nvidia.com/view.asp?IO=cg_faq