D3D/OpenGL shader thread. Reborn.

[mudlord88]

I got back to work on writing shaders via a hook DLL. Previously it worked on D3D9 only.

http://stashbox.org/1090200/Capture.JPG
http://stashbox.org/1090408/koolshock.JPG

Yes, my DLL now works in OpenGL now. So it should work on many more emulators.
However, recently on some forum, they started a XML format.

I am wondering how to get in contact with these people regarding this multi-pass XML shader format made on *some particular forum. I am interested in implementing such functionality into my hook DLL. However, who do I see regarding info on this format.

Thanks.

*PS: Please note I am banished for eternity from said forum, so don't ask about access to that one, because it most likely will never happen.

[Deathlike2]

Say whaaa? You're talking about some sort of parser involved there right? Wow...

[Thristian]

I'm "Screwtape" on byuu's forum, and I've been editing the XML Shader Format spec you're talking about. As I've mentioned in the original thread on that board, the spec now describes features from bsnes' original XML shader format (as implemented in bsnes, snes9x, and Themaister's SSNES), plus the basic multipass features that people were starting to add.

Themaister has already implemented support for XML shaders with multipass (plus some multipass shaders for testing with), If we can get a second, complete, interoperable implementation, I'm going to call that spec finalised, and if there's any more features people want we can start work on the next version of the spec.

If you (or anyone else) has any questions, or comments about places where the spec could be made more robust, or easier to implement, please let me know!

[mudlord88]

Okay, questions:

1) Does it really matter if we use FBOs? Why not plain textures in use being accessed directly in the shaders? Plus, from that, you get full NPOT textures. Not sure if you run into the same issues with NPOT FBOs. Current DLL uses full screen-size framebuffer textures to capture backbuffer content.
2) CgFX supports multiple passes directly in its format. Basically, which means...HLSL for OpenGL. With all the ease of use for multipass shaders like how Direct3D natively supports multiple passes. My question is, why wasn't CgFX considered? Because then, you are essentially reinventing the entire wheel for no real point at all with this format.
3) The format seems very bare for HLSL shaders. I noticed in there no mention of how multipass shaders are meant to be handled in there, not to mention no mention of scaling etc.
4) Will the spec ever include details for depth textures and the formats needed for those textures. This is vital for SSAO/HDAO and other depth buffer based shaders

[Thristian]

1) Does it really matter if we use FBOs? Why not plain textures in use being accessed directly in the shaders? Plus, from that, you get full NPOT textures. Not sure if you run into the same issues with NPOT FBOs. Current DLL uses full screen-size framebuffer textures to capture backbuffer content.

Existing single-pass shaders take the input texture and render it to the backbuffer; it seemed like FBOs were the easiest way to take existing "render a shader pass" code and put it into a loop to make multi-pass shaders. If there's some other way you can have GLSL multi-pass textures without having to add more sampler2D uniforms, then sure, you can use that. I don't care exactly what technology people use, as long the resulting program produces the same visual effect as a program that follows the spec, when rendering the same image with the same shader file.

2) CgFX supports multiple passes directly in its format. Basically, which means...HLSL for OpenGL. With all the ease of use for multipass shaders like how Direct3D natively supports multiple passes. My question is, why wasn't CgFX considered? Because then, you are essentially reinventing the entire wheel for no real point at all with this format.
3) The format seems very bare for HLSL shaders. I noticed in there no mention of how multipass shaders are meant to be handled in there, not to mention no mention of scaling etc.

The answers to these questions are related. Basically, I don't know much about Direct3D (or OpenGL for that matter, although I learned enough to support single-pass XML shaders), and when I started out researching what a multi-pass shader file format would need to do for HLSL, people said "Hey, HLSL already supports multi-pass shaders". So I figured the spec for HLSL should be "do whatever Direct3D needs you to do, to support a multi-pass shader". If there's more information that can be or needs to be supplied, I'm open to suggestions.

There's no explicit description of Cg shaders, because nobody offered to write Cg shader files or implement Cg support in a host application. I understand Cg is quite close to HLSL, though, so my first-draft spec for supporting Cg would be "<shader language='Cg'/> and put the source in a <source/> element" just like for HLSL. Again, if there's more information that can be or needs to be supplied, I'm happy to include it.

