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
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.
gabor;
What ab0ut OpenGL? Ratch
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 (http://bieberworks.net/?page_id=4). 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.
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
::)
GDI is simpler, but less on the function. DirectX is complicated but more on the function. But I do choose GDI than the DirectX.
Tedd!
Thanks for the post. It really cleared and explained things!
Ratch!
Quote from: Ratch on September 22, 2005, 01:55:06 PM
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
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.
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.
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.
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]
Wow. I completely dont understand. By the way thanks for the code jeff.
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.
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.
Some words on the DirectX vs. OpenGL subject that has croped up in this topic:
Quote... 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.
Quote
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).
Quote
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.
QuoteIf 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.
Quote
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
QBRADQ, it seems some excess meaning was loaded onto my statements. I accept the idea that I was incorrect about OpenGL forcibly taking over the main loop (although through many frustrated attempts to find a means for avoiding that, I've never been able to find it). However, I did not say that choosing OpenGL is entirely pointless, being aware that the two libraries do take somewhat different approaches to doing what they do, and some people may prefer OpenGL's approach. Moreover, you neglect the fact of how business forces affect decision-making at graphics card OEMs; although OEMs obviously will not forget about providing good support for OpenGL interfaces, Microsoft's successful campaign at drawing flocks of newbie game developers towards DirectX means that there is still is an incentive in allocating greater resources for developing and maintaining the DirectX interfaces than the OpenGL interfaces. That (sadly, I might say) poses a greater likelihood that DirectX gets slightly better support. I will note too, however, that the difference there should be of minor effect, which I'm pretty sure I had already expressed implicitly. I also never said DirectX is an option on non-Windows platforms, but I will acknowledge that my statement that only wanting to code for other platforms could be the only reason to wan to use OpenGL may be a bit confusing. I should have used the word "might" instead of "could" for greater clarity. But anyway, if you're already going to be using DirectX for things other than graphics, you might as well use it for graphics too, at least if you want a bit more consistency. But anyway, thanks for the info on doing 2D graphics. I'm pretty sure I've seen OpenGL functions for merely doing blits, though I don't have the books in which I saw that, but perhaps you do. I was not aware of the GDI functionality for doing full-screen graphics though. (I suppose the MSDN 98 documentation deliberately leaves that out, as Microsoft documentation often leaves important stuff out, for the sake of promoting other stuff.)
> Really it's pretty much only if you want full-screen graphics that you're stuck with having to use DirectDraw
That's not true. Your window/display context can cover the entire screen. And you can easily change display resolution with GDI as well, using the EnumDisplaySettings/ChangeDisplaySettings API (exists since win95). You can even have a backbuffer, using the SwapBuffers API.
I can demonstrate full screen without GDI if you want. I will prepare it as soon as posible, but depend on my time and my codition :green .
Really? You need an API specifically for swapping back buffers? (Cool!! - a whole API dedicated solely for swapping the back buffer!!) I thought you just need the SetPixelFormat() function to create a back buffer that you can flip with the SwapBuffers() function, once you've drawn whatever 2D graphics you want to do using the glDrawPixels() function. (Uhh - actually, EnumDisplaySettings() and ChangeDisplaySettings() are functions, not APIs, and they are part of user32.dll, not gdi32.dll.) Anyway, I suppose you can just make your window hog the whole screen by making it maximized and top-most, and making it as big as the screen, the way that the Star Simulation program uses it, but then what did the Microsofties slaving away in their cubicles to down an endless stream of sodas make DirectX for? Of course we all know the vast majority of the DirectX API, as well as the majority of the rest of the code of Windows, is redundant, having never really been needed in any way in the first place any more than the many dozens of random software and hardware projects that get started, made, and then ditched there at Microsoft, and DirectX was really made so Bill Gates would have an excuse for which to gradually take over the City of Redmond and slowly creep into the adjacent City of Bellevue as well with not one - but two - absurdly overgrown Microsoft campuses, but look at the other side: DirectX is considerably more sophisticated - meaning in geek-speak that it is a lot more complicated and impractical to use - and as such, using it is like getting fake buck teeth and thick black-framed glasses when you don't even need any vision correction. It's the big dumb geek-statement thing! Get it?
Quote from: Tedd on September 26, 2005, 11:31:35 AM
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.
Not at all. Actually the whole point of DirectX is to bypass GDI entirely and get closer to hardware level - that's where the performance boost comes from. :)
For 3D graphics maybe DirectX. I hope someday directX usage can be more simple.
Something interesting! :U
http://www.cprogramming.com/tutorial/openglvsdirectx.html
> You need an API specifically for swapping back buffers?
> (Uhh - actually, EnumDisplaySettings() and ChangeDisplaySettings() are functions, not APIs
What is your problem with my usage of the word API. An API is any kind of software interface, so yes, a function *is* an API as well. Please don't waste our time with such remarkable stupid comments!
Gustav, you seem to have temper issues. Your expressed loss of composure was more than a bit uncalled for. Perhaps, like a few other people, you're allergic to corn - or something else you're eating. Or maybe you're allergic to alcohol?
FYI, API means "Application Programming Interface," which is not the same as a function. When people talk about APIs, they mean groups of related functions that are all used to handle a common type of thing. If they mean just a single function, then they just call it a function - not an API - because it is just a function. That's why people bothered to create the term API, and bother to use it, rather than using the term function instead. Get it? That's a big difference! It's a very big difference! And you should know it because if you don't, you could get some explanations scrambled. And that's always a bad thing - for any programmer.
:) let's make a competition ... lets make some pretty textured polygon object rotating in space using DirectX nebo openGL
and lets compare what is faster and more code readable.
As for me (very beginning beginner) I vote for openGl because its ASSEMBLY LINE filosophy is quite understandable even for me and i think it is suitable for assembler due to absence of objekt oriented programming.
Finding light in the myst of COM,HAL,HEL and such DirectX stuff is quite a challenge, especially in assembler (again, i am on the beginnig of my studies). And after reading some openGL tutorial (for example NeHe) i made quite quick rotating cube with texture of my favourite
(nude hehe) Czech actress to entertain my friends (if you want it, send an email to fx@slm.cz :) and what is the most important, I understand what i write and i "understand" what is behind it :).
dont kill yourself for words... assembler programmers are RRAAARREE animals indeed :))
> FYI, API means "Application Programming Interface," which is not the same as a function. When people talk about > APIs, they mean groups of related functions that are all used to handle a common type of thing. If they mean
> just a single function, then they just call it a function - not an API - because it is just a function. That's why people
> bothered to create the term API, and bother to use it, rather than using the term function instead. Get it? That's
> a big difference! It's a very big difference!
Please stop producing hot air!
To Gustav - You say I am producing hot air?? What truly useful and meaningful information have you produced? Get off your pointless grudge and grow up already. With your hissy fit, you're the one wasting space here.
Now back on the subject -
Well, sure. As a lot of people have said, using OpenGL or Direct3D really comes down to a matter of preference. Having been studying both, I find that Direct3D actually makes what I see as noteworthy procedural details a little simpler, although OpenGL does make things a little simpler too in general by not requiring the use of COM interfaces. OpenGL, I suppose I should note, also does provide a bit of an advantage by providing up-to-date support for what is referred to as retained mode. For those unfamiliar with this, the deal is that there are two modes of operation that OpenGL and Direct3D can work through: immediate mode, in which the code we write specifies to the graphics engine (be it OpenGL's or Direct3D's) the details about what to draw and how for each new frame of animation; and retained mode, in which we write code that composes batches of commands ("display lists") that the graphics engine can execute whenever we say so, thereby telling the graphics engine the details of what to draw and how. Immediate mode then is referred to as such because all information about scenes is always provided immediately before it is used, while retained mode is referred to as such because information about scenes is retained by the graphics engine for repeated use. Microsoft says that retained mode was essentially abandoned back at about DirectX version 3 because it just made things too complicated, although use of retained mode provides the potential for optimizing 3D engines if it allows for compiling display lists. Dropping continued development of retained mode at least in theory (that is, depending on how the graphics engine is designed) means dropping support for display list compilation of commands that support new functionality. Whether or not this would actually affect the performance of a graphics engine I should note is not certain because there are graphics engine optimizations that could be employed for doing a work-around to this, such as checking for repeated instances of commands and command sequences, and other somewhat more complicated engine-dependent tactics and strategies, although this still does provide some fodder for bets on which is the better pick. As I found however, OpenGL leaves a noteworthy disadvantage when it comes to making distributables because when we package software, we do not have a practical option of bundling it with up-to-date OpenGL graphics engines, while we do have the option of doing that with Direct3D engines. As hinted by the hardware requirements list for Doom3, getting support for software dependent on OpenGL in end-users' systems can require that end users go out of their way to get newer drivers for their graphics cards from their graphics cards' OEMs, which many people can find very tedious - and difficult (silly as that may seem). However, ensuring end-users' support for software dependent only on DirectX requires only that we bundle the newest version of DirectX with our software because Microsoft in that case does all the fishing for all the newest drivers. If we aim to make distributables with support for recently-added graphics card features - and many of us do - that is a major thing to consider. Still, as others keep pointing out, for those who don't have to mess with COM interfaces anyway for other aspects of DirectX, and have to use MASM, and do not aim to make such fancy distributables, using OpenGL does make a much better choice for the simplicity of its interface. So it does all depend on people's preferences.
> You say I am producing hot air?? What truly useful and meaningful information have you produced?
Well, I corrected a wrong statement by someone who claimed that DirectDraw is needed for a fullscreen app (it was possibly you who claimed that - I don't feel to reread your novels). And I did it in 1 or 2 short sentences.
To Gustav - I was referring to your last two bitter postings. And anyway, I would like to see a whole API made just for swapping buffers. I bet anything that Microsoft could make one - and make it very big and complicated too.
Now on the subject of using OpenGL, ah - would anybody happen to know how to get it to use a 3D accelerator? Direct3D 7.0 on my crash-happy Win98 computer uses a 12MB 3D Blaster Voodoo2 just fine, but OpenGL works like there's no 3D hardware installed. (There's a big one for my disenchantment with OpenGL.) I can't find anything available for the purpose of getting OpenGL to use 3D hardware, and there's no driver updates or such available from the OEM (Creative Labs); am I missing some Windows setup function here? I hope there's a solution, 'cause otherwise the situation is gonna remind me of . . .
Quote"Ma mule wouldn't walk in the mud - so I had to put seventeen bullets in it!" - Irish school custodian in The Simpsons, hitching a ride on Bart's school bus
Quote from: JFG on October 30, 2005, 09:09:26 PM
Quote"Ma mule wouldn't walk in the mud - so I had to put seventeen bullets in it!" - Irish school custodian in The Simpsons, hitching a ride on Bart's school bus
Actually I believe he is Scottish.... :cheekygreen: