Skip to main content ↑ ↓
Topic: Actual "cross platform" engines (Read 122517 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Actual "cross platform" engines

I've seen engines around here claiming to be cross platform, but they require MSVC++ library, something that is obviously only on Windows. Is there any engine (newer than 1.5) that actually does run on Linux without WINE and is semi feature complete? WINE is ok, but I'd prefer to run it native, if possible.

Re: Actual "cross platform" engines

Reply #1 –
Sadly my SSFML engine is not cross platform, I'm not sure it will ever be. The reason for this is not SFML (it is known to run under Mono), but because of Jurassic which uses C#'s IL generator to cross-compile JS into IL bytecodes, which is a feature not yet added to Mono.

Once that feature is added to Mono, theoretically I'll have zero problems getting it to run cross-platform, supplied you have the Mono runtime installed.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Actual "cross platform" engines

Reply #2 –
But why should you need that? Why aren't there any implementations that run in pure SDL + OpenGL for hardware acceleration or something like that? I've been looking into restarting JavaSphere, but ditching applets, since Oracle has seen to it that those are utter crap now. I'd just go the Minecraft way and have it run as its own offline program.

Also, between SDL_audio and SDL_mixer, you should have all of the audio functionality and compatibility you'll ever need. Plus there's SDL_gfx, though I'm not entirely sure what that's for.

Re: Actual "cross platform" engines

Reply #3 –
Quote from: Eggbert – on

But why should you need that? Why aren't there any implementations that run in pure SDL + OpenGL for hardware acceleration or something like that?


Because it's incredibly hard and time consuming? And you'd need SDL and OpenGL too if they don't come statically linked or somewhere in the distribution.

Look at FJ. He'll have the most cross-platform engine besides Sphere and it's taken him years of rewriting and updating and scratching his head. Most of that was just figuring out V8 (a very commendable effort). He even had to test on multiple OS's and still not having it work and compile perfect without suffering a substantial headache. I'm sure it is definitely worth it in the end. But right now - at this very moment - Sphere-SFML plays to all the strengths of a managed, Object Oriented programming language like C# by being nearly 80% to 90% complete, and I hadn't worked on it for almost a year now, and that is also when I was working on an editor - that's also 90%+ complete (the first to do this, and succeed, mind you).

So, I don't know about you but I chose all the correct libraries and programming languages in order to succeed. And that's the truth. At, of course, an expense to multi-platform which is only a minor technicality since MONO hasn't matured yet in certain areas. But once it does, I'd be done - and leagues ahead of FJ (no offense). But just to say this: I hardly understand why anyone would want to program in C++ these days besides for the glory of it or the knowledge it'd bring to you (and the supposed "speed increase", that means rather little since we offload our games to shaders ran on another computing chip - your graphics card - meaning theoretically, program execution speed doesn't make you zip through vertices any faster than any other programming language, since graphics are usually the bottle neck in games and not execution speed of the primary logic language). I'm not even sure FJ has unit tests, which could have even been a 'time waste' but I went ahead and added a few of them anyways just to mark my progress against Sphere's API (it's where I draw my % completion from, BTW).

I could talk on for miles about this, but I'll leave it at that. FJ has his thing, and I have mine and I always enjoy reading his posts.

That said, I equally endorse any Java builds of Sphere since that too, blows C++ and even C# out of the water in terms of cross-platform, and ease of use to make a project hit the 'finished' milestone as soon as possible by a single individual. And it may play nice to Android versions and other devices.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

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.

Re: Actual "cross platform" engines

Reply #5 –
Quote from: Radnen – on

That said, I equally endorse any Java builds of Sphere since that too, blows C++ and even C# out of the water in terms of cross-platform, and ease of use to make a project hit the 'finished' milestone as soon as possible by a single individual. And it may play nice to Android versions and other devices.


I don't know, I can't help but feel that Java is dying a slow and painful death under Oracle's management (I can't really explain this, it's just the impression I get), and that's just going to accelerate now that MS is fully open-sourcing .NET and even officially supporting the Mono project, trying to make .NET fully cross-platform.  Point taken on Android, but I don't know, I just think C# is a much nicer language to program in than Java.

Re: Actual "cross platform" engines

Reply #6 –
Quote from: Flying Jester – on

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.


Yeah, I actually agree with you there. And you did learn a lot about C++ making TS! That's totally a good skill to bring into the job market and even though I generally don't care about C++ as a language, the industry still has a grasp on it. A lot of game companies really do use it and it doesn't look like it's going away anytime soon.

Quote from: Lord English – on

I don't know, I can't help but feel that Java is dying a slow and painful death under Oracle's management (I can't really explain this, it's just the impression I get), and that's just going to accelerate now that MS is fully open-sourcing .NET and even officially supporting the Mono project, trying to make .NET fully cross-platform.  Point taken on Android, but I don't know, I just think C# is a much nicer language to program in than Java.


Hey, I feel the same way, too. But there are some neat libraries in Java such as Lightweight Java Game Library and Android stuff. The only good thing I like about Java was that somehow, early on, it was able to be distributed to many different kinds of OS's. C# being a Windows thing kinda made it only a Windows thing (until Mono, that is).
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Actual "cross platform" engines

Reply #7 –
Resurrecting the topic, as now I can definitively answer the question: minisphere is written in straight C and is cross-platform; it's already been compiled on Linux and OS X with no code changes.  Allegro is its sole dependency.
 

Re: Actual "cross platform" engines

Reply #8 –
Quote from: Lord English – on

Resurrecting the topic, as now I can definitively answer the question: minisphere is written in straight C and is cross-platform; it's already been compiled on Linux and OS X with no code changes.  Allegro is its sole dependency.


But every time I've compiled it, Allegro has thrown some assertion or I've hit a segfault you don't get on Windows.
I assume that the ones I've hit are fixed, but this is the same kind of issue that TurboSphere suffers from. Without dedicated platform releases, I hesitate to call it truly cross platform.

Re: Actual "cross platform" engines

Reply #9 –
Quote from: Flying Jester – on

Quote from: Lord English – on

Resurrecting the topic, as now I can definitively answer the question: minisphere is written in straight C and is cross-platform; it's already been compiled on Linux and OS X with no code changes.  Allegro is its sole dependency.


But every time I've compiled it, Allegro has thrown some assertion or I've hit a segfault you don't get on Windows.
I assume that the ones I've hit are fixed, but this is the same kind of issue that TurboSphere suffers from. Without dedicated platform releases, I hesitate to call it truly cross platform.


casiotone has compiled it on OS X, that's the joystick assertion fixed in 1.0.10.  Can't speak for segfaults, but he didn't mention any to me.

But yes, I'll agree that it needs real testing on non-Windows platforms.  I recently set up Hyper-V on my Win8.1 laptop, so I should be able to build on Linux soon, at least.  Unfortunately OS X is out of my league, unless I can can manage to make a Hackintosh setup somehow...

Re: Actual "cross platform" engines

Reply #10 –
Minisphere has been very stable for me on Linux up to this point. Can't test the new releases for the time being, though.

Re: Actual "cross platform" engines

Reply #11 –
Quote from: Lord English

casiotone has compiled it on OS X, that's the joystick assertion fixed in 1.0.10.  Can't speak for segfaults, but he didn't mention any to me.

But yes, I'll agree that it needs real testing on non-Windows platforms.  I recently set up Hyper-V on my Win8.1 laptop, so I should be able to build on Linux soon, at least.  Unfortunately OS X is out of my league, unless I can can manage to make a Hackintosh setup somehow...

The joystick issue is the only thing I've encountered - it's been working perfectly otherwise. I haven't tested the entire API yet though, just some simple maps and image blitting.