Are these changes on GitHub, or...?

Not yet, but soon. I want to add raw file support and finish the TCP stuff with ListenOnPort since technically I haven't touched the Sphere-as-server side of things. Once that is done, I'll put the code up. In reality I could push-as-I-go but I hate pushing incomplete code. :/

Edit:
I will say it gets into my Blockman game now, loads the save file and everything. Now after playing a bit I did run into issues with combat animations and player scripts, which I'll need to diagnose and fix, but this is at least a step closer to perfectly running Sphere games. Blockman had troubles since I nearly use all of Sphere's API, down to every little thing one might not realize exists until they use it... so I'd say it's a very exhaustive list of all the features in Sphere. I reckon Aquarius (Metallix's game) would be pretty consuming too, oh and Kefka's Revenge, which I'm not sure would play in my SSFML if it had troubles with recent Sphere versions (not sure, don't remember exactly what the problem was and if it truly was a Sphere bug or user code (I mean I knew it worked better on a certain version of Sphere which must have had something other versions lacked or at least became bugged)). Oh, and Trial and Error since I think it had larger maps (48*48 sized tiles) and lots of other things.

Edit2:
I just now released the source code and the latest build of it.

Hm, it doesn't appear SSFML shows the proper location when a JS error occurs.  Sometimes errors will show as:

Code: [Select]

Script error in '', line: 0

Yeah, I'm not sure, I think Jurassic has a few areas that don't quite report correctly. Sadly there isn't much I can do about that. :/

There is only one scenario where that often occurs and that's in anonymous functions, but if it's not an anonymous function then that's definitely a problem.

Ok, so weird trick, in SphereSFML you can repeat loops like this to maximize performance:

Code: (javascript) [Select]

// slower:
function Draw() {
    for (blah) {
        DrawA();
        DrawB();
        DrawC();
    }
}

// faster:
function Draw() {
    for (blah) { DrawA(); }
    for (blah) { DrawB(); }
    for (blah) { DrawC(); }
}

Sounds counter-intuitive, huh? But it actually draws faster (higher game fps) since the spritebatcher can batch "like" images easier. (A test demo went from 4900 fps to 6100 fps on my machine, almost 25% faster) Now, in most sprite batchers you can tell it to reorder the textures before each commit. This will undoubtedly change the blitting order for each image, so it's something you have to know going into it. This will increase performance by doing the above optimization on a per-texture basis (since in most hardware acceleration, textures changes are often indicators to change state). Trouble is, Sphere was never designed with this in mind so I can't easily incorporate that behavior into Sphere. There is a way for me to rig a 'manual' mode with a BeginBatch() and EndBatch() call, but of course it won't affect earlier games. And even then you'd pass a parameter into BeginBatch() something like BATCH_ORDERTEX_ASC or BATCH_ORDERTEX_DESC.

(Just posting this out of intrigue).

Edit:
A demo, just to show what it means to keep using the 1 for loop approach:

Code: (javascript) [Select]

function Draw() {
    BeginBatch(BATCH_ORDERTEX_ASC);
    for (blah) {
        DrawA();
        DrawB();
        DrawC();
    }
    EndBatch(); // it is here textures are committed, rather than some place above.
}

That's... crazy. But, well, it functions. It's nice how you handled it because other Sphere implementations could just ignore BeginBatch and EndBatch (by defining the function if it doesn't exist) and read it as normal.

Ok, so weird trick, in SphereSFML you can repeat loops like this to maximize performance:

Code: (javascript) [Select]

// slower:
function Draw() {
    for (blah) {
        DrawA();
        DrawB();
        DrawC();
    }
}

// faster:
function Draw() {
    for (blah) { DrawA(); }
    for (blah) { DrawB(); }
    for (blah) { DrawC(); }
}

Keep in mind that only works if it doesn't matter the order that DrawA/B/C are called.

Well the idea is DrawA uses the same texture A, DrawB uses B and DrawC uses C and that they are more-or-less on their own 'layers'. If they overlap there would be issues. Take for example menus in which the text is rendered on it's own apart from, say buttons, apart from other images, will have better performance.

Okay, so two things.

First: How is it that minisphere, less than a month-old project, runs Specs better than Sphere-SFML which is going on 2 years old?

Second, and the real point of this post: Spectacles' textbox crashes SSFML.  See attached screenshot for what it looks like at the moment of the crash (this screenshot was a pain in the ass to get as the VS debugger suspended the window, preventing it from being focused).  Note that Visual Studio reports it as a FatalExecutionEngineError:

Code: [Select]

Managed Debugging Assistant 'FatalExecutionEngineError' has detected a problem in 'C:\Users\Bruce\Documents\GitHub\sphere-sfml\Engine\Engine\bin\x86\Debug\Engine.vshost.exe'.

Additional information: The runtime has encountered a fatal error. The address of the error was at 0x74c58880, on thread 0x24d4. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.

In other words, a segfault.

Okay, so two things.

First: How is it that minisphere, less than a month-old project, runs Specs better than Sphere-SFML which is going on 2 years old?

Not sure, you do use surfaces a lot and it seems to me, looking at the allegro library that surfaces somehow are drawn much faster. In SSFML my pointer-based surfaces are faster than the hardware ones in practice when that should not be the case. There are no words. Because the HW surfaces should blow performance out of the water. I just don't get it.

Not sure if the error is due to pointer issues or SFML, judging by the P/Invoke it might be SFML. I have noticed errors in my GrabImage() call, causing segfaults, and I'm not calling anything out of the ordinary for the library. I hope it's not some weird interplay between SFML and Jurassic.

At the end of the day I'm not sure you are atlasing textures or sprite batching them, so the speed you get is allegro's awesomeness out-of-the-box. I'm sure my engine is better at everything else, including the map engine. I just need to fix the surfaces issues.

At the end of the day I'm not sure you are atlasing textures or sprite batching them, so the speed you get is allegro's awesomeness out-of-the-box. I'm sure my engine is better at everything else, including the map engine. I just need to fix the surfaces issues.

Yeah, I didn't want to go out of my way and do a ton of unnecessary work to try to frankenstein a sprite batcher onto the Sphere 1.5 API (note that Allegro supports batching natively via al_hold_bitmap_drawing, so if I wanted to do it, the functionality is there).  When I started this I wasn't even sure how well it was going to work.  It was an experiment, and as it turns out a very successful one!  What I'm thinking is, once I get it up and running as a full drop-in Sphere 1.5 replacement (insofar as all APIs being implemented, I can't guarantee full sound/bitmap format parity), I will go about implementing something similar to the Pegasus concept.  This way sprite batching would be a natural part of the API rather than just haphazardly retrofit onto the backend.

