• 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
fanaticlatic

Fixed function and Shaders

7 posts in this topic

Hi all,

I was thinking too myself this afternoon (dangerous I know!) You only ever hear or see of one graphical rendering architecture being utilised on projects; either fixed function or more recently shaders. I am wondering if there is an overhead that prevents the mixing of fixed function and shader architectures being utilised by the same renderer, surely doing the simple lighting/bump map calculation using the fixed function stuff and utilising the shader architecture for the heavier stuff would provide some nice returns? The only downside I can see is the potential throttling of the gpu bandwidth or possible contention issues. Has anyone looked into this and have any interesting links to throw back?

Thanks in advance,

Hinchy.
0

Share this post


Link to post
Share on other sites
As far as I know, modern GPUs don't have any fixed-pipeline any longer (at least the parts which could be replaced by shader code). The driver use shaders to simulate them. So, no benefit from using the fixed pipeline over shaders.
2

Share this post


Link to post
Share on other sites
It's also much much cleaner to just use shaders for everything. The fixed pipeline is not actually simpler - by the time you set all your GL_COMBINE/SetTextureStageState modes you end up with a lot of code that doesn't actually clearly express the operation you're doing. Add in texture matrix ops or texcoord generation and you'll find that the fixed pipeline code starts going into pages (and with a lot of tricksy state change management) that could be expressed by a few simple lines of shader code.

Doom 3 mixed fixed pipeline with shaders and it needed to use an invariant position option in it's shaders because the calculations between the two modes didn't match. That removed it's ability to do interesting things like custom position transforms, or performance optimizations like GPU model animation.

There's also the small matter of the fixed pipeline not being exposed by modern APIs. D3D11 doesn't have it at all, and modern OpenGL won't (or at least shouldn't, unless you're using NVIDIA, in which case you're reducing the chances of your finished product working on other hardware) expose it in a core context.
1

Share this post


Link to post
Share on other sites
Yes I heard on the grapevine that the fixed function pipeline was effectively deprecated. It's interesting to hear id tried it with doom3. I'm looking into migrating away from fixed function for these very reasons. Had I found some more resources about the intermingling of fixed function and shaders I may have taken that approach but it looks fraught with dangers so it's more likely that i'll just rewrite the fixed function stuff as shaders.
0

Share this post


Link to post
Share on other sites
The last hardware to have the Fixed Function Pipeline (FFP), as replaced by shaders, was the GeForce FX (aka GeForce Fail) which had a hybrid FFP/Shader setup internal. The ATI card of the same time, the R300 aka 9700, was totally shader driven and wiped the floor with the GFFX.

The R300 was released in 2002.
The FFP has been dead in hardware for nearly 10 years now.

Forget it.
Move on, you are already 10 years behind.
1

Share this post


Link to post
Share on other sites
[quote name='phantom' timestamp='1328199616' post='4908750']
Forget it.
Move on, you are already 10 years behind.
[/quote]

The rigs we use are roughly the equivalent to your average desktop pc about 4/5 years ago. So we aren't doing anything bleeding edge lol. That being said the minute stuff starts getting deprecated it's time to pack up and "Move on" as you say. So I think my mind is made up on how I'll move the graphics engine forward. Thanks for the input and advice folks.

Hinchy.
0

Share this post


Link to post
Share on other sites
Even with 4/5 year old kit you're going to get fairly solid SM3 support (unless you're talking Intel graphics, where it'll be SM2 on the earlier 9xx series, SM3 otherwise) so you can confidently move on.

I've ported codebases from fixed to shaders a few times and it's not too hard; just a one-step-at-a-time job.
0

Share this post


Link to post
Share on other sites
[quote name='mhagain' timestamp='1328195275' post='4908723']
It's also much much cleaner to just use shaders for everything. The fixed pipeline is not actually simpler - by the time you set all your GL_COMBINE/SetTextureStageState modes you end up with a lot of code that doesn't actually clearly express the operation you're doing. Add in texture matrix ops or texcoord generation and you'll find that the fixed pipeline code starts going into pages (and with a lot of tricksy state change management) that could be expressed by a few simple lines of shader code.
[/quote]
I have to disagree on that, fixed function is actually way simpler, you can set the states of the FF pipeline the way you want, without any worry bout the rest of the states. with shaders, everyone tries to minimize the amount of states, often you pay with slower shaders that do redundant work, to avoid having a state, as you otherwise suffer from the well know shader-combination-explosion.
It's for sure easier to use shader, if you want to implement one specific effect e.g. SSAO, quite a straight forward c code, but if you implement the whole renderer for a game, you end up having "states", which are triggered by artist, game-code, assets,... and you translate those into some bitmasks to index a shaderDB. It's also in no way easier to maintain/debug, there can be tons of visual and technical bugs, that just become visible after an unexpected combination of your feature set. With FF, you have your states and you can easily imagin what happens in a specific setup, with shader flags, you need to make a capture and debug into the shader, and sometimes you figure out, it's a shader compiler bug, or a bug in the internal compiler in some driver... that wasn't really happening with hardware (except of prototype samples)

it makes of course no sense to use FF anymore, but it was simpler, my 2cents.
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