I dunno... since you're porting sphere to the sfml library you'd think you would re-program the map and surface portion of sphere as well that was the absolute weakest point in sphere for me.

Since it's using sfml(I like sfml) are you allowing opengl for some 3d stuff and particle effects?  If not I don't quite get the point of sfml-sphere...

Since it's using sfml(I like sfml) are you allowing opengl for some 3d stuff and particle effects?  If not I don't quite get the point of sfml-sphere...

To move Sphere to a more actively developed and modern base. Plus it's the combo of Jurassic + SFML that can give your game easily a 5x performance increase.

v1.0 == Sphere 1.5
v1.x == Sphere1.6, plus
Shaders
Isometric map engine,
inifinite maps,
etc.

Funny, I thought that surfaces and the map engine were some of the strongest points of Sphere.

As it stands, it makes at least as much sense to rewrite Sphere than use the original engine. Upgrading the SpiderMonkey (JS engine) in it would be a huge hassle, the graphics subsystem uses very old style code, and it relies on Audiere and Corona, which are old and brittle. Just getting Sphere 1.5 or 1.6 to compile using newer versions of the required libraries would be a large amount of work. It may be possible to realize the performance gains Radnen has shown with the old codebase, but it would certainly not be easy.

Efforts like the new engines are a better idea partially because of that. Plus, at least as has been shown in the case of TurboSphere and sphere-sfml, not using the old code gives us the opportunity to use newer technology without shoehorning it into an older codebase--a fully plugin based architecture for TurboSphere, JS-to-CIL compilation for sphere-sfml, we don't begin with age-old bugs and quirks inherent to the project (though that is a double-edged sword sometimes), etc.

And OpenGL (as I'm using it) is more about hardware rendering in general than 3D in particular. Using OpenGL for 2D work is not unusual, and certainly not dissuaded by the API.

Fun fact: GL and DX are very fast at 2D texture work, heck they aren't even made for 3D at all! They can show 3D, but it's indeed all about zipping through 2D fields as fast as possible, performing transformations, clipping, shading, etc.

The shader support would be nice, imagine a game having effects like you see on this page:
One of the best GLSL shader resources on planet earth: http://glsl.heroku.com/

Ok, I will say I now have Hold the Line 2 at a 100% operating condition under sphere-sfml. No crashes so far, no issues, code dependencies, JS quirks and it's a full game (I haven't released it yet). It doesn't use any crazy map stuff though, that's why it works so well.

My next step is to figure out collisions. I my even add a pixel-perfect collision function in sphere-sfml.

Not to derail the topic, but what was Hold the Line about again?  I remember that was one of the projects that made it onto the main page of the old wiki back in the day, but I never checked it out...

Not to derail the topic, but what was Hold the Line about again?  I remember that was one of the projects that made it onto the main page of the old wiki back in the day, but I never checked it out...

It's a tower defense game in Sphere, pretty addictive and fairly well liked too. Therefore I made a sequel, promised to release it by June, and sat there while my own deadline passed me by. (I blame this engine development).

Website: http://radnen.tengudev.com/holdtheline2.html

Re collisions - are you referring to sprite-sprite collision, sprite-tile collision, or sprite-obstruction line collision on the map engine?

Re collisions - are you referring to sprite-sprite collision, sprite-tile collision, or sprite-obstruction line collision on the map engine?

In Sphere you'll find they are all the exact same: line to line obstruction, and there are good algorithms for finding that out.

But I'm going to add C# coded pixel-perfect collision since it is a bit more computationally expensive. Although the JS is compiled to CIL, it's not as optimized as good as other JS engines can do (like v8), and I have access to some private fields that can help speed things up much faster than what's offered from the default Sphere API. The function call for that would be something like:

Code: (javascript) [Select]

ArePixelsObstructed(surface1, x1, y1, surface2, x2, y2);

Edit:
I found a neat resource that explains Photoshop blend modes, and the code to reproduce them. I might just extend Sphere's blend modes! http://www.venture-ware.com/kevin/coding/lets-learn-math-photoshop-blend-modes/

Update:
I have figured out map obstructions and now have the oft-used IsPersonObstructed() implemented. This will (hopefully) makes all games dependent on Lithonite work. I'm pretty sure testing Lithonite is going to be the ultimate challenge.

Remind me again with Lithonite is?

It's Future Boy Nil's de-obstruction and terrain system. It's primary use is to make the player character slide around corners, because it's awful getting stuck on a single pixel and swearing to god you could get through a gap. It also has many built-in terrain options like stairs, ramps, slippery ice, skating ice, sand/slowness, etc.

In short, Lithonite is PURE AWESOME. I always wished that its obstruction handling was built-in to Sphere's map engine, and this script was the next best thing.

Update:
I just added person talking. It's strange, so Sphere doesn't rely on it's internal input handler for talking. It must rely on the map engine itself to handle keypresses, otherwise you can do stuff while still in a talk script. Also there was a weird issue when drawing the map. Since I'm using the gpu for the camera (fast offsetting), I have to reset the camera so it draws things normally to screen (where (0, 0) is true (0, 0)), anyways I thought it would be simple to implement talking but there were a ot of little design things that got in the way - all corrected now.

It's remarkably confusing at times exactly how the map engine operates! But I'm glad to emulate it thus far. For example, the talk distance while in pixels is not the actual talk distance. Sphere must add the distance from a sprites origin to their base on top of the distance. This allows a distance of 8 (smaller than the distances between bases) to work. Most Sphere sprites usually have a base of 16x16, if two entities bump into each other with bases of that size - Sphere's default talk distance of 8 would not work, but yet it does. That's because of the base distance it adds on top of that distance. The code for something like that (for those curious) is something like this:

Code: (csharp) [Select]

Line[] pBase = person.GetBounds();
int w = (int)(pBase[0].End.X - pBase[0].Start.X);
int h = (int)(pBase[1].End.Y - pBase[1].Start.Y);
float dx = person.Position.X - compare.Position.X;
float dy = person.Position.Y - compare.Position.Y;
double a = Math.Atan2(dy, dx);
dx -= (float)(Math.Cos(a) * w/2);
dy -= (float)(Math.Sin(a) * h/2);

if ((int)Math.Sqrt(dx * dx + dy * dy) <= _talk_dist)
    return person.Name;

Code: (csharp) [Select]

Line[] pBase = person.GetBounds();
int w = (int)(pBase[0].End.X - pBase[0].Start.X);
int h = (int)(pBase[1].End.Y - pBase[1].Start.Y);
float dx = person.Position.X - compare.Position.X;
float dy = person.Position.Y - compare.Position.Y;
double a = Math.Atan2(dy, dx);
dx -= (float)(Math.Cos(a) * w/2);
dy -= (float)(Math.Sin(a) * h/2);

if ((int)Math.Sqrt(dx * dx + dy * dy) <= _talk_dist)
    return person.Name;

Okay so I get what sqrt(dx^2 + dx^2) is, that's calculating Pythagorean distance, but what's with all the trig functions?