As a personal project (to get to grips with C++) I've begun my own engine implementation with v8 and SDL...

https://github.com/postcasio/sphereclone

My aim with this is to actually implement a completely new API, while maintaining backwards compatibility by implementing most of the Sphere API in JavaScript.

I currently have Require/EvaluateScript functions implemented in JS, as well as Rectangle and CreateColor. The screen is actually exposed as a surface in the new API, which is set up in the bootstrap script and wrapped by the Sphere API.

Additionally the bootstrap script will be responsible for engine logic like loading games. It will load and parse configuration files and graphical Sphere formats. Speed should be fine with an API function to load bitmap data directly, since the majority of loading time would be spent building images otherwise. The map engine will be built in JavaScript.

A game would be able to specify which version of the API it requires. and the bootstrap will turn off the old functions if the game is developed for the new API. The new API will be as sparse as possible - things that can be done in JS should be. This will allow a great degree of flexibility for games.

So, it will basically be a much lower-level game engine with a JavaScript implementation of Sphere for backwards compatibility.

I've added an Sconstruct file that I've used for developing on my mac... To build, you will need to modify the CCFLAGS and LINKFLAGS variables to point to the right place. Additionally, if you're not using a Mac, remove "-framework Cocoa". I've kept the build process very simple.

What you need (at least):
v8: 3.18.2
sdl: 1.2.15

And scons to build.

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)

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)

I don't think the overhead will be much, especially not for Sphere games, which ran on an ancient SpiderMonkey! v8 should handle it fine.

I have no idea if it will build on an older version, but the only reason Cocoa is required is for SDLmain to set up the window. If you remove it, you'll find out what you need in the errors.

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.

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.

It probably can, but you might need to fiddle. I don't really develop on my windows machine unfortunately.

I've added rudimentary game loading (reading the config file and jumping into a new context). Here's a screenshot of all the engine can do: draw a rectangle and move it around the screen.

This reminds me of what I did, oh so long ago.

Good luck!

Sifting through the code. Looking nice so far.

Is setVideoMode meant purely for engine startup? Because I think you can do more with this...

Switching resolutions is not as easy as I originally made it out to be when I added it to TurboSphere (and I don't expect it to return to TurboSphere any time soon). If you do anything more than software rendering (well, actually storing textures in system RAM), things get very complicated.

I've just pushed some code to support drawing text with fonts. The font loading is done in JS, with the help of a new ByteArray.toSurface method to directly convert bytes. It's fast! The new API has also gained ByteArray.toString, which functions as CreateByteArrayFromString.



The JS for the Font class is very simple:

Code: [Select]

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

I'm trying to keep it as flexible as possible, but I haven't really tested it. If using it more than once works, it's not supposed to yet.

Also, this thing leaks memory like a sieve right now.

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.

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've considered it, but I'm not sure if it would really have a huge benefit for the use case. At the moment the ByteArray is just a pointer chunk of memory and an index accessor that indexes into the pointer. That allows it to stay fast in C++ code, which is where most of the processing happens - toSurface just does a straight byte copy into a surface, toString calls strncopy - having to convert a v8 typed array to raw bytes first would probably be slower, and the accessor should be fast enough.

So I've been moving the graphics to SFML...



Unfortunately RenderTextures (which im using for surfaces) aren't working yet...

Have you started a topic at the SFML forums?

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

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

The problem is that SDL's api is so limited compared to SFML it would be significantly more work to work with it. SFML has transformations built in which is a huge bonus.