Spherical forums

Sphere Development => Engine Development => Topic started by: casiotone on May 29, 2013, 04:34:03 pm

Title: Yet another sphere engine
Post by: casiotone on May 29, 2013, 04:34:03 pm
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.
Title: Re: Yet another sphere engine
Post by: N E O on May 29, 2013, 04:56:45 pm
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)
Title: Re: Yet another sphere engine
Post by: casiotone on May 29, 2013, 05:47:39 pm

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.
Title: Re: Yet another sphere engine
Post by: Fat Cerberus on May 29, 2013, 09:41:14 pm
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.
Title: Re: Yet another sphere engine
Post by: casiotone on May 30, 2013, 03:20:22 pm

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.

(http://i.imgur.com/X3MOoiq.png)
Title: Re: Yet another sphere engine
Post by: Flying Jester on May 30, 2013, 05:50:00 pm
This reminds me of what I did, oh so long ago.

Good luck!
Title: Re: Yet another sphere engine
Post by: DaVince on May 31, 2013, 01:36:03 pm
Sifting through the code. Looking nice so far.

Is setVideoMode meant purely for engine startup? Because I think you can do more with this...
Title: Re: Yet another sphere engine
Post by: Flying Jester on May 31, 2013, 03:43:09 pm
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.
Title: Re: Yet another sphere engine
Post by: casiotone on May 31, 2013, 04:40:10 pm
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.

(http://i.imgur.com/KxvL4nm.png)

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.
Title: Re: Yet another sphere engine
Post by: alpha123 on May 31, 2013, 04:59:47 pm
Have you considered using JavaScript's built-in typed arrays (https://developer.mozilla.org/en-US/docs/Web/JavaScript/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.
Title: Re: Yet another sphere engine
Post by: casiotone on May 31, 2013, 05:19:48 pm

Have you considered using JavaScript's built-in typed arrays (https://developer.mozilla.org/en-US/docs/Web/JavaScript/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.
Title: Re: Yet another sphere engine
Post by: casiotone on June 01, 2013, 03:59:29 pm
So I've been moving the graphics to SFML...

(http://i.imgur.com/Sbc0653.png)

Unfortunately RenderTextures (which im using for surfaces) aren't working yet...
Title: Re: Yet another sphere engine
Post by: Rukiri on June 01, 2013, 04:34:32 pm
Have you started a topic at the SFML forums?
Title: Re: Yet another sphere engine
Post by: N E O on June 01, 2013, 04:55:12 pm
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).
Title: Re: Yet another sphere engine
Post by: casiotone on June 01, 2013, 05:57:39 pm

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.
Title: Re: Yet another sphere engine
Post by: N E O on June 01, 2013, 09:58:10 pm
Ah, ok.
Title: Re: Yet another sphere engine
Post by: Flying Jester on June 01, 2013, 10:18:36 pm
From what I've seen of SMFL, it seems very comparable (but quite different in use) to SDL. But I suppose I don't have that much experience with SMFL.

There's also SDL 2.0, which is supposed to be finally out of beta before the year is done.
Title: Re: Yet another sphere engine
Post by: Flying Jester on June 08, 2013, 01:40:57 am
I've had a quick look at the source.

To get it to compile on Linux, you must change all the
Code: (C) [Select]

#include <SDL/sdl.h>
/*and*/
#include <SDL/sdl_image.h>

to
Code: (C) [Select]

#include <SDL/SDL.h>
/*and*/
#include <SDL/SDL_image.h>


I'm not sure if that works on OS X, but it is necessary on Linux. And obviously I had to hack up the sconstruct file.

For what it's worth, though, it seems to very almost compile for me using V8 3.16 as well (I need to perform the arduous task of compiling v8 3.18 to properly try (as you might expect, it really won't work without it unless I make fairly major modifications to the source).

I'm glad to see the source though. It may be a nice primer to getting TS up to snuff with newer V8.
Title: Re: Yet another sphere engine
Post by: N E O on July 16, 2013, 04:21:29 pm
Of possible relevance to this project is my recent Sphere web utilities (https://github.com/sphere-group/web-sphere-utilities) project, which while being strictly Web JS for now is of similar format loading mindset. I have windowstyle, font, and basic spriteset loading, if there's something you (casiotone) would like to streamline (either streamline mine or streamline yours) :)
Title: Re: Yet another sphere engine
Post by: casiotone on July 21, 2013, 10:59:12 am
So it took me a while but I picked up my progress of moving this to SFML and it's now at this point with no more memory corruption.

(http://i.imgur.com/IT51BIQ.png)
Title: Re: Yet another sphere engine
Post by: Radnen on July 21, 2013, 03:44:27 pm
I'm surprised you got surfaces working in such a short time in SFML. Which leads me to my next statement: I guess we have two sfml based Sphere engines. Yours may already be cross platform too!
Title: Re: Yet another sphere engine
Post by: Flying Jester on July 21, 2013, 10:33:06 pm
It probably at least compiles fine on Linux. I could give it a try, I now have a newer V8 built to try it with.

Also, very interesting how the engines have turned out so far. SDL2+V8, SMFL+V8, SMFL+Jurassic. An interesting opportunity to see SDL vs. SMFL and V8 vs. Jurassic in action.
Title: Re: Yet another sphere engine
Post by: casiotone on July 22, 2013, 04:03:49 am

It probably at least compiles fine on Linux. I could give it a try, I now have a newer V8 built to try it with.


I've still got a lot of stuff to clean up so the git repository hasn't been updated yet. But it should compile easily!

Quote from: Radnen
I'm surprised you got surfaces working in such a short time in SFML. Which leads me to my next statement: I guess we have two sfml based Sphere engines. Yours may already be cross platform too!


I've unfortunately only got loading surfaces, blitting them, and drawing rectangles to surfaces implemented, so you're far far ahead of me! I imagine the more complicated surface features will be more of a problem. At the moment I've done it by storing an SFML sprite along with some information like current blend mode. Drawing on surfaces converts the sprite's texture to a render texture and back again so it's not very fast. I'm not sure what the best way to handle them is really.
Title: Re: Yet another sphere engine
Post by: Radnen on July 22, 2013, 05:22:52 am
I've been slowing hand-rolling my own surface functions as I see them. Check out the code (in C#) here:
https://github.com/Radnen/sphere-sfml/blob/master/Engine/Engine/Objects/SurfaceInstance.cs

I had so wanted to use a render texture, but when it came to the other stuff I was at a loss on how to do it with render textures alone. This method is the slowest and fastest. Fast since the conversion from surface to image is nothing if you script your JS right (do all of the surface methods outside of a major game loop), then it draws no faster than an image object. Otherwise since the hardware isn't being used, it's only as fast as C# pushing the pixel data which is a tad slower than C++, and constant conversions can be a problem if you modify the surface within a major game loop.

I was impressed since tung's startup game had a triangle that rotated with a line that zig-zagged through it. But I guess to get it to work without issues you had to modify his startup game to get it to show on screen... Otherwise surface.line would'be thrown an exception. Unless you just have stubs for them. His game also uses a surface in a major game loop.
Title: Re: Yet another sphere engine
Post by: casiotone on July 22, 2013, 01:15:33 pm

I was impressed since tung's startup game had a triangle that rotated with a line that zig-zagged through it. But I guess to get it to work without issues you had to modify his startup game to get it to show on screen... Otherwise surface.line would'be thrown an exception. Unless you just have stubs for them. His game also uses a surface in a major game loop.

I'm not sure if I have a different version or something but what I have, the triangle is just a simple Triangle call to draw on screen.

It now gets to this point, and unfortunately then it crashes again. Progress!

(http://i.imgur.com/pe0a8A3.png)
Title: Re: Yet another sphere engine
Post by: Radnen on July 22, 2013, 03:08:04 pm

I'm not sure if I have a different version or something but what I have, the triangle is just a simple Triangle call to draw on screen.

Well, I remember he made a compatibility version that probably removed that surface so it would work faster in the then dx8 and GL drivers.
Title: Re: Yet another sphere engine
Post by: casiotone on July 22, 2013, 03:59:53 pm


I'm not sure if I have a different version or something but what I have, the triangle is just a simple Triangle call to draw on screen.

Well, I remember he made a compatibility version that probably removed that surface so it would work faster in the then dx8 and GL drivers.


It used to draw gradient rectangles to the screen, but the last version just loads a pre-generated image, with the generating code commented out.

Code: [Select]
/*	GradientRectangle(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT, COL_LIGHT_GREY, COL_DARK_GREY, COL_BLACK, COL_DARK_GREY);
var temp_back = GrabSurface(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT);
*/
// DEBUG
/* temp_back.save("bgi_" + SCREEN_WIDTH + "_" + SCREEN_HEIGHT + ".png");
Abort("bgi_" + SCREEN_WIDTH + "_" + SCREEN_HEIGHT + ".png");
*/


Code: [Select]
function PreRenderBackground ()
{
/* // Draw the main background
GradientRectangle(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT, COL_LIGHT_GREY, COL_DARK_GREY, COL_BLACK, COL_DARK_GREY);

// Draw the top bars
GradientRectangle(0, 0, SCREEN_WIDTH, mainFont.getHeight(), COL_LIGHT_GREY, COL_LIGHT_GREY, COL_DARK_GREY, COL_DARK_GREY);
GradientRectangle(0, mainFont.getHeight(), SCREEN_WIDTH, mainFont.getHeight(), COL_LIGHT_GREY, COL_LIGHT_GREY, COL_DARK_GREY, COL_DARK_GREY);

// Clock space
Rectangle(SCREEN_WIDTH - mainFont.getStringWidth(" 00:00:00"), 0, mainFont.getStringWidth(" 00:00:00"), mainFont.getHeight(), CreateColor(0, 0, 0, 32));

// Draw the Sphere icon box
GradientRectangle(0, 0, sphereIcon.width, sphereIcon.height, COL_LIGHT_GREY, COL_LIGHT_GREY, COL_DARK_GREY, COL_DARK_GREY);

// Draw the bottom bar
Rectangle(0, SCREEN_HEIGHT - mainFont.getHeight(), SCREEN_WIDTH, mainFont.getHeight(), CreateColor(0, 0, 0, 128));

// Store it and clear it
background = GrabSurface(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT);
Rectangle(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT, COL_BLACK);
*/
// DEBUG
/* background.save("bg_" + SCREEN_WIDTH + "_" + SCREEN_HEIGHT + ".png");
Abort("bg_" + SCREEN_WIDTH + "_" + SCREEN_HEIGHT + ".png");
*/

// Load the appropriate background instead
background = LoadSurface("bg_" + SCREEN_WIDTH + "_" + SCREEN_HEIGHT + ".png");

return;
}
Title: Re: Yet another sphere engine
Post by: Radnen on July 22, 2013, 04:32:29 pm
I guess I remembered wrong then! :P
Title: Re: Yet another sphere engine
Post by: N E O on July 22, 2013, 05:47:39 pm

It now gets to this point, and unfortunately then it crashes again. Progress!

(http://i.imgur.com/pe0a8A3.png)



Is it crashing during a windowstyle blit? Others have mentioned having issues with that during their engine developments as well.

Also @all, with regards to the "how" of all this recent Sphere engine development, keep in mind that there are different methodologies happening here; yes, there are two projects using SFML but one is in C++ using V8 and trying to offload as much as possible to JavaScript (code which would actually benefit a web-based Sphere engine immensely) and the other is in C# using Jurassic and trying to build as much directly into the source as possible.

I'm just glad Sphere engine development is progressing on (almost ;) ) all fronts. :)
Title: Re: Yet another sphere engine
Post by: casiotone on July 23, 2013, 04:39:21 am


It now gets to this point, and unfortunately then it crashes again. Progress!

(http://i.imgur.com/pe0a8A3.png)



Is it crashing during a windowstyle blit? Others have mentioned having issues with that during their engine developments as well.


Nah, it's another memory corruption issue... I love C++