Re: TurboSphere
Reply #154 –
TurboSphere doesn't have anything more (and it's not done, so often less) than Sphere does. It does have more potential to, just because a 2.5D or 3D plugin could be made for it. I did have a ray-tracing 3D plugin working for a short time while I was working out the plugin API, but I never released it. It a software renderer (and was ray-tracing), so it was far, far too slow for realtime use. But even then, an OpenGL or DirectX 3D plugin was quite possible, and still is.
I do plan on adding very basic 3D/2.5D support to the core graphics plugin, mainly just primitives and textured polygons with no perspective, for effects like those from Castevania Symphony of the Night. I don't want to get into anything much more than that in the SDL-GL plugin pack, though. That sort of functionality is also something I'd much prefer to add to a sprite batcher, too. It would be much more elegant that way.
I was wrong before, use GCC 4.6 usually, although it did compile on 4.8 not too long ago and I'll bet it still does. I used to use C++11, but at the moment I'm not because when I moved to Scons I didn't add the switch to use it, and I started using adjacent string literal concatenation, which apparently doesn't work in C++11. That is, as far as I know, the only thing in TurboSphere that doesn't work with C++11.
The main problem with getting TurboSphere working from scratch is compiling V8. TurboSphere proper seems quite content to compile with just about any toolchain, it seems.
I would worry a little about things like XCode or MingW, because for everything that needs to work differently on Windows and Linux (GCC and MSVC), I check for _WIN32, and then assume GCC otherwise, and in only a couple places where something really is MSVC or GCC specific (and probably not always then) I check for MSVC or GCC.
It does compile with the Intel Compiler on Windows, though. But I can't distribute those binaries due to the license. And sometimes it's notably slower (particularly the software graphics use, like surfaces and surface primitives) because if I set it to use more than MMX vectorization it makes binaries that refuse to run on AMD processors, like mine (even if I just enable 3DNow!, which makes no sense from a technical standpoint).