Well, true to form, minisphere 3.0.1 gets released a day after a major update.  I was going to hold off on this until I amassed more fixes, but the command-line segfault bugged me.  This release also adds SetLayerSize() requested (sort of ) by Eggbert.

@DaVince: minisphere 3.0.1 is up on the PPA.  To update automatically:

• sudo apt-get update


• sudo apt-get upgrade minisphere

I'm not sure why the first step is necessary, but if you don't do it it will just tell you you have the latest version already.

I'm not sure why the first step is necessary, but if you don't do it it will just tell you you have the latest version already.

The update command updates your local package manager so that it becomes aware of all the new available program versions. And then you actually install those updates with "upgrade". It's how the system knows when to notify you of updates (and which ones).

I once spent quite a long time wondering why FreeBSD wasn't updating their version of clang until I discovered the difference between upgrade and update

I'm a little surprised that Ubuntu's package manager makes the distinction when Arch's and Fedora's do not. It's a wild world we live in.

The next thing I want to work on is improving the FileStream API, which is currently very basic--it only has "read" and "write" methods that work with ArrayBuffers.  This makes it difficult to extract, e.g., strings from files (for whatever reason, DataView has no string encoding/decoding functions even though in ES5+ strings are unequivocally UTF-8).  I want to take inspiration from the Node.js Buffer object, which has reading primitives for various types like readInt16LE, readUint32BE, etc.  This will make it easier, I think, to write binary loaders in JS to handle Sphere file types which I've found to be quite tedious to do when working with raw ArrayBuffers.

The one thing I'm wondering about is whether it would be clearer to have separate 'LE' and 'BE' call variants like Node, or do what DataView does and take an optional argument for integer-reading functions specifying the endianness (default is BE).

Following up on the above, this is the API I went with:

• https://github.com/fatcerberus/minisphere/blob/master/docs/sphere-api.txt#L1524-L1616

There are no separate methods for int16, int32, etc.  Instead you have read/writeInt() and read/WriteUInt(), which take an argument specifying the number of bytes (1-6) used to encode the value.  I got this idea from the Node.js Buffer API, which is actually quite a bit more powerful--or at least, less confusing--than the ArrayBuffer/TypedArray/DataView mess in ES6.  In fact I actually adapted the variable-length integer encoding/decoding code from the Node.js source.  It rather surprised me that Node is MIT-licensed (which allowed me to borrow code)--I was expecting LGPL or similar.

The full list of FileStream read methods is thus (with a matching set of write methods):

• read - ArrayBuffer


• readDouble - double/float64


• readFloat - float32


• readInt - sized int


• readString - string (utf-8)


• readUInt - sized unsigned int

So if you wanted to read a 16-bit little-endian integer from a file, you'd do:

Code: (javascript) [Select]

/* readInt(num_bytes[, little_endian = false]); */
var num_pigs = file.readInt(2, true);  // 16-bit = 2 bytes

I'm a little surprised that Ubuntu's package manager makes the distinction when Arch's and Fedora's do not. It's a wild world we live in.

When you want to update, you update the whole local database by running

Code: [Select]

# pacman -Sy

Which syncs the database
And then

Code: [Select]

# pacman -Syu

Which updates. Or you can just do the bottom one and it'll check to make sure that the local database is synced.

@Eggbert: I haven't used Arch in some time, so I probably just forgot about that.

@Lord English: Node's license is because Joyent is heavily invested in using it in proprietary systems based on OpenSolaris, solely on amd64 systems. It's a weird and wild world out there.

Hopefully someday they get together with Fujitsu and save the remnants of Sun's empire. But I know they never will.

It would probably be a good idea to also add the typed read and write methods to IOSocket.  Raw ArrayBuffers and ByteArrays are actually quite tedious to work with.

Just for the record, if anyone uses Arch, it's uploaded to the AUR here.

How do I have the game start without showing the FPS in the bottom right? Also, in the past, by default, didn't pressing the escape key exit the map engine, unless you set something to block it?

"spherun" shows the FPS by default because it's meant for development, "minisphere" will hide it by default but you will have to use the "--window" option to not start in fullscreen.

I don't ever remember ESC exiting the map engine by default though, that would be undesirable for most games and be a pain in the neck to have to work around.  You'll have to add your own code to do that in your game if you want it.

"spherun" shows the FPS by default because it's meant for development, "minisphere" will hide it by default but you will have to use the "--window" option to not start in fullscreen.

Oh, right, that makes sense.

I don't ever remember ESC exiting the map engine by default though, that would be undesirable for most games and be a pain in the neck to have to work around.  You'll have to add your own code to do that in your game if you want it.

Yeah, 1.5 and I think 1.6 did. Adding in some code to quit if IsKeyPressed(KEY_ESCAPE) would be pretty trivial on the scripting end.

By the way, why is that showing "61 fps" instead of "61/61 fps"?  Are you using your own throttling code?  You'd do better to call SetFrameRate() and let the engine manage it, to avoid wasting CPU cycles.

It shows only 61 if you pass just one parameter (the location of the map file) because I thought I remember reading something about minisphere not requiring the framerate. If I do MapEngine("mapfile.rmp", FPS), it shows the 61/61. I haven't written any code other than CreatePerson,AttachInput,AttachCamera, and MapEngine. The usual.

Yeah, MapEngine() FPS is not required, but I believe it defaults to the global framerate (which itself defaults to 0, i.e. unthrottled).  So if you call SetFrameRate() at any point and then MapEngine(), you will get that framerate by default.  You should never run unthrottled in a production game because if vsync is turned off in the driver config, you could potentially do 1000+ updates per second!