Skip to main content

News

Topic: Sphere 1.5, 1.6 beta (Read 44685 times) previous topic - next topic

0 Members and 4 Guests are viewing this topic.
  • Rahkiin
  • [*][*][*]
Re: Sphere 1.5, 1.6 beta
Reply #75
Almost all code in either in unix (fixing warnings) or in mac yes. And other code is safeguarded with preprocessor directives. I would like if someone made sure I did not screw up tho. :) There is always rollback ghehe.
There were problems in shared code too so I had to fix those. And the buildsystem is shared per definition.

Re: Sphere 1.5, 1.6 beta
Reply #76
If you updated sphere with Xcode I would literally have your babies... *deep breathing*...

Re: Sphere 1.5, 1.6 beta
Reply #77
It's kind of working on OS X. The thing is, the old Mac video driver is busted big time, and the Unix video drivers kind of...don't work. The SDL32 driver has severely messed up colors (how!?) and does not participate as a proper OS X application (no menu bar, can't get focus), and the SDL_GL driver just has a black screen. I've tried get FJ-GL to work, but there are some issues with it dynamically loading GL symbols (I'll have to face this with TurboSphere at some point, too).

I think the easiest thing would be to port the shader I'm using in FJ-GL to SDL_GL and use that since it can't get an FFP OpenGL context on a modern machine. I'll have a look, and see if I can get FJ-GL working, too. it would be nice to get a working binary for Mavericks.

I also found that Rahkiin was certainly right, I can use libjs 1.7 for Sphere 1.6. I don't even remember why I thought I couldn't. It did require a single modification to compile with the newest version of Clang (related to assigning from variadic arguments...the trick was just to dereference both the lvalue and rvalue and assign by value, which is fine since they are ints). Nice job, Mozilla from 10 years ago, your code still compiles!
  • Last Edit: July 31, 2014, 06:54:24 pm by Flying Jester

  • Rhuan
  • [*][*][*][*]
Re: Sphere 1.5, 1.6 beta
Reply #78
That weird yellow shifted screenshot looks the way my first compiles of sphere for mac looked before I was helped with getting the endian swaps right.

Are you using any of my old source and somewhere setting the big endian flag?

Re: Sphere 1.5, 1.6 beta
Reply #79
Yeah, endian issues were my first guess.

I think your old source was rolled into 1.6 at some point.

I'm using a combination of the Unix sources and the Mac sources. Some of the Mac stuff really doesn't work anymore, and some of the Unix stuff really doesn't work on Mac. Luckily, there seems to be enough of each to get a mostly working engine. The thing is, I'm using the Unix video drivers, so I don't really see how that could be the issue? Unless the endian code was elsewhere?

I poked around a little bit on this, but I didn't see right away how to fix it.

  • Rhuan
  • [*][*][*][*]
Re: Sphere 1.5, 1.6 beta
Reply #80
Couple of points:

The "old" mac video driver was heavily SDL dependent how is your SDL implementation? Also it was designed to be compiled desperately to the engine app like the windows drivers. (There was then a configuration app as it had various settings)

The endian issues are all addressed when loading resources so you need to look at the code that opens an image or a spriteset etc not the video driver code.

If endian issues are your only problem graphics primaries should work fine so you could try looking at those to see if that's the issue.

Also if it is just an endian matter assuming you've got the latest version of my code you should just need to change a compiler flag, the source shouldn't need any changes.


EDIT: Also I feel obliged to mention that I have an Xcode project for all the dependencies (other than wx and SDL) and then the config, the video drivers and the engine itself I'll try and get it across to one of you shortly. Obviously it's for osx 10.5 so maybe a bit outdated but fundamentally should work.

Thing that should be changed before taking it forward to release is migrating it to a newer version of JS it still uses the old 1.5

EDIT2: looks like it still builds as well except the config tool as I've deleted the version of wxMac it needs (can't re-acquire as this machine has no internet connection) going to clean it a bit then at some point in the next couple of weeks will get it on a memory stick and then to email via a different computer.
  • Last Edit: October 20, 2014, 04:20:35 pm by Rhuan

Re: Sphere 1.5, 1.6 beta
Reply #81
I give you Sphere 1.6 (engine only) for OS X Mavericks and Yosemite.

https://drive.google.com/file/d/0B-hkR9nzCDDKZXdJMnZIOHZqVzQ/view

UPDATE: Use https://drive.google.com/file/d/0B-hkR9nzCDDKaDNFVDliVEYyam8/view

I've barely tested this at all. If anyone has a newer Mac (it might work back to Snow Leopard, I don't know), please give it a try!

NOTE! This is very much a Unix program right now and doesn't really act like an OS X application. It needs to be run from the terminal in its own directory. I may try to fix that (it's an issue with directory paths in the engine proper, I believe), but for now I figured I would share what I got. It also tries to use ANCIENT oss audio. Which OS X never had as far as I know, and we will likely never see again. Unless someone got CoreAudio working in Audiere, there won't be any sound.