As for the crash, if you look at the screenshot, what it looks like is SFML is trying to draw the mask rect outside of the surface bounds, eventually leading to a buffer overrun and subsequent segfault.  I also notice Sphere-SFML doesn't seem to honor SetClippingRectangle calls...

This way sprite batching would be a natural part of the API rather than just haphazardly retrofit onto the backend.

Hey, I don't think it's entirely haphazard. It seems to work well enough. But you are right that a good batcher really is discreet, rather than involuntary like mine is. A SpriteBatcher always works better when you have the ability to tell it what and how to batch sprites.

As for the crash, if you look at the screenshot, what it looks like is SFML is trying to draw the mask rect outside of the surface bounds, eventually leading to a buffer overrun and subsequent segfault.  I also notice Sphere-SFML doesn't seem to honor SetClippingRectangle calls...

Good place to start, thanks, I do realize that there could be issues with the pointer based surfaces and respecting the correct widths and heights of images.

SetClippingRectangle should work, usually, but yes, sometimes it might not. Might just be interplay between it and the batcher. <sigh> Looks like minisphere was a good idea for simplicity's sake at least!

Ok, so, I tried the game migget Chainsaw Hands in this and it works very well!

But there is a HUGE issue with it. The game took about 30 seconds to compile the main game2() function. I mean WTF? I write to console the progress, and it literally takes a huge chunk of time to compile the function call. The strange thing is, I have easily compiled code that's far larger than this. I wonder if it's a JIT thing? In game, there was another slowdown when I hit the attack key for the first time. It took another 3 seconds to compile that function call. After that, however, the game operates at normal speed and it looks gorgeous since I have texture smoothing turned on.

I continued playing, seeing if there was anything else wrong with it and, nope, it worked like a charm. This really sucks if there are conditions that make Jurassic take forever to compile code. :/

Wow, 30 seconds?!  I thought Duktape was slow compiling delay scripts, by those were just little stutters--maybe a frame or three.  30 seconds, holy crap.

I took time to recode portions of migget chainsaw hands and was able to get the code to 'compile' in the jit much faster. I just copied large sections of the code and put the sections into functions. Not only did it read better and was clearer, it really made the difference.

It's sad really, migget's code is awful and it's awful code that compiles slowly. See, traditional compilers use syntax trees. His code was written more like a linked list of statements. So in fact, it compiled much slower than blocking it up into a dozen function calls.

... I don't know why Jurassic is particularly slow in this case, a compiler ought to handle statements much longer than Migget's, but I think it's a non-issue. Though come on, loading 1000 images is faster than that! Blockman is coded with normal design practices for code and at 100 times the codebase of migget, it 'compiles' very fast, and never did I see a slowdown due to long strings of code. I... actually don't know what to say about migget, I can't think of anyone who can think like Beaker can, it's almost unbearable to read! How'd he ever debug that?

But that slow compilation is not without a benefit: the game runs at about 8000 fps on my rig in SSFML and only at about 3500 fps in minisphere.

But that slow compilation is not without a benefit: the game runs at about 8000 fps on my rig in SSFML and only at about 3500 fps in minisphere.

Oh definitely, Duktape can never hope to even touch Jurassic without a JIT, but the "benefit" in this particular case is debatable at best--both of those figures are well, well above the 30 fps (or 60, if we choose to be particularly picky) required for the game in question to be playable.  And since this is an extreme edge case anyway, it can't even be considered indicative of real-world performance.