Recent Posts

Pages: [1] 2 3 ... 10
1
Engine Development / Re: miniSphere 4.7.1
« Last post by Fat Cerberus on Today at 02:48:18 am »
miniSphere 4.7.1 fixes a very, very old bug where getting stuck in an infinite loop caused you to be completely locked out of the debugger.  Not only does that mean you no longer have to kill the miniSphere process when that happens, it also means you can click the Pause button in Sphere Studio to find out exactly where your code is stuck!
2
Engine Development / Re: miniSphere 4.7.0
« Last post by Fat Cerberus on July 23, 2017, 06:25:52 pm »
MiniMP3 seems to be buggy or something.  Stereo files at least don't seem to be decoded properly; if I create a stereo stream with the proper frequency, the sound is choppy (like it's coming through a box fan or something) and plays at half speed.  If I create a mono stream at double the frequency, it sounds normal with just a bit of distortion.  No idea what's up with that.

In any case I most likely will ultimately use a different mp3 library.  I want to try to get Fluendo's decoder working because that's MIT-licensed so I don't have to worry about LGPL quibbles.  And all the mp3 patents are expired now so that'll be great :D
3
Engine Development / Re: miniSphere 4.7.0
« Last post by Eggbert on July 23, 2017, 02:17:01 am »
I guess I should have made a new post rather then editing my post to avoid unintentionally giving off the wrong idea. I'm not very familiar with working with threads.
4
Engine Development / Re: miniSphere 4.7.0
« Last post by Fat Cerberus on July 23, 2017, 01:59:44 am »
The sleep function wouldn't need to take the mutex, `soundstream.buffer()` would--every time you call it.  The streaming thread would need to lock the mutex every time it fed more audio data.  It's a lot of extra synchronization overhead that seems unnecessary when we already have a built-in sync point that games need to call anyway and is much easier to predict (screen.flip).  The question is whether I'm clever enough to make it work :)
5
Engine Development / Re: miniSphere 4.7.0
« Last post by Eggbert on July 23, 2017, 01:49:07 am »
I'm not very familiar with working with threads, but I figured syncing could be a challenge. So would Sphere.sleep() be used as or adapted to a mutex?
6
Engine Development / Re: miniSphere 4.7.0
« Last post by Fat Cerberus on July 23, 2017, 12:53:05 am »
That's one option, the main reason I avoided it in the current implementation is because streaming from a separate thread requires synchronization (think mutexes) to ensure the stream buffer doesn't get clobbered.  Right now soundstream.buffer() is super-cheap because it can just stuff bytes into the buffer with reckless abandon secure in the knowledge that Audialis won't touch it until the next flip. :P  Having to take a mutex lock first will most likely hurt performance.

There is one other solution I can try first.  Sphere.sleep() still runs the event pump, and Allegro posts an event to the queue whenever a stream has a free buffer.  If I listen for that event, it might be enough to ensure the stream doesn't starve even during long delays.
7
Engine Development / Re: miniSphere 4.7.0
« Last post by Eggbert on July 22, 2017, 08:38:43 pm »
Would it be unfeasible to have audio, video, and input in separate threads?
8
Engine Development / Re: miniSphere 4.7.0
« Last post by Fat Cerberus on July 22, 2017, 03:40:37 pm »
I was experimenting with adding mp3 support using minimp3 together with the existing internal Audialis bindings and got some promising results, but found out in the process that SoundStreams are pretty much useless at present.  Because the engine is single threaded, the smallest delays will starve the stream and cause stuttering, even the intentional delays from frame rate limiting.  So I'm thinking I'll either need to move the feed into a separate thread or else increase the size of the stream buffer.
9
Engine Development / Re: miniSphere 4.7.0
« Last post by Fat Cerberus on July 22, 2017, 02:49:28 pm »
To be clear on the behavior, when run in v2 mode, the engine boots your game by doing internally the equivalent of:
Code: (javascript) [Select]
let Game = require(mainScriptFilename).default:
if (Game) { (new Game()).start(); }
10
Engine Development / Re: miniSphere 4.7.0
« Last post by Fat Cerberus on July 22, 2017, 02:41:22 pm »
If you don't set Sphere.Game.version to 1 in your Cellscript, the default is 2.  In that case your main script will be loaded as a CommonJS module (like node) rather than normal program code (like Sphere 1.x/browsers).  You have a few options: A) Set the API version to 1; B) Explicitly make the variable global global.objects = ...; or C) Take advantage of closures and pass a function to SetDefaultMapScript().
Pages: [1] 2 3 ... 10