It should work without any extra dependencies, but I've only got a single machine to test it on which has quite a bad case of development library contamination.

I got video working mostly right by backporting more video driver stuff from TurboSphere into FJ-GL, and upgrading the T5 dependency to the newest version. So really, this is very almost a Unix build of Sphere 1.6 with an OS X build of FJ-GL. It still has the old FJ-GL concave polygon issues on some Intel cards (It works fine on my Mac's Intel Iris), and a few bugs with certain blend modes. Please let me know if you find any of these!
  • Last Edit: November 26, 2014, 05:44:06 pm by Flying Jester

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Sphere 1.5, 1.6 beta
Reply #82
I'm running Mavericks on my Air (I'll give specs later) right now. I'll give this a go and report back by the end of the weekend.

Re sound - OSX never had OSS, but CoreAudio with the Core* prefix didn't come about until maybe 10.2 or so.

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Sphere 1.5, 1.6 beta
Reply #83
Update: running ./engine results in the following error:

Quote

dyld: Library not loaded: Darwin_OPT.OBJ/libjs.dylib
  Referenced from: /Users/lux/Applications/sphere_osx/./engine
  Reason: image not found
Trace/BPT trap: 5


OSX Mavericks 10.9.5

Re: Sphere 1.5, 1.6 beta
Reply #84
Oh, well the solution is simple. You just need to guess which version of SpiderMonkey I used, find the unadvertised Mozilla FTP address you can get it at, compile it with the same version of clang I used, install it to the default prefix + Darwin_OPT.OBJ, and then doctor up the install name of the library and the engine binary.

...don't actually do that. Well I mean you could, if you were feeling super adventurous...

I'll fix that up. It'll be pretty simple.

Re: Sphere 1.5, 1.6 beta
Reply #85
Here it is.

https://drive.google.com/file/d/0B-hkR9nzCDDKaDNFVDliVEYyam8/view

That was really weird. I don't really know how it was linking right on my machine.

But now it has SpiderMonkey, and I've changed the engine's link settings to use the local version.

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Sphere 1.5, 1.6 beta
Reply #86
The following audiere error:

Quote

airlux:sphere_osx lux$ ./engine
dyld: Library not loaded: /usr/local/lib/libvorbisfile.3.dylib
  Referenced from: /Users/lux/Applications/sphere_osx/./libaudiere.dylib
  Reason: image not found
Trace/BPT trap: 5


I have a gut feeling every single audio file supported by audiere will give out an error like this, so this is a thing to look at.

edit: Attempted to put the libs from the 5-year-old https://github.com/rubygame/rubygame-mac-pack into /usr/local/lib and get a "mach-o, but wrong architecture" error in my Mavericks, presumably because I'm 64-bit and it's 32-bit. So...it appears that if Sphere OS X is going to continue to support Snow Leopard and Leopard there will need to be separate 32-bit builds. Let's concentrate on 64-bit first.
  • Last Edit: November 27, 2014, 02:40:06 pm by N E O

Re: Sphere 1.5, 1.6 beta
Reply #87
I can fix this. I'm betting that a similar issue will exist for Corona.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere 1.5, 1.6 beta
Reply #88
Wow, reading through the ordeals in this thread again makes me glad minisphere is a thing now. :P. The vanilla engine is so ancient and so broken using modern tools and libraries that it's not really worth maintaining anymore.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: Sphere 1.5, 1.6 beta
Reply #89
I recently learned that Corona was maintained for a time by someone unrelated to Sphere, who added a lot of useful stuff. Chad Austin then, relatively recently, began maintaining and improving it again.

That, combined with what I've learned about modern SpiderMonkey, almost made me want to try and build a new version of Sphere based on the original sources.

But the biggest issue is that no one really knows how most of the old engine works anymore. Audiere is a particularly thorny library, it doesn't work with newer OS X or Linux (either through OpenAL/CoreAudio or ALSA), only the OSS interface which only BSD and Solaris still use. There is a lot of stuff that is undocumented about the 1.6 branch. There are things that kind of make no sense. It would be pretty easy to work on Sphere 1.6, if I actually had written any part of it.

To be fair, SM 1.8.5 is like Java 6. A lot of stuff is still stuck using it, when it really shouldn't be.

With TurboSphere incorporating the more experimental sphere stuff I work on, it wasn't too appealing to fully grok the old Sphere code. With Minisphere, the other promise of proper compatibility is less interesting as well, since it is rather close, and has not accumulated the 15 years of cruft that Sphere has. For its age and complexity, Sphere's code is easy to read. But 15 years is a long time for any project to be in active development.

Finishing my Unix-based OS X release wouldn't have been too useful, either. No one really wanted it that bad, even me. I've only used my OS X build a handful of times. At that point, truly fixing the underlying issues with my OS X build would be more work than either writing full compatibility wrappers for TurboSphere, trying to make some fork of Minisphere that uses SpiderMonkey, or fixing up my Turbo runtime to work in a pre-ES5 environment.