Sign in to follow this  

Which 2D API?

This topic is 4745 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

What is the current API of choice for doing purely 2D graphics? All I need to do is be able to plot individual pixels in a window, clearly as quickly as possible. I don't need blending or any other fancy effects. The window to be drawn to however must be a standard Windows one, with a title bar and menus etc. So, my options appear to be: i) GDI - Surely this will be too slow? ii) Directdraw - Is this too old? If so, is it thus too slow on modern cards? iii) SDL - Can this draw to a standard window, or does it need its own window (a la GLUT, for example) iv) Direct3D/OpenGL and a single textured quad - is this overkill? Thanks for your input

Share this post


Link to post
Share on other sites
Quote:
Original post by bakery2k1
i) GDI - Surely this will be too slow?
ii) Directdraw - Is this too old? If so, is it thus too slow on modern cards?
iii) SDL - Can this draw to a standard window, or does it need its own window (a la GLUT, for example)
iv) Direct3D/OpenGL and a single textured quad - is this overkill?


SDL is the defacto standard for 2d pixel based graphics. It does need it's own window, but being open source, it's possible to hack the source if you need to integrate it into another window (and IIRC has been done before).

D3D/OGL are still quite usable for 2d graphics. To use them to their best potential, you would probably NOT draw a single textured quad. Instead, you would have textures for each of the sprites in your game (either 1 per frame, or 1 per sprite, or combination thereof), and draw a quad per sprite. Similar effect with the background - you'd subdivide it into multiple texturse and draw as needed.

This approach means you get:
1) Hardware accelerated blitting (whereas a single quad you usually must blit in software, or rely on render-to-texture functionality).
2) Less pipe bandwidth used (you don't have to resend the pixel data for the entire screen over the pipe every frame - instead, you just need to upload new sprites or background pieces, and the coordinates of where you're rendering your sprites).

Share this post


Link to post
Share on other sites
I'd try GDI. Contrary to a previous post, you'll find tis better documented than any of the other 3 api's. We use GDI to draw flash animation and get 30-60 frames a second using it. That could be fast enough for you and of the 4 its by far the easiest to get up and running.

CHeers
Chris

Share this post


Link to post
Share on other sites
Allegro!!!
I use allegro for all my simple graphical C++ apps now.

I posted an almost identical message as you on these forums (or flipcode) a while back, as I wanted to have a simple way to draw some things on the screen and experiment without getting into messy details.

The responses were more or less the same, but not terribly helpful. I searched, and fell back on something I had used in the past with much success.

----

As for the above post, SDL is a standard, and is nice, however it doesnt have built in functionality to draw lines, circles, rectangles. So that lack pretty much kills it when one wants to just whip up a small app to push some lines around.

Allegro is also cross platform, and can scale up to do any fancy thing you should need.
Check it out. (No, i'm not being payed a commision. I just like it :P)

- Jacob

Share this post


Link to post
Share on other sites
Thanks for all the suggestions. The summary seems to be:

i) GDI - Probably too slow, but easy to set up
ii) Directdraw - Deprecated
iii) SDL - Cannot draw to a standard window out-of-the-box, and I'd rather get on with making my application rather than fiddling with a windowing toolkit
iv) TinyPTC - Seems to be just a wrapper around DirectDraw/GDI
v) Allegro - Also just a wrapper around DirectX/GDI, although an appealing one

I must admit I'd feel quite odd using allegro, I used to use it and DJGPP years ago. While I'm sure it has come on since, it just doesn't feel "professional" enough. I know that sounds daft, but I guess the best option seems to be OGL/D3D. Which of _those_ is another decision entirely...

Share this post


Link to post
Share on other sites
You should without a doubt use OGL/D3D, as for the question of which , i also have an answer.

D3D, [disclaimer, i use both d3d and ogl, though ogl mostly] it has this BEAUTIFUL thing called ID3DXSprite, its braindead easy to use, youll have no problem getting a sprite engine going with that, not only that but its supposed to be pretty damn fast,

hope that helps
-Dan

Share this post


