Well I'm really interested in this, too - and I'm a bit bored right now...

so I'll just try to create a Deferred-Rendering-Shader xD

I'm pretty sure that I'm going to fail but I will try anyway.

Why don't you take a look at the source code of the one from the video?

Well... getting the normals and depth is pretty easy, but I still don't know how the lightss should be calculated with deferred rendering.
I already looked at a lot of websites but this didn't help me.

At the moment I'm using this:

[Color of the Pixel] = [Color] * ( ( [Distance to the Light] - [Lightrange] ) - [Difference between Pixel-Normal and Light-Direction] ) * [Light Color];

Works fine, but I think it isn't the right way to calculate this.


Another thing is, that I'm currently using vecSkill1 and vecSkill5 to give the Light information (RGB, Range, Position) to the shader.

Is there a way to read the Light information passed by the engine?

(EDIT: This might belong to the Shaders forum, sorry)

@Kartoffel
look for vecLightPos

Salud!

Problem is, as always, the degree of abstraction. You -can- write a rendering pipeline with awesome effects that is very closed (efficient and very well coded for the particular tasks, but hard to extend) and you can write the same rendering pipeline with the same effects but modular and open. This can result, though, into slightly inefficiencies if it is not well written. So, the design of the framework is the most interesing aspect in such an attempt.

So, lets face it: I am actually going to write me my own rendering pipeline for my next game. I will do it like this: I will write down what effects I -really- need and what not and what quality and what techniques I will use. Then, the whole architecture and wiring will be sketched on paper. After everything is thought through, I'll do a straight implementation. Thats it. I get what I need for no additional costs (hopefully ).

If you write a general purpose rendering pipeline instead, you always have to ask "what does the user possibly want to do?". Answers to these questions are broad and sometimes hard to find. Consider, that the rendering requirements of a game like Crysis are totally different to what you have to do for a game like Portal or Age of Empires 3. Plus, sometimes users don't want an effect and disabling it should release some resource of course. E.g. if you don't want to use DOF, you should'nt allocate the render targets for them and you shouldn't compile shaders for them and so on. If you e.g. also don't have any postprocessing effects enabled that need a depth view, then you should'nt render the scene again for it. And what if the user has much vegetation and uses e.g. alpha-to-coverage - how is this treated in the depth view and how is it treated if the user disables this and uses only cutout (binary) alpha??? And what happens if I disable certain features and could put two MRTs into one, just because that the disabling disabled 2 outputs in the first MRT and 3 in the second? How is this treated, is this treated, should it be treated??? These are just basic questions, but very hard to answers, let alone that somehow has to code it.

It is very hard to create a rendering pipeline like this. That is why each (good) game uses it's own pipeline.

So, if we ask each user "what do you basically need for a game" and the user is honest and doesn't add things he saw in a latest tech demo or something, we will get a HUGE list of things which might be compilable into one unified rendering pipeline - or not. Well, I guess the latter.

[EDIT]

The estimation from Slin, btw, is, as he said, relatively free and totally depends on what you need. But you can count 10-20 Eur as standard price per hour. It just depends on the complexity of the task and the versatility you need, as I said.

Old? Yeah, its SDK tools are, but not the engine itself. Bad? I don't think so, mate. Every engine has its pros and cons, Source has great networking system, a nice console and its games are moddable, at the cost of being a bitch to use.

Source gets updated, but the core is old.

So is GameStudio's

Yeah, but with one "correction", Game Studio doesn't get updated so often

To be honest this is why I love Source, you can still find early bits of Quake code in it