All this for 2d?

Started by
25 comments, last by ysotuff 22 years, 4 months ago
Myself it took me awhile to learn 2d DirectDraw programming. ysostuff-I could use your argument and apply it to 3d programming; it should be easy just:
1)render 3d objects
2)get input
3)move 3d objects
Personnally, I like DirectDraw because it''s easy for me (remember I said it took me awhile to learn it though). The hardest part now is programming specific to the program/game (stuff like AI/physics, that sort of stuff) stuff that might not be DX specific though. Other stuff like ANSI C, MFC type dialog based apps (not games), and DAO database type stuff is pretty much the only other C/C++ programming I really know. And compared to advanced game mechanics that other stuff is relatively simple.


"A man can''t just sit around." ''Lawn Chair'' Larry Walters (1982)
"A man can't just sit around." 'Lawn Chair' Larry Walters (1982)
Advertisement
ysotuff- From the sound of your post, it sounds like you are new to Win32 developement. If that''s the case, then not only do you have the learning curve for DDraw, but also for Win32.. which, if you aren''t used to the message/event style of programming, can be very frustrating.

I used to miss the days of DOS programming, where you could just write directly to video memory... and writing custom blitting routines in assembly was fun (trying to wring those last few cycles out of your code). But now DDraw offers you hi-res, hi-color, hardware accelerated graphics in a fairly generic API, that works on every computer (heck, they even emulate most of the APIs that aren''t native to the hardware!)

Also, it may seem like MS neglected the 2D stuff, but take a look at Direct3D. There''s about a million more things that you have to do and setup to make even a simple spinning cube (and then there''s stuff like texture mapping and lighting!). The bottom line is that generic graphics APIs are just getting more and more complex. When I first started messing with DDraw, I swore up and down at the fact that there wasn''t a simple PutPixel() or DrawLine() routine .. I had to do everything myself! But if you are writing a game, would you rather call a generic (and likely slow) putpixel/drawline/sprite routine? Or one that you wrote yourself to be fast and efficient for your particular case? If you''d rather use the generic implementation, then MS has the perfect API for you, it''s called GDI (and there''s a reason it isn''t used for games).

Several people on this thread have suggested using SDL or Allegro. Personally I find the SDL API pretty clumsy and I don''t like the "style", but if you want to write a 2d game in under an hour, then I suggest you look into it. www.libsdl.org I believe will get you there. In the past I have always used SDL when I want to get something up and running as quick as possible. There are a ton of very useful support libraries for it too (like SDL_ttf, or SDL_image). I haven''t used Allegro myself, but I have looked at the API docs for it, and it is a much more complete game API (I believe it has APIs for sprite blitting, etc).

Graphics APIs are definitely getting harder. You can use some of these other libraries to simplify things, but be careful that you don''t cheat yourself out of learning DDraw in the process. It''s like learning to program for Win32 using VisualBasic. Try that for a while, and then try moving to Visual C.. you''ll realize how much more power you have, and how much you took for granted because VB handled it all for you.

Brannon
If you wanted to draw a square, would you render a cube in 3DS Max and view an orthogonal projection of it?

Of course not, way too complicated. You could draw a square this way, but it''s much easier to open up windows paint and use the square drawing tool.

If you wanted to make tictactoe would you do it in DirectX?

Same answer, of course you wouldn''t becaue it''s way too complicated. You could but it would be a waste of time. Do a simple visual program in VB, or write a console program in C.

Why use DirectX? Does your tictactoe just have to be full screen and have exclusive mouse control? Do you want to alpha blend your X''s and O''s or something? It takes a lot of work to make Tic Tac Toe in dx just like it takes a lot of work to make anything in dx. Dx can do many, many different and complex things, so it has many options and requires a lot of setup.
Thanks Brennan, your message was very helpful. I should mention that I never intended to create Tic Tac Toe, I was just using it as an example. If I was, I would probably just use VB.
Bah.. direct3D this, DirectDraw that. Use OpenGL for 2d, it''s much faster than DirectDraw because of the 3d acceleration and you get things like masking, blending, etc.. for free. You can use Direct3D but OpenGL will be a lot easier to code.

You won''t have to write 4000 line programs to make tic-tac-toe

Note that you can still use DirectX for everything else. I hate it when people think you can compare all of directX to openGL or any other 3d api. Compare apples to apples, not apples to oranges, bananes, mangoes, and whatever else!
Like others here i would really suggest SDL. I just started looking into more than simple game programming, and changing language at the same time. Im used to Java, but now im going at it in C++(the only thing i miss is my garbage collector .

Anyway, for that very good reason i know next to nothing about Win32 programming, which makes SDL an excellent choice.
SDL has a very simple interface, but seems to give you what you need for 2D programming. Its totally C based which means they didnt use classes etc, but they programmed it so neatly it almost feels as easy to use as an OOP framework
And if you want to make 3d games later just use SDL together with OpenGL it seems like its pretty painless, and anyway, SDL has a good maillist with people very willing to help out.
I´m sorry but I don´t get what´s the big deal with Windows Programming. I´m not the best Windows Programmer in the world but I know how to make a window class, register it and show a window out of it. The rest is just fetching messages with PeekMessage and passing it to the callback function (usually WinProc) and that´s it! I would recommend you Tricks of the Windows Game Programmig Gurus. It´s the best coverage of Windows game programming I´ve ever read (NB: I haven´t read Petzold´s book yet) + a wonderful tutorial on most DirectX components (note: not Direct3D).

This topic is closed to new replies.

Advertisement