How to create graphics? Use GDI or DirectX?

[gabor]

Hello!


I've read several times about GDI and GDI+ and I've failed several times to find anything usefull about DirectX 2D. Is this not by accident so?

What do you know about these and what do you recommend to use for
- a simple sprite using project
or
- for a Win application that uses graphical representation for its objects (they can be bitmaps or custom controls)?

I'll study this GDI stuff, but I relly on your opinions too!

Greets, Gábor

[Tedd]

GDI is not DirectX. They are separate.
For 2D graphics in DirectX, you should actually use Direct3D with 'orthographic projection' (have a search for tutorials, infos, etc.) It used to be DirectDraw, but graphics cards have better support for 3D now, so directdraw was deprecated.

Making a sprite is as easy as making the polygon, mapping the sprite (as a texture) and then you can move the polygon as you like.
However, it is a bit of trouble to get started, and unless you have lots of sprites and want other effects that directx provides, using the gdi with bitmaps is usually good enough.

[Ratch]

gabor;
     What ab0ut OpenGL?  Ratch

[Bieb]

For your purposes, you'll be much better using GDI and avoiding the overhead and complication of DirectX.  GDI can be a little tricky to get the hang of, but DirectX is downright difficult to learn and use, particularly in Assembly.

Basically, GDI is just a set of Windows API functions you can use to draw graphics on the screen.  DirectX is a whole seperate library, that does graphics, input, sound, and networking.  Definately overkill for a simple sprite using project.

For the very basics of GDI, you can find a demo I wrote while I was learning how to use it here.  Just download "GDI Demo".  I used Easy Code for it.  If you don't have it, just open Window1.ecw in Notepad, and you'll find the code at the bottom.

[OceanJeff32]

I had the very same question: GDI or DIRECT X on my mind for a few years now, and it's still there!!!

Basically, my answer is this:

Windows GDI, hasn't changed much, so the MASM include files that support it, are still very up to date, and all the programming that I do with MASM for Windows GDI, works!

Direct X does not directly ship include files for assembly language with their sdk, THEY WRITE THE SDK IN ASSEMBLY using .DLLs and make life easier for C/C++ programmers.  I wish they made everything open source, but with the work involved in supporting all the graphics hardware, and then interfacing with windows, and the COM interfaces, it's a mess in C, let alone in ASSEMBLY...WINDOWS programming is bad enough... :lol

And besides that, Direct X changes faces and updates faster than you can say, MSDOS is gone....

But I do love both Windows GDI and Direct X, and haven't really considered other libraries or SDKs, but I've heard that NVidia's SDK is quite good...and a lot of people swear by Open GL.

Later,

Jeff C
::)

[Farabi]

GDI is simpler, but less on the function. DirectX is complicated but more on the function. But I do choose GDI than the DirectX.

[gabor]

Tedd!

Thanks for the post. It really cleared and explained things!

Ratch!

gabor;
     What ab0ut OpenGL?  Ratch

You are totally rigth! I should not have forgotten about OpenGL. The reason is that I lack the know how about OpenGL the most...Sad but true.

And thanks for the other posts too!

I guess I'll learn DirectX anyway (I got some experience in DSound already), so why not start with sprites...

About the 2. point of my original post:
Making a graphical representation of the objects of an application... No effects, no tricks, just bitmaps or controlls. Is it possible, that for this purpose neither GDI nor DirectX nor OpenGL is necesary, only the basic API calls for windows and custom controlls will succeed?

Greets, Gábor

[Tedd]

Any drawing operation (even just for controls) will have to go through the gdi :wink
API Functions such as SetPixel, LineTo, BitBlt, etc are all part of the gdi.

[hutch--]

The complexity of the task will determine what is best to use. GDI with a bit of practice is simple and well behaved for most display purposes but when the data become complex or must be fast, techniques like DirectX and OpenGL start to show their advantages. Don't be afraid to have a look at the OpenGL subforum as hitch is doing some good stuff there.

[Farabi]

I want to know what is the equivalent function with BitBlt on DirectX? And how fast if both compared?
I saw a directX demo for only drawing a shape 100 persen CPU Usage on a 2.4 Ghz machine with 60 FPS.
When I made a experiment before my memory burned, I can achieve 500 FPS on the same machine.

