It's often more efficient to store a bunch of vertices in one buffer and then use an index list to take only the ones you need, rather than having a bunch of separate buffers which was always the case before.  Basically, for a bit of extra complexity in the API you get a lot more power to optimize where needed.  It's a tradeoff.

Also by swapping in a new vertex list you can redefine a shape after creation, which I believe is something you asked for before...?

I asked for it then I discovered that shaders let me do what I wanted (a) use a single texture as an atlas for a sprite and b) apply colour masks) more efficiently (or at least with a lot less lines of code).

The only use I can see for a VertexList at the moment is to optimise mode 2 of the rings test script, I'll think on it more though.

You mention that Pentium 4 machines are no longer compatible for obvious reasons (my home server actually has a Pentium 4 and serves Xonotic, Quake 1/3, OpenTTD, and Starbound reasonably well). But Is it possible that this would limit relatively newer PCs?



I was hoping to keep this a secret until I got some basic functionality out of them, but I was working on porting miniSphere to JavaScript via emscripten and to Android. I figure most Android phones should be ok, but do you think this would prevent emscripten/JavaScript compatibility, or make it more difficult? Duktape easily compiles but I haven't gotten Allegro to build yet.

I don't see why not, assuming you can get Allegro to compile.  The mention of P4 machines was more because such machines (at least the low- to mid-level ones) usually had only Intel onboard graphics, which meant Project64 was about the most graphics-intensive thing they could run.  No shader support or anything like that, just the basic fixed-function pipeline.  Sphere 1.x is right at home there, but supporting ancient machines in miniSphere was holding me back from doing all the stuff I wanted to do with the Sv2 graphics system.

I'm trying to load test my map and sprite engines, it can draw a basic map with 1200 sprites moving around on it (with pre-set movement instructions) at 55-60 FPS pretty comfortably.

BUT if I draw the map and sprites to a surface, do some transformations on the surface then convert to a texture, texture a shape with it and draw the shape (with some transformations) the framerate drops to 4-30 FPS and staggers around in that range.

Is there any other way I could be transforming the whole map every frame that may be faster? (Obviously I could try and apply the relevant transformations to everything I'm drawing thought that could be a lot trickier and slow things down for something that is likely going to be a fringe feature.)

That's exactly why I haven't implemented SetLayerAngle/SetLayerScaleFactor yet.  Your results with rendering to a texture don't surprise me - you're talking about a HUGE texture here that there's no way the GPU can keep it all in its cache at once.

One way you could get what you want would be to build a bunch of Shapes for everything you want to render, then add them all to a Model and transform the whole thing as a unit, using a single matrix.  This, in fact, is the very reason the Model object exists.  Just keep in mind that rotation and scaling are always done about the origin--so assuming you're working in pixels, you'd need to offset your vertices by (-W/2, -H/2).  That offset could even be built into the matrix as a translation.

I can't do it as one model as I'm doing different uniforms for each sprite to handle their spritesheets being atlases, I guess I could do lots of different vertex sets instead or something instead of using uniforms to work the atlases BUT I think there would be several negative trade offs to that.

But I can do it a different way it will work

I finally got around to messing with Cell, and some code that worked up until then no longer works

Code: (javascript) [Select]

const objects = require("objects");
//...
func game()
    // console.initialize();
    SetDefaultMapScript(SCRIPT_ON_ENTER_MAP,"objects.generateField(); "); // ReferenceError: identifier 'objects' undefined
}
game();

Just to make sure that objects exists at all, I put Sphere.abort(objects.abort.player.name) outside SetDefaultMapScript and it worked fine. What changed?

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().

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(); }

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.

Would it be unfeasible to have audio, video, and input in separate threads?

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.   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.

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?

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

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.