Skip to main content

News

Topic: Sphere for Mac: Andromeda (Read 23982 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • Rahkiin
  • [*][*][*]
Re: Sphere for Mac <insert fancy name here>
Reply #30
Could you post those images here / send me the images in a PM so I could, later, use them for testing etc?

Re: Sphere for Mac <insert fancy name here>
Reply #31
Once I get home, sure :)

Quote
You should call it Smac!)


I really like this! And if you make it cross platform. Smac for Linux, Smac for Windows

I like that a lot :) (DaVince always has the best ideas)

  • Rahkiin
  • [*][*][*]
Re: Sphere for Mac <insert fancy name here>
Reply #32

I really like this! And if you make it cross platform. Smac for Linux, Smac for Windows

I like that a lot :)


Positive comments. I think the name is easy pronounceable, rememberable, has an origin and is funny (due to that too greasy 'meat').

Smac it is :)

'Sphere for Mac for Windows', Smac for Windows. This does get complicated :P

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Sphere for Mac: Smac
Reply #33
I mostly just said "Smac" to be funny, but if you actually want to use it... Well, no one's stopping ya. :P

  • Rahkiin
  • [*][*][*]
Re: Sphere for Mac: <insert fancy name here>
Reply #34
I figured that I should keep 'Sphere' in my name, or I need to change all class names, framework names and code of my whole project.

xD

Re: Sphere for Mac: <insert fancy name here>
Reply #35
MacSphere would be more classic.

  • Rahkiin
  • [*][*][*]
Re: Sphere for Mac: <insert fancy name here>
Reply #36
Yeah, fits better indeed. Trouble is, that I might try to get it running on Linux some day.
Although, I do not see the use of running it on Linux as there is TurboSphere for Linux, right?

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Sphere for Mac: <insert fancy name here>
Reply #37
Eh, I guess we'll have codenames for internally referring to the Sphere projects.

As a point of consistency, the official name of the official "vanilla" version of Sphere, whether on Windows, OSX, Linux, iOS, Android, whatever, is the Sphere Game Engine, or Sphere for short. Sphere also refers to the working API and formats for devs to use when making their projects, therefore a Sphere-compatible project is a project that should work on all variants/forks of Sphere itself and all engines claiming to be Sphere-compatible because it doesn't rely on enhancements to either API or formats not available to the "vanilla" Sphere engine.

Vanilla Sphere is the codename of the official version of the Sphere engine; the current Windows Sphere, Mac Sphere, and Linux Sphere all share this codename so we've been using Mac Sphere and Linux Sphere to refer to the *nix variants and just Sphere to refer to the original Windows variant. Vanilla Sphere on all platforms uses Mozilla SpiderMonkey for JavaScript and attempts to use native OS capabilities for I/O when possible and falls back to SDL otherwise depending on the OS. I wouldn't mind calling the shared codebase of OSX and Linux Sphere's "XSphere" though ;) A slew of devs over the years have done work on vanilla Sphere at various points.

TurboSphere, or TS for short, is Flying Jester's (mostly) Sphere-compatible engine with non-standard enhancements (though I wouldn't mind useful enhancements being folded into vanilla Sphere) using V8 for JavaScript and explicitly using SDL for I/O. I'm not aware of any particularly different codename for it since we've been referring to it as TurboSphere, Turbo, or TS.

Sphere SFML, or SSFML for short, is Radnen's Sphere-compatible engine done in C# with Jurassic for JavaScript and SFML for I/O. No other codename to my knowledge.

Web Sphere is the codename of the official version of the (currently incomplete) Sphere implementation for web browsers. It has multiple variants based on the framework(s) being used for the I/O shim.

casiotone started work on a Sphere-compatible engine but it's not complete.

I'm not aware of any other active Sphere-compatible engines in progress before Rahkiin's entry into the field. Personally, as I've said once or twice before on this board I would love for one or more of the newer Sphere-compatible engines to actually succeed vanilla Sphere since it seems that the barrier to entry for adding to or even maintaining it is becoming harder to overcome as time passes. Radnen's editor is already fast becoming the de facto replacement of the vanilla Sphere Editor for new and old users alike and the only thing really preventing outright replacement is its primarily Windows construction.

Re: Sphere for Mac: <insert fancy name here>
Reply #38
@Rahklin: That's not an unfair assessment of TurboSphere...sigh.

Just to add to what Neo said...because I can't resist an opportunity to eschew obfuscation of the goals of TurboSphere!  ;D

TurboSphere is many things. It's full of shininess--it has a very flexible plugin system, a threaded graphics system, support for a huge variety of filetypes (all Sphere filetypes, all of Sphere 1.5's supported audio/graphics, and additionally can use Modular music files, Midi soundfonts, vector graphics, PostScript-style bitmapped fonts, and truetype fonts), uses bleeding edge versions of V8 and SDL 2. SDL2 forms the basis of its software rendering backend--which is highly asynchronous, and supports surface operation reordering, and performing them out of order and in parallel.