Link to post
Share on other sites
GDI is _NOT_ too slow for many kinds of games. You won't be writing doom 3 in it, or any mainstream game that pushes polygons, but it is still fast enough for realtime games. With GDI, I can get about 50 FPS updating a 1280*~900 area while loading stuff from the HD between every frame. It took some time, but simply using a profiler made it easy to get that running (the app also updates the 900-1024 lines every frame, but thats with text using GDI labels/buttons and not per-pixel drawing on DIBs).

If you don't need fancy graphical effects and just need pixel drawing, DIBs in GDI will probably work fine and be the easiest (just remeber not to use DIB-specific blit functions and instead select the HBITMAP into a memory DC and use regular blit functions).

Share this post


Link to post
Share on other sites
i don't remember very well, but, if i'm wrong correct me, please.
actually, you can draw to a window (in win32) with SDL (ie: an application form), you have to select the windib driver and do something with the window's handle (i really don't remember, sorry).
here you have some info SDL Docs and there's an example in the JEDI SDL implementation wich draws an image in a form and lets you rotate and scale it with standard windows controls.
there's some more info on the net, but it's been a long time since i used SDL, and/or C.

edit: here you have some more info.

Share this post


Link to post
Share on other sites
Just to add,

DirectDraw isn't at all deprecated. It's merely merged with Direct3D to become DirectGraphics. This merge is done at DirectX version 8.0 or 8.1

The last DirectDraw interface you can access directly is DirectDraw7 Interface. It's definitely not deprecated and in fact, the core of DirectDraw, which is the use of PLAIN SURFACES and OVERLAY SURFACES is still pretty much in use in Direct3D and DirectGraphics. So I do not see it as deprecated at all.

DirectDraw and OpenGL are good graphics API platforms to start with. While we shouldn't argue who's faster DirectX/OpenGL, it's known that OpenGL can support multiple platforms.

My take would be, use DirectDraw surfaces for your flipping chain. Use GDI to render your graphics, draw your lines and such. It's extremely easy to use GDI. The book, Programming Isometric Games in DirectX 7.0, written by Ernest Pazera (TANSTAAFL - correct my spelling if I'm wrong) is great for your purposes.

It'll be much faster than to use two frame buffers in GDI to emulate flipping. Morever, with DirectDraw, you can store your graphics in video ram for a even faster performance.

Share this post


Link to post
Share on other sites
Just an FYI: You only need one surface (DIB Bitmap), because it isn't visible until you blit it to the window. You never need to do any kind of flipping and you can easily do the whole 'only update the part that changed' thing (which is possible but much more difficult when you have two surfaces being alternaded between.

Share this post


Link to post
Share on other sites
Agreed with Extrarius on that part.

It'll highly dependent on whether if you want or need to use a flipping chain or not.

If it's purely pixel plotting, a single frame buffer in GDI should do the job. Probably SDL will do a better job :)

Share this post


Link to post
Share on other sites
Since you've hinted you want to be able to combine widgets with a drawing context, I might suggest using Trolltech's QT (clicky). Although not quite free software, one can develop open source applications for free with it, and it includes an "OpenGL Context" widget, along with other multimedia widget options. See http://doc.trolltech.com/4.0/multimedia.html for details on the 4.0 version.