As for why GLSL is supported at all, my understanding is that you need to obtain a special binary-only library from nVidia to use Cg and ship it with your code. While I'm sure that's not much of a problem on Windows, where every app ships as a binary with a bundle of libraries anyway, it becomes clunky and awkward on most Linux distros. Since people want to write GLSL shaders to avoid the Cg dependecy, we might as well have a spec for them.

4) Will the spec ever include details for depth textures and the formats needed for those textures. This is vital for SSAO/HDAO and other depth buffer based shaders

As the spec mentions in the "Problem Description" section, it's really focussed on shaders for scaling up a 2D framebuffer, with various effects applied. SNES emulation was the original use-case, but I'm sure the same shaders would be useful for other console emulators, MAME, DOSBox, ScummVM, retro-styled games, even things like this. As such, I doubt the spec will ever be much good for geometry more complicated than a single textured quad unless (a) somebody explains to me what features such shader programs would actually need, and (b) it's possible to support those features without breaking existing shader files, or making the format less useful for its primary purpose.

[mudlord88]

Existing single-pass shaders take the input texture and render it to the backbuffer

I take it the shaders are written to be implementation independant? That way, they are not tied to specific framebuffer sizes. Last time I checked some shaders, some made some assumptions to do with the SNES, but that was a a while back.

I don't care exactly what technology people use, as long the resulting program produces the same visual effect as a program that follows the spec, when rendering the same image with the same shader file.

Sounds good, as I ran into limitations with using FBOs when hijacking the backbuffer and capturing to a texture. Using other methods solved this. Or maybe I should replicate render target usage like I did with the D3D portion, and just work out why for me FBOs won't correctly capture the needed info, with my current API hooking method....

Basically, I don't know much about Direct3D (or OpenGL for that matter, although I learned enough to support single-pass XML shaders), and when I started out researching what a multi-pass shader file format would need to do for HLSL, people said "Hey, HLSL already supports multi-pass shaders". So I figured the spec for HLSL should be "do whatever Direct3D needs you to do, to support a multi-pass shader". If there's more information that can be or needs to be supplied, I'm open to suggestions.

Fair enough. What I was saying is that the GLSL spec is more fleshed out. It had specific entries for different shaders in the same file, like for different passes. I was wondering for feature parity reasons, if the HLSL spec could be the same. Of course, you might have to avoid the niceties that HLSL offers with its native multipass support to have more control, like what you seem to do now with GLSL multipass.

There's no explicit description of Cg shaders, because nobody offered to write Cg shader files or implement Cg support in a host application. I understand Cg is quite close to HLSL, though, so my first-draft spec for supporting Cg would be "<shader language='Cg'/> and put the source in a <source/> element" just like for HLSL. Again, if there's more information that can be or needs to be supplied, I'm happy to include it.

I'd advise to read the Cg docs. Its code samples are quite nice, so its easy to comprehend. Its not like other docs where they make assumptions as to skill level with graphics programming. In its docs, it discusses the CgFX format, which is indeed very, very close to HLSL. So close in fact, you can avoid all the complex GLSL stuff for multipass, since Cg offers some functions to easily handle multipass like D3D does ( I am strongly considering porting my current shaders to CgFX so that my GL renderer can natively support my HLSL ones ). Last time I compiled some code for Cg, it didn't need extra DLLs. I know Themaister's SSNES supports Cg in Windows and it doesn't need extra libraries to be distributed.

As the spec mentions in the "Problem Description" section, it's really focussed on shaders for scaling up a 2D framebuffer, with various effects applied. SNES emulation was the original use-case, but I'm sure the same shaders would be useful for other console emulators, MAME, DOSBox, ScummVM, retro-styled games, even things like this. As such, I doubt the spec will ever be much good for geometry more complicated than a single textured quad unless (a) somebody explains to me what features such shader programs would actually need, and (b) it's possible to support those features without breaking existing shader files, or making the format less useful for its primary purpose.

