Hi !
I've just begun learning directX, and I have a few questions :)
Some 6-7 years ago (before directx) I made a 3d-engine in asm+BPascal, for DOS.
It supported triangles, gouradshading, and textures. Now I haven't programmed almost anything since then,
but wanna to learn.

Now, after reading some tutorials on directX, I can't really make out what parts does directX handle, and what do you have to program by yourself ? Also what is supported by hardware ? And are there directX-routines that are slow, and should be avoided ?

I mean:
Im currently playing around with dx7, and there are blitfunctions, to blitt sprites from system memory to the primary surface. Like blt and bltfast, are those the best ones to use ?
When working with offscreen surfaces, should I place them in the video-memory or as system memory?

In 3d:
Is there some kind of hardware support for the matrix-calculations ? x,y,z- rotation ? If not, are the directX HEL versions good, or are they slow ?
Z-buffer, (i used to dream about those before ;) Is there any drawback useing Z-buffer to just using plain "depthsort + painters-algo", I mean, will graphicsdrawing become slower ?

Is it worth learning how to use mmx, 3dnow, SSE ?

Please tell me what i've missed !

Thanks!
//TechnoCore
Posted on 2003-01-06 15:57:36 by TechnoCore
A quick answer as I head out the door. DX will handle anything youu need to draw to the screen and there is a way to create your own buffer to draw directly. Not all functions are supported by the hardware but dx will handle most of the unsupported ones in software. You can query the hardware to find what's available. You can place objects in system or graphics memory but there are recommendations as to which to use when. MSDN has an article about that.

dx will handle vertices as rotated or unrotated and will rotate them for you if you wish.
Posted on 2003-01-06 17:52:01 by drhowarddrfine
Hi

DirectX handles video board initializations (mode setting,linear framebuffer,double or N buffering) acces to 2D surfaces and blit primitives (well up to DX7) and acces to 3D rendering pipeline T&L and pisel shaders (starting from DX8 Direct3D)

-You should avoid reading from video memory at all cost!
-Also keep video memory located surfaces Locked() as little as possible in 2D.
-Mixing 2D operations with 3D should also be avoided when possible or is almost imposible (without converting to simple mapped triangles/quads on DX>= 8) .

Take care at Pitch when working with surfaces! Surface Width <> Pitch Esp. for surfaces located into video memory. You can also loose and have to restore surfaces on Alt+Tab.

Place Primary and it's backbuffer(s) in video memory.

Any sprites that have space and that do not need complex operations (like read and/or alpha blending) just for simple blits...could also be placed in video memory.

NOTE! YOU CAN NOT do alpha blending (transparency not color key) with DirectDraw... you have to write your own optimized software routines . Check the board for some very good examples from Bitrake or Bazik if i recall ok

3D
---------
Some T&L boards will assist you on matrix and light calculations but basically you have to do your own matrix multiplications for most of the scenes.

Z-buffer is fast and well impllemented in DirectX/hardware ... works ok for small scenes... but you still need some form of space partitioning scheme for large scenes to avoid drawing and or sending vertices that will not be drawn to the board.

Knowledge is power ... if you plan using 3dNow and SSE they are good for 3d ...
MMX is supposed to be good for 2D but can not say that it helped us very much until now ...

You have missed: clippers/clipping, vertex and pixel shaders, BSP , texture mapping, physics :)
Posted on 2003-01-06 18:42:25 by BogdanOntanu
Hey thanks a lot BogdanOntanu !

Just what I needed...!

I have made a tile-based game-engine for starters. For now it's just plain dx7 2d, but im gonna make it into
dx3d soon... not that much will differ i guess, since i want an almost topdown view of the map.


>Knowledge is power ... if you plan using 3dNow and SSE they are good for 3d ...
>MMX is supposed to be good for 2D but can not say that it helped us very much until now ...

ok... guess ill get back to you when im gonna start optimizing ;)


>You have missed: clippers/clipping, vertex and pixel shaders, BSP , texture mapping, physics :)

When using clipping in 2d: right now im just doing the clipping myself, from the source-sprite to the screen, using bitbltfast. (Guess im gonna be better off using bitblt since it seems to be using the hardware). I've seen that it is possible to add a clipper to the primary surface maybe... is this good to use ? Is it optimized ?

What exactly is vertex shaders ? is that gourad ?
And pixel-shaders ? Is that phong-shading ?
I guess BSP is not really needed for a topdown gameview, right ? ;)


thank you, drhowarddrfinedrhoward for your quick reply also !

//TechnoCore !!
Posted on 2003-01-07 03:05:21 by TechnoCore


What exactly is vertex shaders ? is that gourad ?
And pixel-shaders ? Is that phong-shading ?
I guess BSP is not really needed for a topdown gameview, right ? ;)


(Psst, you other guys <Scronty, Bogdan, EvilHomer et al.> might want to correct me if I'm wrong...) In DX8 at least, vertex shaders do transformations from 3-d object projection through world, view, projection etc. transforms until it reaches the screen, and can also give a per-vertex manipulation of various sorts (e.g. different colors per vertex, different vertex tweens, geometry blending, etc.). Pixel shaders are the rendering shaders. For instance, by default DX8 uses a linear color interpolation from vertex to vertex, you might want to use a non-linear color interpolation so you create a programmed pixel shader. You might want to mix textures in different ways to create special effects, etc. using Programmed Pixel Shaders.


Anyway, as Bogdan mentioned, a very nasty thing about using a FULL-SCREEN mode (called EXCLUSIVE MODE in DX7 I think) is that if the user does Alt+Tab, you lose all resources that are in video memory (surfaces, textures, vertex buffers). So in general, after detecting a 'LOST DEVICE' condition (which is any condition that would cause you to lose FULL-SCREEN), you must continually wait until the device is restorable, then recreate all resources you need when you can restore (RESET) the device.

What I did was, since I have different screens in my program (and hence several different Render procedures) instead of a Call RenderRoutine, I have a Call DWORD PTR . Every time I need to change screens, I just change the to the proper render procedure. Then I have a macro (DetectLostDevice) which detects the lost device, place the macro in each render routine, and replaces the with a special render procedure. This special render waits for a restoration condition, then resets the device and restores any invalidated resources.
Posted on 2003-01-15 02:21:12 by AmkG