• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Nairou

HLSL vs Cg: Any significant difference?

15 posts in this topic

From what I understand so far, both HLSL and Cg accomplish exactly the same thing, and both are compiled into the same form of shader assembly code. Does this mean that, really, there is no significant difference between them? Can a shader implementation use the compiled code from either language identically, without regard to which language it was compiled from? If so, are HLSL and Cg nothing more than ways of making shaders easier to write, than actually adding features? If neither really adds anything new, why do we even have the two languages, as opposed to one? How different could they really be from each other?
0

Share this post


Link to post
Share on other sites
The reason they both exist is because they were brought out by two seperate companies. Cg was NVIDIA's creation; HLSL is Microsoft's.

NVIDIA have all but stopped supporting CG these days. Most people programming for Win32 use HLSL with DirectX; people on other platforms can use GLSL with OpenGL.
0

Share this post


Link to post
Share on other sites
The syntax of the two languages is nearly identical - most Cg code will compile with the HLSL compiler with minimal changes and vice-versa. Either compiler will generate more or less the same shader assembly for DirectX and the compiled shader code is independent of the language used to generate it. The difference lies in things like the constant tables - mapping shader input variables to constant registers will require different CPU side code for Cg and HLSL.

Microsoft and nVIDIA collaborated on the language design and development. The main reason Cg exists is that nVIDIA wanted to release it some time before HLSL was due to appear in DirectX and also wanted to support OpenGL and DirectX with the same language. At the time there was no GLSL and clearly MS weren't going to support HLSL for OpenGL.

The languages are 'nothing more than ways of making shaders easier to write' but don't understimate the value of that - C++ (and all other high level languages) is nothing more than a way of making assembly language easier to write but that doesn't make it useless. The reasons for the existence of both languages (really both variants of the same language) are historical / political and they're really not very different from each other.
0

Share this post


Link to post
Share on other sites
superpig: I thought CG development still go on. They released a beta version some weeks ago...
0

Share this post


Link to post
Share on other sites
Quote:
Original post by gjaegy
superpig: I thought CG development still go on. They released a beta version some weeks ago...
Really? They're certainly not making a big deal of it any more - they're more pushing their HLSL-based tools, like FX Composer.
0

Share this post


Link to post
Share on other sites
Awesome, thanks guys! That clears it up for me. I didn't know GLSL existed, thats good to know, I guess I'll just focus on HLSL then. :)
0

Share this post


Link to post
Share on other sites
Just to be sure: I think I read that old hardware supports Cg but not GLSL.

Is that correct? Does it make sense to support CG and GLSL in one engine then?
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Clueless
Is that correct? Does it make sense to support CG and GLSL in one engine then?


Personally I would just choose one and stick with it. GLSL requires a ARB_vertex_shader/ARB_fragment_shader level card--Cg can compile some Cg shaders down to a vp20/fp20 (NV register combiners) level card--of course I doubt you'll be able to compile all of your shaders to that level. At least I've had some problems with shaders that compile fine for the arbfp1 that don't like compiling for a GeForce 4.

But I digress--If you need support for older cards and/or API independance, go with Cg. Else use GLSL.

That's just my opinion, though. [smile]
0

Share this post


Link to post
Share on other sites
Correct me if I am wrong here, but for those who want to go for API independence, neither HLSL or GLSL is an appropriate choice, correct? Afterall, no one wants to write two different versions of the same shader for their game.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Correct me if I am wrong here, but for those who want to go for API independence, neither HLSL or GLSL is an appropriate choice, correct? Afterall, no one wants to write two different versions of the same shader for their game.


You are correct, HLSL and GLSL are specific to Direct3D and OpenGL, respectively. However, Cg (though being an almost indentical language as HLSL) has runtime bindings for both Direct3D and OpenGL--you can use the same shader code for either API with Cg.
0

Share this post