Good point. Supporting depth textures won't break your current implementation, apart from a extra sample pass for depth in your render code for your 3D render code. That, and a extra sampler. And some tweaks to capture the depth info correctly. But yeah, for 2D, its utterly useless, for 3D though, you can do some pretty awesome shaders if you have the depth information sampled in a shader.


Oh yeh, forgot one major question: How resiliant must your XML parser be?

[mudlord88]

Say whaaa? You're talking about some sort of parser involved there right? Wow...

Yeah, you remember a while back I created a D3D9 shader hook DLL to infest your favourite emulator/game with fullscreen shaders?

Now I am revisiting it to add OpenGL support.
Now, since then, people have made a custom shader spec it seems to make it easier for developers to implement shaders into their applications. Since there is no common standard for such shaders for interoperability, it seems some people came up with the logical extension to make a agreed upon standards.

I am intrigued to add said shader parser, and said API to said DLL. Also, it is rewritten to hook much less of the APIs involved, which means code size wise, its much more efficient, BUT it involves much more convoluted API hooks. Such as using Detours to hook COM API based interfaces like Direct3D and to intercept OpenGL wgl/SwapBuffers() calls to append my own code to the host, to allow for said shaders in OpenGL.

Sadly, I know one application where this fails. Glide64's wrapper. The way it abuses things is so uncanny its not funny. Or it could be the Glide API is just weird in how you call functions. Or I messed up somewhere in capturing the original projection matrices and restoring them after rendering my fullscreen quads. Worked for the scene demo I tried since the coder there bothered to do things properly. And he didn't have to use Glide to make his demo.

Oh well: seems if you code your shit right, DLL seems to work fine with OGL. Otherwise, fail.

[Themaister]

If I understand it correctly, HLSL shaders won't need the multipass semantics. It should be possible to only have a single entity that does all the passes behind the scenes, given input/output parameters.
Neither me nor Screwtape have any real experience with D3D at the very least.

As for Cg there is something implemented at least out there, I worked on this before I implemented XML shader support in SSNES, and it's implemented in said emulator, Snes9x (PS3 port) and Snes9x (Win32, implemented by OV2). It is single pass oriented though, but the "spec" looks like this:
https://github.com/Themaister/Emulator- ... /Cg/README

If CgFX shaders can do multiple passes behind the scenes with the same uniforms interface (E.g. one simple .cg file), that could be an idea to have a look at.

[Thristian]

I take it the shaders are written to be implementation independant? That way, they are not tied to specific framebuffer sizes. Last time I checked some shaders, some made some assumptions to do with the SNES, but that was a a while back.

Well, it depends on the shader, of course - in the thread on the bsnes forum, I suggested (and Themaister implemented) a shader to do filtering specifically designed to address an oddity of SNES video output, and hunterk's "Scanline3x" shader really wants to be rendered at 3× the input scale, but I would expect most of the shaders we've collected so far to work for any kind of input image.

Fair enough. What I was saying is that the GLSL spec is more fleshed out. It had specific entries for different shaders in the same file, like for different passes. I was wondering for feature parity reasons, if the HLSL spec could be the same. Of course, you might have to avoid the niceties that HLSL offers with its native multipass support to have more control, like what you seem to do now with GLSL multipass. :)

The GLSL spec is definitely more fleshed out, because I better understand the problems that GLSL requires the spec to address. I'd love to have the HLSL side equally fleshed out, I just need to know what to write. :)

I'd advise to read the Cg docs. Its code samples are quite nice, so its easy to comprehend. :) Its not like other docs where they make assumptions as to skill level with graphics programming. In its docs, it discusses the CgFX format, which is indeed very, very close to HLSL.

Sounds like I should read the Cg docs anyway, just so I have a better idea what's up with HLSL.

Last time I compiled some code for Cg, it didn't need extra DLLs. I know Themaister's SSNES supports Cg in Windows and it doesn't need extra libraries to be distributed.

Hmm... interesting. I wonder how that works; static linking? Cg compiled to GLSL at build-time? I'd have been very surprised if, say, MesaGL on Linux were able to support Cg shaders without some kind of wrapper code.

Good point. Supporting depth textures won't break your current implementation, apart from a extra sample pass for depth in your render code for your 3D render code. That, and a extra sampler. And some tweaks to capture the depth info correctly. But yeah, for 2D, its utterly useless, for 3D though, you can do some pretty awesome shaders if you have the depth information sampled in a shader.

