That's good. Galileo is meant to be close to how the lower level APIs work in concept, so it's pretty easy to actually implement. Reimplementing it in OpenGL 2.1 only took me a couple hours, most of the work was making it selectable between that and OpenGL 4 and ensuring I had not broken the OpenGL 4 stuff.

Just for the hell of it I tried to run TurboSphere's map engine in minisphere, and upon RequireSystemScript'ing turbo/map_engine.js I got this back from Duktape:

Code: [Select]

RangeError: C call stack depth limit

Apparently there's some infinite recursion somewhere and I have no clue why.

Edit Figured it out.  I had minisphere set up to update the RequireScript inclusion tracking info only after executing the script, which is useless in case of mutual inclusion.  Surprising that this bug didn't bite me until now...

Of course, sadly it turns out it doesn't work.  I get a "not callable" error in segment.js line 6.

Hm, interesting.  The issue seems to be that the Turbo object created in each script is localized to that evaluation.  It's not actually being created in the global scope, apparently.  I added an Abort call immediately after the format.js inclusion in segment.js to print out the value of Turbo, and got back 'undefined'.  No idea what's up with that.  If I RequireSystemScript 'turbo/format.js' directly, Turbo is not undefined, so...

Bear in mind it's possible that TurboSphere's map engine has some stuff in it that doesn't work on a language level in Sphere 1.5 or similar.

There is one other issue to running the map engine. I escape "#~" in paths to be the system directory. I had intended to just put the format JSON files into a local directory to use the map engine with other engines.

It looks like the biggest obstacle to minisphere being able to use the Turbo runtime right now is Duktape's lack of ArrayBuffers.  He's working on it right now (milestone of 1.3.0 listed on the relevant GitHub issue), but it seems to be slow going.

Can you see where it properly needs one? I tried to allow it to use ByteArrays as well (or any object that has a `[]' operator). I may have left in a couple evil engine calls, though, like making surfaces directly out of ArrayBuffers.

Can you see where it properly needs one? I tried to allow it to use ByteArrays as well (or any object that has a `[]' operator). I may have left in a couple evil engine calls, though, like making surfaces directly out of ArrayBuffers.

I haven't looked particularly hard, but I did find this:

Code: (javascript) [Select]

Turbo.LoadSystemScheme = function(name){

    var scheme_file = new RawFile("#~/formats/"+name);
    var scheme_buffer = scheme_file.read(scheme_file.size);
    
    var scheme_byteview = new Uint8Array(scheme_buffer);
    var scheme_bytearray = ByteArrayFromTypedArray(scheme_byteview);

    return JSON.parse(CreateStringFromByteArray(scheme_bytearray));
}

Which is the most schizophrenic piece of code I've ever seen.   You go from a ByteArray (returned by RawFile:read) to a Uint8Array, back to a ByteArray again, and finally to a string before parsing it as JSON.  Were you just stress-testing the ByteArray stuff on purpose or what?

Also, bytearray.js RequireSystemScript's arraybuffer_bytearray.js without checking to see if a native ByteArray already exists.

Which is the most schizophrenic piece of code I've ever seen.   You go from a ByteArray (returned by RawFile:read) to a Uint8Array, back to a ByteArray again, and finally to a string before parsing it as JSON.  Were you just stress-testing the ByteArray stuff on purpose or what?

It's an extremely cheap operation to convert between ByteArrays and TypedArrays in TurboSphere. It just sets a couple properties of the TypedArray to be compatible methods for a ByteArray.

Previously, read() always returned an ArrayBuffer, and ByteArrayFromTypedArray has wavered between only handling TypedArrays and ArrayBuffers. Now it's able to handle either.
So you're completely right, that code is just too much, making up for issues that don't even exist anymore.

Edit:
Ah, I see. The whole file reader system needs a file reader for ByteArrays.

Last night I did a massive reorganization of the minisphere directory.  It's now set up like a real cross-platform C app instead of the MSVC-generated structure it had before.  Source and headers are in 'src', the MSVC project files are in 'msvc', and the engine is built in 'bin'.  A small thing, but at least now it doesn't look like cross-platform support is an afterthought.

@DaVince and @casiotone: Could you guys check that it still builds on Linux and OS X using SCons?  I updated the build scripts to reflect the new structure but as SCons won't build it for me on Windows, I can't test that everything is working properly.

Yep, still builds here. I encounter a segfault when dying in Sir Boingers though.

Code: [Select]

fish: Job 1, "./msphere ~/Dropbox/projects/sphere/boingers2.2/startup/" terminated by signal SIGSEGV (Address boundary error)

(I use fish instead of bash so the segfault message looks a bit different.)

Is the segfault reproducible?  I know I encountered a few myself with recent builds, but they were always in the Vorbis code so I didn't know what to do about it.

Happens every time I kill myself.

I think it chokes on the dying screen, as my new version uses the original IT files now and this is one that should play only once. I can hear about 0.2 seconds of the music before it segfaults.
Curiously, the win screen does function, even though it also calls a non-looping IT file... (It loops anyway which isn't right though.)

I'll send you the version I'm messing around with.

I also have a request: could you make minisphere check if there's only one game in the games folder and just run it if that's the case? I don't want to put my game into a startup folder because that makes it more of a hassle to package the game without the engine.

Yeah, the looping thing is a bug in Allegro that's fixed in the latest build but hasn't been released yet.  There's nothing I can do on minisphere's end to work around it, unfortunately.  It does work properly on Windows because I compiled Allegro myself and included the appropriate fix. . I actually had no choice, because there are no pre-built x64 MSVC binaries for Allegro, or at least I haven't found any...

Yeah, I noticed it works fine on Wine. Will wait for the next Allegro version then.

I also noticed that in Windows the file selector defaults to My Documents instead of the working directory. Might want to make the default path either minisphere's directory, or the games subdirectory (when found).

Yeah, I noticed it works fine on Wine. Will wait for the next Allegro version then.

Now that you mention it, I remember that there was another bug that was fixed along with the looping: a buffer overrun in the module streaming code. So that's probably where your segfault is.

...and in case there was any doubt, I'm the one that discovered it.