Graphics Poll

I have been trying to figure out how to use Microsoft DirectX 8.0. I downloaded it from MS, but it seems like it is very 3D-oriented, and I am looking for 2D stuff.

I found a super-cool library called Fastgraph -- it costs money, but not much. A mere 299 US$ is nothing for a serious developer. I have used it before (for MS-DOS some years ago).

Now I am interested in hearing what you other people use. I am not starting a major long discussion with thousands of posts fighting out religious battles. My intention is to find out what you guys use and feel free to notify me (and others) of any graphics library you may be using (or know of).

Microsoft DirectX can be downloaded from www.microsoft.com

Fastgraph can be downloaded from www.fastgraph.com

GDI32.DLL can be downloaded from c:\windows\system\gdi32.dll

I use DX8, simply because I work mainly in 3d. If you are planning to work in 2d, you are probably better off using DX7. DX8 has pretty much removed the 2d component of the API, leaving 2d programmers pretty much stuck with polygons.

Z.

Thanks for the feedback. Appreciate it.

I use DX6, because it was on the CD of my game programming book (Tricks of the Windows Game Programming Gurus), and I don't see any need to upgrade to DX7. I also have DX8.1, but I don't use it since I somehow don't get the 3D stuff.

BTW, anyone know a site that explains the fundamentals of 3d (no code, just the system and terminology)

I mainly dabble in DX8/7, just seeing what neat things I can come up with.

Quote:

---

Originally posted by CornedBee
I use DX6, because it was on the CD of my game programming book (Tricks of the Windows Game Programming Gurus), and I don't see any need to upgrade to DX7. I also have DX8.1, but I don't use it since I somehow don't get the 3D stuff.

BTW, anyone know a site that explains the fundamentals of 3d (no code, just the system and terminology)

---

I don't get all that 3D-stuff either.

ALL of you: Thanks for your feedback.

CornedBee, what sort of things are you looking for? I can probably answer any questions that you have, so ask away =).

Z.

Fastgraph may have been good in DOS, but the windows version is absolute GARBAGE. I spent about 2 days playing with it, it's worthless. It requires you to run an external server application (think Graphics Server for the MS Chart control), and it also is just damned slow and outdated.

I mainly use Fury2GE (A graphics library I wrote), though I sometimes use DX7 along with it for extra speed. :)

A beta of Fury2GE can be downloaded at http://fury2.happyapathy.com/fury2/d...ds/fury2ge.exe , but it doesn't have any documentation... ^_^;;

It's a pure software graphics library with about 20 different blitters and a number of flexible effects, along with alpha channel support. It loads about ~20 different image formats and can save BMPs/PNGs and to a custom compressed format. I wrote it because I wanted to make my game engine run on any 32-bit version of windows (nt4, 95, me, xp, etc) without sacrificing features or writing piles of code for multiple versions of DX.

Also, for an alternative to fastgraph that is similar but probably better:
http://www.hicomponents.com/zzimageenocx.asp <- ImageEn OCX, has a LARGE array of features from what I understand, and some of my friends say it's cool, but I've never used it myself.

when it comes to doing graphics in VB, it's pretty much DX or nothing.

Zaei:
I need information how 3D graphics in general work, how to not loose orientation in a 3D area :), how to find out where to place and how to modify vertices and all that geometry stuff.

Without code is ok, C++ is better, but I don't know VB enough to do anything with it.

Vol. 2 of TofGPG comes out June, so until then I have to rely on the internet...

Its pretty simple, once you get going. You start at the origin, 0.0f, 0.0f, 0.0f (just about everything uses floats =). Once you know where you start, you can define vertices. The simplest visible vertes is defined as:

Code:

---

struct VERTEX {
    float x; float y; float z;
    unsigned long color;
};

---

Very simply, x, y, z coordinates, with a color. I usually use Y for up, but you can set this to anything you want. Then, to actually define your vertices, you need a buffer of some sort (D3D8 uses vertex buffers for speed, while OGL can use simple pointers). For simplicity, I will just use a pointer...

Code:

---

VERTEX* verts = new VERTEX[3];
verts[0].x = 0.0f; verts[0].y = 1.0f; verts[0].z = 0.0f; verts[0].color = 0x00ff0000;
verts[0].x = 0.5f; verts[0].y = 0.0f; verts[0].z = 0.0f; verts[0].color = 0x0000ff00;
verts[0].x = 0.0f; verts[0].y = 0.0f; verts[0].z = 0.5f; verts[0].color = 0x000000ff;

---

Now we have a triangle, sitting on the origin, with three different colored vertices.

At this point, you could send your triangle to whatever API you are using, be it D3D, OGL, or whatever. The API will then use matrices to transform your 3d triangle into 2d space. There are usually 3 matices used. The Projection matrix does that actual transformation. The View matrix defines your camera. The world matrix defines transformations that you can do on each triangle drawn. For instance, we could create a rotation matrix around the y axis, and apply it to the triangle, to make it spin. This rotation matrix is multiplied by the view matrix, which defines the camera (and the UP vector, as well), and finally by the projection matrix to create a final transformation matrix. This matrix is multiplied by the vertices to get the final screen coordinates. These are then passed to the rasterizer, which does that drawing. The D3DX library included with DX8 has a ton of matrix functions that you can use, for all three types.

That should be a fairly good base, though quick =). If you need anything, just ask =).

Z.

Thanks.
Do you know a page where matrix math is explained?

No, but if you do a search on google, you should find some stuff. Also, look on flipcode.com, I think that I saw something about matrices on there. If you want, I can post my matrix function library for you to take a look at.

Z.

