GP2X Gp2x And C++

[yaustar]

Just started looking at the gamecube dev kits (SN Systems) at University and was fairly shocked that it didn't really support some of the C++ basics such as Virtual tables and templates. Even the defualt keywords 'new' and 'delete' have to be redefined. So how well does the GP2X handle it? Will using virtual functions slow it down considerably?

 

[Mr.Jabberwocky]

The way you phrased this implies C++ is some sort of inherent functionality of the GP2X itself. I seem to remember another thread where I was left with the same impression. Anyone learning is going to end up believing the same.
Just to clarify - the GP2X has no idea what C, C++, Python or any other language is. High level languages are a symbolic code created to make programming easier for humans. The implementation of the language is down to the compiler not the GP2X.
Should not the question be : how does GCC handle it ?

 

[MadDog]

Just started looking at the gamecube dev kits (SN Systems) at University and was fairly shocked that it didn't really support some of the C++ basics such as Virtual tables and templates. Even the defualt keywords 'new' and 'delete' have to be redefined. So how well does the GP2X handle it? Will using virtual functions slow it down considerably?

Don't know what version of GCC your using, last time I used SN tools they were still on GCC, was some talk of them doing thier own compilers.(ps2 I think) There was a time that SN was using a bust version of GCC, 2.4 or something I think, I worked with Gil J Smith for a while, he had all the gossip having worked at SN for a few years. First thing you should do is make sure its all up to date, really sounds like your not. If you get real stuck with your GC stuff drop me a mail and i'll do a bit of investigating for you.

Spartan: Total Warrior (last game I work on) was as C++ as you can get and the GC was fine with that. As Mr.Jabberwocky says, its the compiler more than the HW that gives support.

There are some issues with the way C++ works that could give some bits of HW a hard time, this is because C++ can be a bit thrashing of memory. Its very powerful but with power come responsibility. Its very easy to 'balls' it up.

