Is the best way to create a new viewport with a diff aspect(90 degree instead of fps aspect), and closer clipping, and the set the camera at a fixed location and all gui element locations are based upon that cameras location? I have used this in the past, I just want to make sure I am doing this efficiently since it involves going into another viewport, setting the camera and then resetting the viewport again every frame (game cam resets next frame before rendering - and gui is last rendered so there would be at least 2 camera sets per frame, 1 gui and 1 game/fps camera). Thanks. edit: I thought about it and realized I did not use viewports for gui, I actually just changed the perspective to 180 deg and set the camera to the orgin. after drawing, I would reset the perspective [Edited by - Valor Knight on April 17, 2006 3:45:50 PM]

You can always used pre-transformed points such that they do not go through any calculations before rendering. This is most likely the fastest way.

Quote:You can always used pre-transformed points such that they do not go through any calculations before rendering. This is most likely the fastest way.

is that really the fastest way? you'd have to use dynamic vertexbuffers and lock them everytime you move a window.

Using a Ortho projection matrix,giving every vertex an ID(which tells the vertexshader to which window(or gui element)) that vertex belongs and let the vertex shader move the windows seems faster to me

regards,
m4gnus

m4gnus,
I've never actually used pre-transformed points, but they have got to be the fastest. At worst, you would have to lock/update/unlock your vertex buffer, but only each time the size of the window changes (which should be never-ish). This method takes the least CPU time.

I typically keep my player's forward, up, and right vector which allows me to billboard GUI elements for free (just update the world matrix, no multiplication or vector functions necessary). This method is best for the GPU pipeline.

Using an ortho matrix is a pretty standard way to do it also, you just have to update the projection and world matrices.

A vertex shader is a good idea, but I wouldn't rely on any graphics card to support that, at least not for my GUI. Also, swapping in/out a vertex shader is the slowest render option to change. That will force the GPU to finish rendering before swapping the vertex buffer (i.e. the call to SetVertexShader or effect->Begin will block and wait until the current rendering is finished). The method is bad for the GPU pipeline.

Quote:
but only each time the size of the window changes (which should be never-ish).

and when it moves,right?

when i wrote my post i thought at windows style guis where changing a windows size and moving them around is necessary. But after some thinking on it i realised that i knew not one game that has a gui like this, so you're right untransformed vertices should be faster.

Quote:
A vertex shader is a good idea, but I wouldn't rely on any graphics card to support that,

even pre-shader hardware supports vertex-shaders(in software though) so that shouldn't be the problem.(i say shouldn't instead of is, because i don't know what the restrictions of vs 1.0 (or whatever version will be used for pre-shader HW) are and i'm too lazy to look it up)

regards,
m4gnus

I wrote my gui to use shader-instancing. All my guis can be resized, moved, changed color, without having to lock/unlock the vertexbuffers, and its done in very few render calls (usually just one).

I would recommend it, or better yet hardware instancing, if you can get away with it. Its not that unreasoanable, dx10 doesnt even support FFP.

Quote:Original post by Evil Steve
You just need to change the projection matrix to an orthogonal projection matrix instead of a perspective one.
See D3DXMatrixOrthoOffCenterLH.

So, I change the projection to an orthogonal matrix, draw the gui and then change back to a perspective one? I have not used orthogonal before, doe it automatically billboard and set the location of drawing at the origin, or are they where the camera is at? Or will I have to do that manually?

Im just starting with my gui, so I have not gotten to any instancing. Though I would love to do hardware instancing and shader colors so the gui can have static VB's, although I think dynamic vb's are a must for text drawing.

[Edited by - Valor Knight on April 17, 2006 3:29:44 PM]

What kind of UI are you talking about, one that scales with the resolution or one where the window size is in pixels (i.e., will look smaller at higher resolution)? In the former case, I'd suggest setting the world/view/projection matrices to identity and having all your coordinates in -1 to 1 space (or set any of these matrices to scale by (1/640, 1/480, 1) or whatever your UI's native resolution is). In the latter case, pre-transformed vertices are a good way to go.

If all UI elements are quads that share one texture, you can easily put them inside one vertex buffer. If they change you can lock it and change them. Don't worry about locking and performance. UI windows almost never move or resize (once the user has found a good configuration, it'd stay so for a long time), and when the user is interacting with a window a slight drop in FPS won't be noticeable anyway.

(The main optimisation you'll likely want to consider is for drawing text. This is often an issue with UIs -- at least, those with a considerable amount of text. Not rendering text each frame is a good idea.)