Whoa, already it's smaller than either of the two current Sphere engines! I shall be watching this one intently What's the performance like when defining API functions in script versus directly in C++? Also, what's the min OS X version required, or by leaving -framework Cocoa can I still build on 10.6.x with XCode 3.x?(edit - I shall also sticky this, as Sphere-compatible engines are important on these forums)
This is awesome. But geez, if I had to try to go back to programming in C++ now I think I'd lose it. Thanks to Sphere and my work on Spectacles, I've been spoiled by JS's duck typing and overall dynamic-ness and not having to declare everything ahead of time. I can handle C#, but C++... *shudder*Out of curiosity, can this be built on Windows? I know you mentioned Mac in the OP, so I was curious.
function Font(path) { this.file = new _sphere.fs.File(path); var signature = this.file.read(4).toString(); var version = int16val(this.file.read(2)); var num_glyphs = int16val(this.file.read(2)); this.file.read(248); // reserved. this.glyphs = []; for (var i = 0; i < num_glyphs; i++) { var width = int16val(this.file.read(2)); var height = int16val(this.file.read(2)); this.file.read(28); // reserved. if (version != 2) { _sphere.engine.abort("Expected version 2 rfn"); } else { var bytes = width * height * 4; this.glyphs.push({ width: width, height: height, surface: this.file.read(bytes).toSurface(width, height) }); } } } Font.prototype.drawText = function(x, y, string) { for (var i = 0; i < string.length; i++) { var chr = string.charCodeAt(i); screen.blitSurface(this.glyphs[chr].surface, x, y); x += this.glyphs[chr].width; } };
Sifting through the code. Looking nice so far.Is setVideoMode meant purely for engine startup? Because I think you can do more with this...
Have you considered using JavaScript's built-in typed arrays instead of Sphere's ByteArrays? It seems much more in the "spirit" of your Sphere implementation to use modern typed arrays and provide a compatibility script for the old ByteArray interface.
I would suggest staying with SDL for a bit since it's more reliable due to its maturity and amount of work that went into it. Move to SFML once you know that your own code is mature enough and hammered out such that issues can be blamed on SFML and therefore reporting can help improve SFML.If SFML's API is sufficiently different from SDL's then the possibility exists that you may need to write a small compatibility shim if you see yourself switching between them more and more often (even for testing purposes).