Link to post
Share on other sites
Originally when I had first started getting into shader languages I was really looking forward to using Cg, but then it looked like it was never getting updated. On top of that nVidia started releasing FX Composer (um.. ok?). It really didn't make sense to me. I'll be honest, this really feels like a situation where not only is there no right solution, but no good solution either.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Correct me if I am wrong here, but for those who want to go for API independence, neither HLSL or GLSL is an appropriate choice, correct? Afterall, no one wants to write two different versions of the same shader for their game.
That's a fair point. Though from what I understand, HLSL and GLSL are pretty similar - such that porting shaders from one to the other shouldn't be difficult. If you wanted to avoid porting altogether then Cg could well be a better bet.
0

Share this post


Link to post
Share on other sites
API independence is overrated. If you want to support non-Windows workstation/PC platforms (x86 Linux, Macs, maybe some other Unix flavours on x86, PowerPC, maybe even Itanium) then go with OpenGL and GLSL. If you are happy with just Windows support (and maybe easier porting to Microsoft console platforms) then go with Direct3D and HLSL. If you want to support other console platforms then there are no higher level shader languages or open APIs so the whole point is moot.

OpenGL is the closest thing to a cross platform graphics API there is. There's little point for most people in building an API independet renderer on top of it. Far better just to pick your API and get on with making your game.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by superpig
Quote:
Original post by gjaegy
superpig: I thought CG development still go on. They released a beta version some weeks ago...
Really? They're certainly not making a big deal of it any more - they're more pushing their HLSL-based tools, like FX Composer.


Cg and HLSL are pretty much the same language, except that nVidia's Cg has some extra facilities to support OpenGL. In fact, Cg and HLSL were both co-developed by Microsoft and nVidia. So while you might hear less about Cg and more about HLSL as time progresses, Cg lives on in DirectX with a different name.

FX Composer is both an HLSL and a Cg tool, because the shaders you write with FX Composer can still target OpenGL using the Cg Toolkit SDK. But for the most part, it's 99.9% compatible with HLSL... right down to the use of techniques and effects.

One problem that the Cg Toolkit SDK doesn't support that DirectX does is vertex and pixel fragment linking. This allows you to construct shaders from multiple fragments that implement different aspects of a complete shader. It's exposed through the CG/HLSL keywords "vertexfragment" and "pixelfragment". In DirectX, you link fragments together using ID3DXFragmentLinker or Microsoft.DirectX.Direct3D.FragmentLinker.

I've complained to nVidia about this, so hopefully they will get around to supporting it in their tools. They're currently accepting input from the development community on which direction people would like to see nVidia's development tools go.

While semantically, there are many similiarities between HLSL/Cg and GLSL, syntactically they are different languages. And afaik, GLSL does not support fragment linking in any form.

The GLSL or OpenGL Shading Language was pioneerd by 3DLabs in their OpenGL 2.0 proposal, which was mostly scrapped, as they originally proposed to make OpenGL an object-oriented C++ API. But as you may know, this isn't the case with the OpenGL 2.0 specification today. Yet, GLSL was accepted by the OpenGL ARB over Cg, which nVidia pushed hard.

ATI and Discreet are working on some tools for abstracting the underying shader architecture. ATI's Ashli technology can transform an HLSL, GLSL, or a RenderMan shader into an either a compiled HLSL or GLSL shader. Discreet has integrated Ashli into 3DS Max 7 and has add a transformation pipeline for converting 3DS Max materials into compiled HLSL or GLSL shaders.

However, after looking at it, I still thought that these technologies were rather immature, as they generated subpar code and there were no good user interfaces to control the transformation process. I expect it will improve over time though.

I'm not sure what Alias or SoftImage have in mind for their DCC toolsets.
0

Share this post


Link to post
Share on other sites
Now I'm a bit confused. Other than platform, whats the difference between HLSL and GLSL? I just assumed GLSL was OpenGL's way of using HLSL shaders.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Nairou
Now I'm a bit confused. Other than platform, whats the difference between HLSL and GLSL? I just assumed GLSL was OpenGL's way of using HLSL shaders.


GLSL is OpenGL's shading language (which is different than HLSL), which has recently been made part of the OpenGL core.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0