Re: Actual "cross platform" engines
Reply #4 –
My engine runs right now in Linux and OS X.
In the past, it has been relatively easy to get a halfway working port to Windows. This has a big issue, though. I simply no longer use Windows for any real work, and so I simply don't test my engine in Windows.
This has resulted in very buggy Windows releases of TurboSphere. Which in retrospect is really sad, since almost everyone tests it using Windows. The engine is portable to a degree, but it's not maintained for any non-Unix OS. If you aren't using OS X, you are likely going to see many bugs in TurboSphere that I have never seen myself.
To be sure, I was lured in to the appeal of the ultimate power of native programming. It's been a while. I stay there because many of the most mature, best maintained, and most performant libraries are written in C or C++.
I do not have unit tests. When I began TurboSphere, I had never heard the term. By the time I became aware of the advantages of test-drive development, It would have been a lot of upfront work. Then I wrote the OpenGL renderer. Then I updated to OpenGL 4.0. Then I wrote Sapphire. Writing unit tests at any given point will surely make things easier in the long run. But recently I've been more concerned with stopping the mass regressions in the TS API. I want to get back to where I used to be with the old graphics plugin, because back then a lot of old Sphere games that didn't use the map engine actually worked. I miss that.
To be certain though, the biggest delay for TS have been the fact that this is how I actually learned to program. The first two or so years were basically just me doing that.
But I don't even consider the goals of SphereSFML and TurboSphere to really have the same goal. TurboSphere's mission really did change at some point, about a year and a half ago. Now, it's a combination of writing a new Sphere-like engine that runs on platforms other than Windows (more esoteric platforms such as Solaris are of special note to me), and doing things that I find interesting that can be used in a game engine. Almost everything I do works toward one of these two goals. The second is really a follow on to what I've always used Sphere for. I rarely make full games, because often I just want to see some certain effect, or work on some specific algorithm or idea. I find that satisfying.
Whether or not the intended purpose of SphereSFML is this or not, I see it as more an attempt at a well built, simple, and modern Sphere engine. C# can fit those qualities just fine. Given that a majority of people (especially gamers) use Windows, it makes a lot of sense to really only worry about Windows.
These missions are not really in contention. They are both forks of different parts of what I think makes Sphere be Sphere.