However, for potentially commercial software, the licence options may not be suited to your needs ($1550 for a single developer, professional (basic) licence - although this includes a year's worth of support and free upgrades). See http://www.trolltech.com/products/qt/pricing.html for pricing info.

Share this post


Link to post
Share on other sites
Quote:
Original post by Thrawn80
Just to add,

DirectDraw isn't at all deprecated. It's merely merged with Direct3D to become DirectGraphics. This merge is done at DirectX version 8.0 or 8.1

The last DirectDraw interface you can access directly is DirectDraw7 Interface. It's definitely not deprecated and in fact, the core of DirectDraw, which is the use of PLAIN SURFACES and OVERLAY SURFACES is still pretty much in use in Direct3D and DirectGraphics. So I do not see it as deprecated at all.


It is quite depreciated. See Microsoft's own webpage, which states this, and things such as the managed DD documentation (here) which has:

"Warning: This class is deprecated. Deprecated components of DirectX 9.0 for Managed Code are considered obsolete. While these components are still supported in this release of DirectX 9.0 for Managed Code, they may be removed in the future. When writing new applications, you should avoid using these deprecated components. When modifying existing applications, you are strongly encouraged to remove any dependency on these components."

Stamped over every single class entry. Deprecated does not mean unavailable, simply "Not guaranteed to be available in future versions - get porting before your application breaks, and don't use it in new applications".

Since DirectX almost follows COM programming methodology, it may stick around. Emphisis on may. Wheither or not this is a good idea is open to debate.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Thats in ralation to *managed code. as in DotNet.
DX7 is more than stable and you'll find that it works on damn near every vid card out there including old laptops and tablet pc's

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Thats in ralation to *managed code. as in DotNet.

The LINKS are in relation to managed code/.NET. The fact that the DirectDraw interface has been REMOVED from the functions in the unmanaged post-7 versions, as well as the lack of more recent documentation on the MSDN, just goes to show that they mean what they say. What little I can find on Microsoft's site about DirectDraw is mostly either the beaten-with-the-depreciated-stick classes of .NET, and the beaten-with-the-archived/no-longer-updated/old-and-out-of-date-information-stick information about DirectDraw7 (which has "Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist." clearly stamped at the top of their pages, along with the addition of "(Direct Draw 7 Archive)" into their titles in the search feature.

The other things I'm finding are driver building documentation and Windows CE programming information relating to Direct Draw.

edit: to underscore the point, let's see the titles (with comments after the # symbol) of some of the entries that popped up under a MSDN search for "DirectDraw":

1. The DirectDraw Driver # not related to USING DD.
2. DirectDraw Architecture # not related to USING DD.
3. DirectDraw # Managed/.NET, beaten with the depreciated/obselete stick
4. DirectDraw # Summer version of num. 3, beaten with the archived stick
5. Microsoft.DirectX.DirectDraw # Managed/.NET/depreciated
6. Microsoft.DirectX.DirectDraw # Managed/.NET/archived AND depreciated sticked.
7. Getting Started with DirectDraw (Windows CE .NET Application Development) # CE, one of the few apparently non depreciated uses.
8. Getting Started with DirectDraw (Windows CE 3.0 Graphics and Multimedia) # CE
9. Getting Started with DirectDraw (Windows CE 5.0: Graphics and Multimedia Technologies) # CE
10. DirectDraw Application Development (Windows CE 5.0: Graphics and Multimedia Technologies) # CE


11. DirectDraw (Windows CE .NET Application Development) # CE
12. DirectDraw (Windows CE .NET Application Development) # CE
13. Multiple DirectDraw Objects per Process (Direct Draw 7 Archive) # Archived
14. DirectDraw (Windows CE 5.0: Graphics and Multimedia Technologies) # CE
15. DirectDraw OS Design Development (Windows CE 5.0: Graphics and Multimedia Technologies) # CE
16. Multiple DirectDraw Objects per Process (Windows CE 5.0: Graphics and Multimedia Technologies) # CE
17. Multiple DirectDraw Objects per Process (Windows CE 3.0 Graphics and Multimedia) # CE
18. Multiple DirectDraw Objects per Process (Windows CE .NET Application Development) # CE
19. DirectDraw (Windows CE .NET Operating System Features) (Windows CE .NET Application Development) # CE
20. DirectDraw # Driver development related


Up to at least item 100 looked similar. I did not look further.

Share this post


Link to post
Share on other sites
Quote:
Original post by Thrawn80
You're right. But shouldn't DirectX beginners know some stuffs of DirectDraw and its Surface management before moving on to DXgraphics?
Why should they? That is like asking "but shouldn't newbies write DOS applications first?" to which the answer is "No, they should write windows console programs first" where they can use the same API they'll end up using for full gui apps(console programs can create windows etc if they want) but don't have to if they just want to stick to std::cout.
If a person wants to learn graphics programming with directX, then they shouldn't start off using deprecated parts but neither do they need to start with full 3d. They would probably do 2D with the current DX9 interface, which in no way invovles directdraw(since it doesn't exist in Dx9).

Share this post


Link to post
Share on other sites

This topic is 4745 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this