Archived

This topic is now archived and is closed to further replies.

Direct3D vs DirectDraw for 2D games

This topic is 5557 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

Hello, long time reader-- first time poster. After having browsed through tutorials and articles relating to DirectDraw and Direct3D, I am asking this simple question: If you were going to create a 2D engine what would you use? I have dabbled in both, but I find that it feels unnatural to start a project by choosing DirectDraw, a no longer supported library from an outdated version of DirectX. However, DirectDraw feels easier to work with on 2D games since it is geared at what Im working on. On the opposite end of things, Direct3D has nifty features that would save time (like being able to set a color for each corner of a tile, etc..) when doing a 2D engine. Anybody have any thoughts on this subject? ~Steve www.foggymyst.com

Share this post


Link to post
Share on other sites
I''d go for (and have gone for) DirectDraw, just because it''s simpler.

I have however made my 2D engine go through an abstract interface as I''m planning on porting it to GameBoy Advance and perhaps an OpenGL renderer, for kicks.


Helpful links:
How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions

Share this post


Link to post
Share on other sites
Sia,

Good idea! I cant beleive I didnt think of that myself-- it would be funnier if you knew how big on abstraction I am. At work, I spend extra time and effort making sure our code has no dependancy on which database system we use. For some reason, that same thought did not carry over into my current dillema.

Still, the question remains... is it bad to go with the aged DirectDraw? =)

~Steve

Share this post


Link to post
Share on other sites
There are only two (noted) reasons why MS stopped updating DirectDraw:

1) Companies no longer added "cool" 2d features to their graphics cards.
2) There was nothing left to update. It''s so complete that they can''t make anymore additions to it.

If you feel comfortable using DirectDraw, then do it! It''s a great API and will be around for a long time.

If you want to try something new, then go for Direct3D, you get more features with only a small increase in difficulty (it''s well worth it, though).

Hopefully I could be of some assistance.

--SuperRoy

[Google!][Stick Soldiers 2 Screenshot][E-Mail Me!]
[End Transmission]

Share this post


