How to create graphics? Use GDI or DirectX?

[JFG]

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.)

[Gustav]

> 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.

[Farabi]

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 .

[JFG]

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?

[QvasiModo]

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. :)

[Farabi]

For 3D graphics maybe DirectX. I hope someday directX usage can be more simple.

[Mincho Georgiev]

Something interesting! :U

http://www.cprogramming.com/tutorial/openglvsdirectx.html

[Gustav]

> 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!

[JFG]

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.

[shaldan]

:) 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 :))

[Gustav]

> 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!

[JFG]

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.

[Gustav]

> 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.

[JFG]

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 . . .

"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

[rags]

"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: