Jump to content
  • Advertisement
Sign in to follow this  
bakery2k1

Which 2D API?

This topic is 4938 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
Advertisement
GDI is slow and not well documented. DirectDraw is deprecated. As far as i know best way to go is probably SDL or Direct3D/OpenGL.

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 would do a google for TinyPTC, its the easiest to use API i know of, consisting of three functions: ptc_open, ptc_update and ptc_close. its pretty good speedwise
also.

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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!