Fair enough. I'll read the Cg docs and see if I wind up with a better understanding of how this stuff might fit in.

Oh yeh, forgot one major question: How resiliant must your XML parser be?

Well, the idea is that XML makes for a nice wrapper format because properly-conformant XML parsers are easy to come by - every Linux box with a GUI should have libxml2 available, Windows has MSXML and XmlLite, and OS X has an XML parser in CoreFoundation, right beside the definition of data-types like "Array" and "Dictionary". So it shouldn't be difficult for even a portable program to have a bullet-proof XML parser.

That said, I know bsnes itself is using a hand-rolled subset-of-XML parser; I don't know exactly how much XML it supports, but if you look at the XML bsnes uses for shaders and cheats, it obviously supports elements, text, comments and CDATA sections. I've avoided adding features that would require more esoteric XML features like namespaces, because a spec that people won't implement is useless.

For the record, it seems SSNES uses libxml2 on both Linux and Windows, while Snes9x uses MSXML on Windows and libxml2 on Linux.

[Themaister]

I know Themaister's SSNES supports Cg in Windows and it doesn't need extra libraries to be distributed.

Huh? Really. Maybe the libraries/headers were included with your GFX drivers or something. I had to explicitly install it along with headers on my Win7 partition at least, and I have an nVidia card.

[mudlord88]

I know Themaister's SSNES supports Cg in Windows and it doesn't need extra libraries to be distributed.

Huh? Really. Maybe the libraries/headers were included with your GFX drivers or something. I had to explicitly install it along with headers on my Win7 partition at least, and I have an nVidia card.

Weird. When I compiled it into my DLL, it worked without having to place DLLs into the same spot as my hook.
Or maybe it detects the Cg install. Or something.

I might try under vbox under a isolated XP install and see what the deal is.

but I would expect most of the shaders we've collected so far to work for any kind of input image.

Excellent.

I'd love to have the HLSL side equally fleshed out, I just need to know what to write.

You need to:
A) get rid of the ruby* uniform names
B) fix the declarations for inverse types. Eg. uniform.z to uniform.w and vicaversa. I guess that was a mistake when I first did HLSL. And it kinda stuck there....
C) possibly add a sampler definition for the previous texture pass or for the initial pass. I seen DOLLS noted this, as my current shader implementation for HLSL does this via fullscreen render target textures (like FBOs in OpenGL). Of course, depending on your implementation you *might* lose MSAA
D) add a timer of some sort. For my water shaders, this was vital for them to even work. I used a uniform seeded with GetTickCount().

from there, HLSL should be pretty damn solid

Well, the idea is that XML makes for a nice wrapper format because properly-conformant XML parsers are easy to come by - every Linux box with a GUI should have libxml2 available, Windows has MSXML and XmlLite, and OS X has an XML parser in CoreFoundation, right beside the definition of data-types like "Array" and "Dictionary". So it shouldn't be difficult for even a portable program to have a bullet-proof XML parser.

I'll take a look at XmlLite. Hopefully its API is not as bad as some certain COM based interfaces.....

[kode54]

You may want to consider seeding a timer with something fed by QueryPerformanceCounter instead, even if you scale it to milliseconds first. GetTickCount will wrap around every 47 days of uptime, lawl.

[mudlord88]

Yes, haven't thought of that.
Will fix.

[mudlord88]

Example: http://www.youtube.com/watch?v=gai5yLqpg3U

[Thristian]

Sorry to take so long responding, work's been surprisingly busy.

I've still got the Cg docs open in a browser tab; I'll try to start chewing through it soon.

You need to:
A) get rid of the ruby* uniform names

Unfortunately, there's existing HLSL shaders (well, one, but people might have shaders they use that haven't been contributed to the official package) that use the ruby* uniform names, so I'd rather not change them if it can be avoided.

Likewise, the GLSL half of the spec uses ruby* uniform names, and of the implementations I know of (bsnes, SSNES, Snes9x/Windows, Snes9x/Linux), only bsnes actually uses byuu's "ruby" I/O kit.