I mostly use API, as I don't normally have good enough graphics to use DX7. I would use DX8, except that I don't know the formuals rotating, resizing, or moving objects in 3D space. I am currently in my 2nd semister of Geometry.

You dont have to know the forumlas. That is what the D3DX library matrix functions are for. You simply have to know how much you want to rotate, how much you want to resize, and where you want to move to.

Z.

Can you explain a little bit more about the functions (such as what the excate calls are for them)?

For D3D8, you can use the D3DX matrix functions:

Code:

---

D3DXMatrixPerspectiveFOVLH()
D3DXMatrixLookAtLH()
D3DXMatrixTranslation()
D3DXMatrixRotationX()
D3DXMatrixRotationY()
D3DXMatrixRotationZ()
D3DXMatrixScaling()

---

take a look in the SDK, either downloaded, or on the msdn website( msdn.microsoft.com/directx ).

Z.

I'll have to play around with it for a little bit, later.

Does anyone here know if MS is planning to support 2D in future versions of DX?

Quote:

---

Originally posted by Jotaf98
Does anyone here know if MS is planning to support 2D in future versions of DX?

---

I am not sure, but with Microsoft's latest move (that is; they "merged" their 2D and 3D in DX8), it seems to me that they want 2D and 3D in one and the same object. It doesn't look like they are going to split the two in a future version of DX.

I think it would be better to have a strictly 2D-oriented component, because I want that for some applications. I think the 3D is really cool and everything, but that doesn't make 2D uncool, does it? It depends on what you need, and I need 2D right now.

You can still implement 2d in 3d with DX8. It is doubtful that MS will split the two up, though. And, since you are now drawing with polygons, you get free alpha blending, sprite rotation, as well as hardware acceleration. You can easily create a wrapper to use almost exact DDraw commands, as well.

Z.

Quote:

---

Originally posted by Zaei
You can still implement 2d in 3d with DX8. It is doubtful that MS will split the two up, though. And, since you are now drawing with polygons, you get free alpha blending, sprite rotation, as well as hardware acceleration. You can easily create a wrapper to use almost exact DDraw commands, as well.

Z.

---

Sounds like extra work to me, but it might be worth a try.

Still, I think it's pointless, it would save a lot of processor power to just use regular blts like we have been doing all the time right?

Actually quite the reverse Jotaf - since we are now doing everything in hardware the strain on the CPU is diminished because we are using the Graphics Card...

That would actually be quite a cool project to try... hmm...

But Zaei, since you know about DX8 Graphics, is there a pixel plotting routine? I have no time to wade through senseless Microsoft drabble in their MSDN. It used to be useful but they only have now the newest things.

You can do back buffer locks, and write the pixels directly, but then you have to worry about bpp, etc. You can also create a vertex buffer using transformed vertices with a diffuse color, and plot the vertices with the D3DPT_POINTLIST flat. This will basically draw 1 pixel per vertex at the location specified, with the color speficied.

For standard Blts, most people use a standard transformed quad, two triangles in the shape of a square.

Z.

Hum sorry, what project?

Still, the graphcis card does a lot of unneeded calculations. And if the user doesn't have a good graphics card and it's rendered by the processor, it's gonna be a lot slower.

When using transformed and lit vertices, you specify the SCREEN location of the vertices, so no transformation calculations are done, and no lighting calculations are done. At that point, the only calculation going on is the texture mapping.

You can also optimize the process by not actually drawing on a Blt call, and saving the coordinates, etc. Then, when everything is bltted, stream the vertices into a vertex buffer, and draw that way (batching textures).

You also reduce the number of Blt calls, because textures can have an alpha component, so there is almost no need for bltting with a mask.

Z.

I have seen the alpha channel before, but I don't know what excatly it does. Can someone please let me know?

The alpha color defines how translucent a color is. An alpha of 255 is fully opaque, while 0 is fully transparent. Values in between are partially translucent. What thsi means is that when you load a texture, you can loop through each pixel in that texture, and find pixels of any color, and set its alpha value to 0, AT LOAD TIME, and whenever you use that texture, you wont see the pixels that you set to alpha 0.

Z.

Ok, thanks.

Meh. For 2D, I use Bitblting and load the pictures into the memory to speed it up. For 3D I use DX8. Simple really.

I'm still learning about both though.

Microsoft doesn't need to spilt the things

for 2D you have directX7, most hardware now supports a directdraw HAL (mine does). Everything you need

DirectX8 includes Directx7.

You can do 2D in DirectX8 anyway, yes it is harder, but it allows these 3d/2d combinations (like 2d blackgrounds and 3d objects or vice-versa which can look quite good) easier.

OK, it seems that most of you use the Windows GDI approach. That is what surprises me a little bit. I don't know why I thought DX would be a clear winner, I must have underestimated you guys.

GDI is the hacker-way (the roC++k-n-roll way), haha. More hard-core coders here than I thought.

Thanks for all the replies.

The GDI can only take you so far. It is a great starting place, but there is a point at which you will need to move up to something more.

Z.

GDI = hardcore?
No, actually DX is far more "hardcore" and roC++k'n'roll. You know, the more powerful and complicated, the more "hardcore".

Maybe in VB, GDI API calls are more complicated than the DX wrapper...

I would put mode 13h in the "hardcore" list, or a software 3d renderer, but not the GDI.

Z.

"hard-core" ... please don't focus on the word "hard" ... the real thing to notice is the word "core".

I agree that the HARDware-part of DX is HARD, but not CORE. The GDI is CORE, but not HARD.

Just playing with words :-)

But GDI isn't even CORE, it's a device independent wrapper (like DX, but even more abstract). I agree, Mode 13h would be HARD, CORE and HARDCORE. But it is only roCk'n'roll, not roC++k'n'roll. (BTW, neither is GDI)