#200 - GbaGuy - Sun Jan 05, 2003 3:06 am
Does anyone use C++ on the GBA?
or do most people stick with C?
Would OOP actually help any if one encapsulated the
sprites and stuff in classes and overloaded operators
for say DMA among other things?
I guess what I really want to ask is: are there any reasons
to use C++ on the GBA?
thanks,
- GbaGuy
#201 - Dragonsimoto - Sun Jan 05, 2003 3:25 am
you can use what you want really.
The only thing is that c++ tends to be a slower executable.
_________________
GBAFAN/GBADEV(soon)
#202 - kemu - Sun Jan 05, 2003 3:45 am
| Dragonsimoto wrote: |
you can use what you want really.
The only thing is that c++ tends to be a slower executable. |
but in return you get that powerfull OOP
#204 - Dragonsimoto - Sun Jan 05, 2003 3:57 am
yeah i know. But there is a pro/con to everything :)
_________________
GBAFAN/GBADEV(soon)
#213 - Burre - Sun Jan 05, 2003 4:49 am
I use C++, to the benefit of OOP as someone stated earlier. I prefer OOP since it simplifies structuring my code. If it turns out to take to much of a hit on execution times I'll just have to optimize in ASM (but I hope not). Does anyone know how big the difference is between C and C++ using gcc? I saw some comparison table some time ago but that was for the x86 achitecture. Anyhow, it feels like the benefits more than even the loss of performance.
_________________
"The best optimizer is between your ears..."
#216 - Touchstone - Sun Jan 05, 2003 5:32 am
Actually C++ doesn't have to be slower than plain C. You could say that using templates and overloading operators result in same speed performance as plain C. When it comes to memory overhead templates are evil. I don't know about overloaded operators but I don't think they use that much memory. Using virtual methods result in a certain memory-overhead for each created instance of a class and I think the code will get slower to because it has to take a look in the vtable of it's instance before executing the method. On the plus side you get much nicer looking code when using C++. I think using C++ for gamecode and C/ASM for speed critical code such as rendering, music etc is a good mix.
#217 - kemu - Sun Jan 05, 2003 5:33 am
where did you saw the difference between c and c++ do you still have that site ?
#237 - Burre - Sun Jan 05, 2003 1:38 pm
| kemu wrote: |
| where did you saw the difference between c and c++ do you still have that site ? |
No, I don't have the site bookmarked :(. I only stumbled upon it when looking for other things. However, since it only shows performance difference between different compilers, wich isn't a reliable reference since compilers can be optimized to different degrees and differently to different chipsets. Don't think that one can make a general comparison between the languages because of that. However, C++ should theroeticaly be somewhat slower since it often executes more code. Following the same algorithm in ASM for example should gain speed, but most highlevel languages shuffle the pipeline quite well so de diffence souldn't be astronomical. However, since C++ benefit from OOP, it should help you write more clever algorithms and help you from writing 'slow code'. But nothing touches ASM when it comes down to executions speeds, for obvious reasons. So I should write the code in C++ and aftewards optimizing CPU intensive parts of it in ASM if I felt the need for it. That way, you'll benefit from OOP and get a pretty fast app in the end using embedded ASM code when needed.
_________________
"The best optimizer is between your ears..."
#338 - KashinKoji - Mon Jan 06, 2003 5:46 pm
I use C++, but I am only working on a relatively small project right now. I think so far my main worry is the amount of memory I seem to be using with my classes. My code is slick, I think, but to make it readable and easy to use I find that I really pack the variables into my classes.
Does anyone know what kind of speed hit an OOP design will really make? I mean if you use data abstraction and have to pretty frequently call get_ functions and the like, the overhead could really stack up...
But I guess that is what experiments like my project are for. Anybody gone down the OOP road and turned back?
#345 - Burre - Mon Jan 06, 2003 6:40 pm
| KashinKoji wrote: |
| Does anyone know what kind of speed hit an OOP design will really make? I mean if you use data abstraction and have to pretty frequently call get_ functions and the like, the overhead could really stack up... |
Many function calls causes lots of branching, and branching is a potential source for slowdowns. Its not only that the branching (and return) in it self is taking some clockcycles to execute. It also involves placing the program counter and registers on the stack. How big the difference is, is hard to say, it depends on how the application is written. Some things might even execute faster in C++ than C, depending on optimizations and differences in the language.
_________________
"The best optimizer is between your ears..."
#451 - tom - Tue Jan 07, 2003 8:12 pm
| KashinKoji wrote: |
| Does anyone know what kind of speed hit an OOP design will really make? I mean if you use data abstraction and have to pretty frequently call get_ functions and the like, the overhead could really stack up... |
I suppose with get_functions you mean short methods that basically just return you the content of some member variable, instead making these variables public. If you make these functions inline, a good compiler (like gcc) is able to optimize such function calls completely away.
Another thing are virtual functions. These require a look up in the object's
virtual function table, so when calling virtual functions you end up with a table look up and then a function call. But even then, what would you use in C where you don't have virtual functions ? You would either shuffle around with function pointers yourself, or maybe decide with a switch statement which function to call. Just don't make your functions virtual if it isn't really necessary.
C++ code isn't that much slower than C code as people often believe.
#452 - arog - Tue Jan 07, 2003 8:13 pm
I use C++ with HAM. You can take a look at my Hearts game
I wrote. It ain't pretty, but it's open source!
http://www.aaronrogers.com/ham/Games/HAM_Hearts/ham_hearts.php
- Aaron Rogers
HAM Tutorial
#902 - animension - Sun Jan 12, 2003 12:48 am
I like the idea of mixing C++ / C code, C++ for game and structure based code and C for speed based code.
If you need OOP like structuring in a speed critical app, consider this: the call myobject->mymethod(param1,param2) can be simulated in C as mymethod(&mystruct, param1, param2), and resultswise you can accomplish the exact same thing almost everytime.
Also as mentioned earlier, accessor methods to object members (get and set functions) can be used as inline functions but be aware that you gain speed at the expense of larger code. If you make a call to a particular function a large number of times, you should stay away from inlining as it will swell your code up a lot. However, if you don't call a function very often, inlining it would be a good optimization for speed.
Personally, the nicest thing I like about C++ as opposed to C is that it is a bit more "relaxed" and performancewise is only slightly slower for most purposes. For high-performance code chunks that deal with large amounts of data, this slight difference can add up to a pretty large difference, thus the suitability of C or ASM to do these things.
#2090 - princew - Wed Jan 29, 2003 5:50 am
I've used C++ in all of my games. I come to use it better the more I go, but I definately prefer an Object Orientated sytle of programming to flat out C. As for speed I've found C++ to be plenty fast for my needs. My Bust-A-Move and Asteroids game's were all C++ and I never really had any issues with framerate. As long as you write good clean code you should be ok. Crap code will run like crap with C or C++.
My Asteroids game is open source which uses a sprite class I wrote about a year ago if anyone is interested in looking at it, or using it. It encapsulates most of the DMA work needed for manipulating sprites.
Russ Prince
http://www.russprince.com/gba
#2267 - col - Fri Jan 31, 2003 11:03 pm
| animension wrote: |
...If you need OOP like structuring in a speed critical app, consider this: the call myobject->mymethod(param1,param2) can be simulated in C as mymethod(&mystruct, param1, param2), and resultswise you can accomplish the exact same thing almost everytime. |
And it will run at exactly the same speed - no faster, but the code is more difficult to follow...
| animension wrote: |
Also as mentioned earlier, accessor methods to object members (get and set functions) can be used as inline functions but be aware that you gain speed at the expense of larger code. If you make a call to a particular function a large number of times, you should stay away from inlining as it will swell your code up a lot. |
An accessor function that is inlined and just returns a member variable will use no more code than accessing the variable directly would!!
(Also remember that if you are inlining very small functions - your code will usually be _smaller_ than if you didn't use inlining!! - because often the call/return code would be bigger than the inlined function would be). To clarify - with a good compiler - using inlined accessor methods will in most cases, cause no size overhead, and no performance overhead! you just get the huge benefit of encapsulation.
| Quote: |
performancewise is only slightly slower for most purposes. For high-performance code chunks that deal with large amounts of data, this slight difference can add up to a pretty large difference, thus the suitability of C or ASM to do these things. |
[RANT]
I don't understand why so many people are resigned to the idea that c++ is always going to be slower!!
On gba with gcc, if you switch off exceptions and rtti, and then write good c++, taking advantage of the more powerful programming constructs that c++ offers - a good programmer will be able to write code that is *at least* as fast as c. They will also produce code that is more flexible, more robust and easier to maintain( not to mention read).
Also If you absolutely *NEED* to optimise further - forget c, you'll have to write assembly! if c++ is too slow, then the problem is either the hardware, your coding or the compiler - these issues won't go away if you switch from c++ to c...
If you like to code in c - code in c, its a great language, but don't kid yourself that it gives you some kind of advantage over using c++. If you've tried c++ and found performance/size issues, then you probably need a deeper understanding of c++ and oop, there are so many potential pitfalls and most of them are subtle...
[/RANT]
cheers
col