B) fix the declarations for inverse types. Eg. uniform.z to uniform.w and vicaversa. I guess that was a mistake when I first did HLSL. And it kinda stuck there....

I'm not sure I understand - you mean the inverse values currently stored in .zw should be stored in .xy instead (and vice-versa)?

How would that be an improvement? Currently the .xy values match the vec2 uniforms used by GLSL, so at least it's consistent. If it wasn't for compatibility concerns, I'd have probably added a similar feature to the GLSL half of the spec, because nearly every shader I've seen uses those inverse valeus.

C) possibly add a sampler definition for the previous texture pass or for the initial pass. I seen DOLLS noted this, as my current shader implementation for HLSL does this via fullscreen render target textures (like FBOs in OpenGL). Of course, depending on your implementation you *might* lose MSAA

As I said to DOLLS, this seems a half-assed solution to what should really be a directed graph of shaders and render targets, and presumably a decent chunk more complex than the current linear render path. I'd like to get v1.1 of the spec done, and then we can talk about fancier things for 1.2.

D) add a timer of some sort. For my water shaders, this was vital for them to even work. I used a uniform seeded with GetTickCount().

It's in the 'next version' list, although if implementors are eager I guess I could sneak it into this version. I seem to recall Themaister wanted an integer frame-count rather than a floating-point seconds-elapsed value, perhaps you two could try and reach an agreement?

[mudlord88]

Unfortunately, there's existing HLSL shaders (well, one, but people might have shaders they use that haven't been contributed to the official package) that use the ruby* uniform names, so I'd rather not change them if it can be avoided.

Right, so they stay.

I'm not sure I understand - you mean the inverse values currently stored in .zw should be stored in .xy instead (and vice-versa)?

No, I meant inverse x should be in w and inverse y in z.

As I said to DOLLS, this seems a half-assed solution to what should really be a directed graph of shaders and render targets, and presumably a decent chunk more complex than the current linear render path.

Wait....we are meant to dumb down the render path to how it is now in OpenGL? Shucks. Elaborate on your approach then. ie: is it meant to be like what it is EXACTLY like in OpenGL currently? If so, that is incredibly stupid since there is already enough functionality in D3D's HLSL implementation to allow for easy multipass usage. Dumbing it down, or overcomplicating stuff is stupid. KISS.

It's in the 'next version' list, although if implementors are eager I guess I could sneak it into this version. I seem to recall Themaister wanted an integer frame-count rather than a floating-point seconds-elapsed value, perhaps you two could try and reach an agreement?

Right, good.

[Thristian]

No, I meant inverse x should be in w and inverse y in z.

Oh, you mean like this:

Code: Select all

float4 thingy = float4(x, y, 1.0/y, 1.0/x);

I'm curious, what's the advantage to this layout?

Wait....we are meant to dumb down the render path to how it is now in OpenGL? Shucks. :? Elaborate on your approach then. ie: is it meant to be like what it is EXACTLY like in OpenGL currently? If so, that is incredibly stupid since there is already enough functionality in D3D's HLSL implementation to allow for easy multipass usage. Dumbing it down, or overcomplicating stuff is stupid. KISS.

I guess I was thinking about OpenGL when I said that. I think it would be nice to have the same capabilities exposed for both shading languages; if HLSL is designed to work at a higher level of sophistication than GLSL, I guess we'd need to accept an imbalance, or uplift GLSL with extra markup, in the same way that we have <vertex> and <fragment> elements because GLSL doesn't support having them both in one translation unit.

So far, I've read through the Cg Language Reference, and made it about 10% (by page count) through the Cg User's Manual. I haven't seen any mention of multipass yet, but I do note that Cg explicitly allows the kinds of shortcuts that I see in GLSL shaders developed by people using nVidia cards. I guess that explains why nVidia's GLSL compiler accepts the same things.

[mudlord88]

I'm curious, what's the advantage to this layout?

No, I mean.

Code: Select all

float4 thingy = float4(x, y, 1.0/x, 1.0/y);

Advantage is obvious: logic.

