Skip to main content

News

Topic: Sphere SFML v0.90 (Read 106447 times) previous topic - next topic

0 Members and 3 Guests are viewing this topic.
  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.90
Reply #285

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. :)
  • Last Edit: January 06, 2015, 12:02:32 am by Radnen
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere SFML v0.90
Reply #286
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
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.90
Reply #287
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.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.90
Reply #288
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.
}
  • Last Edit: January 20, 2015, 01:23:47 am by Radnen
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Sphere SFML v0.90
Reply #289
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.

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Sphere SFML v0.90
Reply #290

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.

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.90
Reply #291
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.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere SFML v0.90
Reply #292
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.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.90
Reply #293

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.
  • Last Edit: February 16, 2015, 12:11:57 am by Radnen
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere SFML v0.90
Reply #294

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...
  • Last Edit: February 17, 2015, 12:31:30 am by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.90
Reply #295

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. :P 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!
  • Last Edit: February 17, 2015, 02:42:54 am by Radnen
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.90
Reply #296
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. :/
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere SFML v0.90
Reply #297
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.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.90
Reply #298
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.
  • Last Edit: April 18, 2015, 10:44:15 pm by Radnen
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere SFML v0.90
Reply #299

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.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub