Sign in to follow this  
blue-ice2002

fvf and perspective?

Recommended Posts

jollyjeffers    1570
If it's 2D you have two options:

1. Use regular geometry (D3DFVF_XYZ|D3DFVF_NORMAL|D3DFVF_TEX1 - maybe a D3DFVF_DIFFUSE if you don't need/want lighting) and set up an orthogonal projection matrix

2. Use whatever projection/perspective you like and have geometry that uses the D3DFVF_XYZRHW and then specify your positions in screenspace.

The second option might appear more "natural" as you're dealing with 2D coordinates on a 2D screen... but you can get the same results using orthogonal projection and have access to the full pipeline (and all attached features).

Is that what you wanted to know?
hth
Jack

Share this post


Link to post
Share on other sites
blue-ice2002    122


yes exactly,but in that point,if i use untransformed,i need to translate the vertices starting point to the upper-left of the screen,
or give it the real screen coordintates,the second case.

What is the major difference or drawback in choosing between two of them,or is there any other things i need to take into consideration?

Share this post


Link to post
Share on other sites
jollyjeffers    1570
Quote:
What is the major difference or drawback in choosing between two of them,or is there any other things i need to take into consideration?

Well it very much depends what you're doing... you can get pretty much the same results from either option.

Using orthogonal (hence untransformed positions) requires a bit more work, both setting it up and rendering... but you gain the advantage of having the full power of the pipeline. If you want to make use of either the fixed-function or programmable pipelines then this is the route for you.

However, if you want a dead-simple approach that you can probably have running in an hour or two that doesn't really need to do anything overly complex, then the _XYZRHW transformed geometry is probably your best bet.

hth
Jack

Share this post


Link to post
Share on other sites
blue-ice2002    122

i will write a tile-based turnbased strategy game with scrolling and zoom,also texture blending.
What would u say for these specifications?And do u need to make a huge vertex buffer that holds all the map,or just make one that is wide as the screen,i mean has the vertice count needed to fill the screen,and change the real data via another structure in real-time when rendering or?...

Share this post


Link to post
Share on other sites
jollyjeffers    1570
Quote:
Original post by blue-ice2002
i will write a tile-based turnbased strategy game with scrolling and zoom,also texture blending.

I'd recommend orthogonal projection because you can effectively get "free" zooming and camera movement by just changing a couple of matrices.


Quote:
Original post by blue-ice2002
do u need to make a huge vertex buffer that holds all the map,or just make one that is wide as the screen,i mean has the vertice count needed to fill the screen,and change the real data via another structure in real-time when rendering or?...

Is your data primarily static (e.g. load it from a file and then do little but draw it?) or are you planning on having dynamic modification (e.g. deformable terrain)?

There are a lot of variables to consider when choosing how you want to represent your world, but for most cases you should look at storing as much data in one or more vertex buffers ready for rendering. Modifying vertex buffers (e.g. recomputing the geometry that appears on screen each frame) can be expensive.

What you do want to be careful of, if you group everything into one huge VB, is the rendering calls you'll need to make - you don't really want to send your entire world to be rendered each frame, and you'll want some sort of culling system. Thus dividing the world up into blocks/cells/areas is a good idea. How you do this, again, has a few options.

As a rough idea... try cramming all of the unique vertex data into a VB, then divide it up into grids (e.g. 10x10) of triangles via an index buffer. You can then set your vertex data once (SetStreamSource()) and then just switch the IB's (SetIndices()) for each sector that is actually on screen.

hth
Jack

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