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

When is the best time to learn vertex/pixel shading?

12 posts in this topic

Should I learn it early on (like on the early stages of a first game)? Or later (like mastered the DX fixed functions and have created some games)? Should I learn the assembly like way first then HLSL, or HLSL first then the assembly like way?
0

Share this post


Link to post
Share on other sites
I'd venture to say that its not worth going to a lot of trouble to learn fixed function (unless you require it), and it's definately not worth the trouble to learn the assembly shaders. Just learn HLSL or whatever equivalent.
0

Share this post


Link to post
Share on other sites
I agree. Learn to manage textures, blending/testing, Zbuff, stream ports, vertex formats, all things that carries to shading as well, then switch to shaders as soon as possible - it's just easier, espcially when it comes to lighting IMHO.
0

Share this post


Link to post
Share on other sites
Agreed.

In some ways, shaders are actually easier to learn than fixed-function graphics. There might be more actual work in shaders, but conceptually, I find them easier to deal with. You write code, which the GPU executes. That's a model a programmer should be familiar with at least. [wink]
There are no hidden tricks, no magic. You tell the GPU exactly what to do, and as long as you understand the math involved in putting triangles on the screen, you just have to code it.

On the other hand, the fixed-function pipeline is a big mystical black box you're never quite in control of. I found it a lot harder to actually get a feel for what was going on there.

But of course, ymmv.

Of course, the fact that the fixed function pipeline doesn't even *exist* in DX10 is a strong hint that Microsoft at least don't see a need for it *at all*, not even for beginners.

And I agree.
0

Share this post


Link to post
Share on other sites
I agree with the other posters. Learning fixed-function is waste of time honestly, there's nothing to be gained (in terms of learning or performance) from using it.
0

Share this post


Link to post
Share on other sites
when you're already trying to learn a brand new api, or possibly even just getting into 3D programming in general, stick with fixed function pipline at first, because it's easier.

but keep this in mind. DirectX 10, and the upcoming openGL(is it gonna be 2 or 3?) both do away with the fixed function pipline and rely solely on shaders, so it's getting to the point where you're not gonna have an option
0

Share this post


Link to post
Share on other sites
Interstingly enough, I started a project around a year ago and was the lead guy in the team. I worked on PR, team management, and was the 'shader guy'. At that time I probably couldn't program a simple mesh to render in DirectX. Really you can learn something like HLSL or GLSL before knowing how to implement it but you won't understand how it really interacts with the rest of your game until you implement them. At least thats how it was for me...
0

Share this post


Link to post
Share on other sites
Quote:
When is the best time to learn vertex/pixel shading?


The witching hour, hands down [wink]

Seriously though, as others have posted shaders are the way forward. I personally found shaders a big relief anyway, since you can just code whatever you want to do with your vertices and pixels instead of having to shoehorn everything into the fixed function pipeline. I'm a happy camper not having to mess around with the TextureStageStates anymore, for example.
0

Share this post


Link to post
Share on other sites
Thanks for your replies. That cleared enough things for me. So I did waste my time on creating some helper classes specifically for fixed function. Gotta start learning shaders.
0

Share this post


Link to post
Share on other sites
I'd use it just so long as you're learning how to feed some basic info INTO the FFP. I wouldn't learn texture stages and all that stuff. Learn the basics of one side of the pipeline, then the basics of shaders, then expand.
0

Share this post


Link to post
Share on other sites
Should I learn it early on (like on the early stages of a first game)? Or later (like mastered the DX fixed functions and have created some games)? Should I learn the assembly like way first then HLSL, or HLSL first then the assembly like way?
The challenge in graphics is understanding the math going on behind the scenes, not mastering any given API, whether DX, OGL, HLSL etc. Using shaders, or GPU acceleration in general, is just a matter of getting the same things done faster. The advice I have been given by my professor is to do everything on the CPU while you are figuring it out - keeping things simple and nice to debug - and move it to the GPU later if and when you actually need performance.

In short, I think messing with shaders is quite likely going too far into technical detail for a first game. Edited by Stroppy Katamari
0

Share this post


Link to post
Share on other sites
What does he mean when he says the "assembly way", I thought it was all HLSL?

HLSL is an easier (higher level) method of implementing shaders. Prior to HLSL you could just write GPU targeted assembly and assemble it the same way HLSL is compiled now. The assembly methods still exist and function correctly, but they don't really allow you to do much that HLSL doesn't unless you're really really into fiddling with individual registers and such. It's not even the same kind of assembly that you'd write for the CPU - it's a specific assembly language developed for use almost the same way that you'd use HLSL. In the end it's just a more complicated way of doing the exact same things. Edited by Khatharr
1

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