SpritesMind.Net

The more I come along in my project, the more I realise it would be nice to have some object-orientation. Would SGDK work with C++? Has anyone ever used it with C++ before?

I do not provide C++ support currently as it adds some overhead compared to C. Depending your code you can keep it low but when you work on such limited system you want to avoid them as much as possible. Also i believe adding C++ support requires more than just adding g++ binary...
Still that is a possible addition and anyone who want to use C++ can add the G++ compiler. I would need to modify the headers (adding required extern "C" block everywhere) to make then compatible with C++ sources though.

My own personal toolchain supports C++ and comes with a C++ example. It's not as full featured as sgdk, but if you just have to use C++, you might give it a try. The catch is you have to build it yourself. I just show how to build the toolchain and provide things like linker scripts and such. Start by reading the thread.

viewtopic.php?t=889

My Linux build toolchain that I think you are using, Zontar, is based off of ChillyWilly's and should have c++ support already built.

I don't actually use C++ for Genesis development since it will be less efficient and lead to a larger file size, so I can't say how well this will work, but you ought to be able to link this with the SGDK archive.

You may need to wrap the headers with the 'extern "C"' syntax stuff. See: http://www.cplusplus.com/forum/general/1143/

There may be more fiddling required, but you should be close to setup already for this.

Building the toolchain with c++ support is also on my todo list.

I do not provide C++ support currently as it adds some overhead compared to C.

I am curious as to what you mean by that. Speed or size? Or both? Did you benchmark it, and if so what optimization flags did you use? I am wondering because when I coded a bit for the GBA, I tested some code in C and C++ and didn't find any overhead in execution speed for my code. The libraries also look as if they would compile without much changing.

Btw: Is building the gnu toolchain a lot of work? I never tried it and I really would like a new version of gcc, since the one provided with SGDK has a nasty bug that randomly stops compiling ("couldn't allocate heap" [...] "died waiting for longjmp") that IIRC only happens on x64 systems.

Stef wrote: Building the toolchain with c++ support is also on my todo list.
...
I am curious as to what you mean by that. Speed or size? Or both? Did you benchmark it, and if so what optimization flags did you use? I am wondering because when I coded a bit for the GBA, I tested some code in C and C++ and didn't find any overhead in execution speed for my code. The libraries also look as if they would compile without much changing.

Well if you use the OO advantages of the C++ language (as inheritance) ans stuff like that, it would necessary add some overhead (vtable to fetch correct methods for instance). GBA already has a more powerful CPU so the overhead might be lighter also it depends a lot from your code, if you code in C with C++ of course it won't make any differences. Sometime also the compiler optimizations are different and you can even get better performance from the G++ compiler but with an older target as the m68k, generally older compilers outperform newer ones.

Btw: Is building the gnu toolchain a lot of work? I never tried it and I really would like a new version of gcc, since the one provided with SGDK has a nasty bug that randomly stops compiling ("couldn't allocate heap" [...] "died waiting for longjmp") that IIRC only happens on x64 systems.

Compiling the toolchain can consume time, you have to take care about defining correct parameters and almost time you experience some issues during the compilation process... I know about the annoying bug, i also got it and it's true it would be nice to get rid of it. Something to know about newer GCC version, they do produce awful code for m68k target so i really recommend you to test them before fixing on a specific version (when i build the initial GCC version for SGDK i used 3 different version and the oldest one produced the best code).

You don't need C++ to write object-oriented code.

Linux core writen in C (as far as I remember). And I don't think that FILE - is not object.

Of course you can everything in C but still having C++ make OO programming far easier I just translated a java program to C code is it was a big pain in the ass compared to C++ translation :p

twosixonetwo wrote:I am curious as to what you mean by that. Speed or size? Or both? Did you benchmark it, and if so what optimization flags did you use? I am wondering because when I coded a bit for the GBA, I tested some code in C and C++ and didn't find any overhead in execution speed for my code. The libraries also look as if they would compile without much changing.

Mostly size. These days, the gcc C++ compiler is nearly as fast as the C compiler, but the size is a bit of an issue. I'm not sure why exactly, but the optimizer has trouble removing unneeded library code, so even just adding the include for iostream adds ALL of iostream, or about half a megabyte to the size of the rom. If you look at my C++ example, compile it with and without the include for iostream and look at the difference in the output roms.

Btw: Is building the gnu toolchain a lot of work? I never tried it and I really would like a new version of gcc, since the one provided with SGDK has a nasty bug that randomly stops compiling ("couldn't allocate heap" [...] "died waiting for longjmp") that IIRC only happens on x64 systems.

It's super-easy in linux. I give step by step instructions in the thread. It's slightly more work in Windows since you need to setup CygWin or MinGW. If you aren't familiar with either, then you have the extra work of learning that before you can build the toolchain.

Stef wrote:Something to know about newer GCC version, they do produce awful code for m68k target so i really recommend you to test them before fixing on a specific version (when i build the initial GCC version for SGDK i used 3 different version and the oldest one produced the best code).

The old compiler does produce faster code, but my opinion on that is if you NEED code that is faster than the new compiler can make, you should be using assembly language for that part instead of C in the first place.

You have the point But still imo the latter GCC really produces bad code for m68k and SGDK performance is really impacted by that :-/

Stef wrote:You have the point But still imo the latter GCC really produces bad code for m68k and SGDK performance is really impacted by that :-/

I think you're overplaying it. "Bad code" was what... 10% the last time someone did any tests? Hmm - maybe we should set up some tests to see what the value is at various optimization levels.

Chilly Willy wrote:

Stef wrote:You have the point But still imo the latter GCC really produces bad code for m68k and SGDK performance is really impacted by that :-/

I think you're overplaying it. "Bad code" was what... 10% the last time someone did any tests? Hmm - maybe we should set up some tests to see what the value is at various optimization levels.

In my case it was really more than 10%, a demo running at 16 FPS with GCC 3.4.6 was running at 11 or 12 FPS with GCC 4.4.x... And that is, at comparable optimization level. Anyway, you can easily replace the defaults SGDK compilers

Stef wrote:

Chilly Willy wrote:

Stef wrote:You have the point But still imo the latter GCC really produces bad code for m68k and SGDK performance is really impacted by that :-/

I think you're overplaying it. "Bad code" was what... 10% the last time someone did any tests? Hmm - maybe we should set up some tests to see what the value is at various optimization levels.

In my case it was really more than 10%, a demo running at 16 FPS with GCC 3.4.6 was running at 11 or 12 FPS with GCC 4.4.x... And that is, at comparable optimization level. Anyway, you can easily replace the defaults SGDK compilers

So 25%... definitely time for another round of checks. I wonder if they've improved that any... or if it got worse.

From my last checks out was getting worse, but maybe absolute latter version are better, I've to admit I didn't checked from sometime now.
Of course for better test you need to benchmark 100% C code, I say that because sgdk uses assembly sometime.