|
HLSL versus GLSL?
#275105 - 02/04/12 10:53 AM
|
|
|
What does HLSL do that GLSL doesn't?
I'd read recently about HLSL being "backported" to SDLMAME (R. Belmont said it, I think over on forums.bannister.org). I'm kinda confused about this statement because I'm not entirely clear about what HLSL exactly is.
Is HLSL simply the equivalent of GLSL- albeit slightly more integrated (and thus static)- for MAME running under Windows and Direct X (D3D)? Or is there something more to it? The HLSL FX files seem to loosely approximate some sort of shader, but there's a heck of a lot of stuff baked into d3dhlsl.c that would imply that HLSL is far more rigid then something like GLSL.
Is there some reason why GLSL isn't up to the task of replicating HLSL's high-quality effects? cgwg seems to be doing a damned fine job of replicating some of the functionality of HLSL in GLSL, though I've noticed he has seemed to have hit a few snags that basically boil down to missing functionality in MAME and not GLSL (ie, an easy way to get the screen direction, stuff like that).
Would it not be better to simply implement a method of loading GLSL options from an INI file (rather then defining them in the shader itself), as well as a series of other options/functions that are essentially MAME specific that shaders can use as convenience to implement certain effects (ie, I'm pretty sure phosphor persistence would require the shaders to have access to the current colour of the fragment, and that requires code in the program itself to pass that information down to the shader- at least that's how I've seen it done elsewhere)? Of course someone would still have to write the GLSL shaders to recreate the HLSL functionality, but I don't see that as being very different from the HLSL *.fx files MAME already distributes.
Basically, I'm just wondering why we need HLSL on SDLMAME. It seems like the functionally could be implemented by a series of GLSL shaders combined with some changes to the way MAME handles INI files (similar to how it handles hlsl.ini) and some internal bits and bobs to allow for fancy things like phosphor persistence?
-CMPX
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: HLSL versus GLSL?
[Re: CMPXCHG8B]
#275128 - 02/04/12 05:27 PM
|
|
|
Your significant confusion over the whole thing demonstrates precisely why I want to just port the HLSL effects and be done with it.
|
|
|
|
Re: HLSL versus GLSL?
[Re: R. Belmont]
#275143 - 02/04/12 08:23 PM
|
|
|
> Your significant confusion over the whole thing demonstrates precisely why I want to
> just port the HLSL effects and be done with it.
even without the 100 available parameters offered in HLSL code, I'd be already very happy if all the GLSL shaders authors & emu devs might agree on a common format for the shaders, so that some cartoonish shaders currently developed for BSNES/Kega could be used in MAME/MESS without the need to rewrite them in a slightly different language... 
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: HLSL versus GLSL?
[Re: etabeta]
#275144 - 02/04/12 08:28 PM
|
|
|
I abandonded "Firefox compatibility" with Windows baseline on this subject and I have paid dearly for it in confused and disappointed users such as the OP. I will not make that mistake again.
(Yes, I realize I had the feature first and they chose to ignore me, but either way the result's the same).
|
|
|
|
Re: HLSL versus GLSL?
[Re: R. Belmont]
#275176 - 02/05/12 06:35 AM
|
|
|
Care to inform a mere mortal as to what "Firefox compatibility" is, what your mistake was, who "they" are and what this has to do with HLSL and SDLMAME?
I'm aware of the arcade game with the same name and the browser. I can't find any mention of Firefox anywhere else in regards to MAME, and none of the commits in the MAME development repository mention Firefox in any other context then the arcade laserdisc game.
I should note that I'm not disappointed in the least. I'm more then happy with my totally unfiltered, nearest-neighbour upscaling (which apparently makes some people want to tear their eyeballs out). CRT emulation looked interesting because it gives the games a totally different feel, and HLSL's CRT emulation looked pretty damned impressive as far as CRT emulation goes. I was recently looking into implementing stuff like phosphor persistence in SDLMAME but I quickly realized this would require changes to SDLMAME itself in addition to a GLSL shader. That was when I read your forum post about porting it and figured "Well if it's being done by R. Belmont, why bother with my own patches?".
I just wanted to know what HLSL was- if it was just a built-in shader for Direct X, and why something like that would be preferred over a more modular approach using GLSL with option parsing similar to HLSL.ini under SDLMAME. Again, I have zero experience with Windows. I've been purely a Mac developer since OS 8. So Direct X is totally foreign territory for me.
Quote:
Your significant confusion over the whole thing demonstrates precisely why I want to just port the HLSL effects and be done with it.
Is someone preventing you from doing so? I'm really perturbed as to why your replies are as abrupt and ciphered as they are. It's almost as if replying to forum posts here is a job you're being forced to do (are you?) and we're all incompetent underlings who have absolutely no chance of ever comprehending your enlightened existance.
-CMPX
|
|
|
|
Re: HLSL versus GLSL?
[Re: CMPXCHG8B]
#275196 - 02/05/12 11:29 AM
|
|
|
Firefox compatibility - meaning that a program should have the exact same look and feel regardless of which system is being used, right down to the command line usage. If you're used to Firefox on Windows, you should feel right at home running Firefox on Linux, with practically no learning curve needed. The same goes with MAME. Install/unzip/compile, throw ROM images into ./roms dir, cd to mame dir and run "mame gamename" - just like Windows MAME and even old DOS builds before it. No messing about trying to relearn everything you've been used to for the past X amount of years.
|
|
|
|
Re: HLSL versus GLSL?
[Re: Heihachi_73]
#275200 - 02/05/12 12:07 PM
|
|
|
Huh.
Thanks for clearing that up. I've never heard of cross-platform feature parity being called "Firefox compatibility", but I suppose it makes sense.
I've been reading up on HLSL (which I see is part of the Direct X API much in the way GLSL is part of OpenGL). It appears as though the "HLSL" support in MAME isn't anything MAME specific (I thought perhaps it was a custom shader language implemented by MAME)- but rather a series of built-in settings that optionally source from an INI file and some code to load up the relevant HLSL shaders (*.fx files) into Direct3D.
So I suppose the equivalent to this, and the answer to my question (which may have been unclear) is that HLSL *is* GLSL, as far as SDLMAME is concerned. If one were to port the "HLSL" functionality from MAME under Windows to SDLMAME, then that functionality would exist as a series of GLSL shaders *and* the relevant code in MAME to read in the options and maintain as you say "Firefox Compatibility". The only real issue would be making sure that the GLSL equivalents achieve 99.5% the same thing under SDLMAME as they would under Windows given the same settings.
Question for R. Belmont, in case he rolls around again: Are you actively working on porting (converting?) the HLSL related code and shaders to SDLMAME? You sounded like you wanted to, but something was holding you back.
-CMPX
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: HLSL versus GLSL?
[Re: CMPXCHG8B]
#275285 - 02/06/12 03:21 AM
|
|
|
> Thanks for clearing that up. I've never heard of cross-platform feature parity being
> called "Firefox compatibility", but I suppose it makes sense.
The SDLMAME homepage has featured that terminology since I posted the first test version. I used that term heavily when the port was originally launched because it was a placeholder for an experience that a lot of people who frequently use Linux/BSD/OS X were already familiar with. It's probably a bit outdated given the rise of Chrome, which is even more fanatical about ignoring native look-and-feel than Firefox and MAME are ;-)
Also, it occurs to me that expecting people to have read said homepage given it's been over a year since you've had to go there to download the app is dumb. My bad.
> Question for R. Belmont, in case he rolls around again: Are you actively working on
> porting (converting?) the HLSL related code and shaders to SDLMAME? You sounded like
> you wanted to, but something was holding you back.
HLSL itself (the MAME feature) has been immature and fairly buggy until quite recently, and its author is now proposing a fairly major shakeup of MAME rendering on all platforms. Both of those mean that a "premature" port would be wasted effort, and in the meantime cgwg is doing a fantastic job with his GLSL CRT shader so that's taken away the immediate pressure.
|
|
|
|
Re: HLSL versus GLSL?
[Re: R. Belmont]
#275301 - 02/06/12 05:52 AM
|
|
|
> Also, it occurs to me that expecting people to have read said homepage given it's
> been over a year since you've had to go there to download the app is dumb. My bad.
I didn't even know that website existed >,>... I figured SDLMAME was just the OSD backend under src/osd/sdl for non-Wintel platforms and that was that. For some reason searching ""Firefox Compatibility" MAME" in Google (sans outermost quotes) doesn't bring that page up, so I had no idea what you were talking about.
> HLSL itself (the MAME feature) has been immature and fairly buggy until quite
> recently, and its author is now proposing a fairly major shakeup of MAME rendering on
> all platforms. Both of those mean that a "premature" port would be wasted effort, and
> in the meantime cgwg is doing a fantastic job with his GLSL CRT shader so that's
> taken away the immediate pressure.
Okay, thanks for the heads up.
Just out of curiosity, is there some place I can follow development on that regard (apart from git.redump.net)? Is Aaron Giles even the author you've mentioned (his name is on the header of d3dhlsl.c), or is it someone else?
-CMPX
|
|
|
Stiletto |
|
They're always after me Lucky ROMS!
|
|
|
|
|
|
Reged: 03/07/04
|
|
Posts: 6472
|
|
|
|
|
|
Send PM
|
|
|
Re: HLSL versus GLSL?
[Re: CMPXCHG8B]
#275305 - 02/06/12 06:17 AM
|
|
|
> Just out of curiosity, is there some place I can follow development on that regard
> (apart from git.redump.net)?
http://forums.bannister.org
The author infrequently posts under the name "Just Desserts"
He's had blogs before, but nothing regarding HLSL, usually other things like N64 emulation.
> Is Aaron Giles even the author you've mentioned (his
> name is on the header of d3dhlsl.c), or is it someone else?
Aaron is not the author.
See here:
http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Board=mamechat&Number=268929
He no longer has an account here (long story).
- Stiletto
|
|
|
Previous 
Index 
Next 
Threaded 
HLSL versus GLSL?
Reply
[Re: 
