All those classes are more like glorified structures at the moment. The reason for your specific question is very simple: I'm not sure how the sprite speed will integrate with the main program loop, so I kept that out of the class. As I've not yet come to the point as how the whole thing will come out...

A lot of things are going on in my mind. Unfortunately I cannot program all day long because I have other work to do.

I guess the point of my using classes is to simplify the main () function and not to achieve true object orientation (ala abstraction, encapsulation, inheritance etc. etc.). I've deliberately kept the classes simple because I don't know how it will work out in the long run.

It's been commented out in that code? Also I guess since I'll be using 16-bit or 32-bit exclusively there's no question of storing palette information.

Also I don't understand the need for checking the video info for all those flags. If I simply use some flags and those cannot be set, I think SDL will ignore them (at least that's what I read somewhere). Not ideal, but at least it's not totally critical that way.

I thought I should explain my SDLSprite class a bit more:

It's not meant to be a full fledged sprite handling class. Here's how it works at the moment. It just takes an image containing all the frames of the animation stored horizontally and then splits it up based on the frame width specified and stores each frame separately. You just need to call the render function specifying the frame index to draw a particular frame at the moment. The calling function should do the actual animation work involved with multiple calls to renderframe every frame.

It's just that thin. The advantage is that this class can also be used for other purposes than just sprite animation. It could also be used as a mere array of surfaces for instance.

I suggest that you should put all of your classes in the "SDL" namespace and strip the prefix off, since you are essentially using that prefix to do the same thing as a namespace.

I did a set of C++ wrappers to get myself used to the API, based on a set of Java graphics wrappers for games a professor of mine already wrote. It was also my first real introduction to library C++ coding minus all of the predone stuff in Visual Studio (blech).

I actually think it is more fun to build your own engine than to use a prebuilt one.

Tuxdev, thanks for the tip.

Yes, I should probably do all those pretty things like namespaces etc. At the moment I'm sort of adding functionality as I go on.

I agree with you on the engine development part. It is fun. And part of the reason why I chose not to use a prebuilt one.

Again, my classes aren't pretty or even very feature rich, but it's got me developing and reducing the code clutter and that's my main objective anyway. To be able to write SDL programs without cluttering my program functions with SDL calls and declarations.

My philosophy is very simple - I have no programming philosophies. OO or otherwise, I tend to do what works best for me. I don't want to particularly stick to one kind of way which is why I guess you might find my coding practices a bit peculiar as in neither here nor there.

The main purpose of using C++ classes in my programs is not to get Object Oriented programming (Note: the concept of OO programming and using classes in code is completely different from one another) concepts into my code but merely to reduce code clutter.

That's why I said my C++ classes are more like glorified structures.

Yes it has and so should other things in the code as for this part of the engine it's just using SDL as an means to get and show input nothing more as OpenGL is the renderer.

Ok if you don't at least try and give SDL hardware flags you app is going to suffer. You may have a graphic card with good memory and gpu but if you don't set the flags you will be using software to emulate the hardware, which doesn't make an sense.

You keep saying your not going to use C++ features, so why use C++ and not C? You could then carry on your structure programming. OO makes games programming easier, everything (or nearly) is an object. If you are talking about clean code how about all characters inhert from a base class Object. Objects are created an pushed into a std::vector and the draw looks something like:

This is a very simple example which does not show clipping of objects etc.

Yes, for precisely the reason you mentioned I use C++. I don't have an objection to mixing and matching methods. Probably what I meant was I didn't want to get bogged down by worrying about coding mechanics particularly when it comes to philosophical rather than practical design decisions and would rather concentrate on the logic.

Yes, I guess that most C++ libraries you find have a good inheritance and abstraction structure in place and that's why I said I use classes mainly as a way to group related functions and variables and to do automatic cleanup through destructors rather than any real intention of doing OOP. It's not that I'm anti-OOP, but I just don't have a preference and am not averse to mixing and matching methods if I can get the final result.

To me, it seems a lot easier to code in a OOP-like fasion in C++ than in C, simply because of all the stuff that the language provides. Really, OOP to me is inheritance + RAII, and it is a lot easier to program an inheritance structure that models the problem. Sort of like "When in Rome, do as the Romans do" because it is harder not to.

In one of my personal projects, I'm trying to port a Java game to either C or C++ with SDL. I started out using C++, but after I had done quite a bit of it, I realized that I wasn't using any of the C++ features that weren't already in C, so I switched. It was pretty ironic because it was programmed in C in the first place! It'll probably grow into C++ eventually when I get past playing catch-up.

Game programming uses a lot of OOP. Unfortunately I think a beginner can get too bogged down into planning and implementing an OOP-based structure rather than designing the game logic and code itself. That's why I think many people love C. It just lets you code quick and dirty (not that C++ doesn't - it's just a psychological factor I guess - Java shoves OO down your throat whether you like it or not - C++ doesn't).

As I said, I find that planning the OOP structure is a rather tedious process and requires immense planning and forethought. For instance, why should a certain class be derived instead of containing another class? Where would you need abstract classes with virtual functions? Why should some classes encapsulate certain functionality and not other functionality? Which classes "own" certain logic and which others shouldn't mess with that logic? How much logic should a class hide from others and how much should it show?

Instead of answering questions like the ones I mentioned I think it's better to just write code and do it the way you think it should be done rather than trying to comply with real or imagined philosophical standards

Definitely. That project I mentioned I used C++ so that I could have the freestyle of C with all of the stuff in C++ that makes life easier. A lot of times, the natural OOP solution pops into my head by trying to figure out what the problem exactly is. So those questions are answered before I get to asking them.

Which brings you full circle to your orignal question which I did not comment on.
If you have never made a game, read tonnes of books on the subject or just want to make a game then I would say no. Use a game engine or rendering engine that is freely available.


Any game (or medium to large project) requires this; otherwise what you create will be mashed together in a horrible mess, with hard to find bugs, hard to follow logic and hard to follow flow of control.


Where as I and ALL game compaines think not. What your are describing is prototyping, from which you find the way you want it to go and what you want to implement.


At the risk of repeating myself lol