Link to post
Share on other sites
I have a complete 2d engine. And I regret using direct draw so much. It's actually the biggest mistake I made in making my engine. Features like fades, you'd think would be so simple are a huge issue with direct draw(you can use gamma controls but then you have to worry about how they'll look on other people's computers or if they'll even work at all). You can't make things transparent without fancy routines that'll slow things down a lot. Direct3d is faster because all of the video card makers focus on 3d acceleration. There's just so much more Direct3D has to offer.

Oh and if Direct Draw and Direct3d aren't my only choices. I would say I'd go SDL and OpenGL to get some platform independence going. I would say look into those two as well.

I think it's safe to say SDL is at least as easy if not easier than DirectDraw to use. If I'm wrong I take it back, don't flame me on that!

And a little disclaimer, Don't take what I'm saying as fact, just opinion.

[edited by - atcdevil on September 8, 2002 9:03:34 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by atcdevil
(you can use gamma controls but then you have to worry about how they'll look on other people's computers or if they'll even work at all).


atc, there's actually a really simple way to do gamma fades on that will look good on any machine. I have a post showing my sample code here. **note** this is some old code and I should have used bitshifting to speed it up, but I was new to C++ at the time**



[edited by - jdinger2 on September 8, 2002 10:50:12 PM]

Share this post


Link to post
Share on other sites
Either choice would be fine, but it depends on what sort of effects you want really. You get sprite roration and alpha blending for free with D3D. But, DirectDraw will cost you some CPU cycles (or extra bitmaps) to get the same effects. Someone said DirectDraw was easier. I highly disagree. 2D in D3D is cake. DirectDraw takes a bit more work, since you have to implement features yourself which D3D provides for you.

Share this post


Link to post
Share on other sites
One thing about going 3D is you are limited to using textures. So they are limited in size and they have to be powers of two in size. This is a real pain in the neck for some 2D games.

Share this post


Link to post
Share on other sites
What if your 2D map is on the order of 1 billion pixels in size -- like 32767 pixels by 32767 pixels (which could be 512x512 tiles for 64x64-pixel tiles -- a total of only 262,144 tiles). A 2D DirectDraw-based engine could handle this no sweat on any old PII system with 64 MB RAM and 4 MB video memory -- does it present problems for Direct3D?

"All you need to do to learn circular logic is learn circular logic"

Share this post


Link to post
Share on other sites
quote:
Original post by SuperRoy
There are only two (noted) reasons why MS stopped updating DirectDraw:

Actually, I heard that there was a 3rd: they intended making DirectGraphics into a decent 2D and 3D API, but never got around to doing most of the 2D stuff. Rumour has it that DX9 has better 2D support. But this is just rumour, so if anyone knows better, feel free to contradict me.

If I was writing a 2D engine now, I would focus on the D3D aspect, but making it abstract enough to substitute in DirectDraw - or more interestingly, SDL - would be very useful.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]

Share this post


Link to post
Share on other sites
I wrote a DirectDraw vs SDL program to test the results and the programs did the exact same thing and here they were (just in case this changes your oppinion to go with DirectDraw or SDL). This is the readme file of the .zip:




README
Created By Brent Gunning
Copyright 2002 All Rights Reserved


Requirements:

DirectX 7 SDK or higher to run DDWrapper
Windows 98 (95 might encounter problems) or higher.


Overview:

This is a test for me to compare SDL to DirectDraw. SDL in this application uses DirectDraw for it's operations but
DirectDraw it still much faster, as you can see from the framerates. The controls are simple, escape to quit. The code
for both is optomized fairly. The SDL application only had 126 lines. The DirectDraw application had 323 lines not including
a DirectDraw wrapper which added 758 lines to a total of 1081 lines! Obviously development time is dramatically cut using SDL
and if speed isn't that big of a deal, then SDL may be the way to go. Plus, SDL is cross platform and much easier to learn.
I learned SDL in 2 hours while it took me 2 weeks to write the wrapper and code and then roughly 4 months to learn DirectDraw
version 4 and 7. SDL is so much easier and less complicated. Plus, everything comes from a main function, not WinMain. I
really like SDL but it's speed isn't high enough for me. Another bad thing about SDL though was that it was a little limited
to windows development and control over your application. This is because of it being cross platform but that is a big
loss if you're going for that control. Well, here's a comparision of the two:


Comparison of SDL to DirectDraw on an Intel Celeron 810E
-----------------------------------------------------------
Topic DirectDraw Results SDL Results
-----------------------------------------------------------
Framerate 324 149
Lines of Code 1081 126
Development Time 2 weeks 20 minutes
Learning Time 4 months 2 hours




---
My Site-My Tetris Clone w/Source
Come join us on IRC in #directxdev @ irc.afternet.org

[edited by - RapidStunna on September 9, 2002 6:26:12 PM]

Share this post


Link to post
Share on other sites
149 FPS isn''t fast enough for you? What''s the world coming to?

SDL will of course be much slower than accessing direct draw directly simply because there''s a lot of overhead wrapping it up and there are often other things going on behind the scenes.

I wrote 2 DDraw based libs a coule years back. The first was an experiment/learning experience, the second was actually quite nice. But the next 2D game I write will certainly be done with SDL. 30 fps is plenty fast for a 2D game. 149 is overkill

Share this post


Link to post
Share on other sites
What about the other alternative OpenGL?

OpenGL allows for effects like alpha blending, transparency and all via hardware (assuming you have a vcard made in the last 5 years).

Also OpenGL sits nicely ontop of SDL.
It may not be as intuitive as DDraw it should be as easy if not easier then Dx Graphics (or D3D if you use something old).




Share this post


Link to post
Share on other sites
The reason you care about 324fps to 149fps is simply what if your application starts doing some heavy graphics? The speed of DirectDraw may come in handy when your framerates start getting lower due to a complex game. A game doing 30FPS in DirectDraw will do 15FPS in SDL. While I cant imagine a 2D DirectDraw game ever bringing things down to 30FPS-- it could happen and if you were using SDL you''d be in quite a bind.

Thats my take on what he was saying. =)

Any good channels on IRC where people hang out and talk about this stuff?

~Steve

Share this post


Link to post
Share on other sites
Newbie here, but...

I am personally half-way-thru making a "2D Engine in 3D" for
Direct3D 8.1
I am using "pretransformed/prelit vertices" and "textured quads"
(two triangles/4 vertices/6 indices speced in screen space NOT
3D world space.)

From my (abeit limited) experiences -

Positives:
* Hardware Alpha blending

* Hardware Scaling

* D3DPOOL_MANAGED textures get swapped in and out of video
RAM/AGP RAM for you (and gets saved when the user ALT-TAB''s.)

* Vertex buffers are MEGA FAST when batched correctly. (see
"Negatives" below)

* Haven''t played with rotation (should be easy just rotate the 4
vertices in s/w screen space before rendering.)


Negatives:
* Debugging COM is messy (pointers to pointers/ bitmasked return
values/ can''t debug between lock calls in Win9x etc. etc.)

* You have to play with and understand "custom vertex formats"
(Without a foundation in 3D graphics theory the SDK docs
aren''t that helpful in this area...)

* Power of 2 texture width/height on all h/w I''ve seen (this eats
video RAM on older h/w eg. 8Mb PCI Voodoo2)

* Older Hardware (eg. Voodoo2) has max texture width/height of
256 pixels. If you want bigger sprites you are going to have
to mash textures together somehow.

* Ideally you want to put multiple sprites one a single (large)
texture and use texture offsets when "blitting" them
(increases render speed.)

* D3D8 Pulled all GDI support. (So functions for eg. writing
text/ drawing a line/ drawing a circle etc. must be written by
you by getting pointers to the DX surface.)

* If you want to have more than say 600 triangles
(300 "textured quads") per frame, you are going to need to use
vertex buffers (this isn''t much - if you have say 640x480pixel
res and 32x32pixel scrolling background tiles approx =
320 "quads" before drawing foreground)

* If you want your vertex buffers to run fast, you must sort
by texture and batch calls to DrawIndexedPrimitive(...)

* Implementing sorted by texture, batched DrawIndexedPrimitive()
calls in a dynamic Vertex buffer with texture offsets gave me
a headache...

Bottom line:
Don''t underestimate the complexity, (read - time involved) of doing "something simple" like 2D in the 3D world when using D3D8.
You may be "brilliant" and *want* a challenge, but will the project ever get finished?

DirectDraw will be fine if you need no h/w alpha/scaling, but is
practically unsupported now (except for SDK and some older books.) I''m not sure about driver support, but the COM model
means that older DDraw Interfaces are always available for use.
I can play DDraw3?? (1997) game "Twinsun''s Oddesey" on a
GeForce2 Pro.

From other feedback, (without ever looking at OpenGL,) it is
probably the best bet if you *need* h/w alpha blending/scaling
- Although OGL Glut runs on top of DDraw??
As I said never played with it...

You will need to learn COM (the hardest bit of DirectX) for DSound/DPlay/DInput support anyway...

Keep in mind that, although OpenGL is cross platform, M$ now think they "own" the ARGB_VertexShader extension. This only
affects OGL1.4+, but I have become very suspicious of M$ intellictual property purchases...


- MrNewbie
"Opinion''s only - no repercussions."
"Wait till they''re all hooked then crank up the price."

Share this post


Link to post
Share on other sites
quote:
Original post by RapidStunna
I really like SDL but it''s speed isn''t high enough for me.

That''s fair enough, although I never noticed results like that myself.

My main interest in SDL is platform independence and ease of use. I see next to no reason to use DirectDraw these days... if you want speed you can go with OpenGL or Direct3D, and if you value development time you can use SDL. DirectDraw falls uselessly somewhere in the middle on most hardware.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]

