I'm going to have to do one of two things:
1. Preprocess all files so that const will act as var (via string replace).
2. Modify the Jurassic lexer to recognize const and treat it as a var if I'm quick 'n dirty, or as a privileged var if I have time.

Perhaps you could even properly make it act more like a preprocessor define. I know how that could be done with V8 (although it wouldn't be pretty).

Edit:
Also .__defineGetter__ and .__defineSetter__ are not ECMA standard, and quite a lot of games use them. :/

If Jurassic implements ES5 you could polyfill those with Object.defineProperty, otherwise... fork Jurassic, I guess?

Hmm, it seems to work, I need to test further but yes the 'get' and 'set' attributes are indeed present in ECMA 5, which I used to implement __defineGetter/Setter__. Thanks for the tip!

As a side note: radlib now compiles on the latest edition of sphere-sfml. Still some broken functions since they are not implemented yet such as Set/GetClippingRectangle.

I have no idea how to do a clipping rectangle in SFML.

So some issues in vanilla Sphere 1.5/1.6:

1. The surface's gradient functions produce gradients exactly opposite of the primitives API.
2. Rotations go the opposite direction compared to Image.rotateBlit.
3. The surfaces miss some extra drawing methods that are in primitives such as 'complex'.
4. Surface's Line method produces a line off-by-one on any graphics driver (not GL related).

Issues with Sphere-Sfml:

1. For say a 48x48 image, the range of 0 to 47 is used. In Vanilla sphere the range of 0 to 48 can be used.

Issues with Sphere-Sfml:

1. For say a 48x48 image, the range of 0 to 47 is used. In Vanilla sphere the range of 0 to 48 can be used.

Range?

2. Rotations go the opposite direction compared to Image.rotateBlit.

Does the rotation consider the coordinate system the standard "O=topleft and increase right and down" (and rotate visually clockwise) or does it attempt to normalize internally for expected human visualization of Cartesian coordinates and rotate visually counter-clockwise?

1. For say a 48x48 image, the range of 0 to 47 is used. In Vanilla sphere the range of 0 to 48 can be used.

This statement makes no sense, the only thing I can think of is you're referring to exclusive rectangle coordinates, i.e. the image's range full range being expressed as (0,0)-(48,48) (so that you can do x2 = x1 + width rather than having to add an additional subtraction)

Edit:
Nevermind about that. I was being silly.

NEO:
In plain English, Sphere primitives rotate counter-clockwise. Sphere surfaces rotate clockwise. Or in other words: freakin' opposite.
Sphere primitives: 180 degrees is north.
Sphere surfaces: 180 degrees is south.

So then what happens if you do SetPixel(47, 47, green) in Sphere 1.5?  Or SetPixel(0, 0, green)?  Or SetPixel(49, 49, green)?  The reason I ask is because explicitly scaling the coordinate space up by 1 pixel requires division, multiplication, or both--in other words, something you'd have to invest conscious, purposeful effort to implement.  What I'm thinking is that either Sphere is clamping the coordinates (48+ gets clamped to 47, negatives get clamped to zero), or it's a genuine off-by-one error and (0, 0) actually puts the pixel off the image.  I've never had a need to use SetPixel() so I can't personally say.

In plain English, Sphere primitives rotate counter-clockwise. Sphere surfaces rotate clockwise. Or in other words: freakin' opposite.
Sphere primitives: 180 degrees is north.
Sphere surfaces: 180 degrees is south.

That's pretty inconsistent. How did that even end up happening?? o_O

Except for game execution, Tung's startup game works 100%. Now, it's really really slow. :/

It's his gamelist code. Why is it so damn horrendously slow!? Outside of drawing that game list my sfml version is 6+ times faster.

Okay, he's drawing surfaces to screen on each games' line. He clears it, draws a color, and whether or not it's light or dark blue, then the text. In fact I don't know what compelled him to do this that rectangles and drawText can't. Surfaces were never designed for that use (outside of software rendering that is).

My sfml solution is still really fast if you think about coding with hardware in mind. Tung's demo was just so old that software renderer's were the norm. And I don't see a problem with that. Anyways it's time for new startup games. I'm glad to just emulate his game in my Sphere engine.

Hm, tried to run Specs with this, got the following console output and then the engine died:

Code: [Select]

Script error in '', line: 0
ReferenceError: SCRIPT_ON_ENTER_MAP is not defined
Script error in '', line: 0
ReferenceError: SetRenderScript is not defined

Also, using sphere-sfml with SphereStudio doesn't work at all.  Try to run any game from SphereStudio, a console window pops up and immediately disappears.

Yeah, I've been trying to work on the map engine lately. I got render and update scripts working, but trouble is they have to run throttled to the map speed. If you unthrottle the update loop (you can do this in Sphere 1.5 by hitting F1) my map engine will go to 12 fps or lower. Jurassic takes a hit when it first runs a script, after that it's just fine. That hit happens to take less than 16.67 ms, so a 60 fps game will still run smoothly. Another method might be to thread those loops.

As for the spherestudio thing: that's weird! Hmm, I might have it fixed by now since I realized right after v0.65 sphere takes a folder path, not the file path to the SGM. So that may solve it. If it does I'll put up a newer version "0.70alpha" soon.

What seemed odd to me was the "SetRenderScript is undefined" line, when the included test suite uses it just fine.  I figured I'd get issues with the map engine, but the SetRenderScript error threw me for a loop.

edit: Also, why are all the script errors listed as being on line 0 with no filename?

edit: Also, why are all the script errors listed as being on line 0 with no filename?

No idea. Syntax errors show up correctly, but execution errors do not.

What seemed odd to me was the "SetRenderScript is undefined" line, when the included test suite uses it just fine.

I might have gotten the test wrong. A test suite is no silver bullet because to ask the age old question: "what tests the tests?"

Edit:
Setters and Getters work!
Also, the editor indeed works with my current version. That means there is now a legitimate use for the settings switcher tool, and not just because I'm an organization freak.