Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


A couple of Vertex Shader Questions

This topic is 5202 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all, im having trouble decyphering the pants vertex shader example in the DX9 SDK, why do Microsoft have to use their framework! Anyhoo, i have a couple of questions: 1. Where exactly does the VS fit into an engine. I cant quite see how the VS knows which vertices its gonna be altering. 2. I find the best way to learn this stuff is from examples, not tutorials, the SDK exampe doesnt have a separate .VSH file so its tricky to figure out. Any links? 3. Am i right in saying that u could manually do the lighting of say a point light on an entire scene using a VS.Obviously programming the maths behind the lighting. I also havent found the tutorials on here much help cos theyre basically a programming manual with very little in the way of complete source which is what i''m after. Help appreciated, ace

Share this post

Link to post
Share on other sites
1. The VS takes the place of the T&L, or geometry, pipeline. Basically, anything that has to do with SetTransform(), D3DLIGHT9, D3DMATERIAL9, etc. The viewport transform is the first thing that happens after the VS.

2. There are a lot of SDK examples which use separate files. Look through them.

3. VS can do anything the fixed-function shader can do, and then some. So, yes.

The D3D framework is ideal for learning, because it lets you focus on the pertinent code instead of the whole mess.

If you want to play with shaders/effects by themselves, run EffectEdit and play around, or get RenderMonkey.

I like pie.

Share this post

Link to post
Share on other sites
1. When you call Draw*Primitive, the vertices are fed into whatever vertex shader is currently set, or the fixed function pipeline if none is set.

[edited by - Raloth on April 20, 2004 7:12:32 PM]

Share this post

Link to post
Share on other sites
Basic concepts of a typical game engine:

A game engine simulates a world according to some rules, and displays the results to the screen. The player manipulates the simulation using the input/controller device.

In the world, you have an environment, and entities moving around the environment.

The entities are controlled by the player, or by AI; that''s how they know how to move around.

The entities and environment have collision and trigger representations; that''s how they know not to fall through the floor.

The entities and environment have visible geometry with material description state; that''s how the renderer knows how to render a snapshot of the simulation world to screen.

The vertex shader, pixel shader, texture map bindings, constant values, framebuffer blending, and other material state used to render something is all part of the material description state. The actual location where you render the entity is extracted from the simulation, and potentially prettied up (say, by applying a running animation).

The location from where you render is typically extracted from a special world entity known as the camera; the rules for how the camera moves are often different from the rules of other things in the simulation.

To render something to a rendering device, you set transform and shading state, and you issue geometry to the device. The vertex shader is just one of many pieces of shading/transform state you can configure the device with before you issue the geometry.

Now, the real trick is to implement the simulation, AI, collision, control, and rendering pieces in a way that works well as an integrated system, yet makes good use of available resources, and optimizes for constraining factors (memory, geometry throughput, input controller latency, what have you).

However, that''s what takes 30 people 3 years to do these days -- to just write a game, you still need to implement these pieces, but you don''t need to implement them optimally. To just write a game, you need one of each kind of piece, but if you''re doing it on your own, your goal is to keep each of those pieces as small as possible, so you can actually finish.

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!