So far, I've read through the Cg Language Reference, and made it about 10% (by page count) through the Cg User's Manual. I haven't seen any mention of multipass yet, but I do note that Cg explicitly allows the kinds of shortcuts that I see in GLSL shaders developed by people using nVidia cards. I guess that explains why nVidia's GLSL compiler accepts the same things.

Yeah, look up CgFX You'll see the multipass stuff.

[Thristian]

No, I mean.

Code: Select all

float4 thingy = float4(x, y, 1.0/x, 1.0/y);

OK, now I'm confused. Here's what the spec says now:

All parameters of type float4 must store the inverse of the values in their .xy property in their .zw property, like this:

Code: Select all

variable.z = 1.0 / variable.x;
variable.w = 1.0 / variable.y;

...which seems to be identical to what you're proposing, since the four components of a float4 are x, y, z and w.

Yeah, look up CgFX ;) You'll see the multipass stuff.

OK, yes, I've read through the "Introduction to CgFX" section of the Cg User's Manual, and it seems that CgFX is frustratingly almost-but-not-quite-exactly what we want.

On the upside, CgFX lets the shader author specify a bunch of render passes, a vector and fragment shader for each pass (like our GLSL <vertex> and <shader> elements) and some state (like point/linear texture filtering). On the downside, CgFX lets the shader-author specify all kinds of state that they possibly shouldn't be messing with (pretty much everything), it doesn't allow the author to specify the size of frame-buffer that each pass should be rendered into (and there's no obvious way to extend it to have that capability), and most annoying of all: if I read the syntax correctly, every shader program in a shader pass must specify what Cg profile to use when compiling, rather than letting the host application (or the Cg library) pick which ever profile is most appropriate for the available hardware.

So, I'm not sure what to do. I can't immediately see a simple way to bend CgFX to the specific application I have in mind (scaling 2D raster graphics on a textured quad), and it seems a shame to throw it all away and (as you put it) dumb Cg/HLSL down to GLSL's level.

Any suggestions?

[Themaister]

I've also had a look at CgFX as well, but I couldn't quite figure out how it was supposed to fit into the big picture.
If CgFX/HLSL can do multi-pass in the language itself, I believe the support actually isn't needed from the XML shader spec itself as far as I see it at least.

So ideally, we should be able to treat the multi-pass shader as a single normal shader, and just render as normal, and have it create all the magic. Does this make sense? With the current model implemented in ssnes at least, we have something like this:

Code: Select all

struct input // Pretty much ruby* uniforms.
{
    float2 input_size;
    float2 video_size;
    float2 output_size;
};

void main_vertex( uniform input IN, ... ) {}

float4 main_fragment( uniform input IN, ... ) : COLOR {}

This is single-pass though. How would it look with e.g. a two-pass CgFX shader? Can we use the same uniforms?

[mudlord88]

On the downside, CgFX lets the shader-author specify all kinds of state that they possibly shouldn't be messing with (pretty much everything), it doesn't allow the author to specify the size of frame-buffer that each pass should be rendered into

Indeed.

and most annoying of all: if I read the syntax correctly, every shader program in a shader pass must specify what Cg profile to use when compiling, rather than letting the host application (or the Cg library) pick which ever profile is most appropriate for the available hardware.

I hardly consider that a problem. Shader Model 3.0 is more than enough for NTSC filtering/whatever. Plus, most recent cards support up to SM5.0
I don't see that as a problem at all. Unless your video card's processing capabilities are shit (eg. GeForce FX).

So, I'm not sure what to do. I can't immediately see a simple way to bend CgFX to the specific application I have in mind (scaling 2D raster graphics on a textured quad), and it seems a shame to throw it all away and (as you put it) dumb Cg/HLSL down to GLSL's level.

Any suggestions?

You could just ignore Cg/HLSL for now, and focus on OpenGL. Besides, for you BSNES people, I thought cross platform abilities > ease of use of API/multiple pass shaders in API itself/saner syntax/speed anyway. :/

If CgFX/HLSL can do multi-pass in the language itself, I believe the support actually isn't needed from the XML shader spec itself as far as I see it at least.

Indeed, hence simplifying the specs.

This is single-pass though. How would it look with e.g. a two-pass CgFX shader? Can we use the same uniforms?

I'm sure annotations and stuff can be done in CgFX, like in HLSL. So, I think so.

[Themaister]

Read up some more on CgFX, starting to understand some more. I believe I misunderstood the "pass" part in CgFX/HLSL terms. It doesn't seem to do what the current XML shader spec does. At least not directly. I was under the impression that we could do a single draw_stuff(); once in our frame and have CgFX take care of FBO allocation at correct sizes, render the textures through many shaders after each other, etc. However, this is apparently not the case since it only handles texture state (we only care about GL_LINEAR or GL_NEAREST ...), and takes care of wrapping the passes up. Still is FBO handling + rendering logic needed, which is 90 % of the hard work anyways. You still have to iterate over the passes individually, and render them manually ;\ Lame.

As for annotations, CgFX also has it.

[mudlord88]

Goody.

I noticed this at that place:

Either that, or just the result of sleep deprivation. I'm away for easter holidays, so I don't have the originals to check - but please consider all shaders under the license posted here: viewtopic.php?p=33487#p33487

In regards to that, the end user is suggesting all shaders be under GPL. My HLSL shaders, like the ones you reused for Cg, etc., I FORBID to be in GPL.

They can be considered public domain, or AT LEAST a minimum of the ISC license. NOT GPL.

[Thristian]

He was talking about all the shaders in the .zip he'd uploaded (which were derived from GPL-licenced shaders from the XBMC project, I believe), not all shaders everywhere, so nothing to worry about.

Out of curiosity, which shaders in my archive are you responsible for?

I believe I misunderstood the "pass" part in CgFX/HLSL terms. It doesn't seem to do what the current XML shader spec does

For starters, it doesn't let you define the sizes of intermediate textures - although I guess you could define more uniforms (semantics, whatever) for that stuff. So you'd need a place to record that information, and a Direct3D/Cg equivalent to the "Performing multi-pass rendering" subsection that describes the algorithm for GLSL. We wouldn't need a Direct3D/Cg equivalent of the algorithm in "Building a list of shader passes from a shader file", because Cg (and I assume Direct3D) has API calls to extract that information from a CgFX file.

I hardly consider that a problem. Shader Model 3.0 is more than enough for NTSC filtering/whatever. Plus, most recent cards support up to SM5.0

Well, I thought part of the attraction of Cg was that you could write a shader that would work on OpenGL or Direct3D... and having to specify a Direct3D or GL profile in the CgFX file kind of shoots that in the foot. Of course, if you say 'to hell with Cg, let's stick with HLSL' then what you suggest sounds reasonable.

You could just ignore Cg/HLSL for now, and focus on OpenGL

Well, at the very least I'd like to document what needs to be done for existing HLSL shaders, and (as you mentioned) it seems a shame to spec out all these extra features for GLSL and leave HLSL high and dry.

On the other hand, despite (I assume) most bsnes users using the Direct3D video-driver, I think every single third-party shader posted to the board has been a GLSL shader, so maybe I should just ditch the Direct3D stuff after all.

[mudlord88]

Ah, none in that pack.
There was at least that bloom CG shader I seen. Which seemed to be a port of mine.
But yeah, since its not involved in anything BSNES related (I seen it in that nice Snes9x PS3 port), I'll forget about that, since you seem far nicer, and more reasonable than that **** twit
And yeah, I noticed in your VBA-M PS3 port you wanted some parts of VBA's API fixed up. Personally, I wanna redo the entire thing. I suppose the GBA portions can be salvaged, and the GB/GBC parts redone for accuracy at least.

Well, I thought part of the attraction of Cg was that you could write a shader that would work on OpenGL or Direct3D... and having to specify a Direct3D or GL profile in the CgFX file kind of shoots that in the foot.

Sadly, I didn't expect that either. I thought, "Wow! HLSL shaders under GLSL! YAY" and then this crap happens. v.v Oh well.

On the other hand, despite (I assume) most bsnes users using the Direct3D video-driver, I think every single third-party shader posted to the board has been a GLSL shader, so maybe I should just ditch the Direct3D stuff after all.

Yeah, since people seem to prefer GLSL, might as well just make D3D shaders obsolete. Besides, I thought now ATI has improved their GLSL support anyway.