As a side note, the GC had very quick memory, so out of the three consoles its prob the best for C++. (don't quote me on that)

I'm using C++ in my code, having looked at the HW over the last few weeks I don't see why C++ could cause probs, at the end of the day, if some code is going slow the first thing to do is see if changing the algo will make it quicker. Only when your sure that the algo is the best way then for heavy code drop in to asm, its the only way.

If your looking to go into games development then C++ is a must, very few dev houses use C only these days.

 

[yaustar]

Mr.Jabberwocky: Point taken.

MadDog: I see what version the University is using and drop you a PM/email. Thanks..

 

[Mr.Jabberwocky]

For speed I am not convinced that c++ is the best option on a relatively weak device such as this. In a commercial environment developing for powerful machines it makes sense in terms of productivity and maintenance. For a hobbyist trying to squeeze the most out of a GP2X I feel the inevitable overheads that it introduces are a reason not to use it.
It seems a little perverse to me to program in c++ and pay the price in terms of speed and then have to resort to assembler to compensate.

 

[TKF15H]

C++ is not something to stay away from for speed reasons. Most of the time, if code runs slowly, it's an algorithmic fault (the idea behind the algorithm is slow, not the code itself).
Virtual functions in C++ (used in the right moments) can actually be used as an optimisation, while they can also slow your game down to a slideshow. Up to you.

 

[yaustar]

Virtual functions in C++ (used in the right moments) can actually be used as an optimisation, while they can also slow your game down to a slideshow. Up to you.

Can you give me a quick example of both situations?

 

[TKF15H]

Good:
class Monster{
... stuff ...
public
virtual void DoAI() = 0;
};

Rather than doing a chain of if's or some switches (depending on the compiler a switch may be compiled into an 'if' chain, and in some situations it may be optimized with a jump table, in which case it may be slightly faster than a virtual function call).

Bad:
(probably not a very good example, but it's the only thing I could come up with at 1am. And in English++ )

For each Object in ObjectList
For each Polygon in Object.PolygonList
Polygon.Rasterize()
Next
Next

class Polygon{
List<f32> Vert;
public:
virtual void Rasterize() = 0;
};

class GouroudPolygon : public Polygon{
virtual void Rasterize(){ ... }
};

class PhongPolygon : public Polygon{
virtual void Rasterize(){ ... }
};

class PlainPolygon .... etc....

This is bad because the number of virtual function calls are pretty high and in a speed-critical location. The AI call shown previously is called maybe around 50 times per game loop, while the polygon rasterization thingy is probably called at over 1000. It won't turn your game into a slideshow, but I couldn't come up with anything better ATM.

Must... sleep... zzz...

 

[foft]

Just started looking at the gamecube dev kits (SN Systems) at University and was fairly shocked that it didn't really support some of the C++ basics such as Virtual tables and templates. Even the defualt keywords 'new' and 'delete' have to be redefined. So how well does the GP2X handle it? Will using virtual functions slow it down considerably?

In short, it just works. No redefining new/delete etc since its all running on Linux. Much simpler than it was on GP32...

Just make sure you have a recent g++. Also if using c++ it will need the correct libstdc++ to run unless you do a static build. I'm not sure which C++ libs the GP2X has on by default.

Mark

 

[Mr.Jabberwocky]

It is great that you guys are so helpful, but I am getting a bit confused by some of the things you are saying.

C++ is not something to stay away from for speed reasons.

This is bad because the number of virtual function calls are pretty high and in a speed-critical location

Your first statement implies speed is not a consideration yet your second states it is. Could you clarify, please.

In short, it just works. No redefining new/delete etc since its all running on Linux

What does linux have to do with wether/how gcc implements the new/delete commands ?

Also if using c++ it will need the correct libstdc++ to run unless you do a static build.

I was under the impression we had to statically build when using the current toolchains. Could you explain the role of libstdc++ and tell me how I know which is the right version and where to get it. Does this mean no more static linking ?

I also fail to understand why a virtual function should be so expensive. At the end of the day is the function not just selected from a list of pointers ? The code to manage this is going to be an overhead indepent of function type, surely ?

 

[TKF15H]

Your first statement implies speed is not a consideration yet your second states it is. Could you clarify, please.

I mean to say that C++ is good but you have to be carefull. It has features that can be used badly.

 

[slygamer]

Just started looking at the gamecube dev kits (SN Systems) at University and was fairly shocked that it didn't really support some of the C++ basics such as Virtual tables and templates. Even the defualt keywords 'new' and 'delete' have to be redefined.

We use CodeWarrior for Gamecube at work and it supports everything that every other C++ compiler supports, and it is even more strict in conformance to the C++ standard than CodeWarrior for PS2. We have the same C++ code, with virtuals and templates and everything, compiling under Visual C++ (PC, Xbox), CodeWarrior (PS2, GC), GCC (PSP) and SN Systems (PSP). I have never experienced the problems you describe.

 

[yaustar]

Doh'. I am going kill the guy that spread that rumour around. The SN systems compiler DOES support inheritence/virtual tables etc. Sorry everyone, my bad.

 

[MSweeney]

Doh'. I am going kill the guy that spread that rumour around. The SN systems compiler DOES support inheritence/virtual tables etc. Sorry everyone, my bad.

Just my 2c to this thread..

C++ is not 'slow', in fact when used correctly C++ can dramatically improve the performance of complicated programs and algorithms. The problem is that people often over-use and abuse the OOP concepts that C++ is s o well known for - this in turn can lead to slow, unwieldy applications.

Basically it comes down to understanding the differences between classic C and C++, and knowing when to use structs over classes, aggregation and composition over inheritence, etc. etc.

 

[thingy88]

Slightly late contribution to this thread... :rolleyes:

This doc Technical Report on C++ Performance provides a fairly thorough analysis of the costs and overheads involved with using the many features of C++.

C++ is pretty good in that, in general you don't pay for any features you don't use, and you can turn off features that affect the whole program such as exceptions and RTTI with compiler switches. This means that you can use its advanced features where you can afford them and not use them in parts of the program where you feel that you'll get a performance increase by doing things the C way. Although as with all optimisation you should of course 'avoid premature optimisation' and 'profile your code so you can actually measure the performance increase'... you know the drill...