Wondering if some of you nice folks might be able to help me. I''ve been reading "Tricks of the Windows Game Programming Gurus." and feel that I have all the direct draw concepts down, enough so that I''m ready to write my own sprite engine but I can''t decide whether to use C or C++. To me C++ seems the natural choice for doing things like bitmaps and sprites because I can see these as objects, but making a class for all the direct draw stuff is a little more abstract it seems. I''ve been trying to go by the recommendations of OOP methodology and make the classes self sustained and protecting their internals while providing an approved interface blah, blah, but I think I''m having a concept problem here. My bitmap and sprite classes have to ''dig'' into the direct draw class. The whole idea was to make the code more manageable, you know, abstract away the details so that when it got to the actual game programming part I wouldn''t have to deal with all the internals every time. Well, my attempts at making C++ wrapper classes for everything is even messier than straight C. I find myself having these strange thoughts like making a base class that contains the ddraw stuff and then using inheritence to derive bitmap and sprite classes from it so on and so forth. Ugh! brain hurt! Question: Since I''ve never actually written a whole game before, should I use Andre''s methods and finish a small game before trying to make my own ddraw wrapper library? The concept of "fill out structure - pass to function - use lots of globals" just gives me the screaming heebee-geebees for some reason. Ok, I admit that I may have an acceptance problem. I think it''s cool to have an object create itself and then draw itself on the screen with out any outside help, but I also realize that game programmers have been doing things similar to the way Andre does it for years. Last question, I promise Can anyone recommend some sample code to look at that shows a good way to make C++ wrappers for ddraw? Sorry so long winded. Thanks, Phillip

I''ll answer your C/C++ debate. Just because the tools are there, doesn''t mean you have to use them. Coding any game using pure C++ ideology is suicide performance wise. Writing it all in C can cause you brain cramps.

I recommend you make use of classes when you think they are beneficial to you. If you don''t think it makes sense that something should be a class, make it procedural.

If you work out a nice blend between pure c and c++ you should have no problems writing a well designed and efficient game.

I think you may be trying to stretch the class concept too far.
It can be very useful if it''s used right, but when you find
yourself doing something just to make it fit into a class, even
though it doesn''t logically fit with your program or programming
style, then it''s lost its usefullness.

It can be very useful for isolating different functionality and
providing a clean interface. e.g. - if you encapsulate all your
direct draw stuff in a class, decide what needs to be passed to
it and returned from it, then you don''t have to think about all
the internals of what''s happening there when you get ready to
render something - you just have to think about the interface.

Anyway, back to your actual question, if you haven''t done much
(or any) oo programming before, then it would probably be useful
to just go ahead and write a small program first. I think it
will be easier to go back in retrospect and see how you could
make some use of classes and object-oriented concepts, than it
would be to try to decide all of that before you write the
program. Trying to put this nicely -- if you''re finding that your BMP''s, etc. are having to ''dig down'' into your direct draw classes, you may not quite have mastered the concept yet.

information is the illusion of knowledge

quote: Original post by justj

Anyway, back to your actual question, if you haven''t done much
(or any) oo programming before, then it would probably be useful
to just go ahead and write a small program first. I think it
will be easier to go back in retrospect and see how you could
make some use of classes and object-oriented concepts, than it
would be to try to decide all of that before you write the
program. Trying to put this nicely -- if you''re finding that your BMP''s, etc. are having to ''dig down'' into your direct draw classes, you may not quite have mastered the concept yet.


Yes, you''re probably right about that. I seem to be stuck in limbo between functional and object oriented programming at the moment. I think I understand the broad principle of OOP design, but I''m still having problems with implementation in C++. Thanks for the suggestions, I think I''ll just press on and try to concentrate on making a useful attempt at a game and worry about doint in the OOP way when I have more experience with it.

Phillip

quote:
To me C++ seems the natural choice for doing things like bitmaps and sprites because I can see these as objects, but making a class for all the direct draw stuff is a little more abstract it seems.

Was that an attempt at a pun? A little more abstract than it seems. hehe

Anyway...I think you should C++. It is a superset of C and doesn''t lack anything that C has but has more than C. If you don''t want a class or it isn''t logical, you can just tuck your engine functions away in a file never to be seen again. But if you DO and you started the game with a C compiler, then it will be harder to port. Go with C++.

Lucas