[OceanJeff32]

Oh Boy, it's been a while since I've done Direct X, but in the new Direct X 8.0 and 9.0 (I haven't seen anything since April of this year, when I stopped updating, or was it June?) ANYWAYS

The ID3DXSprite Interface, once exposed, allows you to load, transform, and display a wide variety of image styles (.jpg, .bmp, .png, .tga, and there are more)  I made a Breakout game with that interface last year.

Although, I did the programming in Visual C++ 6.0  I used just regular C, and learned about the COM interfaces to do it.

There are other ways to perform basic 2d Graphics with Direct X, such as mapping all your coordinates AS IF THEY WERE TRANSFORMED, I never figured that out, but it's supposedly very easy.

If I ever pick up direct x again I will look into it.

The following attachment is my breakout in C with Direct X 9.0b (remember 9.0b, the ID3DXSprite Interface changed after 9.0b, so that further revisions are not compatible.)

Later,

Jeff C
:U

[attachment deleted by admin]

[Farabi]

Wow. I completely dont understand. By the way thanks for the code jeff.

[JFG]

If you're going to do anything that requires windowed 2D graphics, go with GDI.  It doesn't matter if DirectDraw (the DirectX component for 2D graphics) works faster because GDI should still be able to give you a higher frame rate than what your monitor can display anyway, and certainly more than what your eyes are able to perceive.  (It's like:  Oh well if DirectX with high-end graphics acceleration can give you 600 frames-per-second compared to 450 or whatever with something else; you cannot see past 30 frames-per-second anyway!!)  Really it's pretty much only if you want full-screen graphics that you're stuck with having to use DirectDraw.  If you don't mind having to write all the code needed to get DirectDraw set up in your program, set the video mode, and do all the necessary and often neglected cleanup afterwards, you may decide that getting full-screen support is worth it.  (And no, DirectDraw never became Direct3D, and also, no, it did not get left behind by Microsoft.)

As for OpenGL, you conceivably could use it to do 2D graphics, but apparently all the documentation out there on it covers only use of OpenGL for 3D graphics, which you do not want to get into if all you care for is sprite animation in 2D, and then also apparently OpenGL forcibly requires you to let it take over the main loop in your program, rather than merely requiring that you call a few of its functions to do what you want it to do.  By now, choosing OpenGL is becoming rather pointless as well; since version 7, Direct3D (in "Immediate" mode) has become at least as practical to work with as OpenGL.  And since Windows dominates the computer industry, for pure economic reasons the big graphics OEMs put more focus now on getting their graphics cards supported through DirectX than through OpenGL.  If nothing else, that at least means you can expect to see less bugs if you use DirectX rather than OpenGL.  The only reason for which you could want to use OpenGL instead now would be wanting to make something for a non-Windows platform, except you're not supposed to do that with MASM.

That said, you might still want to hold off on DirectX if you really don't need it.  Accessing its functions requires use of COM interfaces, and although it's easy to learn what the deal with that is, putting together the include files you need to make use of those is quite a bit of busy work.  But then, for what you can get out of it, at least I figure it's worth the effort.  If you're interested now in doing stuff with sprites, you'll probably want to do more than just that later, so you may as well look into this too.

[Farabi]

Honestly I dont understand DirectX. You are right, our eyes cannot catch up to 60 hz frame rate. But I have prove using GDI is faster than directX. BTW have fun programming with directX. If directX is not good enough MS will not invent it.

[QBRADQ]

Some words on the DirectX vs. OpenGL subject that has croped up in this topic:

... apparently OpenGL forcibly requires you to let it take over the main loop in your program, rather than merely requiring that you call a few of its functions to do what you want it to do.

Not true! Simply not true. OpenGL is a procedural graphics library, and is leveraged just like any other library. Although it is typical of an OpenGL program to have a main rendering loop, this loop is hand coded by the application developer, and is typicaly a sub-loop of the main application loop. This is also not the only approach. In my C++ OpenGL appliations, I typicaly write a unified loop which calls update procedures for all objects, which take care of thier own drawing independantly.

I think this point of confusion may come from the fact that all rendering instructions must be contained within a call to glBeing() and glEnd(). These functions delimit a rendering procedure for OpenGL, however any application instruction may be executed between these calls. I won't go into further detail on this, but please be aware that OpenGL does not restrict the logic of your application in any way.

By now, choosing OpenGL is becoming rather pointless as well; since version 7, Direct3D (in "Immediate" mode) has become at least as practical to work with as OpenGL.

Just because Direct3D is as practical to work with as OpenGL does not diminish the usefulness of OpenGL. May people prefer one or the other for various reasons. Two often cited reasons for developers to choose OpenGL are that it is a state-based structured API (as opposed to DirectX's OO design), and OpenGL is a cross-platform, open standard (as opposed to DirectX's MS-Only approach).

And since Windows dominates the computer industry, for pure economic reasons the big graphics OEMs put more focus now on getting their graphics cards supported through DirectX than through OpenGL.

Again, this is simply not true. The OpenGL standard has continued to evolve and develop over the course of time. Even though Microsoft Windows only has native support for OpenGL 1.1 SAL and HAL (Software Abstraction Layer and Hardware Abstraction Layer), video card vendors continualy update thier drivers to support the latest OpenGL specifications (currently OpenGL 1.5). In addition, video card developers have continued to add support to thier cards for the wide array of OpenGL extensions, and continue to develop new extensions, such as in-hardware texture compression and paletization.

If nothing else, that at least means you can expect to see less bugs if you use DirectX rather than OpenGL.

Again, this is simply not ture. As an application developer, you will introduce bugs into your program no matter what API or language you use. That's just a part of the life. Similarly, video card manufactures will introduce bugs into thier hardware and drivers no matter what approach they may take. The frequency of bugs within a manufacture's equipment and drivers will continue to fluxuate over time, and has nothing to do with which API you are dealing with.

The only reason for which you could want to use OpenGL instead now would be wanting to make something for a non-Windows platform, except you're not supposed to do that with MASM.

Again, this is not ture. OpenGL and DirectX both have thier merits on the Windows platform. However, when it comes to cross-platform development, the differance is this: When developing for a non-windows platform, OpenGL is an option, DirectX is not.

The debate over OpenGL and DirectX has gone on since DirectX first came about. The main thing to keep in mind is, both have thier own merits. One should not close thier mind to any option, for this is the beginning of ingorance. May developers use OpenGL and DirectX in concert, as the play very well together. One quite recent example of this is id Software's Doom 3. It uses OpenGL for the rendering backbone, while leveraging DirectX for input and sound. Other libraries are leveraged for networking (Windows Sockets) and video streaming (unknown to the author).

Although I have never done a full game project, in my demos I use OpenGL for rendering, and DirectX for input. I don't personaly like the DirectX interface, however the input library (DirectInput) is far superiour to using the limited input support of OpenGL, and much faster and accurate than utilizing the Windows message system.

Also, a comment was made about being "stuck" with DirectX for full screen 2D rendering. Have a look at this post: http://www.masmforum.com/simple/index.php?topic=1013.0 . The provided demo provides an example of using GDI+ with MASM for full screen rendering. Although I don't understand the code very well, the results are very promising. It even dealt with a dual-monitor setup appropriotly (see my comments in that post).

Finaly, I would like to point out that although OpenGL does support some limited rasterization functionality, it is often used for "pesudo 2D" by using orthagonal projection. The advantages of this is that you can harness the power of the 3D rendering hardware to preform rotation, scaling, and alpha blending. Pharming these computations out to the GPU has odvious advantages. Additionaly, pixel and vertex shaders may also be loaded onto the GPU for advanced graphical effects, VRAM vertex lists may be utilized for static rendering, and all of the other optimizations afforded on a modern 3D accelerated video card.

(It is important to note that all of the things mentioned above can be accomplished with the Direct3D library as well.)

Well, there's my piece. Just remeber that DirectX and OpenGL are two very different libraries, both having thier merits and pitfalls.

What about the Twinky?
QBRADQ