#6632 - shoaib - Sat May 31, 2003 10:52 am
Does programming games in OOP on the GBA have any serious performence issues? I know the slow down is not significant on the PC but does the GBA have enough muscle?
#6634 - MojoJojo - Sat May 31, 2003 1:04 pm
If you avoid virtual functions (so no inheritence), and avoid getting any runtime type information, then C++ is just as fast as C (at least, I don't believe there should be any difference).
However writing your code in fully object oriented style is probably a bad idea - the paradigm is a bit too distant from what the actual machine code is doing to make designing efficient code hard. The approach I prefer is to right mainly in C, with a few classes around where I think they might be useful.
#6635 - Touchstone - Sat May 31, 2003 1:07 pm
Not necessarily. THPS2 for instance was programmed in C++. Not the whole thing ofcourse but the game code.
Virtual methods are slower than direct methods.
Overloaded operators are not slower then regular operators. At least they have no reason to be since they are evaluated in compile-time whereas virtual methods are evaluated in run-time.
Templates shouldn't be slow but for each instance of a template you get a whole lot of extra code on your cartridge.
If you look at the asm code generated you can easily get your own idea of what the do's and dont do's in C++ are.
_________________
You can't beat our meat
#6665 - torne - Sun Jun 01, 2003 1:08 pm
Mojo is right, the only 'slow' features in C++ is RTTI and virtual methods. But writing OO code is not inefficient! =)
Many well-designed C programs have a rather object-oriented style anyhow; I don't write games, but I've seen a lot of games written in fully OO code that were efficient.
T.
#6716 - MumblyJoe - Mon Jun 02, 2003 5:44 am
OK, I am biased in this regard as I love C++ and loathe reading code that is all C.
Regardless, according to all the books I have read oc C++, it can be faster than C if done right. In fact there was originally a guarantee from the C++ committee that C++ would be at least 5% faster than C, to get people to convert. I dont know if it's true or worth it but I read it somewhere in a text book.
Anyway, people keep saying to avoid virtual functions in a GBA game but I believe that they are the way to go almost always. I dont know how good the gcc compiler is at doing optimisations of OOP, but I know that most good compilers will only use the code to call a virtual function if you are using pointers or references when calling it, otherwise the code to call that function directly is inserted. An example:
| Code: |
class A
{
public:
virtual void Draw(){}
};
class B : public A
{
public:
void Draw(){}
};
int main()
{
A a;
B b;
A* list[] = {&a,&b};
a.Draw(); //No dereferencing to call function.
b.Draw(); //No dereferencing to call function.
list[0]->Draw(); //Dereferencing.
list[1]->Draw(); //Dereferencing.
return 0;
} |
So you can still cut out the overhead of a virtual call sometimes. As for the vtable and vptr they will always be there as far as I know but thats more of a size than speed issue. Regardless the speed cost of dereferencing a virtual function is incredibly small, and seems even smaller if you compare it to the C style of long conditional statements that need to be checked to call the right function.
Then you have the fact that a tight OOP implimentation can make a program smaller as well and it seems to me the answer is if you know C++ (and I mean actually know it, not just understand classes) then use it, otherwise stick with C and your bad 1970's style of coding.
_________________
www.hungrydeveloper.com
Version 2.0 now up - guaranteed at least 100% more pleasing!
#6728 - torne - Mon Jun 02, 2003 10:14 am
No, nothing in C++ is innately faster. It just sometimes allows better design.
Yes, virtual dispatch is only used when dispatching through a pointer or reference; but you can only invoke methods directly on objects allocated on the frame, which is usually very few of the objects you are using. There's no way to directly call methods on heap objects, so you always take the hit. vtables and vptrs only take up space, yes, but the GBA doesn't have *that* much memory, and IWRAM is tiny. =)
The speed cost of dereferencing a virtual function is not guarenteed to be extremely small (consider multiple inheritence, for example), and polymorphism is frequently misused to produce code that is slower than a switch statement.
Nothing about object-oriented programming is likely to make your program smaller. The only way you'll get it to be smaller is by better design, which requires more than an OO language; it requires serious amounts of developer experience. Saying 'bad 1970s style of coding' is inaccurate too; anyone who knows Smalltalk, Objective C, or other more object-oriented languages wil tell you that C++ is just as dire a style of coding on the whole. =)
It's all about how you use the language; the language shouldn't be using you. It's perfectly possible to write clean, object oriented code in C (with the exception of convenient type polymorphism), you just don't get the syntactic sugar that C++ has; and I've done this on more than one occasion when developing for platforms where the vptrs are a significant hit. So, well, come down off that pedastal, and realise that it makes very little difference. =)
BTW, I don't program in C when I can avoid it, or C++. I use appropriate languages for the task, and I've yet to find a C dialect to be appropriate. =)
Torne
#6761 - Naaga - Mon Jun 02, 2003 4:35 pm
So what language do you feel is appropriate for GBA development?
#6765 - tepples - Mon Jun 02, 2003 4:57 pm
If you're experienced in C++, I'd suggest using C++ for game logic and C for low-level stuff. Just remember to turn off RTTI (if a design uses RTTI, its polymorphism may be flawed anyway), and don't overuse virtual methods. Also remember to use extern "C" properly in your headers.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#6768 - Jason Wilkins - Mon Jun 02, 2003 5:41 pm
MumblyJoe,
I like C++, but the readability of C++ can be absolutely horrible at times. A combination of classes, templates, and overloading can make it nearly impossible to figure out what is going on in any non-trivial piece of code without either actually running it in a debugger, reading some good documentation, and/or reading all of the code.
C++'s biggest problem is that you cannot always understand a piece of code in isolation. With C, you just have to dig down and understand what the called functions do, with classes you have to look upwards, and with overloading you have to look sideways, and with templates you jump into hyperspace!
I still like it, you just have to admit that it is very complicated and probably too complicated for what you are doing (whatever that is).
ADDENDUM: I am never one to say that something is absolutely bad or good, so lets look at the flip side.
Classes allow you to encapsulate code so that it is located in one logical lump. Overloading allows you to chose more sensible names for your functions. Operator overloading allows you to express code in ways that are more elegant. Templates allow you to write something ONCE, which has got to be my number one rule of good programming.
So why are some C++ programs so hard to read? Maybe it is because it does such a good job of hiding complexity, that when you go looking for how something actually works, you stumble upon complexity everywhere, and it compounds itself. This is fine as long as you don't have to fix something someone else wrote when it breaks ^_^
God forbid it be complex and badly written, I've been talking about good C++ code.
_________________
http://devkitadv.sourceforge.net
#6810 - MumblyJoe - Tue Jun 03, 2003 1:53 am
You make a good point Mr Wilkins, it can be a huge pain to maintain, and I have in the past rewritten whole programs of my OWN code rather than update it because I couldnt remember why I was doing it the way I was. Now I have learned that lesson and keep extensive notes and UML diagrams and comment my code a bit better, and it turns out ok in the end.
As a note I have been working on 2D game engine for the GBA in OOP C++ recently, mostly for my own use, and I have found using a 'Java' style of coding useful to keep it neat. In other words I use lots of internal subclasses and keep all code inline, and it seems pretty easy to read... so far, but it's not that complex yet. Besides, my theory is that if the code is slow where it is loading palettes and tiles and maps etc then I can fix that later, I'm more concentrated on getting the main loops for movement and collision detection to work better.
_________________
www.hungrydeveloper.com
Version 2.0 now up - guaranteed at least 100% more pleasing!
#6850 - MojoJojo - Tue Jun 03, 2003 1:31 pm
While C++ isn't strictly speaking slower, it does make it easier to do things slower.
For example, defining operator functions can hide the fact that you are doing lots of function calls and/or creating temporary variables, as was pointed out in the Floating Point thread in the Coding forum.
(Although, I'm not sure if defining operators has been back ported into C. Even if it has, you're far less likely to use it much).
When you use C++, the compiler does a lot more. This means it is a lot harder to work out exactly what it is doing, and means it is harder to make sure you're not doing something inefficiently.
#6862 - Jason Wilkins - Tue Jun 03, 2003 8:01 pm
I have not really settled on a C++ coding style yet. I think one of the rules will be to try and not compound complexity by combining too many features together at once. No problem is that complicated ^_^
I guess the reason that object browsers are so popular is that it is very easy to get lost in C++ code otherwise. I would love for someone to create a GUI that makes it easier to visualize templates and the results of combining them.
_________________
http://devkitadv.sourceforge.net
#6887 - Ninja - Wed Jun 04, 2003 6:16 am
I just wrote a class for sprite management in C++, and I found it to be exceptionally fast. I can release it here if there is a demand for it at all. I would have to replace the sprites though, as they are not mine, and the artist might be angry with me if I bundled them with a piece of code I made.
There are still functions I want to implement, but the base code is nice and fast. It would be good for beginners at least.