Share this post


Link to post
Share on other sites
About the 149 vs 360 somethin-like framerates and them not being high enough, they were actually really low. My friend had over 600 for the DDraw sample. The program was very simple. It loaded a bitmap w/ a color key and then drew it bouncing around the screen while clearing the back. It was that simple.

---
My Site-My Tetris Clone w/Source
Come join us on IRC in #directxdev @ irc.afternet.org

Share this post


Link to post
Share on other sites
I am doing the same, but in my case I am using unlit but transformed vertices. I do zoom, rotation and transparence on sprites/map.
I build a first version using many little vertex buffer (one for every tile, map or sprite), but I redo it so I can use only one giant vertex buffer. but it''s still no completly optimized since I didn''t sort the primitives by texture.
I''m asking myself about the effectivness of such on method, since 2d will always use a huge amount of texture. one solution could be to gather many of them in bigger texture, but I still have a vodoo 3 accelerator (arg :/) and I''m limited to 256x256 square textures.
As far as I know, I think it''s the best method, even since it may appear too complex for a "simple" 2d rendering engine...

Share this post


Link to post
Share on other sites
quote:
Original post by zilch_
I read a couple of days ago that TV has something like 20 or 30 FPS (it was low!). 149 should be enough


The reason that TVs only run at 30 fps (slightly less, actually) is because every frame is blurred into the next. This fools your brain into thinking that the images are much smoother than they actually are.

Also, I have to disagree with those people saying that using D3D8 for 2D games is harder than DirectDraw. It took me less than 2 days to get my DirectGraphics 2D engine up and running (I used the very easy-to-use IDirect3DSprite interface). With DirectDraw you have to worry about a lot more low-level stuff than you do with a simple D3D app.

-Mike

Share this post


Link to post
Share on other sites
Don''t forget hardware compatibility. It''s extremely easy to write something in D3D8 that runs on only 2 different graphics cards. DirectDraw is pretty straightforward and runs well on all cards. With Direct3D, you have to do LOADS of testing until you get it right. I tend to think that it''s hardly worth that for a simple 2D engine...

- JQ
Full Speed Games. Period.

Share this post


Link to post
Share on other sites