gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

C/C++ > Object Oriented Implementation

#13124 - Schweets - Fri Dec 05, 2003 10:11 pm

Greetings GBA community! I'm a female programmer and have been going at this for many years with my husband in the web buisness. We picked ourselves up a GBA this year for x-mas and I have been excited ever since to take a hand at programming on them. I've done a few little games like "Counting With the Powerpuff Girls" and a clone of "Atlantis" from the old Atari 2600. But what I have a hard time finding is object oriented c++ tutorials. The whole community seems to be centered on c and thats great but I was hoping to get a little more from the c++ side.

And now to the point sorry for rambling. I've done quite a bit of object oriented programming esp since we decided to pick up on c# in the past year and a half but when it comes to games I have an incredibly hard time trying to decide where everythign should go. I was hoping I could get some suggestions on how some of you would set up a good object oriented structure for your games. Not the implementations and code for it. But things like wether or not I should make a general display class that handles all the sprites and tiles on the screen. Or separate them all into classes. Some of the main classes and methods that I might consider using. Thanks in advance for your time.

#13131 - Quirky - Sat Dec 06, 2003 1:11 am

I think that the hardware has a huge influence on what you can do. Not in a "C++ is too slow" way (it isn't), but in a design approach way. I started writing a gbalib in C++ and two of the classes I created were a Sprite class and a Keypad class.

My Sprite class was really cludgy, you shouldn't create more than 128 of them (due to the underlying hardware limit of 128) and it's actual storage method was really similar to a lot of the tutorials - i.e. a (private) static array of 4 shorts in a struct, rotation data overlayed on that, with each sprite updating that array depending on its "id"... once I run out of (hardware) Sprites, I set the next created underlying sprite id to INVALID, and then you have a Sprite object that is totally useless! When a sprite dstructor is called, it "frees" the underlying entry in the static array.

Classes like Keypad (also screen) I used the singleton approach. I think that's the only way you can go for that type of thing. Then the class writes itself, you have a "isKeypressed" type routine, an update, etc etc... looks pretty much like bog standard C, but with all the advantages C++ gives you. I suppose you could also just use all static methods, but that's not very interesting.

Then in a game... well, that is more standard C++ than writing the low level library stuff. The tricky bit comes in memory management and "where code goes". Some classes I've written use the trick of having a (inline) member function that just passes all the work off to a static function that takes a reference to the class type. That way you don't use up too much stack space. Or at least that's the plan. And I don't worry about "all those excess function calls!!" because C++ compilers can optimise better than I can :)

I really learnt a lot of C on the GBA and have just started out in C++ (I've tried learning C++ before, it just doesn't seem to sink in sometimes and there are so many places you can cock it up) so I'd like to hear how other people tackle these problems. Most of the C++ code I've seen for the GBA is really just C, but using inline and enums. Not very exciting.

#13132 - dagamer34 - Sat Dec 06, 2003 1:16 am

If you really know C++, then you can just jump right in. Now, I'm not saying that you should create a class to manage everything.. because often C++ code is kinda messy. Functions are simple and easy to reuse.

Basically, really the only TRUE C++ I use is to manage a game itself, as in states and control structures. Other than that its just C.
_________________
Little kids and Playstation 2's don't mix. :(

#13146 - sajiimori - Sat Dec 06, 2003 5:20 am

Quote:

...a general display class that handles all the sprites and tiles on the screen.

I wouldn't worry about trying to force different aspects of the hardware (e.g. sprites vs tiles) into an inheritance hierarchy. Make them independent classes unless there is some compelling reason to do otherwise. Inheritance is a very strong dependency, and we all know that dependencies are the bane of encapsulation.

Or did you simply mean making a single class that handles both tiles and sprites? In that case, it would probably be better to seperate responsibilities. Each class should have a single, well-defined purpose.

One approach is to make a singleton for each aspect of the hardware (e.g. sprite ram, character ram, keypad, tilemaps, DMA, audio), giving them minimal interfaces (e.g. the sprite ram class could provide an interface for setting the attributes of particular hardware sprites).

Then you can make abstractions of those base classes. For instance, you could make a class that automatically allocates hardware sprites as needed, in order to hide the details of choosing where to store particular sprites.

After you have those basic abstractions from the hardware, you can start thinking in terms of elements of your game itself. Free from the details of bitmasks and register addresses, you can organize the rest of your program into any sort of hierarchy you like (e.g. an Actor class that is the base of Player, Monster, and NPC...).

A general guideline: if your code would require changes to work on something other than GBA, do more abstraction. ;-)

#13160 - Ruiner - Sat Dec 06, 2003 7:43 pm

Thanks for all the suggestions so far. Most everything I have learned has been from sitting behind my husband watching him program and picking up a few of his books.

Quirky thanks, those 2 classes are actually the only thing i have implemented on my own before this post. Its pretty easy to handle sprites and keyboard through a class.

Quote:
Or did you simply mean making a single class that handles both tiles and sprites?


Exactly, but after seeing your idea to separate each class by a hardware aspect is starting to make a bit more sense to me. What I was attempting before that was really confusing me was making a GBAScreen class that I could ask to create new sprites and move the tiles and such around for me. But there were some headaches in the end as to who should control what data.

Please feel free to add more suggestions if anyone has them. I'm more than open to anything that I can learn from someone that knows what they are doing ;)

#13167 - sajiimori - Sun Dec 07, 2003 12:59 am

Quote:

I'm more than open to anything that I can learn from someone that knows what they are doing ;)

Oops! Err...disregard my previous post. :-D

#13169 - Schweets - Sun Dec 07, 2003 1:13 am

ROFL!
Quote:
Oops! Err...disregard my previous post. :-D


Just realized I was logged in as my husband (Ruiner) when I posted last comment too. /sigh

If any of the admins can change that then please feel free. :)

#13176 - MumblyJoe - Sun Dec 07, 2003 8:24 am

Personally I have been writing a C++ based library for personal use, and I have found the best way is to make classes to represent things like timers and registers and dma etc (example: I have classes with functions to set and unset the right bits in the display registers etc). Then use these inside of other classes to represent sprites and sound etc. I almost have a full set of libs for most things (except interrupts, thats a trickier thing to do).

I also have a main Engine class with heaps of random functions like SplashScreen() which takes a picture the size of the full screen and displays it until start is pressed then returns everything to its previous states.

My Sprite class is undoubtably the best though, has a virtual function called Update() which updates to the OAM, and I inherit other things from this class, such as ControllableSprite which uses my Keys class for controls, then I inherit something like Frog from that. The bonus of this is that I keep an array of all my Sprites, and call the virtual function Update() on each of them and they do the right thing (normally the update function in the derived classes does something then calls the superclass version of Update()).

Hope this helps.
_________________
www.hungrydeveloper.com
Version 2.0 now up - guaranteed at least 100% more pleasing!