PS If you do not conform to every single law of Object Orientation (section 1 through 6545433.4.543) then I will find your computer and burn it. Then i''ll ring ANSI and ISO and tell them. Then i''ll ring Bjarne Stroustrup up and boy will he be angry! So make sure you abide by every single rule of encapsulation. And remember, if its not a class and its not a preprocessor directive, then it is RUBBISH and Bjarne will smite your ass.

PPS that was a joke if you hadn''t guessed

PPPS except for that stuff about Bjarne smiting you for lack of OO

PPPPS That was a joke too.

PPPPPS hehehehe

quote: Original post by Ataru
Coding any game using pure C++ ideology is suicide performance wise.

Only if you suck at C++ - you haven''t read my article, have you?




Give me one more medicated peaceful moment.
~ (V)^|) |<é!t|-| ~
ERROR: Your beta-version of Life1.0 has expired. Please upgrade to the full version. All important social functions will be disabled from now on.

Go with C-style functions and globals for starters and just try to isolate the complex directx stuff away from your main game. When that works perfectly then start thinking about putting it in a class. And make small games first or else you''ll never get anything done.

If you don''t need to put it in a class, don''t.

- Daniel
VG Games

Which article Keith?
can you post a link to it?

That was your article? I had a hunch that it was, what with the reference to that operator overloading thread. Maybe you should use your nick when you submit it?

It was a great article!


To the original poster:

I've never written a DirectDraw wrapper class, because DirectX is so class-like anyway... My advice is just to learn C++, and practice with it. It takes a lot of practice to get good at modeling things with OOP.

Anytime you write a wrapper class, don't just write lots of inline functions that simply call methods with the same name. I mean stuff like this:


class direct_draw
{
public:
create(...) { DirectDrawCreateEx(...); }
release() { lpdd->Release(); }
};



That's just duplicating all the function names - it really doesn't do anything to help the user of the class, because they'd still have to worry about all that stuff anyway.

The purpose of classes is to allow you to work with things at a higher level. For example, you want might want to call:


surface.blit(mysprite);



And let the surface worry whether the sprite is in the correct color depth and how to convert it, whether or not to stretch it, etc. Or you might want a method like this:


surface.alpha_blend(RGB(255, 0, 0), 0.10f); // make it a little red



Instead of having to worry about all the details and the surface format and things like that. That's really the same reason why we have functions and structs - so you can write the code once instead of having to duplicate the code every time you need it. If when writing a class you find yourself copying and pasting large blocks of code, the code probably belongs in a class somewhere as a member function, or perhaps as a new class. Only the very simplest code should be duplicated anywhere.

How complex the member functions are depends on what you need. If you don't need to do any fancy clipping, don't bother making functions to manipulate clipping regions. If don't need to write directly to a surface, don't bother putting in functions to do that. Your classes will change quite a bit between projects. One game may need to play MP3s, while another only needs to play some wav files in the background. The DirectSound class will be different in those two projects.

Don't start off by writing a do-everything library - just make it work, and try to keep the code clean. You may want it to be limited to one resolution (maybe 640x480x16?), and maybe once you learn enough you can make your DirectDraw class and your sprite class work together, so that your main game loop can handle any resolution and color depth without any changes to its code.

To write good classes, you _have_ to know how those classes need to be used, and how the programming task (in this case, drawing stuff on the screen) really works. If you only know a little about those things, then start off by making a very simple interface. Make a game (even if it's a Tetris clone) with it to measure your progress. As you learn more, you might want to add a feature or two to your classes. But keep testing your knowledge, and when you fail read everything you can get your hands on to find out why.

Once you get a pretty spiffy library going and some games under your belt, start reading some articles on performance, like MadKeithV's article. Eventually, when you start writing stuff that needs to be high-performance (like a 3D engine), you'll need the very fastest classes. LaMothe's books often provide a bit on optimization, which really makes you think. Most of optimization is just knowing how the computer works, and using common sense.


- null_pointer
Sabre Multimedia


Edited by - null_pointer on August 31, 2000 9:17:58 AM

Since we''re talking about classes, I''ve got a class question I''ve always wondered about. If I have class A delcared as:

class A
{
private:
int myint;

public:
int GetMyInt();
int SetMyInt(int);
};


and I want to derive a class B from it, should I keep the myint variable as private, and use the Get/Set functions to access it, or should I declare it as protected: and access it directly, so I don''t have to make that extra function call?