SpritesMind.Net

Will SGDK ever meet C++?

SGDK does not support C++ as it requires more binaries and libraries to get it work (actually a lot more). I always wanted to maintain SGDK size to the strict minimum requirement, also C++ add some overhead which might hurt for megadrive development...
Still i agree it would be nice to have C++ (and so OO programming) support, that may be something to thing about... I believe Chilly Willy already got C++ support on with 68k targeted gcc and he reported overhead was not that heavy. Problem is that i really want to stay on gcc 3.4.6 for SGDK as newers version are really awful in term of code generation for 68k target.

My toolchain does support C++ and comes with a C++ example. You can't use SGDK with it, but you could use pieces from it where needed.

The ridiculous overhead is if you include the iostream... the example is a few hundred KB with it, and less than 64KB without it. The facility that strips unused library code doesn't work on MD binaries due to the binary blob at the start.

By binary blob you mean the inclusion of the header binary right ?
I do not see how to handle it so we can easily modify it without modifying the sega.s file directly.

Do you mean binary blob like the Linux,the kernel includes if so a binary blob has the bad side-effect of making all programs that use it non-free software. I would assume that non-free binary blob can easily be replaced with a free-software replacement. I don't see the need for a binary blob.

sega16 wrote:Do you mean binary blob like the Linux,the kernel includes if so a binary blob has the bad side-effect of making all programs that use it non-free software. I would assume that non-free binary blob can easily be replaced with a free-software replacement. I don't see the need for a binary blob.

I assume Chilly is referring to the cartridge ROM header which is just a 68K exception vector table and the Sega header which contains the 'SEGA' string that's checked by the TMSS and some useful information which in the modern context is probably mostly useful for emulators. At the very least, the vector table is strictly required and at least the 'SEGA' string is required for TMSS systems.

I wonder if the dead code elimination issue could be fixed by producing a proper ELF binary and then producing a final binary with objcopy and perhaps an extra script or two.

The compiler is used to stripping a regular ELF file with a standard entry vector. I may try to find a way to strip the file before adding the rom header and making the final binary. At the moment, it's not very critical - just avoid iostream, which isn't useful on a console anyway.