Skip to main content ↑ ↓
Topic: Where should Sphere compete? (Read 83131 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Where should Sphere compete?

"I will be using turbo-sphere for all intents and purposes for this topic, thank you!"

Sphere is a nice toolkit, for basic 2D games and limited in the department of effects that can be done so competing against current versions of Game Maker, or RPG Maker is silly (for effects and gfx) but the core of the game should always be doable on any system so let's focus on that.

Sphere is ancient, turbosphere is using Google v8 which I have yet to look over as I thought of writing a javascript extension for game maker (I'm beginning to like js) and improves on the current api, I did manage replicate mode7 across the board wit 2D engines using the formula that's on Wikipedia and performance is doable but I'm using static images not data from map files, tried taking a screenshot of the map every 2-3 frames impacted performance on sphere heavily.. but barely impacted on Unity and Game Maker studio (I've hated GML for awhile now but man, for snes console rpgs it's perfect for that task).

I've also tried particles in sphere and at the end of the day kinda gave up because performance is horrible...   I really think sphere needs a brand new base not just forking the project and a modern UI (dark gray is perfect as I work on games at night as I have a life... not. I just can't work under the sun).

I really think OpenGL + SFML would be a nice start and a breath of fresh air and implementing the current api into a modern engine should be cleaner as my jaw pretty much dropped to the floor after looking at the source (not a good thing).

Re: Where should Sphere compete?

Reply #1 –
Quote from: Rukiri – on

[snip...] as my jaw pretty much dropped to the floor after looking at the source (not a good thing).


I actually had the opposite reaction when I looked at the Sphere source (had to sift through the code a couple times to diagnose bugs in Spectacles), the code was a lot cleaner than I expected it to be (barring any oddball stuff like the hq2x filter), I've seen much, much, MUCH worse.  But I will agree Sphere is dinosaurian, half the middleware it uses is a decade old (particularly Audiere and Corona, but even the SpiderMonkey version it uses is hopelessly outdated, not counting Sphere 1.7 since it's pretty much dead in the water).

As for TurboSphere though, you seem to be under the impression that it's a fork.  It's not.  What you described in your last sentence as "a breath of fresh air and implementing the current api into a modern engine" is exactly what TurboSphere is. :)

Re: Where should Sphere compete?

Reply #2 –
I think Sphere is basically this: an open-source, cross-platform 2D game development for people who just want to develop their game without the API getting in the way too much (and while still having the freedom to make what they want). There's really not that many engines out there that fulfil exactly this.

Quote
I really think sphere needs a brand new base not just forking the project

...You mean like TurboSphere? ;)

Re: Where should Sphere compete?

Reply #3 –
I certainly hope that TurboSphere is a more modern engine than Sphere is. And I make sure that I not only does it not share code with Sphere, I don't even look at the Sphere source for reference unless I really need to (and that isn't often). TurboSphere is much more architecturally modern, at least. It uses pretty new V8 (and I do update the V8 version from time to time), modern(ish) OpenGL (although on underneath of slightly older SDL), and has a plugin architecture. I'm not sure what more could be done to make it modern and powerful. And OpenGL+SDL is pretty much identical in functionality to OpenGL+SMFL.

The Sphere source is one of the cleanest and most beautiful sources (that isn't brand new or being backed by something more than just individuals) I have ever seen. It's what I expect to see after over a dozen good programmers work hard on the code over a decade.

TurboSphere's isn't beautiful just now. But that's because for one Sphere has been gone over for over a decade, TurboSphere hasn't, and for two TurboSphere is still being built and changed (less so at the moment) in basic architectural ways.

Re: Where should Sphere compete?

Reply #4 –
Quote from: Flying Jester – on

And OpenGL+SDL is pretty much identical in functionality to OpenGL+SMFL.

SMFL does seem to provide a reasonably nice integrated socket library; I'm not really sure how good SDL_net is. SMFL is also slightly more modern and "C++y" if you will. You really can't go wrong with either of them however.

Quote

The Sphere source is one of the cleanest and most beautiful sources (that isn't brand new or being backed by something more than just individuals) I have ever seen. It's what I expect to see after over a dozen good programmers work hard on the code over a decade.

I agree with this. For a decade-old codebase, Sphere is nice. It's not without it's fair share of warts and ugly parts (what codebase isn't) but it's definitely understandable (especially given that it's written in C++).
 

Re: Where should Sphere compete?

Reply #5 –
I guess that's why I like SDL so much more than SMFL. The longer I use C++, the more I yearn for C (mostly...there are certainly a couple things I'd rather not lose by switching to C).

On the other hand, SDL and SMFL have different goals. SDL_net was only created because so many folks asked for it, not because it was in the original scope. I for one am OK with using different libraries to handle networking and sound, for instance, (since I don't plan on using SDL for those things in TS) than for graphics and WM shims.