But it's also supposed to be fast. That's why I started it, good ol' Sphere 1.5 was getting too slow, particularly in a couple pseudo-3D tech demos I wrote and some pathfinding systems that Radnen and Beaker (among others) wrote. And it is fast, breaking through the limits of Sphere 1.x all over the place. Sphere-SFML may be faster, though. It seems like, in raw JS power and some graphics benchmarks, TS beats Sphere-SFML, but there are cases where Sphere-SFML is faster. It really depends on what you are doing and how you do it.

TurboSphere is supposed to be cross-platform. All native C and C++, with Unix and Win32 backends. It's just that I don't use Windows very much, and don't own a V8-capable macintosh, so it tends to be tested and developed in Linux, and released for Windows on special occasions.

  • Rahkiin
  • [*][*][*]
Re: Sphere for Mac: <insert fancy name here>
Reply #39
Too bad, I think my runtime will not be able to succeed Vanilla Sphere, for a single reason: portability. I won't be able to port my runtime to Windows. I might be bale to port it to Linux though. That would make it the only native *nix runtime.

That of course does not mean it, or TS, can't be the new standard. I add a lot of modern-age functionality, paradigms, etc to my engine. Also I try to keep it modularised so it can be used for other projects. (For example a file viewer). TS is plugin based and also has new functionality. We could look together in a 'Sphere 1.7' or 'Sphere 2.0'. Not a runtime, but rather a 'Standard'.

The Vanilla code is indeed messy. :)

For a code name, I named my repository JSphere, as J is the first letter of both my company's name and my name (not a coincidence. Or is it?). I could go with that codename.
In my code all over, I have been using plain Sphere  ;D Now I know I should not as I am not part of the Sphere Group and it is not the official engine, but when I started the project I assume 'Sphere' as the collection of the JS library and the file formats. Not as the runtime itself. (Concept vs Object).

So I guess this is it now:

Vanilla / Vanilla Sphere = Official engine
TurboSphere / Turbo / TS = Flying Jester's engine
Sphere SFML / SFML = Radnen's engine
JSphere = Rahkiin's engine

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere for Mac: <insert fancy name here>
Reply #40

Sphere-SFML may be faster, though. It seems like, in raw JS power and some graphics benchmarks, TS beats Sphere-SFML, but there are cases where Sphere-SFML is faster. It really depends on what you are doing and how you do it.


Yeah, well I realized the JS engine really isn't the bottle-neck most of the time. SFML uses GL underneath and so technically can be just as fast as your code graphically. Plus it does depend on your hardware. Now, you are using V8 so I suspect that hand-written 3D engines or other pieces of code that does a lot of on the fly calculations will perform faster in your environment. My engine is really tailored to be faster under normal Sphere use: the map engine, menus, and other such things. Yours might be on average faster on an all-around basis. Oh and I couldadd plugin support to my SSFML, it's just a matter of time. But these plugin's would be more along the lines of functional additions where you write the code in C# and use the plugin to expose it to the engine. In this way custom battle systems and map engines can be made apart from the core engine. It'll still remain with it's largely monolithic graphics and input backend.

@Rahkiin: don't worry about portability too much. If you can target mobile devices (iPad or iPhone) with your engine then I'd say that's a huge win. It turns out that cross-compatible engines are messy to write and hard to maintain. Jest can attest to that by trying so hard to make sure TS works across *nix and Windows. It's hard! I have the stability in my engine since it's only for one OS. Since there are a lot of indie game developers, especially XNA users, this was my motivation to make Sphere for Windows. I have looked into Mono for SSFML, but it seems Mono is an incomplete library (still) and does not support some features that .Net has which are crucial to the operation of my engine. My Sphere Editor on the other hand has a shot at being cross-platform under Mono. I just need to find the time to do any conversions or research in order to make it work. But then that really requires me to coordinate among people with different OS's, which is a huge pain.
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

  • Rahkiin
  • [*][*][*]
Re: Sphere for Mac: <insert fancy name here>
Reply #41
@Radnen Thanks for the tip. I will then focus completely on the Apple devices with my Sphere software (I will probably make L8 work for ObjFW). My editor will also be very native with all kind of special Mac stuff, much like Xcode. But that is for later.

I switched my project completely to L8 (V8) now that I made a lot of updates to the framework. Still have to do some major profiling, some caching and some tiny features but that's it. Then I can go on with the runtime.

I might update L8 later to be fully compatible (API) with JSC so that I can use JSC on the iOS version (iOS8).

Re: Sphere for Mac: <insert fancy name here>
Reply #42
I suggest just keeping it Mac-exclusive. You can't really have a native Mac app that's portable; Apple's frameworks make sense on OS X and not really anywhere else (plus they're not really implemented anywhere else).

Re: Sphere for Mac: <insert fancy name here>
Reply #43
They could make sense on FreeBSD with GNUStep =P

Re: Sphere for Mac: <insert fancy name here>
Reply #44
FreeBSD FTW! ;D

GNUstep is kind of a joke though. I think I looked at it once and sort of lost interest once I realised they'd only implemented to like OS X 10.4 or something similarly old.