Spherical forums

Sphere Development => Engine Development => Topic started by: Radnen on July 06, 2013, 07:03:11 pm

Title: Sphere SFML v0.90
Post by: Radnen on July 06, 2013, 07:03:11 pm
(http://radnen.tengudev.com/images/spheresfml.png)

Introducing Sphere-SFML
A modern day, Windows only (presently) .NET based Sphere Engine alternative using SFML, aimed to be Sphere standards compliant with over 350 unit tests and under 5,000 LOC.

What do I mean by "Sphere Standards Compliant"? I mean you can take a game from way back in 2003 and still use it in my engine with *no* added changes. You might be able to load games earlier than that, but sphere file formats have changed since then and you might be loading a game that's simply too old. This also means it's for games against the latest Sphere standard (Sphere v1.5/1.6), which coincidentally hasn't changed since around 03'. See Github Sphere Documentation (https://github.com/sphere-group/sphere-doc/tree/master/internal) for raw sphere filetype details.

Source Code:
https://github.com/Radnen/sphere-sfml

Sphere Compliance:
**Complete**
- Images: 100%
- Input: 100%
- Sounds: 100%
- Fonts: 100%
- WindowStyles: 100%
- Spritesets: 100%
- Files: 100%
- Networking: 100%

**Incomplete**
- General: 92%
- Persons: 90%
- Surfaces: 69%
- Primitives: 65%
- Map Engine: 60%

Alpha versions:
Latest: http://radnen.tengudev.com/spheresfml/sphere-sfml-0.90.zip
Other: http://radnen.tengudev.com/spheresfml/

Tips and neat additions
1. MapEngine() can take the fps as an optional parameter default = 60.
2. Hashing functions take a boolean as a second variable, that will return a SHA1 instead of an MD5 hash.
3. Along with other interesting Sphere keys, key F2 will automatically double the viewport size (giving you x2 scale).
4. Has a built-in BinaryHeap, use 'new BinaryHeap(func)' in your code to use it.
5. Has an experimental built-in method for serializing JS to XML files (for save-games etc).
Title: Re: Sphere SFML
Post by: N E O on July 06, 2013, 10:45:49 pm
I'm intrigued as to what this "Jurassic" library is. I look forward to seeing the progress of this engine implementation!
Title: Re: Sphere SFML
Post by: Radnen on July 06, 2013, 11:27:00 pm
I lied. It's not Mono compatible! Welp. I was running and testing code under MonoDevelop (now titled Xamarin Studio) but it seems it was using .NET 4.0? When I run it exclusively under mono it doesn't seem to work. Anyways, JSIL may not be mono-compat as well, I juts hope it's cross-platform in the end (I mean it's JavaScript in the end).

Jurassic is an abstraction layer and full implementation of ECMA script v3 and v5 (plus v5 strict mode). It's pretty fast, I think it uses v8 (it literally compiles JS to CIL) but it's not yet chrome-fast, check it out here: http://jurassic.codeplex.com/
Title: Re: Sphere SFML
Post by: Fat Cerberus on July 06, 2013, 11:33:25 pm
Hey, awesome, I've been looking for a JS engine for .NET for a while now, I'll have to check Jurassic out when I have some free time. ;D

Edit: Wow, this is ridiculously easy to use!  The Jurassic API is really quite nice.
Title: Re: Sphere SFML
Post by: Radnen on July 07, 2013, 12:40:31 am
It was actually a nightmare to use.  :o But it is indeed a necessary nightmare. In Javascript.NET I could directly pass .NET objects to and from the JS engine which makes it incredibly easy to wrap .NET classes for images, colors, etc. But it didn't implement exactly what Sphere had, for example ToString() wasn't do the right thing, variable access were muddled, and many methods I didn't want carried over, carried over.

At least with Jurassic I get full control over how I present the underlying .NET object to the JS environment. So, much more work, but better results and emulation of Sphere 1.5's native object idioms.
Title: Re: Sphere SFML
Post by: DaVince on July 07, 2013, 08:28:06 am
I guess I'd need to compile this in order to test? In any case, I don't think .NET is the way to go when it comes to implementing a Sphere engine (portability?).

Though it's still nice work. I think. I can't test it. :P
Title: Re: Sphere SFML
Post by: Radnen on July 07, 2013, 02:35:25 pm
Well I wanted to make it in Mono, but the JS engine won't run in Mono, Welp.

But there is JSIL, so Maybe that will make it cross-platform?
Title: Re: Sphere SFML
Post by: Vakinox on July 07, 2013, 02:43:26 pm
Isn't Lua script like JS?

I know it works with Linux because of the Rainmeter program.
And of course works with Windows also.
Is it possible to replace JS with Lua, or is that a little more difficult than what is in mind?
Title: Re: Sphere SFML
Post by: Radnen on July 07, 2013, 02:47:59 pm

Is it possible to replace JS with Lua, or is that a little more difficult than what is in mind?


Not to mention such a move would break all existing games! I want something existing JS games can run on. If I went with Lua I'd be making a new game engine basically.
Title: Re: Sphere SFML
Post by: Vakinox on July 07, 2013, 03:09:41 pm
Yes, but it'd still be Sphere in spirit.
After all the point is to have a scripting language that can be somewhat easy to
learn and understand for those inexperienced with programming languages.

I was also reading a blog though about something with a Javascript interpreter in Mono.
What I understand from reading, Mono relies heavily on C# and what you'll need is something
to translate Javascript for C# programming. C# compiler for using Javascript essentially I think?

Just contributing ideas. I admit these matters are a bit too advanced for me to understand most of.
Title: Re: Sphere SFML
Post by: Flying Jester on July 07, 2013, 03:34:46 pm
Mono is (correct me if I'm wrong, .NET isn't exactly my area of expertise) an implementation of some primary components of .NET, including the CLR (common language runtime?), which is (part of?) the backend for C#, VB.net, C++/CLI, and some other languages. Ideally, Mono would let you run .NET programs without specifically having the Microsoft .NET framework, which is mostly important for non-Microsoft platforms (such as Linux).

There are already a lot of LUA engines, it's a very popular language for scripting games. But what makes Sphere interesting is that it uses JavaScript, and has a lot of freedom (most other JS-scripted engines I've found really don't). In fact, what I would consider the most similar engine in spirit (or how I see the spirit, anyway) to Sphere, Love2D, uses LUA.

And I for one prefer curly-bracket languages to LUA/Basic style languages.


I lied. It's not Mono compatible! Welp. I was running and testing code under MonoDevelop (now titled Xamarin Studio) but it seems it was using .NET 4.0? When I run it exclusively under mono it doesn't seem to work. Anyways, JSIL may not be mono-compat as well, I juts hope it's cross-platform in the end (I mean it's JavaScript in the end)


.NET 4.0 is the most compatible thing for Mono, at least as far as I've found. If you have 64-bit Linux, you can't even use .NET 2.0 (supposedly you can, but if so then it's extremely difficult). I may have a look, and see if it will run for me.
Title: Re: Sphere SFML
Post by: DaVince on July 07, 2013, 04:18:31 pm
Quote
There are already a lot of LUA engines, it's a very popular language for scripting games. But what makes Sphere interesting is that it uses JavaScript, and has a lot of freedom (most other JS-scripted engines I've found really don't). In fact, what I would consider the most similar engine in spirit (or how I see the spirit, anyway) to Sphere, Love2D, uses LUA.

I was thinking that as long as the API Sphere provides is kept, the language doesn't really matter that much.

...Well, I'm saying that even though I like JS and know a bunch of details in JS I don't know how to do in any other language. So JS is optimal for me, and sticking with it just strengthens my knowledge on it. Though that makes me a one-sided coder. :P
Title: Re: Sphere SFML
Post by: Vakinox on July 07, 2013, 05:27:17 pm

...Well, I'm saying that even though I like JS and know a bunch of details in JS I don't know how to do in any other language.
So JS is optimal for me, and sticking with it just strengthens my knowledge on it. Though that makes me a one-sided coder. :P


This is how it's viewed in my perspective also. Totally agree.
Either way I'm happy, and either way helps.

Just saying if there's an amount of effort put into keeping sphere the same
and it's extremely difficult to get that result, maybe a different language
is needed for Linux-users. Personally open to it, with Lubuntu on my Netbook
cause then I can code on the go :p
Title: Re: Sphere SFML
Post by: Radnen on July 07, 2013, 05:29:10 pm
Jester: You are right but some libraries just aren't ported over 100%. Jurassic uses a dynamic IL converter that comes with the Windows .NET package. Mono does not have that implemented. So I can't run it in Mono.

Guys, if you are running in Linux/Mac do any of the demos on this site work for you? http://jsil.org/

If they do, then I'll continyue development in .NET.

Also I was able to get Jurassic to compile and run under Mono, but I had to modify the source, removing dynamic methods. This sucks because the Sphere API is implemented as dynamic methods in the JS engine. That means you can Run JS in Mono, but you can'u use a native function (Like LoadImage()).
Title: Re: Sphere SFML
Post by: DaVince on July 07, 2013, 05:39:54 pm
Those demoes work! If this is the easiest way to go for Sphere on the Web, I'd say go for it!

Edit: doesn't always work as well as I'd hope, though. The sound in http://hildr.luminance.org/RPG/RPG.html is really distorted, but the sound in Escape Goat if fine, for example.
Title: Re: Sphere SFML
Post by: Radnen on July 08, 2013, 03:23:42 am
OH MY GOD GUYS. Test driven development is awesome! I just found a quirky bug in Surface.getPixel() because of it. Otherwise I would have _never_ spotted it until it was too late!

I've been creating many, tests against the Sphere API. Still not done, but 100% of my effort is going into these tests. Once the tests are done, I'll start to implement features until I get a 100% green-light. :) That will mean all features work and are implemented.

But it is not a silver bullet. Other things that I did not test for may indeed still creep up, but I hope to get the entire API down first. :)
Title: Re: Sphere SFML
Post by: Fat Cerberus on July 08, 2013, 12:37:03 pm
I never had the patience for TDD.  I get why it's a good thing, but if I can't see the results of my efforts in some practical form (for example, when developing a game, I want to see something playable, not just "oh, all these tests passed, yay") I get bored very quickly.  If I were to spend all my time writing unit tests, it'd take me so long to get to that point that I'd end up giving up.

Out of curiosity though, what was the quirky bug?
Title: Re: Sphere SFML
Post by: Radnen on July 08, 2013, 01:44:23 pm

Out of curiosity though, what was the quirky bug?


The JS environment doesn't like bytes, but SFML's colors were in bytes. That means I have to cast to int going between the JS side of things and SFML. The Property setters took objects tho, so I forgot to cast to a byte when creating a new instance with a color in the constructor.

A new feature in my Sphere version: CreateColor(copy);

TDD does take a lot of time. I cannot create the tests I want too it'll be too exhausting. I only made tests that test against Sphere's API. Does toColor return [object color]? Do images have .blit, .blitMask, etc. implemented? You can download the source and run the tests yourself and get a good idea how far along I've implemented the Sphere API.
Title: Re: Sphere SFML
Post by: Fat Cerberus on July 08, 2013, 01:58:28 pm

A new feature in my Sphere version: CreateColor(copy);


Yay, cloning colors!  I could never figure out why Sphere's color object is non-enumerable, this prevents my clone() method from working on them.  I managed to find a neat trick to clone them in Sphere 1.5 though:
Code: (javascript) [Select]
var copy = BlendColors(color, color);
Title: Re: Sphere SFML
Post by: Radnen on July 08, 2013, 02:17:40 pm
Well, in Sphere-sfml you can't clone the objects I give you. The reason for this has to do with the fact that the underlying color object is a type of color instance that contains with it a SFML color object. If I move to a pure object instance, then colors have to be recreated each time they get used, which is a tad slower. So it's a trade-off: speed vs cloning power. To mitigate the cloning tho I can do things like CreateColor(copy) which returns a copy of the color and it being a color instance.

However there is one freedom I do give you: in sphere-sfml you can tack on properties whenever you like, the objects are mutable and enumerable. :)

I just tested this, you can do this:
Code: (javascript) [Select]

var col1 = CreateColor(255, 0, 0);
var col2 = CreateColor(255, 255, 255);

for (var i in col1) col2[i] = col1[i];

image.blitMask(0, 0, col2); // will be red.
Title: Re: Sphere SFML
Post by: N E O on July 08, 2013, 04:24:01 pm
What's your procedure for writing tests, just visiting the API list (either in doc_functions or the wiki page) and going down the list or do you concentrate on specific areas at a time like "all Image API" then "all Surface API" then "all Sound API" etc?
Title: Re: Sphere SFML
Post by: Radnen on July 08, 2013, 04:29:22 pm

What's your procedure for writing tests, just visiting the API list (either in doc_functions or the wiki page) and going down the list or do you concentrate on specific areas at a time like "all Image API" then "all Surface API" then "all Sound API" etc?


I'm concentrating on areas at a time, but there's no way I can do all of the surfaceblits in a reasonable amount of time, so I'm aiming for a good subset of these areas. Some of the methods I don't think are possible to implement in Sphere SFML. And I'm being a bit selfish and trying to implement all of the functions my sphere game Blockman uses, as because I think its a good candidate for a well-established game in the Sphere API. If you have an editor with NUnit (Xamarin Studio (the new name for MonoDevelop)), you can check out the code and see for yourself :).

Edit I can't get gradient triangle implemented because this line is not possible in C#. There are too many args!
Code: (csharp) [Select]

            engine.SetGlobalFunction("GradientTriangle", new Action<double, double, double, double, double, double, ColorInstance, ColorInstance, ColorInstance>(GlobalPrimitives.GradientTriangle));


:P

I'm going to have to do a different style in which you pass point objects to the drawing methods. A required JS file can then link the two for backwards compatibility. Anyways who would put in so many arguments? These days all primitives are drawn with (x, y) vertices.
Title: Re: Sphere SFML
Post by: Fat Cerberus on July 08, 2013, 05:50:35 pm

I just tested this, you can do this:
Code: (javascript) [Select]

var col1 = CreateColor(255, 0, 0);
var col2 = CreateColor(255, 255, 255);

for (var i in col1) col2[i] = col1[i];

image.blitMask(0, 0, col2); // will be red.



I assume you mean that works in sphere-sfml, right?  Because it definitely doesn't work in Sphere 1.5, I know because I had to hack a special case into to my tween scenelet in Scenario to handle tweening CreateColor()'d colors, otherwise it didn't work.
Title: Re: Sphere SFML
Post by: Radnen on July 08, 2013, 06:21:04 pm
No, yeah I meant Sphere-Sfml. :)

I just got basic input in. I thought it would be a nightmare to try and cover all of the key constants, but I was able to make a mapping between SFML's keyboard constants and the KEY_* fields. However, they may not be the same as Sphere 1.5. Therefore if you have a saved game that saved your key mappings from Sphere 1.5 they'll change if you switch over to sphere-sfml! I'll have to individually remap each key... to fix that.
Title: Re: Sphere SFML
Post by: Radnen on July 13, 2013, 05:29:11 pm
Alright, latest version now at github. This one can play most games that do not use the map engine or system scripts. So if you have a graphics only tech demo that doesn't utilize the surface object (as it is incomplete), then you can run your game in it.
Title: Re: Sphere SFML
Post by: Flying Jester on July 13, 2013, 09:33:50 pm

I just got basic input in. I thought it would be a nightmare to try and cover all of the key constants, but I was able to make a mapping between SFML's keyboard constants and the KEY_* fields. However, they may not be the same as Sphere 1.5. Therefore if you have a saved game that saved your key mappings from Sphere 1.5 they'll change if you switch over to sphere-sfml! I'll have to individually remap each key... to fix that.


I've got the same issue with SDL (and now SDL 2) key constants. One night I just bit the bullet and wrote all 130 SDL Key Constants into the input plugin, which was *not* fun, nor would I wish it on anyone else.

I did figure out a better way, though. I can just loop from 32 to 130 (100? Something like that?), bind the variable as the number, and then call SDL_ScanCodeToKeyCode (or maybe it was KeyCodeToScanCode? Either way it changed in SDL 2) and then call the SDL Key Name function on that number. I'll certainly get a bunch of garbage values in there, but I'd also get all the codes needed. And it would be prettier code, easier to write, simpler in general, and better to maintain.

I'm just writing the changes in key constant literal values off as a loss of compatibility, myself. The code will work the same if you actually used the key constants as you should. The only problems would show up in game saves...but in that case, it should be relatively simple to just edit the save.
Title: Re: Sphere SFML
Post by: Radnen on July 13, 2013, 09:49:04 pm

I did figure out a better way, though. I can just loop from 32 to 130 (100? Something like that?), bind the variable as the number, and then call SDL_ScanCodeToKeyCode (or maybe it was KeyCodeToScanCode? Either way it changed in SDL 2) and then call the SDL Key Name function on that number. I'll certainly get a bunch of garbage values in there, but I'd also get all the codes needed. And it would be prettier code, easier to write, simpler in general, and better to maintain.


I did a similar approach too! But some of the key nnames were different. There were 'Left/Right Alt/Control/Shift', (yeah ctrl was spelled control) 'Return' instead of 'Enter', etc. So some string conversion had to be done. I am left with invalid key references for saved games tho. Maybe a JS script convert from * to Sphere and Sphere to *? That might take some work, lol. I wonder if it's a constant off or altogether mixed up? I'm tempted to do something like: "key_code + n = sphere_key_code"

Alright, I just added joysticks. It can support up to 8 (currently), joysticks at a time. It can also auto-detect a plugged-in joystick. Vanilla Sphere could not: you had to restart the game engine.

Also, my windowstyle test crashes in Sphere v1.6 and in Sphere v1.5 but not my my sphere-sfml. It has to do with WindowStyle.clone();

Code: (javascript) [Select]

// Purpose: Tests the speed and efficiency of images.

function TestWindows()
{
var done = false;
var wind = LoadWindowStyle("main.rws");

var wind2 = wind.clone();

var blue = CreateColor(0, 0, 255);
var white = CreateColor(255, 255, 255);
var time = 0, i = 1, x = 0, y = 0;

while (!done) {
wind.drawWindow(32, 32, 80, 80);

wind.setColorMask(blue);
wind.drawWindow(128, 32, 80, 80);

wind2.drawWindow(32, 128, 80 + x, 80 + y);

wind.setColorMask(white);

if (time + 25 < GetTime()) {
if (x == 100 || x == -4) i *= -1;
x += 4 * i;
y += i;
time = GetTime();
}

FlipScreen();

while (AreKeysLeft()) {
if (GetKey() == KEY_ENTER) done = true;
}
}
}


I cannot believe Sphere does not have a clone method for windowstyles when it does have one for most other objects. Removing the offending windowstyles makes it run in Sphere 1.5, but it crashes after 5 seconds in sphere 1.6. There you have it folks: Sphere 1.6 is very unstable. Oh! Now I know why Blockman randomly crashes, it too grows and shrinks windowstyles.
Title: Re: Sphere SFML
Post by: Flying Jester on July 14, 2013, 06:55:46 am
Makes me want to check how TS handles hot-plugged joysticks! I honestly don't know if it can see them, and it's hard for me to properly test that properly--especially considering most of my testing has been with a slightly hokey userspace XBox controller driver on Linux, and a re-wired original XBox duke controller.

Perhaps we should write up the new functions and behahiour for WindowStyles, they obviously haven't had as much love as the other Sphere objects. Having getImage() and Clone() members would go a long way to making them more usable, and much more similar to how other Sphere objects work.
Title: Re: Sphere SFML
Post by: Radnen on July 14, 2013, 03:38:09 pm
I don't know why but .NET code always take 30,000+ K of memory. Sphere has a very light footprint, which I guess is something I can't really try to change. The good news is that my engine can use more than a single core. On my quad core it's usually in the mid 30's of CPU usage, rather than stuck at 25%.
Title: Re: Sphere SFML
Post by: DaVince on July 14, 2013, 04:06:18 pm
I say don't worry about it, considering how most peoples' systems have plenty of RAM nowadays. What I'd worry about more is how much space the engine would take up when converting it into an HTML app.

Also, it can run games already? Nice!
Title: Re: Sphere SFML
Post by: Radnen on July 14, 2013, 04:21:50 pm

Also, it can run games already? Nice!


Just about *anything* that doesn't use the map engine or certain function calls that I hadn't implemented, to see the list check out the project and run through it's test cases. I'll try to enumerate a better list later today, but so far I have:

Color object 100%,
Images, 100%,
Windowstyles 100%,
Fonts 90%,
Input minus mouse wheel and joystick axes (so like 90%),
Surfaces like 20%.

Nothing with the map engine, yet. But I have emulated the Sphere command queue in another project of mine, so I know exactly how it works.
Title: Re: Sphere SFML
Post by: DaVince on July 14, 2013, 04:23:52 pm
Hmm, do you have anything precompiled for us non-.NET folks? I wanna try out some stuff. :) (In Windows now, too, so it'll Just Work.)
Title: Re: Sphere SFML
Post by: Radnen on July 14, 2013, 04:44:19 pm

Hmm, do you have anything precompiled for us non-.NET folks? I wanna try out some stuff. :) (In Windows now, too, so it'll Just Work.)


Oh, uh soonish. :)
Title: Re: Sphere SFML
Post by: DaVince on July 14, 2013, 04:45:47 pm
Okay. I can wait until things get stable. :P

Edit: Oh! Uh... The Japanese full-width font was on, for some reason. Strange, normally it toggles between regular text and Japanese, not this weird stuff...
Title: Re: Sphere SFML
Post by: Radnen on July 14, 2013, 05:45:49 pm
I'll put up an alpha build. I should add a webpage or it too. Check the OP for a download. Use -game to run a game, just like in normal sphere. It worked for me... but you *might* need to have the games in a /games folder for now I haven't tested a full path, but it should work.
Title: Re: Sphere SFML
Post by: DaVince on July 14, 2013, 05:49:28 pm
Thanks! Checking it out right away.

(Fixed the link, tengudev is a .com. ;))

(edit - TENGUDEV is a .com, spheredev is still .org ;)  ~neo)
Title: Re: Sphere SFML
Post by: DaVince on July 14, 2013, 06:20:27 pm
Well, it will certainly run your game, no matter if I just run the engine or use -game! But trying any of my own test games, it always crashes with the following (tried translating the error from Dutch):

Code: [Select]
C:\Users\Vincent\Downloads\temp\sphere-sfml-0.5\sphere-sfml>Engine -game games\D
aVince-Examples\Example2\game.sgm

Unhandled exception: System.ArgumentOutOfRangeException: Length can't be lower than zero.
Parameter: length
   bij System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length,
Boolean fAlwaysCopy)
   bij Engine.Objects.GameFile.ReadFile(String filename)
   bij Engine.Program.Main(String[] args)


This happens even if I set it as the startup game.
One of the games I tried is attached.

EDIT: re-uploaded so it works without the time.js system script, and uses SetFrameRate() instead (it checks if the functionality SetFrameRate exists, first).
Title: Re: Sphere SFML
Post by: Radnen on July 14, 2013, 06:36:46 pm
Ok, I see what's wrong.

I also don't have RequireSystemScript. So, I'll have to add those in soon.
Title: Re: Sphere SFML
Post by: DaVince on July 14, 2013, 06:41:27 pm
Nice! Looks better, too. And I fixed the test for now by using SetFrameRate instead (if the function exists).

A request: being able to run the game by dragging its game.sgm or directory to engine.exe. In other words, supporting "Engine.exe path/to/game". The old engine was able to do this, and it's useful for quick testing (dince I need to find the console and cd to the path right now).
Title: Re: Sphere SFML
Post by: Radnen on July 14, 2013, 06:47:50 pm
Alright.

Wow, setCharacterImage will be tough to do! It involves dismantling the font's texture atlas and rebuilding it with the new letter added. Jeez.

Edit: alright, it is done. I'll make a newer version soon after I implement a few more things.

Edit: dragging and dropping a game over the .exe seems to set the working directory to the directory of the dropped item. Hmm... I need to do some changes to fix system scripts access in that case.

Edit: finished that, phew! I couldn't compromise at all. If you load from the exe, the working directory becomes the exe's which makes the game's directory unavailable, but if you load with a file dragged and dropped onto it, the working directory becomes the games, which makes /system directory unavailable. So I had to say "hey, no matter where you are executing from just remember this executable and the game and use those explicitly". I wanted to have an implicit working directory, but that's not going to happen.

I'll have a new download up soon. Just a few more API features and I'll go.

Edit: And it's done another release is up.
Title: Re: Sphere SFML
Post by: Radnen on July 15, 2013, 05:17:44 am
Sounds added! I've put up a new version, get while it's hot!
Title: Re: Sphere SFML
Post by: DaVince on July 15, 2013, 06:27:41 am
Nice work! However, the engine crashes when I change my system volume (currently outputting through a secondary HDMI source, if that matters). It's also making a very slight high-pitched noise during the silent menu (and it will crash when changing the volume there, too).

I like the pitch changing feature. :P

Oh, and I can't up the volume in-game when I turn it down. It seems to set a new upper limit or something.

Edit: something else, the ctrl key isn't detected properly. The attached demo tries checking if you press ctrl, and it will only continue if you press right ctrl, not left ctrl.
Edit 2: that Hmm rectangles demo from before reports it's running at 63 FPS instead of the fixed 60.
Edit 3: IT modules won't load (unsupported format). That's fine and all, but instead of aborting, the engine locks up and crashes with a Windows error message. Try the attached SoundTest. It seems to recognize that the sound format isn't supported, but then it seems to try and play it anyway.
Edit 4: the colours do something funky they don't do in regular Sphere. Check the attached DaVince-AnimTest and pay attention to the colour-changing text.
Edit 5: In the attached DaVince-textdemo, most of the characters from the font aren't drawn! I only see these characters: ! 0 :
Title: Re: Sphere SFML
Post by: Radnen on July 15, 2013, 03:21:48 pm
1. the pitch changing features is in normal sphere too.
2. the volume SFML takes is between 0 and 100, there might still be a rounding issue when converting from 0 and 255, but my tests seem to pass.
3. SFML has RControl and LControl. :P I may need to make a separate global variable for ctrl and tie it to both buttons. Same for Alt and Shift.
4. SFML doesn't use fixed timestep. When you set it to 60fps it'll aim for 60. It has to do with the OS sine it idles/sleeps between frames and that's not perfectly timed.
5. I need to move away from SFML's sound library, if you want to know hat types it can load go here: http://www.mega-nerd.com/libsndfile/
6. Hmm, weird.
7. Well, the letters started to consume the whole texture atlas! Ok, I have made the texture atlas larger and now it works. I was testing with smaller fonts and that didn't happen. Anyways I'll try for an automatic detection.
Title: Re: Sphere SFML
Post by: DaVince on July 15, 2013, 04:48:10 pm
Quote
2. the volume SFML takes is between 0 and 100, there might still be a rounding issue when converting from 0 and 255, but my tests seem to pass.

Your test game starts at 255, and I can go down as much as I like, but I can only go back up a few bits. So when I lower the music volume to 245, I can only get back up to around 247. If I go down to 200, I can only get back up to 202. That's what I meant.
Title: Re: Sphere SFML
Post by: Radnen on July 15, 2013, 07:28:53 pm

Quote
2. the volume SFML takes is between 0 and 100, there might still be a rounding issue when converting from 0 and 255, but my tests seem to pass.

Your test game starts at 255, and I can go down as much as I like, but I can only go back up a few bits. So when I lower the music volume to 245, I can only get back up to around 247. If I go down to 200, I can only get back up to 202. That's what I meant.


Right, but the difference from 255 and 253 is not the same as 100 and 98, because of this mapping issue, you can't climb back up (or very far), since things are floored you can only go down. In sphere if you notice things go down in 1 increments while in my version it can down in 1 to 3 increments due to the rounding + conversion. This can be fixed with an independent value scaled to fit SFML and Sphere.

Edit: and it's fixed.
Title: Re: Sphere SFML
Post by: N E O on July 16, 2013, 03:50:02 pm
You know what? I feel the need for a tutorial article on the wiki Developing a Sphere-compatible engine (http://wiki.spheredev.org/Developing_a_Sphere-compatible_engine). Engine devs edit as needed with your personal experience on creating the thing :)

Also, stickying the topic.
Title: Re: Sphere SFML
Post by: Radnen on July 16, 2013, 06:25:17 pm
I don't want it stickied. In fact I'll make a stickied topic that points to the forum posts, in this way the stickied topics don't clutter this subforum.

Edit: I can't do that.. I remember doing that here before. Weird.
Title: Re: Sphere SFML
Post by: DaVince on July 16, 2013, 06:29:46 pm
I unstickied it for you, Radnen. :)

I'm thinking... Would it be better to have a special subforum for engine-related projects? That way, we don't have to have this many sticky threads.
Title: Re: Sphere SFML
Post by: Radnen on July 16, 2013, 06:33:36 pm
Oh, I found out where to do that now XD. Okay, thanks DaVince. +1 on the subforum idea for engines. I'll hold off on making a post until god, ahem, Neo decides. :P
Title: Re: Sphere SFML
Post by: Radnen on July 16, 2013, 09:02:42 pm
I have finished Spritesets.

Now I am working on the FileSystem functions, File and RawFile objects.

Then I'll do general game loading (to run startup games correctly). How about this guys: starting a game opens it in a new window; keeping your current window open. That way all strange bugs are eliminated, and there were plenty: invalid screen size, sounds going forever, crashes, etc.

Finally, I'll do the map engine last.

Edit: Guys, with Jurassic it will one day be possible to compile JS to a file and use compiled JS straight-up when you launch your game. This can greatly increase execution speed in some cases.
Title: Re: Sphere SFML
Post by: N E O on July 17, 2013, 05:06:00 pm

Finally, I'll do the map engine last.


Isn't that indeed often the case? Map engine implementations always go last ;)
Title: Re: Sphere SFML
Post by: Radnen on July 17, 2013, 05:34:25 pm
Wait for it.... Networking will be the very last to do in fact. I swear! :)

I just finished file reading/writing. Interesting thing I found out about Sphere: If you save a double, make sure to read back a double. It sounds stupid but it's true.

Code: (javascript) [Select]

file.write("test", 1.568);
file.read("test", 5); // returns 1
file.read("test", 7.2); // returns 1.568


So that explains why I had numbers screw up in my early years w/ sphere's file object. :P Also you can't run the above test in Sphere 1.5/1.6, because you need to flush, save, and reopen the file. But in sphere-sfml you can.
Title: Re: Sphere SFML
Post by: Flying Jester on July 17, 2013, 11:20:28 pm
You generally have to make sure the default value you give a read is the same type you want to read out if it exists. I ran into a couple issues with that and strings before.
Title: Re: Sphere SFML
Post by: Fat Cerberus on July 18, 2013, 12:25:58 am

You generally have to make sure the default value you give a read is the same type you want to read out if it exists. I ran into a couple issues with that and strings before.

Indeed, but JS makes no distinction at the language level between an integer and a double--a number is a number (in other words, 1 === 1.0 === true).  So I can see why it's weird in this case to have them treated differently.
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 18, 2013, 01:42:46 pm
So I forgot to link the latest release here, v0.65. It introduces all manner of file objects and the ByteArray class Have fun!
Title: Re: Sphere SFML v0.65alpha
Post by: Vakinox on July 18, 2013, 03:45:14 pm
Question, bit confused with all the other engine releases being worked on.

Is the goal of sfml Sphere to be cross-platform, or to forward web development for sphere (access from browser)?

Know that TurboSphere is to increase performance (originally to achieve ability to make mode7 games).
The others though I'm a bit lost on as well.
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 18, 2013, 03:52:33 pm
It is intended as a multi-platform, and web-based solution that is also really fast and error-free. It's supposed to be a silver bullet.

But, it's not currently cross-platform since Jurassic is not. It is also not web-based yet since I haven't ran JSIL on it. But once those problems are resolved it will be.

Currently you can make games that do not use the map engine or networking features.
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 19, 2013, 12:16:32 am
MAP ENGINE.

I'm surprised how little effort it took to get this far. I basically copied and pasted the map file code straight from the editor (thank god I used the MVC design). That means I just wrote a quick SFML wrapper for the graphics and there you have it. Maps.

Ignore the fps, that's stuck on from the last frame. It's more like 800ish

Edit: I optimized the drawing to use surfaces. It's now back to 6000 fps on maps. :)
Well, now the hard part is doing this for very large maps. Luckily I have an implementation for that in my sphere editor. :)
Title: Re: Sphere SFML v0.65alpha
Post by: Fat Cerberus on July 19, 2013, 10:06:30 am
Hmm, I really need to try running Specs on this now and see what happens. :)
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 20, 2013, 03:13:55 am
So the largest error I cannot solve easily in Sphere-Sfml is the use of const. Many older games used it everywhere, but it's not ECMA standard as of today (the latest standard v6 may add it in). Because it's not standard only SpiderMonkey can run const. If it works in v8 it's because they borrowed/stole that functionality as because it strictly is not standard compliant...

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.

Since I do *not* want to lose focus of my goal I will just do #1 and then do #2 down the road.

Edit:
Also .__defineGetter__ and .__defineSetter__ are not ECMA standard, and quite a lot of games use them. :/
Title: Re: Sphere SFML v0.65alpha
Post by: Flying Jester on July 20, 2013, 06:34:37 am

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).
Title: Re: Sphere SFML v0.65alpha
Post by: alpha123 on July 20, 2013, 11:51:25 pm

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?
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 21, 2013, 03:51:44 am
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.
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 22, 2013, 12:13:49 am
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.
Title: Re: Sphere SFML v0.65alpha
Post by: Flying Jester on July 22, 2013, 05:03:30 am

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?
Title: Re: Sphere SFML v0.65alpha
Post by: N E O on July 22, 2013, 05:39:42 pm

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?
Title: Re: Sphere SFML v0.65alpha
Post by: Fat Cerberus on July 23, 2013, 12:05:21 am

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)
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 23, 2013, 12:26:38 am
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.
Title: Re: Sphere SFML v0.65alpha
Post by: Fat Cerberus on July 23, 2013, 12:36:13 am
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.
Title: Re: Sphere SFML v0.65alpha
Post by: N E O on July 23, 2013, 12:41:03 am

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
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 23, 2013, 04:16:15 am
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.
Title: Re: Sphere SFML v0.65alpha
Post by: Fat Cerberus on July 23, 2013, 11:13:57 pm
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.
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 23, 2013, 11:21:51 pm
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.
Title: Re: Sphere SFML v0.65alpha
Post by: Fat Cerberus on July 23, 2013, 11:50:55 pm
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?
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 24, 2013, 12:35:52 am

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! :D
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.
Title: Re: Sphere SFML v0.65alpha
Post by: Flying Jester on July 24, 2013, 05:11:52 am
Having to 'spin up' on a script is pretty common for JS engines, V8 does the same thing as the low optimizer collects information.

It seems to me that all rotations should be anti clockwise, with an angle of 0 being normal. I could live with 0 being top-to-right though, that's more trigonometrically correct.
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 24, 2013, 07:58:26 pm
Problem with Jurassic:

I run this bit of code:
Code: (javascript) [Select]

function game()
{
    var prop = 8;

    var a = {
        get prop() { return prop; }
    };

    Abort(a.prop);
}


In Sphere 1.5/1.6 with Spidermonkey 1.5 it will print out 8.
In Sphere SFML with Jurassic it will print out "function prop() { return prop; }".

Obviously there is a scoping issue in one or the other. I'm betting that Spidermonkey is itself nowhere near the ECMA standard, but it could also be that the Jurassic parser missed a corner case. And since Jurassic uses a recursive decent parser I don't know where the grammar is to change besides to hand-roll the correct procedure for resolving the right scope. It could be a complex issue!

But I'm not certain it being a scoping issue. Because this works in both:
Code: (javascript) [Select]

function game()
{
    var other = 8;

    var a = {
        get prop() { return other; }
    };

    Abort(a.prop);
}


So long as it doesn't used a variable named after the getter/setter call it will work just fine.
Title: Re: Sphere SFML v0.65alpha
Post by: Fat Cerberus on July 24, 2013, 08:33:05 pm
I'm not completely sure here, but my instinct is telling me the function printout is the correct result, since if you don't consider the name of the containing function before anything else, a case like this would break recursion.  I don't know about you, but for me, from a langauge-design point of view, being able to completely break a working inner block by a modification to its containing block (not counting syntax errors here, obviously) strikes me as bad juju.
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 24, 2013, 08:46:22 pm
Well, I put it into the discussion at the Jurassic page, the problem with Jurassic is that it's no longer being developed.

Well I think that since 'prop' is defined as a variable outside of the scope of the object a, it becomes bound to the function. But then again it is impossible to get to the getter any other way since "return this.prop" will put it into a loop that basically ends when the stack runs out.
Title: Re: Sphere SFML v0.65alpha
Post by: Fat Cerberus on July 24, 2013, 09:06:52 pm
Hm, well here's a question.  How does Jurassic handle return prop; when there is no such variable in the outer function (i.e. the only thing named 'prop' is the property itself)?  What about SpiderMonkey?  If you get the function listing as output from both in that case, I'd say that's the correct result, since otherwise you have inconsistent scoping.

I always like to do little experiments like this whenever I run into a snag, gives me more insight into how things work under the hood. :)
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 24, 2013, 09:19:18 pm
Vanilla Sphere: "prop is not defined"
SFML Sphere: "function prop() { return prop; }"

Which is strange. That means unlike JS fashion it is not easily possible or possible at all to get the getter function in Sphere 1.5/1.6.  :o
Title: Re: Sphere SFML v0.65alpha
Post by: Fat Cerberus on July 24, 2013, 09:31:34 pm
Haha, see what I mean? :)  Now you know more than you would have if you just assumed it was a scoping error!  Turns out it is, but now you know the error is most likely on SpiderMonkey's part, not Jurassic's.  Unfortunately I can't offer any more input here since I don't know what the standard says about it...
Title: Re: Sphere SFML v0.65alpha
Post by: alpha123 on July 25, 2013, 01:03:23 am
ES5 11.1.5 (http://es5.github.io/#x11.1.5) is fairly clear that nothing is added to the lexical environment for getters/setters in object literals, so SpiderMonkey is 100% correct in both cases.
Additionally, according (http://es5.github.io/#x10.2) to (http://es5.github.io/#x13) ES5 (http://es5.github.io/#x10.2.1.1.7), a variable already in scope is not overwritten when a function declaration is made with the same name. Since these aren't really function declarations I don't think this applies, but even if it did SpiderMonkey would still be right.
Title: Re: Sphere SFML v0.65alpha
Post by: N E O on July 25, 2013, 01:25:43 am
What do the consoles for Chrome and Firefox output?
Title: Re: Sphere SFML v0.65alpha
Post by: alpha123 on July 25, 2013, 01:36:29 am
Code: (javascript) [Select]

function testPropertyScoping() {
    var prop = 8, o = {get prop() { return prop; }};
    return o.prop;
}
testPropertyScoping(); // 8 in both Chrome 30 (Canary) and Firefox 22 (Stable).

function testPropertyScoping2() {
    var o = {get prop() { return prop; }};
    return o.prop;
}
testPropertyScoping2(); // Both throw ReferenceError: prop is not defined.
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 25, 2013, 01:49:30 am
Good news; it's been fixed. :) The maintainer is still active in the discussion board over at codeplex.
Title: Re: Sphere SFML v0.65alpha
Post by: Fat Cerberus on July 25, 2013, 02:14:14 am

a variable already in scope is not overwritten when a function declaration is made with the same name.


...wow, that's... not what I'd expect at all.  That means if you have a named, recursive function and move it into a scope where a local variable by the same name exists, the entire function would break.  From a language-design point of view, that's just asking for trouble.
Title: Re: Sphere SFML v0.65alpha
Post by: alpha123 on July 25, 2013, 02:45:39 am

...wow, that's... not what I'd expect at all.  That means if you have a named, recursive function and move it into a scope where a local variable by the same name exists, the entire function would break.  From a language-design point of view, that's just asking for trouble.

JavaScript as a language is just asking for trouble. :P

It's possible I interpreted the spec wrong however. In both Chrome and Firefox,
Code: (javascript) [Select]
function outer() {
    var inner = 5, fn = function inner() { return inner; };
    return fn;
}
outer()(); // function inner() { return inner; }

seems to confirm that. And yes, I know that's technically a named function expression, not a function declaration.
Title: Re: Sphere SFML v0.65alpha
Post by: Fat Cerberus on July 25, 2013, 02:54:20 am


...wow, that's... not what I'd expect at all.  That means if you have a named, recursive function and move it into a scope where a local variable by the same name exists, the entire function would break.  From a language-design point of view, that's just asking for trouble.

JavaScript as a language is just asking for trouble. :P


Haha, so true, and yet I've had more fun programming in JS (and thus, more productive) than any other language I've ever used.  Go figure!
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 25, 2013, 04:14:52 am
The bleeding-edge version of Jurassic is like 33% slower. Arrgh! :/
Title: Re: Sphere SFML v0.65alpha
Post by: Fat Cerberus on July 25, 2013, 10:52:19 am
So Radnen, what's your opinion of SFML?  I've been meaning to try it out myself, but haven't gotten around to it yet.
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 25, 2013, 01:10:00 pm
Extremely easy to use and powerful. I almost prefer it over XNA, it just doesn't come with a sprite batch. In C++ there are many neat features added to it to make sure it works cross platform.
Title: Re: Sphere SFML v0.65alpha
Post by: alpha123 on July 25, 2013, 05:34:20 pm

Haha, so true, and yet I've had more fun programming in JS (and thus, more productive) than any other language I've ever used.  Go figure!

Indeed, I love JS even given all its quirks. You should try Lua sometime, it's basically JavaScript's saner cousin. :P Also, LÖVE (https://www.love2d.org/) is like a modern version of Sphere with a more consistent design and far more powerful features. Sphere is better suited for RPGs though, IMO.
Common Lisp is a remarkably fun language too, I find I'm extremely productive in it. I'm learning Haskell and I've seen a lot of people say it's fun and fast to develop in for real-world projects.


The bleeding-edge version of Jurassic is like 33% slower. Arrgh! :/

Is it possible the release versions are compiled specially somehow?
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 25, 2013, 05:56:14 pm


The bleeding-edge version of Jurassic is like 33% slower. Arrgh! :/

Is it possible the release versions are compiled specially somehow?


I can go ask.

Edit: Hmm, I don't think it's that much slower. In fact I was doing some stuff with clipping and other things that made it slower! Well, at least I thank revision systems for having histories. I sometimes can't remember which change I made to cause something to slow down, etc.  ::)
Title: Re: Sphere SFML v0.65alpha
Post by: Fat Cerberus on July 26, 2013, 11:15:18 am
@Radnen:
Was just perusing the code and found a potential bug: you replace all instances of the word const followed by a space with var.  problem: this also replaces instances inside quoted strings, not desirable behavior.  Any way you could fix the regexp to only replace const at the beginning of a statement?  I'd do it myself, but regular expressions are black magic to me--I wouldn't know where to start. :P
Title: Re: Sphere SFML v0.65alpha
Post by: casiotone on July 26, 2013, 12:15:31 pm

@Radnen:
Was just perusing the code and found a potential bug: you replace all instances of the word const followed by a space with var.  problem: this also replaces instances inside quoted strings, not desirable behavior.  Any way you could fix the regexp to only replace const at the beginning of a statement?  I'd do it myself, but regular expressions are black magic to me--I wouldn't know where to start. :P

This is still risky. You can't properly replace const without doing some real lexing of the source - any regexp solution is always going to cause problems.
Title: Re: Sphere SFML v0.65alpha
Post by: alpha123 on July 26, 2013, 01:19:46 pm
Oh no, please no, please tell me someone isn't using regexes to parse and alter source code. :(

Basically, that's about as terrible an idea as they come. JavaScript (indeed, most if not all, programming languages) is a Chomsky type 2 (context-free) grammar. Regular expressions - even Perl's extended (and no longer strictly "regular") ones - can only parse type 3 grammars. It's impossible to parse JavaScript with regular expressions! Please don't do that, every time you do a little part of a computer scientist's soul dies. Even worse than it being impossible, it almost looks like you can do it, which is dangerous because no matter how good you think your regex is there will still be edge cases which won't show up initially.
Even HTML can't be parsed with regular expressions (http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454), and I think we can agree JS is even more complicated to parse (although technically they're both context-free grammars so it's not, but it does have a more complicated syntax).

Okay, now that I got that out of my system, have you considered writing a simple lexer? Or perhaps better yet, just altering the Jurassic lexer a bit and submitting a pull request (or whatever Microsoft's GitHub ripoff's equivalent is).
Title: Re: Sphere SFML v0.65alpha
Post by: Fat Cerberus on July 26, 2013, 02:30:00 pm
I think the idea was to avoid modifying Jurassic since the thing we're trying to support is nonstandard (const in JS... at least I think it's nonstandard) and Jurassic is meant to conform to the ES5 spec.  Basically this is just a quick hack for backwards compatibility with Sphere 1.x, writing a whole lexer just for something so trivial seems like overkill. Unfortunately there's no way to polyfill keywords in JS, only functions.

edit: haha, alpha, that HTML post was hilarious. ;D  I still wish I knew how people do the eldritch-looking text...
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 26, 2013, 03:50:02 pm
Yeah that was a quick and dirty of me to edit the consts like that. I know a lot about compilers and lexers etc, I could try to modify Jurassic if I wanted to I guess it'll then be a non-standards compliant build. :P However, const is not a word people use by itself for dialogue and I don't know of any words that end in const that would accidentally get replaced, it's quite safe even if the algorithm is dangerous at the same time. XD

That's why this is still very much in alpha. :)

Const is coming to ECMA6, though.
You can see what's breaking/being considered for ECMA6 here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/ECMAScript_6_support_in_Mozilla.

And interestingly, other browsers do a similar thing and made const act like var just to get some code to work: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const.
Title: Re: Sphere SFML v0.65alpha
Post by: Flying Jester on July 27, 2013, 06:26:01 am
I know there's a way to make functions in V8 that work like keywords (like instanceof), perhaps you could do something like that using Jurassic for const?
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 27, 2013, 07:01:43 am
@Jest: sadly it's called source-code modification, Jurassic doesn't let you do that. Plus that won't help in the case you write over a const; they should be produced as a read-only type of thing, and that means it changes the IL that's produced (really just a var augmented with a read-only privilege).

It seems the System.Reflection.Emit.DynamicMethod is in Mono 3.2, so I'm going to compile a Mono 3.2 version for Win (they don't have the installers up despite boasting the D/L's are up, ::)) and see if it works well enough for Jurassic to run...

Edit:
YES!!!!!!!!!!!!!
I modified Jurassic to store pre-compiled code in memory. That means update scripts and render scripts don't have to 'wind-up' each time they are used, only when they are set. The map engine runs at 8500 fps now. :)

Also, I modified Jurassic to read consts, it still treats them like vars though since I'd have to do a lot of legwork to add read/write permissions to the standard var structure. But at least no more regex's. JS is not a regular language almost no programming language is, and so this is for the best.

Edit:
I dropped the fps down to 6200, but now it does this universally. Any map size, with tiles that can change at any moment. Before it was just static images of small maps, which is why the FPS was so high, if I started animating map tiles every frame the FPS would plummet fast. Now it's statically at 6200 no matter when the tiles change or how large the map is.

The tiles immediately on the screen get refreshed every frame, but I don't do what Sphere does and draws each tile to screen separately. I tried that and got 800 static fps. I'm an evil genius. I construct a large vertex map. It's basically an array of 4 vertex points each store a source position and destination position for each corner of a tile. It's constructed only once. This gives a giant map as floating point data. I send this to the graphics card and draw it to screen. Now I can draw a map of any size... And watch the fps plummet to 300. Okay, so I have this large chunk of floating point data that the GPU *can* efficiently parse, how do I reduce the load for maps that are HUGE, and a few games have map that large. I create a cutout of the float data, the algorithm looks like a standard image-processing function that uses scan-lines and offsets to produce a cutout:

Code: (csharp) [Select]

        private static void CutoutVerts(Vertex[] inverts, int x, int y, int scan)
        {
            scan <<= 2;
            y /= _map.Tileset.TileHeight;
            x /= _map.Tileset.TileWidth;

            int h = GlobalProps.Height / _map.Tileset.TileHeight + 1;
            int length = (GlobalProps.Width / _map.Tileset.TileWidth + 1) << 2;
            int offset = (x << 2) + y * scan;
            int height = offset + h * scan;
            int index = 0;

            for (var i = offset; i < height; i += scan)
            {
                Array.Copy(inverts, i, _cutout, index, length);
                index += length;
            }
        }


It's super fast. I had made an algorithm that filled an array and asked each iteration is the tiles vertices on screen? That approach was terribly slow, and only got really fast when there was a lot of data in the screen and slower the further away you went. At best that approach was 3200 FPS. This is the best and fastest method I found so far since it's mostly direct access: find the start and copy the scans. Since Array.copy copies contiguous data, this really has now become an O(n) algorithm rather than an O(n^2) algorithm.

Okay, so you got a really fast map blitting algorithm, how does it handle the case when every tile on the map must animate? This is the killing blow to every map engine in existence. But not this one. The floating point data is sent to the graphics card each frame. That means the tile only has to modify the 4 source points (it's neighboring animations source) prior to the next draw cycle in order for it to show up when the screen is flipped. So that issue has indeed been covered.

Okay, so how does it handle layers? Not well I'm afraid. All map engines take a hit with layers, it's impossible to not take a hit. Why? Because a new layer is basically a new map engine construct but with different tiles. But look at it this way, to draw a layer it's O(n). To draw many layers it's O(n*l), that's still way better than Sphere which is O(x*y*l). Can it go faster? Yes! Technically I can append layers on to the floating point data-map, and have the GPU zip through all the layers in O(n+l1+l2+...+ln) time, but that will *technically* be no faster except that it doesn't have to re-init for the next draw call.
Title: Re: Sphere SFML v0.65alpha
Post by: alpha123 on July 29, 2013, 01:31:06 am

I modified Jurassic to store pre-compiled code in memory. That means update scripts and render scripts don't have to 'wind-up' each time they are used, only when they are set. The map engine runs at 8500 fps now. :)

Nice, that should compensate pretty nicely for the design blunder of using strings for update/render scripts.
Speaking of that, it would be a nice feature if Sphere SFML's SetUpdateScript/SetRenderScript could accept functions as well.

Quote

Also, I modified Jurassic to read consts, it still treats them like vars though since I'd have to do a lot of legwork to add read/write permissions to the standard var structure. But at least no more regex's. JS is not a regular language almost no programming language is, and so this is for the best.

Yay! Okay, I'm happy now. :P ;)

Regarding the map engine stuff: That's pretty darn cool! Is it possible to test at map load time if the map contains any animated tiles and use the original algorithm if it doesn't? Although I think the performance you got from your method is easily more than enough (plus your algorithm has a nice cleverness factor :P).
Title: Re: Sphere SFML v0.65alpha
Post by: Fat Cerberus on July 29, 2013, 01:44:04 am
I'm pretty sure Sphere 1.x (spidermonkey) consts aren't actually constant either, at least in Sphere 1.5--you can modify them. At least that's what I remember from testing it quite a while back, maybe my memory is deceiving me though.

Why const wasn't in standard JS from the beginning I'll never understand, it's such basic functionality.  And there's basically no excuse at all why it shouldn't have made it into ES5.
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 29, 2013, 04:16:53 am
re: function input on set update/render: the compiler does not take a function as input. Hmm, maybe there is a way to cast it to string? I think the ECMA standard of a function's toString() is the body source. So I think it's certainly possible.

re: map algorithm: there's no reason to go back to the other one. It was at 8500 FPS since each layer was a compiled, static, image. This is good until you pass the 2048x2048 texture mark. Then I spend equal amounts of time cutting larger maps into smaller maps... Then at the end of the day it's almost no faster than it is now.
Title: Re: Sphere SFML v0.65alpha
Post by: Fat Cerberus on July 29, 2013, 10:21:09 am

re: function input on set update/render: the compiler does not take a function as input. Hmm, maybe there is a way to cast it to string? I think the ECMA standard of a function's toString() is the body source. So I think it's certainly possible.


Why do you have to compile it? If the caller passes a function then by definition it's already been compiled (barring lazy compilation, anyway).  In that case you just have to store the function instance and call it later through Jurassic's API.  That can be done, right? Calling toString() on the function and compiling it a second time is just adding an extra step to the process for no gain--in fact, you lose in that case since such an approach breaks closures.
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 29, 2013, 06:49:35 pm
Hmm, you are right. I just looked through the source and saw an explicit call method on a function instance. This might just do the trick! However there must be compilation for the string input since that was created during runtime.

Edit: Okay it is done.
Title: Re: Sphere SFML v0.65alpha
Post by: Fat Cerberus on July 30, 2013, 03:00:48 pm
Radnen, what exactly do I need to compile this?  Visual Studio gives me an error on Packages.mdproj (never seen an .mdproj extension before, what kind of project is that?) when opening the solution and then if I try to compile it I get a bunch of errors mentioning NUnit...
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 30, 2013, 03:30:19 pm

Radnen, what exactly do I need to compile this?  Visual Studio gives me an error on Packages.mdproj (never seen an .mdproj extension before, what kind of project is that?) when opening the solution and then if I try to compile it I get a bunch of errors mentioning NUnit...


I used Xamarin studio, it has an integrated nunit test suite and supports a neat packaging solution called "monodevelop packages". Yes, MonoDevelop changed names to Xamarin Studio. I don't know why.

For visual studio you only need nunit for the tests, the .mdproj can be ignored, heck I'm pretty sure the tests can be ignored. But yea that's the only requirement so far. I got it working in visual studio, I like it's debugger better! And it doesn't crash as often. And it doesn't lock up when you test a build, and it's intellisense doesn't get confused if a syntax error occurred earlier in the document (because you were still in the middle of writing code), etc. Xamarin is still in development and I'd even say it's in alpha at times.
Title: Re: Sphere SFML v0.65alpha
Post by: Fat Cerberus on July 30, 2013, 03:43:17 pm

I used Xamarin studio, it has an integrated nunit test suite and supports a neat packaging solution called "monodevelop packages". Yes, MonoDevelop changed names to Xamarin Studio. I don't know why.


Hm, if you need NUnit built in, there's an NUnit plugin for Visual Studio 2012 that you can download through Tools->Extensions and Updates that lets NUnit integrate with the VS test explorer (which is nice).

So yeah, I can go install NUnit, that's no problem, it was the .mdproj that threw me for a loop. I'd never seen that type of project before and VS wouldn't open it so I figured I'd be missing something.
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 30, 2013, 04:31:02 pm
So, I was able to get tile animations working with a tile anim helper: it's a list of tiles and their next values in a list. It just goes through these lists updating the tiles. This is how Sphere does it and I think I emulated it well enough. One issue: If you update enough tiles quick enough the fps drops to 800 as if it were drawing each tile individually that's the worst case: every tile on the map animates. Otherwise it's around 4000 FPS for maps that have a standard amount of tile updates: water, grass, etc.

I might get it to go a bit faster, the problem is that once I construct the giant pool of floating point data, it's static. I can either modify all of the vertices to use the bounds of the next animated tile, or I can change the tile image in the texture atlas directly. I decided to change the tile in the atlas directly which is the easiest method since I change it in one place and it's reflected everywhere. But, modifying the texture atlas is a software thing, not a hardware one. I guess it might be possible to use a render texture for the atlas. I'll have to attempt that.

I don't want to directly modify the floating point data since I get the speed for the fact it's static: each frame it doesn't have to change. Only the texture atlas should change. Also for large maps, modifying the texture atlas is always faster than zipping through literally hundreds of thousands of floating point numbers.

Edit: I got up to 3600 fps now if every tile were animating on a map. :) And for smaller maps it hovers right around the 6200 area making it the lightest performance hit for animations yet. I did this by creating a wrapper of the TextureAtlas object and called it the FastTextureAtlas - it's basically a texture atlas that is hardware accelerated. So the downside is it's kind of a memory hog: you need a texture atlas before you need a fasttexture atlas. But a little bit of memory can go a long way in speeding up code. :)
Title: Re: Sphere SFML v0.65alpha
Post by: N E O on July 31, 2013, 04:12:20 pm
Re tile anim speed hit - has there been a test where a tile's animation delay was only one frame? Are the benchmarks about the same as the "animate every tile" benchmarks?

I want to make sure that we can come up with as fast a map blitting algorithm as possible so that when I finally resume the map portion of the Sphere Web Utilities I can put in a decently fast reference implementation the web engines can port even if using a 2D Canvas context instead of an OpenGL context. You say you've got O(l*n) but is there any way we can bring that down to O(l log n) or so for the larger maps? An N-tree algorithm where N=#layers or something?
Title: Re: Sphere SFML v0.65alpha
Post by: Radnen on July 31, 2013, 04:25:39 pm
I test a full single layer with every tile animating at 1 frame. But I can attempt to create a more rigorous test bed if you want. However, I think that the speed hit is minimized since only the texture source is being updated at least once per frame - no matter if it's one or all tiles being updated.

I'll get back to you soon with a test map and various performance measures.
Title: Re: Sphere SFML v0.65alpha
Post by: N E O on July 31, 2013, 04:54:26 pm
Shiny :)
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on July 31, 2013, 04:58:19 pm
x64 Win7 SP1 w/ Intel i5 ivy bridge @ 3.30Ghz
Nvidia 550ti w/ 2GB ram
8GB DDR3-1600 memory.

Sphere-sfml: 4000 fps (GL)
Sphere 1.5: GL: 1390; software: 2750
Sphere 1.6: GL: 1280; software: 2666

You can test the files yourself; they are attached. Several tiles animating at different frequency's and starting from different states. In fact this revealed a bug in my code, but now it's fixed. The above used the fixed version.

Edit:
Now you can test this for yourself with version 0.75alpha :)
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 01, 2013, 03:40:21 pm
HashFromFile and HashByteArray now take an extra optional parameter, sha1.

In Sphere 1.6/1.5 the last parameter would be ignored, like so:
Code: (javascript) [Select]

HashFromFile(filename, true); // generates a SHA1 hash in sphere-sfml, and an md5 hash in vanilla.


At least this option will help create better / more secure hashes (despite it's MD5 fallback for vanilla compatibility).

Edit:
Jurassic now gives correct line numbers and filename for bad scripts during runtime. Therefore, it now mimics Sphere in handling errors. :)

Edit:
My map engine is slower to load than Sphere 1.5's since it does a lot of caching for the GPU. Subsequent map loads go by much faster though. I wish Sphere 1.5 did this but the problem with it's graphics abstraction layer is that you can't do neat things with the map engine directly depending on hardware configuration. All you supply to it is how things are drawn, but not how they get drawn (emphasis on the latter).

Edit:
It's now even faster, wow. It seems that clearing a software texture atlas was slower than straight-up rewriting it with image data. It's now 3 times faster, but not that noticeable since it went from basically 300ms to 90ish. It was slow since a texture atlas can be say 1024*1024 but you only use a small portion of it, you rarely use the whole atlas since sprites are packed into it pretty efficiently. It's speedup comes from drawing only what it needs to. BTW, Subsequent loads are around 10ms which is damn fast for a map with 11 entities, animating tiles, 3 layers, and larger than the screen which is a good candidate for an average sphere map.

Edit:
Now surfaces have seen a 10x boost in performance. It rivals Sphere 1.5 now. :D My trick was to use byte arrays and muck around directly with the bytes than go through the SFML abstraction layer. My guess is that it tries to be safe and does a lot of checks /etc that slow it down. I never realized how slow that was though. I always think C# is much slower than C++, but heck it's all about the algorithm, not the language. :P I'm giving the namesake of TurboSphere a run for it's money!
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on August 04, 2013, 12:58:33 pm
Everyone assumes C# is slower because its bytecode, but once the JIT gets ahold of it you're ultimately running native machine code anyway. The only reason C++ can be faster is because you can do a lot more low-level optimization tricks.
Title: Re: Sphere SFML v0.75alpha
Post by: Flying Jester on August 04, 2013, 07:58:22 pm

Everyone assumes C# is slower because its bytecode, but once the JIT gets ahold of it you're ultimately running native machine code anyway. The only reason C++ can be faster is because you can do a lot more low-level optimization tricks.


I assume C# tends to be slower because the language is much safer, contains more run time information, and depends on large packages being present. Although this is certainly not a definitive or concrete assumption, it may be reasonable to assume that a larger binary file contains more code to execute, and therefore compared to a smaller binary that performs the same function which performs the same task but has less instructions to execute, can be slower.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on August 04, 2013, 09:03:31 pm
True, but you can't exactly compare based on file size alone when one is native machine code and the other contains bytecode (apples and oranges)--indeed, the bytecode may ultimately be JIT'd to the same (or equivalent) code to the native version.  Sure, there are plenty other factors that could slow it down (the aforementioned runtime checks, non-deterministic garbage collection, JIT overhead, etc.) but unless you have super-mission-critical code (in which case, yes, it should be written in a lower-level language), the speed hit is negligible.  Not to mention a lot of runtime checks are turned off when compiled in release mode, as evidenced by the fact that even .NET apps will trigger a native crash ("this program has stopped working") in a lot of cases, in lieu of, say, a NullReferenceException.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 04, 2013, 09:23:45 pm
Well games do need to be optimized they are considered speed-sensitive. The surface overhaul I did was quick and easy and I could do a lot more interesting things with a byte array than with an image object. True they might be considered similar, both large chunks of RGBA, but the array I can do raw memory transfers and other things that go by faster - especially if you can neglect bounds checking. I know it's dangerous but the way I see it, you are only limited to the code via the JS interface. So long as the JS interface is safe all under-the-hood optimizations no matter how unsafe as long as they are stable, should be okay.

I'm currently trying to fix some camera bugs right now - maps smaller than the screen were crashing. But no longer. Also the camera is a strange beast. In Sphere when you run an ON_LEAVE_* script, it's the camera passing the bounds that triggers it - not the player character. I noticed this when I created a "follow-cam" where it may lag behind the player: not until it catches up with the player it won't fire the map leave code. I have to emulate this behavior too even if it's not correct: zones, triggers, and NPC's use the player characters coordinates to fire events, not the cameras, and not attaching input will turn that behavior off. Not attaching the camera or input and setting the camera past the map bounds will fire the LEAVE code. It seems like that's correct since you technically left the map w/ the camera, but not from a gaming perspective.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on August 04, 2013, 09:30:54 pm
That does seem like odd behavior re: leave-scripts, although it makes a certain amount of sense if you assume the real purpose of the leave-script, from a design standpoint, may be to load other stuff when the camera leaves the source map.  e.g. splicing maps together or something? Can Sphere even do that?
Title: Re: Sphere SFML v0.75alpha
Post by: Rukiri on August 05, 2013, 11:37:11 am
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...
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 05, 2013, 02:02:36 pm

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.
Title: Re: Sphere SFML v0.75alpha
Post by: Flying Jester on August 05, 2013, 07:01:06 pm
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.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 05, 2013, 07:08:36 pm
Fun fact: GL and DX are very fast at 2D texture work, heck they aren't even made for 3D at all! :P 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/
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 05, 2013, 07:46:26 pm
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. :)
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on August 05, 2013, 09:08:41 pm
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...
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 06, 2013, 12:30:26 am

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. :P (I blame this engine development).

Website: http://radnen.tengudev.com/holdtheline2.html
Title: Re: Sphere SFML v0.75alpha
Post by: N E O on August 06, 2013, 05:04:37 pm
Re collisions - are you referring to sprite-sprite collision, sprite-tile collision, or sprite-obstruction line collision on the map engine?
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 06, 2013, 05:44:01 pm

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/
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 10, 2013, 12:57:09 am
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.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on August 10, 2013, 01:16:16 am
Remind me again with Lithonite is?
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 10, 2013, 01:19:53 am
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.
Title: Re: Sphere SFML v0.75alpha
Post by: N E O on August 10, 2013, 06:19:02 pm
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.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 10, 2013, 08:46:46 pm
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;
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on August 10, 2013, 09:34:42 pm

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?
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 10, 2013, 10:11:15 pm
So Atan2 will give an angle. This is the direction to offset the distance check by.
Cos will give you the amount of X to use, Sin will give you the amount of Y to use.
So, in fact it kinda turns the persons base into an oval or a circle if they have a square base.

Image 1 is a person to the left (the player) trying to talk to the person on the right. Notice the 8 pixels do not go far enough.

Image 2 includes the correction. Since you are to the left Atan2 will return PI. Cos(PI) is 1, and so 8 pixels (the size of the bases width divided by 2). That's enough to puncture the base and give you a distance within 8 pixels of the player. Atan2 is used since we need to add this offset to each direction you could approach the other sprite at.

In fact if I assumed a square base I don't need all of that math. I just add size/2 to the distance and just use that.
Code: (csharp) [Select]

Line[] pBase = person.GetBounds();
int w = (int)(pBase[0].End.X - pBase[0].Start.X);
float dx = person.Position.X - compare.Position.X;
float dy = person.Position.Y - compare.Position.Y;

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


Since Atan2 would have just given an extra distance all around it can be simplified out. But that's not true if you approach from the east or the north for rectangular sprites, and so this accounting has to be made.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on August 10, 2013, 10:25:23 pm
Wait, so Sphere calculates talk distance based on the center of the base...?  I guess it makes a certain amount of sense, but at the same time it's counterintuitive--if it were me implementing this from scratch, I'd probably set it up to use distance between the edges of the bases instead--or better yet, just inflate the base rects by the talk distance and simply check if they intersect.  This way the same talk distance would still work even if you changed the size of your sprites later.  Oh well, not much you can do since you're aiming for parity with Sphere.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 10, 2013, 10:28:32 pm

Wait, so Sphere calculates talk distance based on the center of the base...?  I guess it makes a certain amount of sense, but at the same time it's counterintuitive--if it were me implementing this from scratch, I'd probably set it up to use distance between the edges of the bases instead.  This way the same talk distance would still work even if you changed the size of your sprites later.  Oh well, not much you can do since you're aiming for parity with Sphere.


No you are right, it uses the edges in a way. It starts from the center, then finds the edge, then checks distance from that edge to your edge, but mathematically. The side effect is that it turns it into ovals/circles rather than true rectangles. I'm actually not certain if that's what sphere really does, but it beats doing extra work to check in which direction you are talking from using constructs other than math.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on August 10, 2013, 10:33:05 pm
What's wrong with just inflating the baserects and checking for an intersection?  That would save you from having to do all that trig, which might help performance...
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 10, 2013, 10:37:47 pm

What's wrong with just inflating the baserects and checking for an intersection?  That would save you from having to do all that trig, which might help performance...


Actually I don't follow. It might work for square bases as I did above, but what about rectangular bases?
Title: Re: Sphere SFML v0.75alpha
Post by: N E O on August 10, 2013, 10:40:28 pm
I think the issue revolves around the implementation of baserects in the first place. Even though there's only one per spriteset it can be placed anywhere on it and sized within the sprite's bounds. I gather there might have been an intent of one of the older devs to add support for multiple baserects per spriteset somewhere in the future, but that's pure conjecture on my part. If I was updating the spec I'd definitely use some of those reserved bytes in the beginning for more bases.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on August 10, 2013, 10:46:03 pm


What's wrong with just inflating the baserects and checking for an intersection?  That would save you from having to do all that trig, which might help performance...


Actually I don't follow. It might work for square bases as I did above, but what about rectangular bases?


What I mean is, calculate the size of the rect for each dimension (x2 - x1, y2 - y1) and then add to the size of each dimension sqrt(talkdistance), keeping the center where it is.  Then simply check if the talker's inflated base intersects with the other sprite's base.  Now that I think about it though, this would allow you to talk to someone while facing away from them, which probably isn't desirable.  So yeah, your method is better. :P
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 11, 2013, 02:53:22 am
No wait, in Sphere if you face away you can't talk to the other entity. In my Engine you can. This is a problem... I'll have to visit the vanilla talk code - it's doing more than just figuring out a distance.

And it's here:
https://github.com/sphere-group/sphere/blob/v1.6/sphere/source/engine/map_engine.cpp#L6110-6130

Definitely not what I expected! Potential bug in there; if your sprite doesn't have a cardinal direction it fails, even if you are facing the person you are talking to. I'll introduce direction vectors like in Lithonite and my combat engine. It'll solve the problem but not make it backwards compatible if you decide to use different directions for north/south/etc. But then again you wouldn't be able to use the FACE commands either.

Edit: I just used the Sphere method instead. The code looks like this now:
Code: (csharp) [Select]

        public static string GetClosest(string name)
        {
            int talk_x = GetPersonX(name), talk_y = GetPersonY(name);
            string direction = GetPersonDirection(name);

            if (direction.Contains("north"))
                talk_y -= _talk_dist;
            if (direction.Contains("south"))
                talk_y += _talk_dist;
            if (direction.Contains("east"))
                talk_x += _talk_dist;
            if (direction.Contains("west"))
                talk_x -= _talk_dist;

            foreach (Person p in People)
            {
                if (name == p.Name)
                    continue;
                float dx = p.Position.X - talk_x;
                float dy = p.Position.Y - talk_y;

                if ((int)Math.Sqrt(dx * dx + dy * dy) <= _talk_dist)
                    return p.Name;
            }
            return null;
        }
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 11, 2013, 07:06:39 pm
Interesting fact of the day:

In Sphere 1.5/1.6 using a map of pre-calculated sqrt values is almost 2x faster than using Math.sqrt.

In Sphere-Sfml: using Math.sqrt is almost 4x faster than a map of sqrt values.

That means using math in Sphere-sfml is so damn much faster than caching. Which is interesting since you can use a sqrt map to speed up your old games that used distance formulas often, but in my version of sphere you'll in fact get a slowdown. From this test I have also revealed that array accesses must be far slower than in Sphere 1.5/1.6, about 2x slower in fact. Despite being a language compiled to CIL I believe that 'boxing' and 'unboxing' is causing this.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on August 11, 2013, 08:59:53 pm
Boxing only applies when you convert a value type to a reference type (storing an int in a variable of type object, e.g.).  Just passing values around won't cause anything to be boxed or unboxed.  One thing you might want to try though: Compile the thing directly to x86 or x64 and test again.  Right now you're compiling it as "Any CPU", i.e. pure CIL.  I'm not positive, but I think targetting a specific platform lets the compiler make additional optimizations that it can't do in the general case.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 11, 2013, 09:32:25 pm

Boxing only applies when you convert a value type to a reference type (storing an int in a variable of type object, e.g.).  Just passing values around won't cause anything to be boxed or unboxed.


So you think boxing doesn't happen in array [] resolutions? I'm pretty sure when you get or set an array element it's being boxed. Jurassic implements a Jurassic array with object types so when you put a double or int into an array it's boxing it somewhere down the line, and grabbing a value would then unbox it.

In Xamarin studio I can't make builds other than Any CPU. I might have to try in VS.

Edit:
It's slower when built for x86, and I don't have SFML for x64. Ugh, building for x64 is a nightmare. I don't know enough to get the References list to choose which dependency to use. I believe I need to create a cloned copy that uses a different references list entirely. But in the end I don't think making platform-specific builds will help that much...
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on August 11, 2013, 11:11:42 pm
If you have an array of ints, for example, and you store ints in it, it makes no sense for the ints to be boxed.  The array itself is a reference type, sure, but the elements aren't.  The only way you'd end up with boxing happening is if: 1) you have an array of type object and then store value-type values in it, or 2) you use one of the old, non-generic collection types like ArrayList that cast everything to object internally.  A native value-typed array should never cause anything to be boxed.  If it did, I think I would have to take that up with the compiler writer!

edit: Just found this Stack Overflow post, I was right, arrays don't box: http://stackoverflow.com/questions/8213887/does-system-array-perform-boxing-on-value-types-or-not
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 11, 2013, 11:31:36 pm
LordEnglish you can't compare a C# array to a JS array! There's a distinction between doing this in C# and implementing JS in C#.

In C# you can't do this without boxing:
Code: (csharp) [Select]

array[0] = 0;
array[1] = "hello";
array[2] = true;


Now tell me what you'd do to implement a JS array that behaves just like the above. Of course there's boxing involved!

Maybe I wasn't clear enough:

If you have an array of ints, for example


In a JS environment you can't be certain of that like you can in C#.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on August 11, 2013, 11:38:42 pm
OH!  See, I thought you meant the performance drain was on the C# side, you weren't entirely clear in the original post where the sqrt() calls were being done, and your remark at the end about a "language compiled to CIL" made me think you were referring to C#.  Especially since we were just discussing sqrt() earlier in the thread in the context of talk distance checking...
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 12, 2013, 01:04:36 am
Ah, :P I can see how that can be ambiguous. Haha, yeah the JS engine I use compiles it to CIL, but must handle JS arrays as boxed C# arrays, it's the only way to do it, unless you use the new C# dynamic constructs, which Jurassic doesn't use since it was made prior to .NET 4.0.

Edit:
Ugh! People are created after the update script has ran at least once.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on August 12, 2013, 07:44:59 pm

Edit:
Ugh! People are created after the update script has ran at least once.


That seems like odd behavior, you'd think something like that would go right into the map-loading routine.  Looks like Sphere has more quirks than anyone realized! :P  Good thing the engine codebase is so clean, or things like this would be a nightmare to emulate.
Title: Re: Sphere SFML v0.75alpha
Post by: casiotone on August 13, 2013, 02:02:03 pm
What's the current state of your map engine implementation? I've noticed that when running my current project, the SCRIPT_ON_ENTER_MAP is never called (which is unfortunate as that's the entry point to my engine!)
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 13, 2013, 02:16:08 pm
The version up now, has like a 10 - 15% working map engine. The one in development now has like a 75% working map engine, barring extra features like Layer parallax and reflection, and this one has map scripts working.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on August 16, 2013, 11:51:10 pm
What does the fatal error "Source array was not long enough" mean? I keep trying to run Specs with it with each new commit, but I get this every time:

Code: [Select]
Compiled Script: "Threads.renderAll();"
Compiled Script: "Threads.updateAll();"
Compiled Script: "analogue.runMapEvent(GetCurrentMap(), 'enter');"
Compiled Script: "analogue.runMapEvent(GetCurrentMap(), 'leave');"
Compiled Script: "analogue.runMapEvent(GetCurrentMap(), 'leaveNorth');"
Compiled Script: "analogue.runMapEvent(GetCurrentMap(), 'leaveSouth');"
Compiled Script: "analogue.runMapEvent(GetCurrentMap(), 'leaveEast');"
Compiled Script: "analogue.runMapEvent(GetCurrentMap(), 'leaveWest');"
Compiled Script: "analogue.initMap();"
68.044921875
Fatal Error: Source array was not long enough. Check srcIndex and length, and th
e array's lower bounds.
Line 0:


The weirdest part is, despite the so-called "fatal error", the engine seems to run anyway--but I get a completely blank engine window hovering around 60 FPS.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 17, 2013, 12:38:29 am
Hmm, that might be due to a map that's too small? I need to revisit the map drawing routine. See, I make a cutout of the area of the screens size. However for maps smaller than the screens size you get the above error. I thought I had a fix, but it seems to not be working. Don't expect the map engine to work perfectly however, ;)
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on August 17, 2013, 12:45:45 am

Don't expect the map engine to work perfectly however, ;)


Oh believe me I don't, it's just that there was no indication that was a map engine-related error; if you hadn't just told me that it was, I'd have assumed a bug in the JS engine or something.

But yes, I do have a tiny 1x1 map since that was the only way I could get my opening scene to show up on a black screen without flashing a map for a split second first.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 17, 2013, 02:06:35 am
Ok, small maps are now fixed. Also I added an Abort() implementation that behaves like the Sphere Abort but doesn't do the same thing. I am still trying to figure out how to manually call an error with line numbers just like calling abort would do. somehow I need to invoke a custom error message, and apart from just tossing in a random syntax error, I don't know how to do that in Jurassic.

See how far you get LordEnglish, and I'll try to diagnose the rest.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on August 17, 2013, 10:27:12 am
Well the error went away, but I still get a black screen, and I'm not even really using the map engine right now, literally the flow of my engine is MapEngine() -> analogue:map:enter(), which creates a person, attaches the camera to it, then immediately hands over control to Scenario for the opening scene.  So I finally stuck an Abort call in the analogue enter() function, and it looks like the enter script is never being called.  Well, that explains that.

That out of way, I tried testing the battle engine WITHOUT starting up the map engine, but the minute I got to the title screen (after re-enabling it) it errored out with "GetPlayerKey is not defined". Damn.

Additionally, got this when trying to start the battle engine: GradientCircle is not defined (my MP gauge uses it).
Title: Re: Sphere SFML v0.75alpha
Post by: casiotone on August 31, 2013, 08:57:35 am
Small suggestion: at the moment functions like GetSystemFont create a new font object every time they are called, loading the font each time. These should really be cached, otherwise scripts that call them in a loop will quickly run out of memory.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on August 31, 2013, 09:57:19 am
I think that was done intentionally, so that if the user makes changes to the object the changes don't propagate between calls (the idea is to get an unmolested stock object).  It's really not good to call functions like this in a tight loop anyway, even if you know it just returns a cached value.  Function calls carry overhead, so every one you call inside of the loop adds up.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 31, 2013, 01:20:57 pm
GetSystem* used to not return copies but I think that changed for precisely what Lord English said. You can of course, cache your own system resource. :)
Title: Re: Sphere SFML v0.75alpha
Post by: casiotone on August 31, 2013, 01:37:26 pm

GetSystem* used to not return copies but I think that changed for precisely what Lord English said. You can of course, cache your own system resource. :)

Yeah, I'm lazy and often use GetSystemFont().drawText for debugging.

A possible solution would be to cache the texture rather than the whole object.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on August 31, 2013, 05:13:54 pm
Texture caching is used for the GetSystemArrow's. Modifying them just replaces their texture, but recalling it just gives you back the original texture reference. I can do this for fonts too, but there were some optimizations in place so that you directly edit the underlying texture atlas. This means GetSystemFont() and GetSystemWindowStyle() will keep cloning but GetSystemUp/Down/Arrow's are free to use in a loop.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on November 30, 2013, 09:18:28 pm
I tried JSIL on this beast and it works! ... sorta.

So, I got it to finally read in all of the dependencies to run the program, but then it get's caught up: "Failed to find game.sgm in startup/"

So, at least it's searching for a game in the startup folder if one is not specified. So, I'm close but not quite.

Edit: the error here is that there indeed is a game.sgm in the startup folder!! So I don't know why it can't find it.
Title: Re: Sphere SFML v0.75alpha
Post by: N E O on December 01, 2013, 01:03:07 am
Once you get to a usable point I highly recommend creating a JSIL branch in your sphere-sfml repo or in the web-sphere repo! ^_^

Let me know if you need the reference map engine JS done before that happens, since I'll be working on it Sunday afternoon.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on December 01, 2013, 01:40:35 am
It should be complete, that's what JSIL does. I need 0 percent JS effort to do any work. Provided I can correctly set up the website it runs on.

Edit 1:
I had a discussion with JSIL's creator and he says that this is a massive waste, and it has everything to do with browser game development. See, he's emulating .NET's file IO at best because you can only load files asynchronously in a browser. Now, he was able to synchronously load games - if you tried them on his website - but they were in the pipe so-to-speak. There is a problem when you are trying to load other peoples assets, which is precisely what Sphere does since it's a game engine.

I could get by with a simple demo, but I can't ever run a full game efficiently with it. :/

I think it better to try and recreate Sphere in JS god willing. Which would prove to be a very difficult task and be no easier than what JSIL could do since you'll also run into certain problems with file loading, while loops, window handles, and speed. But at least you'll have lower level access, and the ability to custom tailor it to the game you are wanting to run.

Edit 2:
That said, we did discuss a way of doing it via a bootstrap JS file that pumps game data into the JSIL virtual file system. It might then work...
Title: Re: Sphere SFML v0.75alpha
Post by: DaVince on December 01, 2013, 11:42:15 am
Nice work! Too bad about the complications.

Would it be possible to parse JS files beforehand, look for any Load* functions and preload/cache all of these? And then implement the actual Load* functions to refer to the preloaded files. This would obviously add a loading screen before the actual Sphere game can run, but would it solve any of the mentioned problems?

Hmm, I wonder, would Native Client be any kind of solution? That'd be Chrome-only, though...
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on December 01, 2013, 02:44:47 pm

Hmm, I wonder, would Native Client be any kind of solution? That'd be Chrome-only, though...


It only supports C and C++. :/
Title: Re: Sphere SFML v0.75alpha
Post by: N E O on December 02, 2013, 02:33:46 pm
I'd suggest emscripten+asm.js (if emscripten can compile C#) before attempting to port to Native Client first. Maybe emscripten on the original C++ engine if C# isn't doable?
Title: Re: Sphere SFML v0.75alpha
Post by: Flying Jester on December 02, 2013, 03:08:09 pm
It would be possible if you could compile C# or CIL to LLVM bytecode, but as far as I know you can't.

I've been trying to compile some pieces of TurboSphere using emscripten (such as the spritebatcher, possibly for use in web-based Sphere engines). An issue there is having both the version of V8 that node.js wants and the one TurboSphere wants living together in harmony on a Linux system. There are some issues with the plugin system, too, since it does fancy things with function pointers.

I haven't tried compiling the original engine using emscripten...I'm still struggling to get it compiled on Linux in the first place. But if you can compile Sphere using Clang+LLVM, it should be pretty easy from there.
Title: Re: Sphere SFML v0.75alpha
Post by: Mooch on December 16, 2013, 04:33:23 pm
Nice progress so far, Radnen ^_^

Hey, I thought up something to feature-request of Sphere-SFML. A hotkey to automatically Open Last Project. Or even better, an option to automatically open the last project when the editor is launched. Because - and I'm probably not alone here - every single time I open up the Sphere editor I have to go to File > Open Last Project. Why not let it be default?
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on December 16, 2013, 04:37:31 pm
1. That question does not belong in the engine thread.

2. That editor problem is already solved in my Sphere Studio. It's in the settings, just tick the box that says "automatically open last project."

3. If you are not using my editor, I can't add that to the old one, sorry. :/
Title: Re: Sphere SFML v0.75alpha
Post by: Mooch on December 16, 2013, 06:38:20 pm
1. Whoops, sorry! I Searched for Sphere-SFML and this is the only topic about Sphere-SFML that showed up. If you want me to delete my last message and this one, and you can delete yours just there, lemme know, so as to un-gunk up your topic. Sorry again.

2. I can't get Sphere Studio to work, didn't know that was already in that. Good thinking.

3. I know, I'm gonna convert to SFML when at least Beta launches. Didn't know if such a feature would be in there, just wanted to throw out the idea.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on December 16, 2013, 07:14:39 pm
For #1, since you seem to be confused about this: sphere-sfml is just an engine, one of several that implements the Sphere API. The editor is a totally separate piece of software.  Editor-related feature requests (such as yours) have nothing to do with sphere-sfml or any other engine.

As for Sphere Studio, you should have .net 4.5 installed. If you have an earlier version than that it probably won't work.
Title: Re: Sphere SFML v0.75alpha
Post by: Mooch on December 16, 2013, 07:59:47 pm
Oh! I was confused on that point. I could've sworn I read that Radnen was redoing/adding to the API, though, that Sphere-SFML was basically a ground-up Sphere rewrite.

Wait, yeah. Sorry to muck up your topic even more, but Rad said in my Gauntlet topic he was adding multiplayer support to Sphere-SFML. If Sphere-SFML is just implementing the existing Sphere API, how can he add stuff? I guess I sorta don't understand what "a Sphere engine" is. Someone can just PM me if you don't want more clutter in the topic.
Title: Re: Sphere SFML v0.75alpha
Post by: Flying Jester on December 16, 2013, 08:10:10 pm
Yes, Sphere-SFML is a complete rewrite of Sphere. It takes no source from the original (it can't easily, it's in a different language).

Both Radnen and I are adding new features to the API and refining old ones with Sphere-SFML and TurboSphere respectively. Sphere-SFML takes a more compatible route, mainly adding switches for new features that, when omitted, will default to Sphere behaviour. I took a more ambitious route, and so TurboSphere is not directly compatible with Sphere (you'd need some extra code to make Sphere games work in TurboSphere--not much, but still not totally backwards compatible like Sphere-SFML is).

I believe that most of the additions to Sphere-SFML are either new functions or added optional parameters to existing functions, so all the original Sphere API functions can still work the way they do in Sphere 1.5-1.6.

As far as Engine vs. Editor, look at the binaries in the Sphere folder.

An Engine runs games. That's all it can do. You can't edit maps, it has no GUI, it just plays games. This is called `engine.exe` in Sphere.

The Editor, on the other hand, can't actually play games. It can edit and save files, and it can launch the engine, but it does not have the guts to actually play a game on its own. This is called `Editor.exe` in Sphere.
Title: Re: Sphere SFML v0.75alpha
Post by: Mooch on December 17, 2013, 06:34:30 am
*salutes*

Got it. And thanks. And sorry >_>
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on December 23, 2013, 12:43:17 am
I wanted to do some speedruns on SSFML, and I compiled a document that outlines the speed of execution for a non-trivial task in Sphere 1.5, 1.6 and SSFML.

All detailed in a report here: http://radnen.tengudev.com/Speeds%20of%20Sphere%20Engines.pdf

tl;dr:
- SSFML is 28x faster than Sphere 1.6 and 58x faster than Sphere 1.5
- Sphere 1.6 is about twice as fast as Sphere 1.5
- Incrementing for loops in the check section is quite fast.
- In Sphere 1.6 and SSFML: += 2 is slower than doing 2 ++ increments. In SSFML it can be as much as 12 individual ++ is faster than a += 12.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on December 23, 2013, 09:39:42 am
How is ++ so much faster than +=?  I thought at the machine level ++ is the same as += 1, so you'd think the successive increments would be slower, not faster. ???
Title: Re: Sphere SFML v0.75alpha
Post by: N E O on December 23, 2013, 03:13:15 pm
IIRC most/all modern CPU instruction sets have an "increment by 1" instruction, and "a += 1" is usually just shorthand for "a = a+1" (an assign and a non-optimized addition of a number).
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on December 24, 2013, 04:34:46 pm
New Feature: Heap
So, in this engine I exposed a new feature, the heap data structure. I wrote a C# and JS version of one based on this exclent article: http://eloquentjavascript.net/appendix2.html

I find that while the Jurassic-compiled JS version of the heap is pretty fast, the C# variant-exposed-through-code version is much, much faster. So much so it can make a JS-based A* algorithm right at the speed I like: milliseconds. Of course, going further, I could continue to implement the A* pathfinder straight in C#, but a binary heap is still useful for many things, such as figuring out the next bullet to impact a target, efficiently find the next turn in a turn based combat system prioritized on speeds (example below), sort a list, find a closest enemy or ally, get a shortest distance, etc.

Example:
Code: (javascript) [Select]

var heap = new BinaryHeap(function(x) { return x.speed; });
heap.add({speed: 5});
heap.add({speed: 4});
heap.add({speed: 5});
heap.add({speed: 3});
heap.add({speed: 1});
heap.add({speed: 6});
heap.add({speed: 2});

heap.shift(); // get next fastest enemy

// or just get the sorted list:
var array = heap.toArray();

// underlying data changed dynamically? No problem, we can do a heapsort on it:
heap.resort();


What do you think about the API?
Code: (javascript) [Select]

heap.add(object); // adds and sorts in the object
heap.shift(); // returns the topmost priority item
heap.pop(); // removes the bottommost priority
heap.remove(node); // removes that node/item from the heap
heap.resort(); // resort the list (ideally for lists of objects)
heap.toArray(); // get underlying array
heap.size(); // get length of heap
heap.clear(); // clear out the heap


If I'm missing anything or it needs changes, feel free to ask.

Benchmarks:
JS A* algorithm on a worst-case 64*64 sized map with various heap implementations and Sphere engines.

SSFML using C# heap: 33ms
SSFML using JS heap: 100ms
Sphere 1.6 using JS heap: 80ms
Sphere 1.5 using JS heap: 140ms

Notice the SSFML version does not optimize the JS heap very well; it performs worse than Sphere 1.6 which is shocking! So in fact using the JS heap in 1.6 and checking for existence of native heap for SSFML will give you a good solution that is cross engine.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on December 24, 2013, 11:41:32 pm
What exactly is a heap?  I've heard the term tons of times and I think I even looked it up once, but unfortunately I programmed in C/C++ for so long that I'm conditioned to automatically associate the term with the heap (i.e. free memory), which despite the fact I know is something entirely different, that particular meaning is so ingrained in my mind that the other meanings never seem to stick...
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on December 25, 2013, 01:21:02 am
I'm pretty certain if you read the article, you'll learn exactly what a heap is. Fun fact: it is very similar to a binary tree, but faster due to efficient array lookups.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on December 25, 2013, 06:32:40 am
See, if I read the article I'm pretty sure it's not going to stick due to the other meaning being so deeply ingrained.  I figured if I had someone explain it to me (i.e. in a non-academic context) I'd be more likely to remember it.

Maybe I'm just weird.  :D
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on December 25, 2013, 06:47:18 am
Do you know what a Binary Tree is? Do you know what Binary Search is? Because it's exactly that in array form.

Basically in a tree you have a node at index i, and then the indices at i*2 and i*2+1, would be it's children (the nodes right underneath it). So by using those formulas we can create a direct representation of a tree inside of an array. The benefit is that there is no stack recursion over node objects, and instead everything is reduced to efficient array accesses. The speeds arrive at O(Log2(N)) time (logarithmic time means it gets faster at finding the answer the more items there are with respect to linear time). It's nice in C#-land since I can type the underlying array, whereas in JS-land I can't.

I might add a BinaryTree next, but with the heap as fast as it is, I don't think it's wise. ;) You don't have to know how it works (on the inside) to use it in a game, though. Just know it orders inputs from smallest to largest really fast. Which is good for all the cases I pointed out a couple posts up.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on December 25, 2013, 06:55:52 am
Ah, that's pretty clever.  So basically the idea is that you take the tree (which is two-dimensional) and flatten it, then just index the flat array.  Neat, I never would have thought of something like that.  Not sure where the auto-sorting comes into play though, since nothing in your description of the actual tree structure indicated that the nodes had to be sorted. Am I missing something here?
Title: Re: Sphere SFML v0.75alpha
Post by: N E O on December 26, 2013, 07:01:01 pm
The auto-sort in a binary heap is almost always done upon insertion and insertion is usually O(2*log(N)) in worst case IIRC. The inserted node is compared to the current (root at the start) node and if less than it goes to the left child node else it goes to the right; that left or right node is then the current node. It usually repeats in that manner until either there are no more child nodes to compare to. The re-sort usually performs node "rotations" to re-balance the tree so search and future insertions are faster (the "bubbleUp" and "sinkDown" functions in the linked page).
Title: Re: Sphere SFML v0.75alpha
Post by: Flying Jester on December 27, 2013, 04:20:54 pm
Can we see the test code for the A*?

Have you tried using Typed Arrays (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays) for the A*? They are used for storing, accessing, and modifying binary data with very little overhead, and I've heard they are very fast.

I mean, Sphere 1.5-6 can't do it, but I would imagine Jurassic could, and I know V8 and modern SpiderMonkey can.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on December 27, 2013, 07:24:49 pm
It has been proposed to ECMA: http://wiki.ecmascript.org/doku.php?id=strawman:typed_arrays

But, since the proposal is newer than 2010, it hadn't made it into ECMA v5, which is used by Jurassic. So it doesn't work. :( V8 has it since the internet is kinda their motivation. :P It looks good for being in ECMA 6 though. I can, however, implement the API in my engine, it shouldn't be too hard, and would make reading Sphere binary files like map, tileset, and spritests easier to read in (with JS, that is).

Edit:
Actually, I can't modify Jurassic to do that. I would need access to the [] operator (not the C# overload, but the JS one), which means adding to and modifying the parser so that a new Array type, the TypedArray, has the ability to get and set bits of an underlying buffer with the [] operator.

Because doing this in JS, is not possible:
Code: (javascript) [Select]

var buffer = new ArrayBuffer(100); // 00000000 ... 0000

var intarray = new Int32Array(buffer);
intarray[0] = 5;

buffer.toBinary() != 00000000 ... 0101

// there would need to be:
buffer.update(intarray); // but this is not a spec.


(Which is probably another reason why it is not standard).

Anyways, I'll attach the A* code. Put both into a test game folder, and try it out, using pathtest as the parent script. Use the left mouse button to create obstructions. F1 ... F6 loads maps, Shift + F1 ... F6 saves maps (for fun, testing etc), then use the right mouse button to set the two pathing nodes (you have to click a place for each node before it paves again). It is quite robust. It has 6 presets, three for speed (so you might not get shortest path, but a fast performance), and 3 accurate ones (shortest path, but slow). I'd use the first 3 for movement depending on how you want movement to work in your game (diagonal vs. tiled), and the bottom 3 for... academics. :P

The A* algorithm under the newer speed model, has these speeds in the Sphere Engines: (64*64 worst case)

SSFML: 36ms          - old: 33
Sphere 1.6: 67ms   - old: 80
Sphere 1.5: 104ms - old: 140

So, these are faster than earlier indeed, it might seem slower (36 v 33), but I found a worse worst case: not finding it's target. xD
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on December 28, 2013, 12:51:04 am
New Feature: XML serialization (alpha)

The idea is to have a different way to store data, we have:

1. The Sphere like ini-file format
2. JSON in a raw file.
3. ... and now XML!

Example:
Code: (javascript) [Select]

var file = new XmlFile("test.xml");
file.write("my_object", { x: 45, y: 54, ended: false, map: { name: "test.rmp", start: { x: 50, y: 50 } }, arr: [0, 1, 2] });
file.close();


Output:
Code: (xml) [Select]

<?xml version="1.0"?>
<!--Generated by Sphere SFML XML Content Serializer v1.0-->
<my_object s_x="45" s_y="54" s_ended="False">
  <o_map s_name="test.rmp">
    <o_start s_x="50" s_y="50" />
  </o_map>
  <a_arr s_0="0" s_1="1" s_2="2" />
</my_object>


Notice o_ means object, a_ array, s_ string, n_ number, b_ boolean, and I don't store functions.

The ultimate goal is to make data serialization easier than using JSON. Compare the above with this:
Code: (javascript) [Select]

var file = OpenRawFile();
var json = JSON.stringify({ x: 45, y: 54, ended: false, map: { name: "test.rmp", start: { x: 50, y: 50 } }, arr: [0, 1, 2] });
file.write(CreateByteArrayFromString(json));
file.flush();
file.close();


Which is not bad, but not easy to read for filesaving purposes. XML I think is a cleaner, more user friendly way (and the output is also human readable and therefore easier to spot issues in the saving).

The proposed API
Code: (javascript) [Select]

var file = new XmlFile();
file.write(name, object);
var o = file.read(name);
file.close();


I wanted it to be simple to use and store any kind of object datatype.
Title: Re: Sphere SFML v0.75alpha
Post by: N E O on December 28, 2013, 01:23:39 pm
I've always been partial to declaring a variable's type (object, array, string, etc) in XML as an attribute of the element, with my alternative method being <type name="x">value</type> or <bool name="isDone" value="true" />.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on December 29, 2013, 07:42:47 pm
N E O: looks good, I'll move to this style: <type name="x">value</type>.
Title: Re: Sphere SFML v0.75alpha
Post by: Flying Jester on December 30, 2013, 09:36:56 pm

Actually, I can't modify Jurassic to do that. I would need access to the [] operator (not the C# overload, but the JS one), which means adding to and modifying the parser so that a new Array type, the TypedArray, has the ability to get and set bits of an underlying buffer with the [] operator.


Huh, V8 allows you to overload the bracket operator (scriptside) of objects. It's a shame Jurassic doesn't have the same feature. Perhaps you could add a .at() member (like std::strings in C++...God knows why they have it) that performs the same function as brackets would?

I only push this because it is kind of native JS (well, kind of future native JS).
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on December 30, 2013, 10:45:04 pm
Well... There might be a way I'll go ask the creator, see what he thinks. It might be buried somewhere...
Title: Re: Sphere SFML v0.75alpha
Post by: Flying Jester on January 04, 2014, 04:06:57 pm
Do you have a link for json2.js?
Title: Re: Sphere SFML v0.75alpha
Post by: alpha123 on January 04, 2014, 04:28:29 pm

Do you have a link for json2.js?

json2.js (https://github.com/douglascrockford/JSON-js/blob/master/json2.js) (GitHub (https://github.com/douglascrockford/JSON-js)), although I recommend json3.js (http://cdnjs.cloudflare.com/ajax/libs/json3/3.2.6/json3.js) (GitHub (https://github.com/bestiejs/json3)).
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on January 04, 2014, 05:25:12 pm
Jest: you may not need it. SSFML and I hope your v8 engine have JSON in them already. I know SSFML's JSON is faster than loading up Crockford's JS library.

I don't know about the speed of json3, though, it might be faster, it might not.
Title: Re: Sphere SFML v0.75alpha
Post by: Fat Cerberus on January 05, 2014, 12:43:59 am


Do you have a link for json2.js?

json2.js (https://github.com/douglascrockford/JSON-js/blob/master/json2.js) (GitHub (https://github.com/douglascrockford/JSON-js)), although I recommend json3.js (http://cdnjs.cloudflare.com/ajax/libs/json3/3.2.6/json3.js) (GitHub (https://github.com/bestiejs/json3)).


Just updated json2 to json3 in Spectacles due to your recommendation, but is there any difference outside of under-the-hood changes? e.g. New features?
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on January 05, 2014, 01:27:07 am
Json3 is in fact slower than json2, and all I see is it parses dates differently and increases support for particularly older browsers. Oh, it also detects cyclic structures, which if you know you are not using (mainly since you want to serialize straight-up data), then I wouldn't bother. That said, they do a good job with it, but for a closed system like Sphere I'd choose the fastest one that works any day, it is after all, not the web so it's not like standards change or environments change overnight.

Though I'm not sure about the correctly serializes primitive wrapper objects part, it might be beneficial, I dunno, but I've had no problems with Json2.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on January 16, 2014, 09:39:33 pm
I've been tweaking with things and I wanted a good benchmark for speed, so I took to drawing things. Here are the results. The numbers are the amount of items drawn before the FPS dips below 60. I eyeballed them, so it's not "scientific" by any means, but it should show you the general trend, at the very least.

Code: (text) [Select]

+--------+------+-------+-------+
|Version | Game | Draw  | Cull  |
+--------+------+-------+-------+
|v1.5 32 | 3300 | 7400  | 6400  |
|v1.5 GL | 4000 | 8800  | 7000  |
|v1.6 32 | 6000 | 11000 | 12000 |
|SSFML   | 7000 | 8600  | 14200 |
+--------+------+-------+-------+


Game: A test in which items are drawn in a game environment (separate update and render loops).
Draw: Items are drawn on screen and stay on screen (single update/render loop).
Cull: Same as draw, but items allowed to leave screen.

It turns out SSFML has really good culling, but in the end of the day is no faster than a software driver. WTF? I think hardware acceleration isn't that fast. In fact I think it has to do with Sphere's API. Because you can't do a lot of tricks in Sphere, you nerf the maximum potential that "hardware acceleration" gives you. You have an API such that you draw things in order as they appear, so sprite batching is harder to achieve. You have methods like blit() and blitMask(). And you can't tell Sphere to put things into texture atlases. I could get away with fonts, but not for general images. So Sphere forces you to use unique textures each time something is drawn to screen, caising many GL state changes and making it perform not as fast.

In a general game environment, SSFML it is faster, but it has to do with both culling and the fact, generally, the JS executes faster so game calculations happen faster. Yes, the JS environment can be more of a bottleneck than rendering in Sphere, and obviously, it shows.

But I do have an idea. SSFML could generate atlases for you behind-the-scenes. It might be possible to cache all loaded textures into a giant texture. If that giant texture is filled up, it then creates another giant texture to use. An image, behind the scenes, then only encodes where it's base texture is, and what atlas to use. This might just work.

I did implement a sprite batch, but at the end of the day, it drew things out of order, and was only like 15% faster (if you were lucky and it happened to draw everything in the same order you blitted them in).
Title: Re: Sphere SFML v0.75alpha
Post by: Flying Jester on January 16, 2014, 09:55:13 pm
I am going to add automatic atlasing to TurboSphere (the spritebatcher already provides the API for me). In TurboSphere, all images used in a spritebatch are all in the same GL texture.

In the end, the Sphere API is not well suited to hardware acceleraton. I certainly wouldn't want to remove the graphics API that Sphere exposes, because it's extremely approachable. But this is why the addition of a batching API is important, since you just cannot get full performance from an immediate API. Not without losing some speed in software lookup and cacheing, and using a lot of system RAM.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on January 16, 2014, 10:46:11 pm
The important test, I think, is the cull test since it's advantageous to those making their own tile engine in Sphere, and not worrying about rendering stuff off screen.

Also, "immediate API" is a great way of putting that, I should remember that term for Sphere. :)

Also a texture atlas only helps when you draw many different items on screen. My draw tests used only a single graphic, so atlasing that image for the test wouldn't actually help.

New Test:
Code: (javascript) [Select]

var nums = 0;
var items = [];
var image = LoadImage("star.png");

function Item() {
this.x = 0;
this.y = 10;
}

Item.prototype.update = function() {
this.x += 2;
image.blit(this.x, this.y);
if (this.x > SW) return;
}

for (var n = 0; n < 10; ++n) {
var time = GetTime() + 1000;

while (time > GetTime())
{
items.push(new Item());
for (var i = 0, l = items.length; i < l; ++i) items[i].update();
FlipScreen();
}

nums += items.length;
items = [];
}

Abort(nums / 10);


This runs 10 trials of the 1 second test: Draw things for one second. Here are my results:
Code: (text) [Select]

1.5: 488 items drawn
1.6: 800 items drawn

GL:
1.5  : 1141 items drawn
SSFML: 1065 items drawn


If you want to run it go ahead. :) (have a 3px*3px image though). Oh, and 1024*768 screen
Title: Re: Sphere SFML v0.75alpha
Post by: Flying Jester on January 16, 2014, 11:44:26 pm

Also, "immediate API" is a great way of putting that, I should remember that term for Sphere. :)


I didn't come up with it. I call it that because the Sphere API is pretty much 1:1 with the OpenGL immediate mode.

In Linux, 1.6, using the system arrow and a 480x640 screen:

SphereGL: 504
FJ-GL: 538

With a 1024x768 and a 3x3 image:

SphereGL: 442
FJ-GL: 486
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on January 17, 2014, 01:05:42 am
You can't do that demo in TS? Your FJ-GL is not bad though! (We can't compare my results to yours since computers vary, but between Sphere drivers it's not bad certainly).
Title: Re: Sphere SFML v0.75alpha
Post by: Flying Jester on January 17, 2014, 01:48:13 am
I could (in fact, that's one of the few demos that the new VAO code will work perfectly for), I just am not on a machine with TS right now.

FJ-GL should always be at least as fast as Sphere-GL. It will certainly be a lot faster with primitives (which are pretty fast anyway, so not too much overall gain there), image creation, deletion, and cloning (which is very cheap  with the new OpenGL extensions). FJ-GL also does simple software occlusion testing for the current clipping rectangle, although OpenGL's scissor test is really pretty fast anyway.

We also can't directly compare since, as I've found out recently, a lot of Sphere is exclusive to each platform.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on January 20, 2014, 03:06:27 am
Jest, how are you doing surface.rotate? My surfaces look strange when not rotated at perfect PI increments.

Ok, I figured it out. It was a directional thing. I had to find the colors from the source to the destination. In this way I assure every color is mapped - even if some are mapped twice, which is how Sphere does it. :)

Here's the code to rotate the x and y points:
Code: (csharp) [Select]

        private static int RotateX(int x, int y, double rad, int m_x, int m_y)
        {
            return (int)(Math.Round((x - m_x) * Math.Cos(rad) -
                     (y - m_y) * Math.Sin(rad)) + m_x);
        }

        private static int RotateY(int x, int y, double rad, int m_x, int m_y)
        {
            return (int)(Math.Round((x - m_x) * Math.Sin(rad) +
                     (y - m_y) * Math.Cos(rad)) + m_y);
        }
Title: Re: Sphere SFML v0.75alpha
Post by: Flying Jester on January 20, 2014, 03:49:10 am
I don't yet. For that and transformBlitSurface, I plan on using OpenGL and framebuffers to dump the change back to software. It's just so much simpler, and either as fast or faster as doing it in software.

At that point, I plan on surfaces being mirrored in hardware, so if they do need an update in hardware it will also prime them for being blitted directly to the screen anyway.

I may even change zoomBlit and stretchBlits (if those still work, there have been a lot of changes to the graphics code recently) to do that too. I was having issues similar to what you are seeing in your rotate with my zoomBlits when I first tried to do them. But if all surfaces are, at some point, mirrored in hardware anyway to allow them to easily be changed in Images or to be blitted directly, it makes as much sense to me to just have the GPU do these kinds of transformations.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on January 20, 2014, 05:37:14 am

I don't yet. For that and transformBlitSurface, I plan on using OpenGL and framebuffers to dump the change back to software. It's just so much simpler, and either as fast or faster as doing it in software.


I don't find it that simple... Maybe it's because there are certain things I want control over. Some thing are indeed easier: primitives, image blits, etc in hardware. But in SFML I have no access to masks like ADD or SUBTRACT etc. nor can I control the more pixel-perfect details to try and emulate Sphere.

Though what I may do is get around to writing a shader that will do the blend mode stuff really fast, especially when compositing two images. And I haven't figured out a good way of resizing images for rotation besides putting them into a buffer large enough to support a fully rotated version of it or something like that.

Anyways I made enough progress to bump the version number and release an updated version. This newer one has now played tenfold more games than the v0.75 I have listed here. :) (the surface.rotate was a large part of that.... surprising how often it gets used).
Title: Re: Sphere SFML v0.75alpha
Post by: Flying Jester on January 20, 2014, 06:08:39 am
You can't use glBlendFunc or glBlendEquation, and the -Separate variants? With those, you can do every blend mode in Sphere except Invert and Average. You'd need shaders for those (I think?).
Plus, there is the NV Square blend mode (which every card in existence seems to support), and several others that could easily be added that way.
Title: Re: Sphere SFML v0.75alpha
Post by: Radnen on January 20, 2014, 06:37:31 am
I could, but SFML doesn't give that access to you since it does a lot of wrapping around GL. I'll have to use an actual C# GL wrapper, by using OpenTK or something like that, SFML is completely compatible with ditching it's main features for a real GL environment (and I can still continue to use input, sounds, and even things like it's sprites and primitives too).

Maybe I can at some point convert completely over to OpenTK. But I'll need to take time to learn it's API, but it seems to have quite a lot of good stuff packed in.

http://sourceforge.net/projects/opentk/
Title: Re: Sphere SFML v0.80
Post by: Flying Jester on January 20, 2014, 07:09:47 am
Ah, that's a shame.
I never really thought about how you would go about using OpenGL from C#, I guess I assumed that OpenGL would be about as well exposed in C# as it is in C++ (on the MS side of things).
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 21, 2014, 05:03:13 am
So, I'm working on a smarter sprite batcher and I realize I can more or less do some immediate blitting as textures change. That means images can be drawn in order as they appear in code, but they may not always draw when things like fonts and windowstyles draw. This leads me to believe that I should render all sprites in the sprite batcher, not just images.

Anyways, I made a test (and it doesn't use external resources so anyone can run it) (on a 320*240 sized window)
Code: (javascript) [Select]

function TestManyImages() {
    var image = CreateSurface(48, 48, CreateColor(255, 0, 255)).createImage(),
        done = false,
        factor = 2,
        w = GetScreenWidth() * factor,
        h = GetScreenHeight() * factor;

    while (!done) {
        for (var y = 0; y < h; y += image.height) {
            for (var x = 0; x < w; x += image.width) {
                image.blit(x, y);
            }
        }

        FlipScreen();

        while (AreKeysLeft()) {
            if (GetKey() == KEY_ENTER) done = true;
        }
    }
}


Speeds:
SSFML-culling: 10000 fps (which seems to be my computers limit, I cannot go beyond this in performance).
SSFML: 7600 fps
SSFML - culling - nobatch: 8300 fps
SSFML - nobatch: 5400 fps

1.5 SphereGL: 3400 fps
1.5 Sphere32: 2000 fps
1.6 Sphere32: 2700 fps

Which means the sprite-batcher is better than the 15% I had been working with before.

It may not seem like a lot to move from immediate to batched, but it has longevity stability. So even at 10x the images the speeds are still the same while Sphere grinds to a sudden halt. But that's culling. The next test negates any culling and draws things on the same screen:

Replace the inner drawing function:
Code: (javascript) [Select]

                image.blit(x % (w / factor), y % (h / factor));


factor of 2:
SSFML fastest: 5900 fps
1.5 fastest: 3400 fps
1.6 fastest: 2000 fps

factor of 4:
SSFML: 1600 fps
Sphere 1.5: 450 fps

So, as you can see keeping things on the same screen hurts performance by a lot. Thankfully people don't usually draw 200+ images in the same screen bounds. Even if you made your own tile-map engine, it'd only draw the amount on screen.
Title: Re: Sphere SFML v0.80
Post by: Flying Jester on January 21, 2014, 06:28:31 am
Out of curiosity, how are you drawing primitives?
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 21, 2014, 03:20:05 pm
By passing vertices to the GL window:

Code: (csharp) [Select]

            Color sfml_color = color.GetColor();
            _verts[0] = new Vertex(new Vector2f((float)x, (float)y), sfml_color);
            _verts[1] = new Vertex(new Vector2f((float)(x + width), (float)y), sfml_color);
            _verts[2] = new Vertex(new Vector2f((float)(x + width), (float)(y + height)), sfml_color);
            _verts[3] = new Vertex(new Vector2f((float)x, (float)(y + height)), sfml_color);
            Target.Draw(_verts, PrimitiveType.Quads);


_verts is a static array that gets overwritten by new vertices each time you ask to draw a primitive. It is then sent to the GPU with Target.Draw. It's similar to doing:

Code: (cpp) [Select]

glBegin(GL_QUAD);

glColor4f(r, g, b, a); // rgba components of sfml_color
glVertex2f(x0, y0);

glColor4f(r, g, b, a);
glVertex2f(x1, y1);

glColor4f(r, g, b, a);
glVertex2f(x2, y2);

glColor4f(r, g, b, a);
glVertex2f(x3, y3);

glEnd();


Except made a bit more flexible since I use an array. I can pass just 2 points for a line, and 3 for a triangle. But a GL display list could be used to cache these on a lower-level (which I can't do in SFML). It might make it go faster... or not, display lists seem to be only useful for static objects. But they can be scaled, transformed by manipulating the matrix stack, etc, but then again that's primitives. A GL display list doesn't help sprite batching all so much.

Come to think of it... I should add primitives to the sprite batch too (making sure I draw those in order with textures in code, too).
Title: Re: Sphere SFML v0.80
Post by: Flying Jester on January 21, 2014, 03:52:51 pm
Are you texturing primitives with a full-color texture, or disabling texturing?

I've done many tests, and in C++, if you have to change the color and vertex values pretty much every call, it's just as fast to use immediate mode, buffers with rewritten subdata, fully rewriting buffers, or using vertex arrays. I haven't seen primitives be especially slow, but I haven't found any way that is really any faster than any other when it comes to sending vertex or color data.

But I thought up a simple way to make interleaved primitive and texture drawing faster. Just give a single pixel of every texture full color, set the texture coordinates of the image appropriately (so the image does not overlap the single pixel), and never unbind textures completely or disable texturing. That way, you just use the single pixel of full color to texture the primitve, you only need a single shader (and don't have to add any branches to the shader or swap shaders), and you reduce the number of state changes related to texturing since you never need to bind a texture or disable texturing to draw a primitive. If you put the pixel of pure white in the corner, you can even use texture coordinates of all zeroes for primitives and keep the all-zero texture coordinates in a very static buffer.
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 21, 2014, 04:02:48 pm
Hmm, that seems too low-level of a solution for SFML, again I'd have to use OpenTK for that. But, I could draw primitive rectangles faster perhaps if I used a single white pixel and stretched it to fit? I noticed in DirectX that was a really fast solution.
Title: Re: Sphere SFML v0.80
Post by: Flying Jester on January 21, 2014, 04:16:50 pm
All you'd need to do is add an extra row or column to any image to be uploaded to a texture, and make one of the pixels white with full alpha. You do need to worry about texture coordinates of the images then, though.

Essentially, each texture becomes a texture atlas, holding at least a normal image and 1x1 image of 0xFFFFFFFF.

It's faster in OpenGL for a couple reasons. Never disabling texturing lets you use a single shader with no branches in it, which is faster than a branching shader and (by far) switching between shaders, especially multiple times a frame. That's why you'd want to texture primitives, at least. Second, you never need to change the bound texture to do a primitive draw. Changing textures is the slowest part of TurboSphere, that's part of why I came up with this (I doubt I was the first to think of it, however).

It slightly complicates image drawing, but actually simplifies writing shaders and primitive drawing.
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 21, 2014, 05:21:03 pm
Hmm, I'll do that then. I was going to add a feature to dynamically add loaded images into a texture atlas. It won't hurt having a single extra pixel in it.

Edit:
I moved text rendering to the sprite batcher and saw the fps of a screen with a text-heavy menu skyrocket from 4200 fps to 8300. That's not bad at all! Next is to move windowstyles over, and see what that adds. :)

Jest:
I have an interesting problem to solve (I haven't yet ran into it, but I presume I will soon enough). When someone creates a surface, then casts that to an image (a surface-created image) should you leave it as it's own texture or do you put that into a texture atlas? There isn't an easy answer.

What if you want to create a lot of surfaces and do a lot of little edits and then cast those to image to do some drawing techniques for a while, then throw that away. If that all gets put into an atlas, would you clear the atlas? Creating dynamic atlases like that isn't easy since texture-packing is not a two-way thing. Conversely if you leave surface-created images outside of texture atlases, then while you'll suffer some performance loss drawing surface-created images, you at least don't run the risk of a lot of unnecessary atlas management that could slow surface generation down.

Or perhaps, better yet, surface-created images don't share an atlas with loaded images. But then having this special kind of atlas would still incur surface generation penalties as you muck with it (by adding and removing). You don't want to bloat up atlases for no real reason.

I might have to benchmark both when the time comes. It's important to find a fast method here since some surface-created images *do* have fundamental uses (besides just being 'middlemen'). Say you have a game where the main character's sprite is paper-dolled. To do this you create a bunch of surfaces, then compile them into one surface in the end. For the surfaces you used to build the one image, you don't need them to persist in an atlas. But the single image you finish with should go into an atlas for fast blitting. Now, of course by calling .createImage() you are intending to keep it for longer, so I guess that's the best hint to say the intended image gets "atlased". But it still can't stop someone from abusing the feature (using many surface-created images).

Edit:
I've been thinking, in SSFML, I could add a new blit method: "WrapBlit" this could come in handy for images that tile... The API would be like:
Code: (javascript) [Select]
image.wrapBlit(x, y, u, v)


where x and y is where it goes and u, v, is the texture wrapping part. I made a space game demo in XNA and for the nebula backgrounds I had huge, beautifully tiled images that could wrap easily from the fact the u, v can repeat (it's far, far, far more efficient than drawing 9 images and looping them around). But I can't do this at all with texture atlases. :/

Since, though, it is not a feature Sphere has I might propose this API:
Code: (javascript) [Select]

var wrapped_image = new WrappedImage();
wrapped_image.blit(x, y, u, v);


Then it doesn't have to get sent to an atlas and can be ignored if you target vanilla Sphere. :) (Also useful for parallax backgrounds)

Edit:
I moved windowstyles over to a partial system. The corners are drawn fast, but the sides and background image are not. They must use un-atlased textures, and cannot be batched since their u,v's must be repeated. The hybrid system only gains another hundred fps, which is good but not the best.

I think there is a way to take the representation of a windowstyle and forgo the u,v approach altogether and generate an actual windowstyle mesh, physically repeating the side images (yes I'm talking about looping and repeating the texture). I just hope this is faster than the current method (which is certainly not bad). I mean, I get to use a full atlas rather than a partial atlas, and vertices are fast to generate.

Edit: (again)
I did the benchmarking and it turns out the hybrid approach is the best on windowstyles. The u,v texturing on sides and bg image give a huge speed boost and accurately clips the images. The vertex mesh is good, but starts failing if there are a lot of images, say, in the background.
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 22, 2014, 03:15:32 am
So my last post was getting kinda long, it's just me logging my progress and asking questions.

So, in Sphere 1.5 GL drawing a windowstyle that filled a 320*240 screen that had a 1px background image put the fps to 13. In SSFML the fps was unchanged at 8800 fps. That is 676 times faster. :) This is important sinces games use windowstyles. My old trick to speed up games in Sphere GL was to use gigantic tiling sprites in a windowstyle. In SSFML it's good to know I don't have to. I want to know how FJ_GL handles windowstyles, because I know SphereGL implements them wrong.

In Sphere 1.5 Standard32, drawing that insane windowstyle took 770fps. Which means SSFML is only 11.5 times faster.
In Sphere 1.6 Standard32, drawing that insane windowstyle took 850 fps. Which means SSFML is only 10.4 times faster.

But I think the takeaway here is SSFML draws windowstyles at constant speed, while the underlying image sizes vary the performance of vanilla Sphere.

Edit:
FPS of drawing 100 Rectangle Primitives (320*240, 100 32*24 rects) in each version:
SSFML: 8800 - fixed 10000
Sphere 1.5 GL: 7900
Sphere 1.5 32: 1700
Sphere 1.6 32: 2800

Gradiented:
SSFML: 5900 (why?) - fixed: 9900
Sphere 1.5 GL: 6400
Sphere 1.6 32: 500
Sphere 1.6 32: 430

So that means SphereGL has pretty fast primitive rendering (better than SSFML). SSFML's faster now due to sprite-batching primitives, but it used to be much slower (at 6800 fps). It only batches rectangles right now since it was set up for rectangle-textures.

SSFML should have gradient's as fast as non-gradients so something is weird...

edit:
Ok, I have to toss out all of my results, everything is much faster now. Everything. I was storing values in the color object wrong. :P See, colors take bytes and JS's Number object is sometimes a double, or an int and I was doing all kinds of crazy conversions to make sure it was an int and then make sure that int was a byte. Now I streamlined it without conversions and now most everything renders at 10000fps. I solved it by adding getters/setters to the color object on the C# side of things. But now there is a strong performance hit if all 4 fields were being modified each second. Thankfully, that doesn't happen often.

Edit:
Scratch that. There is a way to have efficient property getters in Jurassic but it makes color object etremely expensive to create. Extremely expensive. I have a pixel-perfect collision detector and it must check all kinds of colors, in all Sphere versions it was fast enough, but in SSFML it grinded the computer to a halt. I remove the "efficient" property getters and the speed returns - at the expense of some slowdown to reconstruct colors.

What I need to solve is this:
Code: (idea) [Select]

JS Object Property -> Byte


It's definitely not easy since JS Object Property might not be a number and so you error. It might be a double, or it might be an int. Problem is, Jurassic only tells you the property is of type 'object'. :/ It boxes a value true enough, but the check code is always yucky to write:

Code: (Csharp) [Select]

if (object["red"] is int) _color.R = (byte)((int)object["red"]);
else _color.R = (byte)((double)object["red"]);


There is a faster way of doing this in Jurassic, but it makes the color object 1000 times slower to create, but 10 times faster to use.
Code: (Csharp) [Select]

// ... in declaration
[JSProperty(Name = "red")]
public int Red { get; set; }

//... later on:

_color.R = (byte)red; // red is a Jurassic JSField
Title: Re: Sphere SFML v0.80
Post by: Flying Jester on January 23, 2014, 02:27:26 am

So my last post was getting kinda long, it's just me logging my progress and asking questions.

So, in Sphere 1.5 GL drawing a windowstyle that filled a 320*240 screen that had a 1px background image put the fps to 13. In SSFML the fps was unchanged at 8800 fps. That is 676 times faster. :) This is important sinces games use windowstyles. My old trick to speed up games in Sphere GL was to use gigantic tiling sprites in a windowstyle. In SSFML it's good to know I don't have to. I want to know how FJ_GL handles windowstyles, because I know SphereGL implements them wrong.


FJ-GL is about 10-20% better than Sphere-GL (which is just generally true of the two). And it's not the video drivers fault, it's Sphere's. The way it really should be rendering windowstyles is used greater-than-one texture coordinates to tile the texture with a single API call. But it can't, since Sphere itself has no concept of texture coordinates, that's up to the video driver. So, using the video driver API, you cannot draw windowstyles in any way other than calling BlitImage for every time the background and each edge component is tiled. What it really should be doing, in that case, is have video drivers that have a BlitImageTiled procedures, and then if there is no way to optimize tiled drawing in that backend, the video driver would just tile it with a bunch of BlitImage calls (as Sphere forces it to do anyway). Perhaps there is some optimization for DirectX I'm not seeing (probably because I know almost no DIrectX), but it's the worst way to call an OpenGL-based backend. WindowStyles show perfectly the limitation of Sphere's video driver API--tiled image blits could speed up the map engine, as well.

Of course, a stronger relationship between the video backend and the video procedures would help in every way as well. Sphere's 'plugin' API is only just high level enough to let it use OpenGL, DirectX, and SDL. A higher level separation, with more procedures in the video backend would let many, many more optimizations and simplifications be possible. It wouldn't even have to be anywhere near as much as in TurboSphere--the 'engine' there does almost nothing but load plugins and manage V8. The advantage is that every plugin has full control of the script functions, from script to the GPU or filesystem or audio API, the plugin knows what is happening and can have any optimization possible in it. It comes close to being as powerful, in that respect, as a purely monolithic architecture.
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 23, 2014, 02:35:53 am
I'm running tun's startup game with a fair list of games to see how well it handles. By far it's quite badly coded, yet is a good worst-case code candidate for speed.

In SSFML 0.7.5 I get 64 fps
In SSFML 0.8.0 I get 265 fps
In SSFML 0.8.1 I get 300 fps
In Sphere 1.6 32: I get 750 fps
In Sphere 1.5 GL: I get 640 fps
In Sphere 1.5 32: I get 700 fps

I still have a ways to go, but my next step is to try and move to hardware textures.
Title: Re: Sphere SFML v0.80
Post by: Flying Jester on January 23, 2014, 02:52:18 am
On Linux:
FJ-GL gets 262 FPS
Sphere-GL gets 213 FPS

It's spamming DirectBlits (aka surface.blit) to the video driver. I have no idea at what point in time that was a fast thing to do. I would imagine the best thing to improve the performance of Tung's startup game would be to have surfaces always also exist as textures, and then reupload the texture to GL when surface.blit is called, but only if the texture has changed.
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 23, 2014, 04:00:15 am

I would imagine the best thing to improve the performance of Tung's startup game would be to have surfaces always also exist as textures, and then reupload the texture to GL when surface.blit is called, but only if the texture has changed.


I had been doing that since SSFML 0.7.5, it doesn't help. Tun's startup game is redrawing the texture each time which is even worse. In the Standard32 drivers the speed of writing a texture and drawing it to screen is not that bad. But in hardware accelerated drivers, it's really bad. This necessitates having render textures. Do you know how Sphere-GL does it so fast? Because I was hoping SSFML would have been the same there since my current surface code is not doing anything fancy.

In fact I was surprised to see SphereGL at 640 fps, I swear I saw it much lower (around mid 70's to early hundreds) before...
Title: Re: Sphere SFML v0.80
Post by: Flying Jester on January 23, 2014, 06:38:16 am
Can you at least do a call to glTexSubImage2D, just to limit bandwidth?

Sphere_GL's surface.blit is identical to doing surface.createImage().blit(). From the hallowed source:
Code: (c++) [Select]

    IMAGE i = CreateImage(w, h, pixels);

    if (i)
    {
        BlitImage(i, x, y, CImage32::BLEND);
        DestroyImage(i);

    }


It uploads the surface anew to the GPU every single call. The only OpenGL-based speed-ups possible here would have to be in the OpenGL library itself.

The best reason I can give is that it is so simple that the compiler can optimize it really well, and it has little to do in the first place.[/code]
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 24, 2014, 12:19:36 am
I don't know how the above is any fast. I went to many graphics forums and looked around a lot and that should not work quite so fast. Every frame an image is created then destroyed, that's like doing this in your Sphere game:

Code: (javascript) [Select]

while (true) {
    var image = LoadImage("file.png");
    image.blit(0, 0);
    FlipScreen();
}


Now, I've been caching the surfaces as a texture, and not losing the texture pointer. Whenever I update the bytes I update the texture. I just think C++ has more raw speed than C#, to test this I decided to rewrite large portions of code to use direct pointer accesses into memory and noticed a considerable speedup.

I went from this (replace blend mode):
Code: (csharp) [Select]

    int off = (y * _width + x) << 2;
    _pixels[off + 0] = c.R;
    _pixels[off + 1] = c.G;
    _pixels[off + 2] = c.B;
    _pixels[off + 3] = c.A;


to this:
Code: (csharp) [Select]

    Color* color = (Color*)(buffer + (y * _width + x) * sizeof(Color));
    color->R = c.R;
    color->G = c.G;
    color->B = c.B;
    color->A = c.A;


Went from this (Blend blend mode):
Code: (csharp) [Select]

    int off = (y * _width + x) << 2;
    Color source = GetColorAt(x, y);
    float w0 = (float)dest.A / 255, w1 = 1 - w0;
    _pixels[off + 0] = (byte)(source.R * w1 + dest.R * w0);
    _pixels[off + 1] = (byte)(source.G * w1 + dest.G * w0);
    _pixels[off + 2] = (byte)(source.B * w1 + dest.B * w0);
    _pixels[off + 3] = (byte)(source.A * w1 + dest.A * w0);


To this:
Code: (csharp) [Select]

    Color* color = (Color*)(buffer + (y * _width + x) * sizeof(Color));
    float w0 = (float)c.A / 255, w1 = 1.0f - w0;
    color->R = (byte)(color->R * w1 + c.R * w0);
    color->G = (byte)(color->G * w1 + c.G * w0);
    color->B = (byte)(color->B * w1 + c.B * w0);
    color->A = (byte)(color->A * w1 + c.A * w0);


It's likely faster since I take a full color object a time and modify it rather than just the components at a time. Furthermore, there are a lot more lower level optimizations being made, such as no bounds checking. This is simply called "unsafe" code in C#, but it's technically just like C++.

The FPS of the main screen went from 300 to 500, but I've seen it as high as 650 while screwing around (but it could have just been a fluke).
Title: Re: Sphere SFML v0.80
Post by: Fat Cerberus on January 24, 2014, 12:28:59 am
The image is created from an existing surface, so it's probably just reusing the surface for the image bitmap, perhaps with some copy-on-write magic to prevent disasters.  Not quite the same as doing a LoadImage() every frame.
Title: Re: Sphere SFML v0.80
Post by: Flying Jester on January 24, 2014, 01:16:36 am
I hate to say it, but very simple C++ will usually be faster than very simple C#. I do not believe that is the whole story, but it could account for, perhaps, 10% in this case.

And it really isn't the whole story, Sphere-GL iterates through every pixel of a surface on CreateImage, and once it finds one that has an alpha that isn't 0, it considers the texture not transparent. Not that much overhead, but some.

I would expect that it isn't super slow because Sphere is CPU-limited, mainly due to using ancient SpiderMonkey. I've done a lot of testing with FJ-GL, and there is really only about 10% performance to be gained over Sphere-GL no matter what. At that point, you are taking hardly any cycles in the video driver, and all the time is being spent in jsapi calls. FJ-GL can never, never double speed over Sphere-GL. The biggest performance gain I could get was with image.clone(), since I can do that fully in hardware, and Sphere-GL has a GPU download, a full pixel copy and analysis, and then a full upload. FJ-GL is about 80% faster at it, depending on the image size.

Re replace blend mode: If you could set the GL blend mode, you could do that all with only a single call to OpenGL: glDisable(GL_BLEND). If you really want full performance, I would recommend using a toolkit that gives you more OpenGL control. OpenGL has a lot to offer, if you can use at least most of what it exposes to C/C++.
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 24, 2014, 02:28:49 am
No, yeah, this was just me not doing the hardware-stuff yet. I was just trying to get close to the speed of the C++ version of the software driver's ability to perform fast surface edits. I have it good now, but yeah, part of the problem is I'm contending with a software driver. I should get started moving things straight to hardware. :P

In fact it's going to be fairly easy since my primitives class wraps a render target. So technically I should just set the render target to the texture of the surface and have at it, easy as pie. The sprite batcher was made with the same concept in mind, so that means you get full sprite batching benefits on surfaces as well. This is nice if you want to make your own map engine in Sphere and decide to draw lots of textures straight to a surface.
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 24, 2014, 05:07:49 am
Alright, I moved over to hardware and now it draws at 120fps, but accurately. I have no idea how to make this faster. It should be blinding fast, and well, I think it is. It's just that tung's startup game redraws surfaces each frame. In the way I'm doing it, the render target is updated each time that happens. Then there is a further slowdown since he is only using 3 surfaces. Yep. So that means when he draws a list of names he keeps clearing and moving the surface as well. This should not make a huge difference in fact it's not that bad since he is only using 3 surfaces. But it slows my HW draws way, way down.

I know you think this can go faster, but I just don't see how. My  (naive) intuition on HW draw calls says I should be lucky to get more than 30 fps on tung's startup game. I have no idea where to optimize. Technically he isn't really using HW surfaces right. Every resource on them say to keep a hardware target floating around - never keep creating and destroying them - and scarcely update them. That's the damn definition of them.

Now here's why I'm going nuts. When I properly use them my fps is even greater than the software version. The fill rates are faster and I can draw them at 10000 fps.

See this: http://www.sfml-dev.org/tutorials/2.1/graphics-draw.php

Quote

This clear/draw/display cycle is the only good way to draw things. Don't try other strategies, such as keeping pixels from the previous frame, "erasing" pixels, or drawing once and calling display multiple times. You'll get strange results due to double-buffering.
Modern graphics chipsets and APIs are really made for repeated clear/draw/display cycles where everything is completely refreshed at each iteration of the main loop. Don't be scared to draw 1000 sprites 60 times per second, you're far below the millions of triangles that your computer can handle.


Tung was not doing the above in his code; to emulate Sphere's legacy pixel-buffer strategy to surfaces means not adhering to the modern design principle of using such features. I think it's the double-buffering that's killing my performance. Laurent did not design SSFML with older API's in mind.  So in order to emulate Sphere I keep my old way of doing things which is slower, or I switch to a toolkit and abuse features to make things work.

But I am indeed perplexed. The trade-off is odd, my HW surfaces are really not that bad when used right, but really bad when used like how tung treated them. :/
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 24, 2014, 07:15:43 am
But, not all is lost. See, while the performance is horrendous on Tung's demo, it's outstanding on other surface demos. See screenshot for an image of what's produced.

So, I was thinking Tung's demo is seriously flawed for HW acceleration. So I decided to make a different "thrash test" to see how robust my changes are. Turns out I get quite good results for "misusing" the surfaces like I do, below:

Code: (javascript) [Select]

var surf = CreateSurface(48, 48, white);
surf.rectangle(12, 12, 24, 24, green);
surf.gradientRectangle(0, 0, 48, 48, green, green, white, white);
surf.line(0, 0, 48, 48, red);
surf.setPixel(8, 2, red);
surf.drawText(sys_font, 0, 0, "Hi");

while (!done) {

            // draw surfaces:
    for (var i = 0; i < 5; ++i) {
        for (var j = 0; j < 5; ++j) {
            surf.blit(0 + i * 48, 16 + j * 48);
        }
    }
    // now, try to "thrash" the GPU (for Sphere GL/SSFML):
    surf.rectangle(12, 12, 24, 24, green);
    surf.gradientRectangle(0, 0, 48, 48, green, green, white, white);
    surf.line(0, 0, 48, 48, red);
    surf.setPixel(8, 2, red);
    surf.drawText(sys_font, 0, 0, "Hi");


SSFML: 2700 fps
Sphere 1.5 GL: 1200 fps (pictured)
Sphere 1.5 32: 1700 fps
Sphere 1.6 32: 2100 fps

Sphere 1.6 really is a very fast Sphere version. But at least it shows my HW surfaces are really very fast. Tung's example is just bad for HW acceleration I guess, even though you will see better performance in other more cryptic methods of drawing textures. I will never arrest my case, his code is an anomaly, I am still shocked SphereGL's method is any good, considering I still win in the above thrash test over Sphere-GL.
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 24, 2014, 05:58:47 pm
Well, well, it turns out I get 6100 fps moving back to my software surface code. So Tung's code is really bad, but if the surfaces are used right not only did my HW solution skyrocket, so did the SW solution.

Again to do the test:
SSFML HW: 2700
SSFML SW: 6100
Sphere 1.5 GL: 1200
Sphere 1.5 32: 1700
Sphere 1.6 32: 2100

That means I have a very fast solution. :) The colors are not that accurate though, I think the color blending needs some rework but that's ok.

Edit: On full color replace (not blend) the fps of SSFML is at 6600, and in Sphere1.6 32 it's still at 2100. BTW all of my tests were on 2x screen size.
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 25, 2014, 01:36:16 am
I found out the solution. Color objects are expensive to create in SSFML. I'll have to think up a better color strategy.
Title: Re: Sphere SFML v0.80
Post by: Flying Jester on January 25, 2014, 05:36:35 am
You can't put colors directly in the state on a per-vertex basis?

That's how I've been doing it (originally glColorPointer, but that's deprecated, so I switched to using Shaders and a vertex attribute). I actually considered making calls to new Color/CreateColor allocate their own vertex buffers that hold the color (theoretically quite fast, although on-the-fly color uploads are also pretty quick). I already do that with a single buffer of full color, just for non-color masked operations. So I suppose in the case of direct blits and plain old image blits, that probably speeds up FJ-GL (and TurboSphere) compared to Sphere-GL, which uploads the whole color every call--although only once per draw, in ancient immediate-mode fashion, through glColorub().

I considered creating a pool of vertex buffers that hold colors, and ref-counting them. Theoretically it could be quite expensive memory-wise, since V8 is extremely lazy about freeing handles, but I could probably certainly get away with making the colors 24 bit on the GPU (r6g6b6a6, for example). Technically, colors only need to be 30 bit, since if alpha is all zero I can just put a zeroed-out buffer on the state (I can even share that data source with primitive texture mapping buffers which also should be cache friendly), and I can put full alpha on the state using only any buffer that is equal in RGB and use blend modes (sometimes, wouldn't work for gradient primitives). I haven't done that because TurboSphere mostly isn't bus-limited, and color uploads are not a huge consumer of bandwidth.

There is no equivalent to glColor() in SFML? It's beginning to sound like SFML works a bit differently than OpenGL.
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 25, 2014, 07:07:59 am
SFML colors are fast to make. Yes, I can put them in on a per-vertex basis. It's just that the Jurassic wrapper around them was god-awful slow and I have no way around that. So, to circumvent that altogether I make the engine make a color object like this:

Code: (javascript) [Select]

function CreateColor(r, g, b, a) {
    if (a === undefined) a = 255;
    return { red: r, green: g, blue: b, alpha: a };
}


Yep, colors are just objects, which is near instantaneous to create. Then the rgba is 'parsed' out of it only when needed. It helps in Tung's demo since I realized he always created new colors when modifying things rather than set the rgba properties.

This made the SW surfaces blit at 750fps, which is now the fastest among all Sphere versions on my computer. The HW surfaces are still slow, and I'm still wondering why since technically I see nothing obvious to cause the slowdown. The color object fix just makes those HW surfaces run from 120fps to 200fps.

I made a fill-rate test where I constantly fill a surface in a loop, (on a 320*240, 2x screen):
Code: (javascript) [Select]

function TestSurfaceFillRate() {
    var w = GetScreenWidth(),
        h = GetScreenHeight(),
        surf = CreateSurface(w, h, CreateColor(255, 255, 255)),
        green = CreateColor(0, 255, 0),
        done = false;
   
    while (!done) {
        surf.rectangle(0, 0, w, h, green);
        surf.blit(0, 0);
        FlipScreen();

        while (AreKeysLeft()) {
            if (GetKey() == KEY_ENTER) done = true;
        }
    }
}


SSFML SW: 650fps
SSFML HW: 2900fps
Sphere 1.5 GL: 910fps
Sphere 1.5 32: 780fps
Sphere 1.6 32: 780fps

So I *know* my HW approach is the fastest, so again I'm still befuddled on why Tung's code is performing so slow.
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 25, 2014, 07:33:00 pm
Ok, I think a lot of slowdown is really the JS side of things, not Jurassic's compiled stuff it's actually pretty fast. But the CLR handlers and wrappers are slow. So I was thinking of moving over to an environment that implements .NET in JS, there are a few libraries that do this, but this one got my eye since it may be built to use V8, which is a heck of a lot faster than Jurassic: https://clearscript.codeplex.com/

So not only might I get really fast performance script wise, modern Sphere games can use the C# Runtime in their JS code:
Code: (javascript) [Select]

System.Console.WriteLine("Hello World!");

System.Linq. //... usage of Linq in your game

System.XML. // ...

SFML. // ... use sfml features in your code, includes shaders, textures, everything really!


And I can pass wrapped SFML objects directly into the environment.
Title: Re: Sphere SFML v0.80
Post by: Flying Jester on January 26, 2014, 03:05:01 am
Is it any faster to unwrap integers? You could try having colors be JS numbers behind the scenes. Primitive types are faster to deal with in V8 than full objects (although not by much).

If we are exposing console writing, I would recommend it at least be wrapped to also look like Web-JS console writing.

The XML exposition would be an excellent addition, though.
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 26, 2014, 05:03:03 am
Currently it turns out ClearScript is very slow. Doing this:

Code: (javascript) [Select]

while (true) {
    CreateColor(255, 255, 255, 255);
    CreateColor(255, 255, 255, 255);
    CreateColor(255, 255, 255, 255);
    CreateColor(255, 255, 255, 255);
    CreateColor(255, 255, 255, 255);
    CreateColor(255, 255, 255, 255);
    FlipScreen();
}


Brings the framerate way down. In Vanilla Sphere and my Jurassic branch, the above code had little slowdown. It seems exposing CLR to JS is very slow.

In ClearScript I got a 3 to 4 times performance boost by switching from this:
Code: (javascript) [Select]

var image = LoadImage("test.png");

while (true) {
    image.blit(0, 0);
    FlipScreen();
}


To this:
Code: (javascript) [Select]

var image = LoadImage("test.png");
var blit = image.blit;

while (true) {
    blit(0, 0);
    FlipScreen();
}


And that's running in a V8 context! Despite that, ClearScript is faster at RAW JS computations and computation speeds. About 2x slower than Chrome, which is damn fast since Jurassic is like 38 times slower than Chrome, even though it is 67 times faster than Sphere 1.5.

Argh! I hate this. I hate how going from C# to JS is so damn slow. How the hell can Sphere get away with fast Host-to-JS support? WTF is it doing differently?
Title: Re: Sphere SFML v0.80
Post by: Flying Jester on January 26, 2014, 07:11:21 am
How direct is the JS to CLI connection in Jurassic?
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 26, 2014, 07:23:11 am

How direct is the JS to CLI connection in Jurassic?


Very intimate, you must tell it precisely what methods and members to "cast" to JS.

Jurassic Definition:
Code: (csharp) [Select]

public class MyClass : ObjectInstance
{
    private Texture _tex;

    public MyClass(ScriptEngine parent) : base(parent) {
        PopulateFunctions();
    }

    [JSFunction(Name = "blit")] // needed
    public void Blit(double x, double y, [DefaultValue(0)] int state = 0)
    {
        Program.window.draw(x, y, _tex);
    }
}


ClearScript Definition:
Code: (csharp) [Select]

public class MyClass
{
    private Texture _tex;

    public MyClass() { }

    [ScriptMember("blit")] // optional
    public void Blit(double x, double y, int state = 0)
    {
        Program.window.draw(x, y, _tex);
    }
}


There's far more annotated C# code for Jurassic. I"m not sure that is it's secret or not. You always take a hit going between Host-to-JS, I've even read a post in the ClearScript discussion board claiming that. I'm just baffled that Jurassic and Vanilla Sphere do it without much overhead. I mean, I should be able to blit hundreds of items before the JS-to-CLR overhead creeps up, not just 2 to 5 items.
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 27, 2014, 10:45:59 pm
Alright, with some tweaks to the Jurassic-wrapped color object (thanks to Jurassic's creator) I finally have fast color creation. :)

I can't get ClearScript to run fast, so I'll stick with Jurassic for now, it's superior in every way to ClearScript for one reason: CLR to JS performace is slow and a game that uses JS in Sphere needs fast performance in precisely that area. Jurassic is fast since it compiles everything to the same bytecode C# uses so there is 0 performance hit going between them.

I noticed under Sphere 1.5 color creation is not as fast as under SSFML. Interestingly,
Creating Colors in a loop:
SSFML: 10600 fps
Sphere 1.5 GL: 8600fps
Sphere 1.5 32: 2500fps // holy cow!!

I really think that the color creation in the 1.5/1.6 Standard32 drivers are to blame for slow performance in Tung's startup game.
Title: Re: Sphere SFML v0.80
Post by: Radnen on January 28, 2014, 06:04:54 pm
So I added a new draw method, wrapBlit(x1, y1, x2, y2 [, width, height])

This is a very useful modern technique for creating backgrounds that never end, by wrapping it's drawing around the screen. This can be emulated in vanilla Sphere but it requires 4 images and a clipping rectangle. Therefore it is possible to add this ability in, but it wouldn't be efficient at all. wrapBlit uses your graphics card to wrap a single texture around the area you draw it in.

(x1, y1) is the location to draw at. (x2, y2) is the inner texture offset. Width and height are useful for expanding the area the texture is drawn in. If not specified it just uses the textures default width and height.

There is one other variant:
Image.wrapBlitMask(x1, y1, x2, y2, color [, width, height])

Technically you can make your own windowstyles this way. :)
Title: Re: Sphere SFML v0.80
Post by: Fat Cerberus on March 17, 2014, 10:27:39 pm
Hm, still can't run Spectacles on SSFML 0.80.  No SetDelayScript.  It's probably missing a bunch of other functions too (how much of the Sphere API is implemented?), but unfortunately it closes out after the first one so I have no idea what else is missing.
Title: Re: Sphere SFML v0.80
Post by: Radnen on March 18, 2014, 01:56:59 am
It should have a sizable portion of the Sphere API implemented. I checked and SetDelayScript is honestly one of the few not to make it thus far.

Are you building from source? If so, all you need to do is update and build it again and then you'll have the bleeding-edge version with SetDelayScript. :)

And please, if you see any more functions not yet added I'll definitely add them.

Edit: I see what you are trying to do; seeing if SSFML is stable enough to run your game with my Link library. I think it should be ready enough, all I need to know is if it supports all of the functions your game needs. I'd say I have 80% of the functions mapped out. There are many extraneous surface and map stuff that have not made it through. I tried to prioritize the API to things I think would be immediately relevant. For example, SetPersonAngle, an honest to goodness function in the Vanilla API is just not implemented yet.
Title: Re: Sphere SFML v0.80
Post by: Fat Cerberus on March 18, 2014, 01:59:30 am
I was using the 0.80 alpha linked in the OP.  I'll try building from source tomorrow.  What do I need to build it?  Just VS, or do I need any other libraries/SDKs?
Title: Re: Sphere SFML v0.80
Post by: Radnen on March 18, 2014, 02:05:38 am
I think at this point you just need the github source. NUnit now downloads via Nuget, Jurassic would too, but I run a modified version of Jurassic to handle somethings otherwise impossible through code. I put Jurassic into the repository despite the fact it's a binary. I always aim for an out-of-the-box build so I don't think you actually have to go anywhere and download anything.
Title: Re: Sphere SFML v0.80
Post by: Fat Cerberus on March 18, 2014, 02:16:32 am
Haha, you got me. ;D  The segfault in 1.5 did it for me; vanilla Sphere is really starting to show some dry rot at this point.  I guess I'm the first person to write a battle engine this complex in Sphere!

Honestly, my first choice for migration would have been TurboSphere, but I know there's no way that's ready for primetime yet and it's also not 1:1 with the Sphere 1.x API, meaning lots of retrofitting.  So yeah, Sphere-SFML it is!
Title: Re: Sphere SFML v0.80
Post by: N E O on March 18, 2014, 09:12:00 am
Can one of you provide an up-to-date binary dist of SSFML? I want to compare Flappy Sphere's current performance btwn 1.5, 1.6b, and SSFML.
Title: Re: Sphere SFML v0.80
Post by: Radnen on March 18, 2014, 03:54:21 pm
N E O, soon, if  Lord English wants to try out the bleeding-edge first, I'll let him and fix any problems he has since you might have them too. Once all of those problems are fixed, I'll then roll out a better version. ;)
Title: Re: Sphere SFML v0.80
Post by: Flying Jester on March 18, 2014, 04:42:34 pm

Honestly, my first choice for migration would have been TurboSphere, but I know there's no way that's ready for primetime yet and it's also not 1:1 with the Sphere 1.x API, meaning lots of retrofitting.  So yeah, Sphere-SFML it is!


Definitely not ready for production, but less reworking is needed than you'd think. I've included a compatibility script with TurboSphere that, when included, makes it 1:1 with Sphere 1.5.
Title: Re: Sphere SFML v0.80
Post by: Radnen on March 18, 2014, 06:01:02 pm
<Adding irc chat to my Sphere Studio>
Title: Re: Sphere SFML v0.80
Post by: Rahkiin on March 18, 2014, 06:12:46 pm
What would you want with IRC in a game? Using it as in-game chat?

I came across this IRC Client lib today: http://www.ulduzsoft.com/libircclient/
Although, it is C :P
Title: Re: Sphere SFML v0.80
Post by: Flying Jester on March 18, 2014, 06:39:12 pm
Wait, IRC in the editor?

It's really easy to make an IRC client, though.
Title: Re: Sphere SFML v0.80
Post by: Radnen on March 18, 2014, 06:59:21 pm
Wait, I posted an editor related topic in my SFML topic! Silly me! :P

But yeah, I would like to put an irc chat thingy into my Sphere Studio as a plugin. And I don't want to make one from scratch since I'd like to utilize what's already out there, and make sure it's bug free. In-game chat wouldn't be a bad idea, but I have ideas for creating plugin's for this engine. Soon enough I'll get around to doing it.
Title: Re: Sphere SFML v0.80
Post by: Rahkiin on March 18, 2014, 09:03:31 pm
But then, we should start a sphere channel too! #spherical on FreeNode?
Title: Re: Sphere SFML v0.80
Post by: Flying Jester on March 18, 2014, 09:07:46 pm
We already have one. #Sphere on espernet.
Title: Re: Sphere SFML v0.80
Post by: Fat Cerberus on March 18, 2014, 11:50:15 pm
Okay, well that was some obstacle course.  First it wouldn't build because "unsafe code not allowed unless you compile with /unsafe".  That was easy enough to fix in the project settings.  Then I got this error during build:
Quote
Error   1   The command "
if not exist "C:\Users\Bruce\Documents\GitHub\sphere-sfml\Engine\Engine\bin\Release\" md "C:\Users\Bruce\Documents\GitHub\sphere-sfml\Engine\Engine\bin\Release\"
xcopy /s /y "C:\Users\Bruce\Documents\GitHub\sphere-sfml\Engine\packages\ClearScript.V8.5.3.10.0\tools\native\x86\*.*" "C:\Users\Bruce\Documents\GitHub\sphere-sfml\Engine\Engine\bin\Release\"
if not exist "C:\Users\Bruce\Documents\GitHub\sphere-sfml\Engine\Engine\bin\Release\" md "C:\Users\Bruce\Documents\GitHub\sphere-sfml\Engine\Engine\bin\Release\"
xcopy /s /y "C:\Users\Bruce\Documents\GitHub\sphere-sfml\Engine\packages\ClearScript.V8.5.3.10.0\tools\native\amd64\*.*" "C:\Users\Bruce\Documents\GitHub\sphere-sfml\Engine\Engine\bin\Release\"" exited with code 4.


However, that was a post-build step, so the engine executable actually was generated and I was able to run it despite VS's protests.  Unfortunately, trying to run Spectacles with it threw this at me: "Fatal Error: Parameter not of type string or function: System.Int32"

Oh, and Visual Studio gave me an error about Packages.mdproj when loading the solution.
Title: Re: Sphere SFML v0.80
Post by: Radnen on March 19, 2014, 12:23:10 am
It's loading ClearScript for some weird reason. Despite the fact it's not loaded. I have a branch using ClearScript instead of Jurassic to test V8, it was loaded as a NuGet package. Packages.mdproj is a MonoDevelop/Xamarin thing, so VS won't recognize it. I'll delete my local git branch and re-clone to test what a fresh build looks like.

I'll try running specs through the engine and see what I can find.
Title: Re: Sphere SFML v0.80
Post by: Radnen on March 19, 2014, 01:21:32 am
Ok, I see it's SetDelayScript. I got the API call wrong, lol. It's frames first then the string. Also you use SetDelayScript(0, string) which is weird since it technically should not run... unless 0 in this case means immediate. In my SSFML it doesn't run unless you call it starting with 1. I'll definitely have to change this behavior.

I ran into a problem with Specs and Jurassic, it's a serious low-level issue. I got around it by fixing this area of Scenario:
Code: (javascript) [Select]

// from this: (line 147)
if (command.start != null) {
var parameters = [];
parameters.push(scene);
for (i = 0; i < command.arguments.length; ++i) {
parameters.push(command.arguments[i]);
}
command.start.apply(commandContext, parameters);
}

// to this:
if (command.start != null) {
var parameters = [];
parameters.push(scene);
parameters.concat(command.arguments);
command.start.apply(commandContext, parameters);
}


For some reason it was mistreating arguments. I'll have to isolate the issue and give a bug report to Jurassic. Anyways, concat is a better solution.

But then I get another issue:
Battle: definition 'undefined' doesn't exist!

BTW: my engine should compile normally now. ;)
Title: Re: Sphere SFML v0.80
Post by: Fat Cerberus on March 19, 2014, 01:53:19 am
That code was written early in Scenario's development, before I knew much of the JS standard library.  I'll definitely see about using concat for such cases in the future.

The undefined battledef is odd though, the latest commit works fine in Sphere 1.5.
Title: Re: Sphere SFML v0.80
Post by: Radnen on March 19, 2014, 01:58:08 am

The undefined battledef is odd though, the latest commit works fine in Sphere 1.5.


Hmm... I see. That happens when I move to concat to "fix" the problem. That's odd because concat should do functionally the same thing! Why is this happening!? What the heck is command.arguments??? It's definitely not of an array type.

Line 33 of scenario is of arguments type - not an array. Fix it like so:
Code: (javascript) [Select]
arguments: [].slice.call(arguments, 0),


Hmm, but that still doesn't fix it in SSFML.
Title: Re: Sphere SFML v0.80
Post by: Fat Cerberus on March 19, 2014, 02:08:06 am
You're right, it's not a proper array.  I just checked, and command.arguments is the exact arguments object passed to the function that enqueues the command.  Look at Scenario.defineCommand() to see it.  Am I doing something evil?

Regarding delays: Yes, the 0 means "as soon as possible", i.e. on next map update (I feel using 0 here is more of a guarantee of that than 1).  The only reason I defer at all is because the cutscene changes maps a couple times.  I found out the hard way that you can't change maps during a map load when using persist/analogue.

Edit: Ninja'd.  Not surprising given I'm using my iPhone to post! :)
Title: Re: Sphere SFML v0.80
Post by: Radnen on March 19, 2014, 03:03:48 am
Ok, I updated my Jurassic JS engine to latest version. It seemed to fix the array wonkiness with your scenario. Furthermore, I'm going to update Link to 0.2.10, which fixes a JS issue with array.splice - it should be array.slice. I don't know why Sphere 1.5 has this working for you, but this is a serious bug in Link, and *might* be why you crash sometimes.

So, I'll update SSFML again, update Link to 0.2.10 and then you should be good to go to run specs in SSFML. I was able to get it partially working. So hooray for me to load all that code and have it do something! :)

I'm now running into an issue both code and not code related. Let's just say the game works, but isn't displaying right. I don't know why... Add SSFML's Print(text) method to your JS-console's writeLine method to get real-time feedback, even if it seems stuck in a loop.

Edit: and both are done.
Title: Re: Sphere SFML v0.80
Post by: Fat Cerberus on March 19, 2014, 08:12:14 am
Just some feedback: Specs certainly gets much further than it did before, but is still unplayable on SSFML.  It won't accept input (I use the keyboard mappings defined by config.exe, are those implemented?), and the rendering is very wonky.  Screenshot attached.

Also, using concat like you do above is incorrect, and is what caused the undefined battle error.  concat returns a copy of the original array, it doesn't change it in-place.  Which is likely the reason I overlooked it when I wrote that code.
Title: Re: Sphere SFML v0.80
Post by: Radnen on March 19, 2014, 03:09:51 pm
I don't have config.exe-like key-mappings implemented yet, so that will definitely take me some time. About concat, yeah I forgot it copied the array silly me.

I really don't know what to say about the rendering. There's just so much code to sift through it could be anything, anywhere doing something. In isolation SSFML can run your kh2bar and should be able to draw all the other things I see, so it's just weird where it get's hung up. By adding SSFML's Print() function to your Console.writeLine() method, it seems to stop on calling headlessHorse.start(). Specifically where the textbox displays. I'll need to do more digging to see exactly what the culprit is.
Title: Re: Sphere SFML v0.80
Post by: Rahkiin on March 19, 2014, 05:47:42 pm
Maybe it is time so set up a Unit Testing framework for Sphere runtimes, and a big set of Unit Tests for those runtimes. Now we have Vanilla, SFML, TS and mine.
Title: Re: Sphere SFML v0.80
Post by: Fat Cerberus on March 19, 2014, 06:23:52 pm
Looking at what ultimately gets rendered, it looks like it might be a Z-ordering error.  This is reinforced by the fact that, if you turn on the console, you can see it show up for a split second at startup before being covered by the battle.

Z order is handled in Specs by having the threader sort the thread list by priority.  Threads.js might be a good place to start looking.

Edit: And I was right.  Screwing with the thread-sort function changes the order stuff is rendered in.  I believe I figured out the issue: Spidermonkey's Array.sort() must be stable, so threads with the same priority are rendered in order of creation (most recent last).  Jurassic's sort is not stable, and the expected Z-order gets shuffled as a result.  As it turns out, this was stupidity on my part: The JS standard doesn't specify whether Array.sort() is stable or not, so relying on stable behavior was foolish.  I should be able to fix it by using the threadID as a bias, similar to what I do in the turn predictor.

As for it hanging in headlessHorse.start(), that's because you didn't implement config.exe key mappings, so the textbox is waiting for the confirm key (A in config.exe) to be pressed, which never happens.

Edit 2: Biasing the thread sort doesn't seem to help.  I'm wondering if it's actually the reverse and SpiderMonkey sort is actually UNstable while Jurassic's is stable.  The unstable sort just happened to put the equal-priority renders in the right order, but the stable sort reveals the error...
Title: Re: Sphere SFML v0.80
Post by: Fat Cerberus on March 20, 2014, 02:36:51 pm
Okay, this is interesting: NOT sorting the thread list at all results in the exact same rendering order as with the sort, despite the thread priorities being different.  Is Jurassic's Array.sort() bugged?

EDIT: Yep, Array.sort is bugged.  Without the sort, everything gets rendered, but in the wrong order.  With it, some of the renderers get wiped out (set to null) and thus never get called.

EDIT2: Alright, I'm stumped.  Try this: Comment out the sort() calls in Threads.js and add a line that gives feedback after the for loop in Threads.renderAll().  For example, a Print() call.  You would think it would just keep printing the line over and over, once per frame, right?  It doesn't though--after a while it stops printing it, as if .renderAll() is returning before reaching that line.  There are no premature returns in that function, though...  That suggests infinite recursion (which would be a bug on my end), but unless Jurassic is allocating an ungodly amount of stack space, it should crap out within seconds, which it doesn't.

So yeah, this is really weird.
Title: Re: Sphere SFML v0.80
Post by: Radnen on March 20, 2014, 03:28:13 pm
Equal-priority is always undefined; you need a tie-breaker. I can't honestly say if Jurassic is at fault here since the specification doesn't really say what the ideal sort is, it's up to the implementer. I'll try some isolated tests and get back to it's creator. You might be on to something here.

I'll look at the other things later today.
Title: Re: Sphere SFML v0.80
Post by: Fat Cerberus on March 20, 2014, 03:32:12 pm
Even with the tie-breaker (the thread ID), I still had the issue of renderers getting null'd.  So yeah, definitely a bug somewhere.  And that other issue in my second edit is just bizarre...
Title: Re: Sphere SFML v0.80
Post by: Radnen on March 21, 2014, 01:07:33 am
All of my isolated tests pass. I too use a priority-based hooklist in Blockman and it uses Array.sort and it doesn't seem to fail. Time to use your Threads.js in a small demo project and see if it works or not. I also wonder if the rendering is due to my sprite-batched graphics backend... Could you be fooling it? That said, the array.sort method should never nullify anything.

Ok a small test, you'll need at least a test-map:
Code: (javascript) [Select]

RequireScript("Threads.js");

function Test() {
Threads.initialize();
Threads.createEntityThread(new Textbox("Hi, how are you?"));
MapEngine("testmap.rmp", 60);
}

function Textbox(text) {
this.wind = GetSystemWindowStyle();
this.font = GetSystemFont();
this.text = text;
}

Textbox.prototype.render = function() {
this.wind.drawWindow(16, 16, GetScreenWidth(), 64);
this.text.drawTextBox(16, 16, GetScreenWidth(), 64, 0, this.text);
}

Textbox.prototype.update = function() {
if (IsAnyKeyPressed()) return false;
else return true;
}


I don't think it's Array.sort() that's doing it, I mean it's really messed up. I get a green wash over everything, which is otherwise not possible with this code. And it doesn't draw the text.

Edit:
However if I change the update method to this, it seems to draw everything correctly but the text:
Code: (javascript) [Select]

Textbox.prototype.update = function() {
if (IsKeyPressed(KEY_ENTER)) return false;
else return true;
}
Title: Re: Sphere SFML v0.80
Post by: Fat Cerberus on March 21, 2014, 01:28:49 am
I guess it's possible I could be interacting badly with your rendering code, but all I know is, when I had the renderAll() method print out all the renderers, without the sort all the functions were intact, but after being sorted several of them were listed as null.  And like I said, if you remove the sort() call, everything gets rendered (this is best seen by commenting out the rectangles in BattleScreen.render and comparing the output with and without the thread sort).

The issue with it not reaching the end of renderAll() is very strange, too.  I did some tests, and that doesn't happen in vanilla Sphere, only in SSFML.

I don't know, all these glitches are very, very bizarre.

EDIT: Just saw your edit.  I'm on my phone so I can't test, but how does that test code even work?  You need to put updateAll and renderAll in the update/render scripts but it doesn't look like you did.  You shouldn't get ANYTHING being rendered in that case...

EDIT2: Ignore that edit, I'm an idiot.  Threads.initialize() sets the update and render scripts for you.  My bad :)
Title: Re: Sphere SFML v0.80
Post by: Radnen on March 21, 2014, 02:13:03 am
Wait.. do I know your own threaeding library better than you!? :P

So, I did find a bug in my code, two of them! One: IsAnyKeyPressed was exposed wrong. Two: It is true your code is competing with my rendering backend. Only on maps, however! It seems that the sprite-batcher is running out of order with the map itself. My Solution: run the map itself through the spritebatcher, so it's rendered behind any renderscript calls.

About the randomness in Threads.js, what is this void null thing? Can Jurassic understand that syntax? It could drop stuff here, it's the only other place things get set to null.
Code: (javascript) [Select]
	renderer = renderer !== void null ? renderer : null;
Title: Re: Sphere SFML v0.80
Post by: Fat Cerberus on March 21, 2014, 09:39:15 am
Little known fact: void is an operator in JS.  It sets whatever comes after it to undefined.  I did this as a precaution, to get around the fact that undefined can be assigned to (at least in earlier versions of JS, like SpiderMonkey, I believe the current standard forbids it however), which would screw up direct comparisons against undefined.  Most people use void 0, I prefer void null.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/void

And no, I just forgot that Threads.initialize() sets the render and updatescripts because at one point in development, it had to be done separately.  And I tend to forget implementation details after a while if I don't touch the code for a while; eventually, only the public API will stick in my mind.
Title: Re: Sphere SFML v0.80
Post by: Fat Cerberus on March 22, 2014, 11:33:52 pm
So did you ever figure out what was wrong?  I went back to Sphere 1.5 for now; nothing I do can coax the threader to work properly in SSFML.  So far I haven't seen any crashes, though, so maybe it was the slice/splice thing in Link causing it after all...
Title: Re: Sphere SFML v0.80
Post by: Radnen on March 23, 2014, 01:51:26 am
I haven't yet touched the engine. I'll do this now.

Good news! I may have it working! It's now saying GradientCircle is not found, which means not only am I drawing things correctly it's finally found the direct calls for rendering your GUI. Now I just gotta implement these extra draw calls and fingers crossed it should be good. I decided that the map engine is too big/complex for the sprite batcher, so it'll draw everything map-related first, then flush the sprite batcher just in time for the RenderScript() to run I think this is a good solution.

Edit:
Eureka! I did it! It's not perfect but pretty damn close. It all works, the text moves, elements pop in, etc. I don't think you were dropping renders, I think sort() is just fine in Jurassic. :)

The reason you were finding strange render issues had to with the fact render scripts were calling render scripts and this created recursion - precisely when a loop ran a scenario context in which you called RenderMap. But it didn't run the stack out since it operated in a loop that just drew stuff over and over to the screen. The update script would have been the real issue here and I put a block on it, to prevent it from recurring update and render map calls.
Title: Re: Sphere SFML v0.80
Post by: Fat Cerberus on April 04, 2014, 01:15:03 am
Damn, I just noticed your edit now, several weeks later, go figure.  I really wish the forum notified for edits...

But awesome that you got it working.  The render recursion makes sense, although why that only seems to happen in SSFML and not Vanilla Sphere I don't know.  I did recently start having issues with the threader in Vanilla Sphere however (specifically, my textbox's renderer sometimes randomly got called several minutes after the textbox was dead and gone, causing undefined variable errors), which led me to discover that the glitches was indeed on my end: As new threads are usually created during another thread's update, this causes the thread list to be re-sorted in the middle of traversing said list, leading to all sorts of weirdness.  The most benign manifestation of this was my battle engine sometimes calling its shutdown code twice (which has been a long-standing bug for a long time, and I never would have noticed except for my trusty console); however, as Sphere-SFML has shown, the consequences can be much, much worse.  I haven't yet figured out how to solve it yet.  My first thought was to defer thread registration until after the thread list has been fully traversed, but since individual threads can block (essentially causing Threads.updateAll to recurse), and my engine is built on that functionality, that won't work.  Can I maybe use Link for this?
Title: Re: Sphere SFML v0.80
Post by: Radnen on April 04, 2014, 05:14:56 am
Yeah, I should say SSFML only works up until it asks for player key input (unless you use a workaround for now).


Can I maybe use Link for this?


Yeah, but it doesn't make algorithm design a silver bullet. :P You'll have to come up with a way to do thread locking with semaphores or what-not, or a thread-level dependency resolution system. Or I guess you can have two arrays, one for the in-traversal array and the other for what to replace it with when finished. You just swap between the arrays like so when changes get made:

Code: (javascript) [Select]

var cur_stuff = [obj1, obj2];

// new_stuff is not ever looped through, preventing the 'creation in same loop' issue
// also new_stuff must contain same references to old_stuff, you'll see soon enough
var new_stuff = [obj1, obj2, obj3]; // here obj2 from cur_stuff added obj_3 (but to new_stuff)

// switch out to the array with the new stuff
if (changes_made) {  // ie: new_stuff.length > cur_stuff.length
    cur_stuff = new_stuff;
}

// then you can do deletions like normal, or whatever else you may want to do
// it is important that before this step new_stuff at least contains the cur_stuff
if (deletions_made) {
    cur_stuff.splice(deletion, 1);
}

// then reset new_stuff to do the process over again in case there are changes
// if there were no changes made, well the worst is nothing (cur = new) and it's like nothing happened.
new_stuff = shallow_copy(cur_stuff); // we need a new identity, but same object references

// feel free to optimize this, but I think the shallow_copy above is the real trick here. You want to work on the same data, you just want to run an array with elements you are sure are made to be executed during that cycle. I'm sure there are better ways of doing this, but I hope this code here makes for a seamless transition between thread lists behind-the-scenes.


Also, my engine is very slow when it runs your game -__-... you're testboxes render at 121FPS on my rig, but on Sphere they are like 600ish(?). Why must you draw to surfaces like that!? The way I particularly coded Sphere SFML, surfaces are very slow when modified in loops (but fast when modified outside of loops so they are only drawn when 'finished') it has to do with a lot of cpu->gpu bottlenecking that I can avoid if I were to go to straight-up hardware surfaces (which well, I'll need a more open GL library to do that first... maybe).
Title: Re: Sphere SFML v0.80
Post by: Flying Jester on April 04, 2014, 08:00:34 am

You'll have to come up with a way to do thread locking with semaphores or what-not, or a thread-level dependency resolution system.

Out of curiosity...why semaphores?


Also, my engine is very slow when it runs your game -__-... you're testboxes render at 121FPS on my rig, but on Sphere they are like 600ish(?). Why must you draw to surfaces like that!?


Some versions of Sphere 1.6 are even faster with surfaces than Vanilla Sphere. (http://rpgmaker.net/users/FlyingJester/locker/sphere16fj.zip)
Title: Re: Sphere SFML v0.80
Post by: Fat Cerberus on April 04, 2014, 11:42:54 am

Yeah, I should say SSFML only works up until it asks for player key input (unless you use a workaround for now).


Can I maybe use Link for this?


Yeah, but it doesn't make algorithm design a silver bullet. :P You'll have to come up with a way to do thread locking with semaphores or what-not, or a thread-level dependency resolution system. Or I guess you can have two arrays, one for the in-traversal array and the other for what to replace it with when finished. You just swap between the arrays like so when changes get made:


Obviously not, but the main issue is that threads can block, effectively causing Threads.updateAll to recurse and thus even if I delay thread creation until after a full traversal, that just shifts the problem down the rabbit hole one level, it doesn't actually fix it.  The main issue I was trying to solve with Link was this: Don't sort the thread list, just add to it, and then create a sorted array using Link on demand at render time.  I actually ended up doing this, though I'm not sure how much of a performance hit I'm going to take by doing so.


Code: (javascript) [Select]

var cur_stuff = [obj1, obj2];

// new_stuff is not ever looped through, preventing the 'creation in same loop' issue
// also new_stuff must contain same references to old_stuff, you'll see soon enough
var new_stuff = [obj1, obj2, obj3]; // here obj2 from cur_stuff added obj_3 (but to new_stuff)

// switch out to the array with the new stuff
if (changes_made) {  // ie: new_stuff.length > cur_stuff.length
    cur_stuff = new_stuff;
}

// then you can do deletions like normal, or whatever else you may want to do
// it is important that before this step new_stuff at least contains the cur_stuff
if (deletions_made) {
    cur_stuff.splice(deletion, 1);
}

// then reset new_stuff to do the process over again in case there are changes
// if there were no changes made, well the worst is nothing (cur = new) and it's like nothing happened.
new_stuff = shallow_copy(cur_stuff); // we need a new identity, but same object references

// feel free to optimize this, but I think the shallow_copy above is the real trick here. You want to work on the same data, you just want to run an array with elements you are sure are made to be executed during that cycle. I'm sure there are better ways of doing this, but I hope this code here makes for a seamless transition between thread lists behind-the-scenes.



That's an interesting idea, I might consider it if Link turns out to be too much of a performance hit.


Also, my engine is very slow when it runs your game -__-... you're testboxes render at 121FPS on my rig, but on Sphere they are like 600ish(?). Why must you draw to surfaces like that!? The way I particularly coded Sphere SFML, surfaces are very slow when modified in loops (but fast when modified outside of loops so they are only drawn when 'finished') it has to do with a lot of cpu->gpu bottlenecking that I can avoid if I were to go to straight-up hardware surfaces (which well, I'll need a more open GL library to do that first... maybe).


I did it that way because that was the only way I could figure out to get the effect I wanted.  If you slow down the effect, you can see that it's not really a typewriter effect like in most games, but a sweeping fade. I don't believe there's any way I can do that without surfaces.
Title: Re: Sphere SFML v0.80
Post by: Radnen on April 04, 2014, 03:16:31 pm


You'll have to come up with a way to do thread locking with semaphores or what-not, or a thread-level dependency resolution system.

Out of curiosity...why semaphores?


I think they would have been easy enough to implement in raw software. I mean I guess spin-locks would be okay too, with busy-waiting. But it's still impossible to have/mimic atomic locks.
[/quote]



Also, my engine is very slow when it runs your game -__-... you're testboxes render at 121FPS on my rig, but on Sphere they are like 600ish(?). Why must you draw to surfaces like that!?


Some versions of Sphere 1.6 are even faster with surfaces than Vanilla Sphere. (http://rpgmaker.net/users/FlyingJester/locker/sphere16fj.zip)


I tried it out and the framerate was inconsistent, drew polygons wrong, and dropped certain renders altogether. Have you tried testing FJ-GL on the actual games repo?
Title: Re: Sphere SFML v0.80
Post by: Flying Jester on April 05, 2014, 02:37:47 am
I tried it on KR, the Particle of Infinite Free Will, Entropy, and Hold the Line (among anything else I've tried out since January), along with all the demos included with 1.6, and it seems to work perfectly. I currently use it exclusively.

Did you try it since I fixed the miscoloration (and added Bezier Curves, it was all in the same release)? The miscoloration, dropped frames, and bad vertices were all the same issue, basically (bad shader for GL 2.0 and greater).
Title: Re: Sphere SFML v0.80
Post by: Radnen on April 05, 2014, 04:02:39 am
I tried the release you linked to here. :P I tried the Sphere 1.6 collision demo with the polygon shapes, and they were missing sides (the demo still worked since technically the shapes' pixels aren't used in the collision - just their vertices). I then tried it on my Hold the Line 2 game (which I ought to upload and share soon) and the background turned white on some frames, and in other frames the fps went between 1200's and 48 (unthrottled). I will admit that it's only so much faster, SSFML rendered HotL2's background in the 2000's fps range.

Look, if your FJGL is more stable than Sphere 1.6's current drivers then that's amazing. My only issue with 1.6 so far is the occasional crash due to memory mismanagement or whatever (it might not even be at the driver level).
Title: Re: Sphere SFML v0.90
Post by: Radnen on January 04, 2015, 04:25:19 pm
I fixed a lot of little bugs and completely added TCP networking support. To demonstrate, here is an image. I haven't uploaded the code yet, but soon I'll release another version of this engine. It can play quite a few more games now. Also, it mostly handles Lithonite.js by FBN which is a huge success since Lithonite uses a lot of features intrinsic to the map engine and player bases (I say mostly since I still need to do a thorough test, but all my games that use it for it's basic features and deobstructioning all work).

So, yeah, basically I've taken some time to work on this. :)

Edit:
About the networking. I'm not using SSFML for client and server. I'm running a Node.js TCP server in the background that handles the broadcasting of events. Since it's Node.js I can create game state files the client and server can share since they are all written in JS. I've noticed far better performance doing it this way (I should have done it like this in the past when I dabbled with networking games earlier, like that Pokémon game). Technically, SSFML can be used for server, but much like Sphere it's be a huge waste since I have not yet programmed a "server-only" version of SSFML, so there's lots of waste going on if you do use it as a server. But I am using SSFML here as a TCP client, reading and writing to a socket using the exact same API as Sphere. The demo below looks exactly the same in Sphere 1.5 as it does in SSFML, but in SSFML there is far less lag since on the JS side of things there is a far better speed improvement when reading and writing to sockets over Sphere 1.5. There's simply no lag. :)
Title: Re: Sphere SFML v0.90
Post by: DaVince on January 05, 2015, 06:25:09 am
Looking good. Makes sense that Node.js is a good match for Sphere.
Title: Re: Sphere SFML v0.90
Post by: Fat Cerberus on January 05, 2015, 11:19:01 am
Are these changes on GitHub, or...?
Title: Re: Sphere SFML v0.90
Post by: Radnen on January 05, 2015, 08:06:33 pm

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. :)
Title: Re: Sphere SFML v0.90
Post by: Fat Cerberus on January 06, 2015, 01:07:13 pm
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
Title: Re: Sphere SFML v0.90
Post by: Radnen on January 06, 2015, 08:15:23 pm
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.
Title: Re: Sphere SFML v0.90
Post by: Radnen on January 20, 2015, 01:19:07 am
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.
}
Title: Re: Sphere SFML v0.90
Post by: DaVince on January 20, 2015, 07:13:31 am
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.
Title: Re: Sphere SFML v0.90
Post by: N E O on January 20, 2015, 03:21:12 pm

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.
Title: Re: Sphere SFML v0.90
Post by: Radnen on January 20, 2015, 09:10:50 pm
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.
Title: Re: Sphere SFML v0.90
Post by: Fat Cerberus on February 15, 2015, 09:56:25 pm
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.
Title: Re: Sphere SFML v0.90
Post by: Radnen on February 16, 2015, 12:03:06 am

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.
Title: Re: Sphere SFML v0.90
Post by: Fat Cerberus on February 17, 2015, 12:29:50 am

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...
Title: Re: Sphere SFML v0.90
Post by: Radnen on February 17, 2015, 02:41:08 am

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!
Title: Re: Sphere SFML v0.90
Post by: Radnen on March 28, 2015, 06:10:23 pm
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. :/
Title: Re: Sphere SFML v0.90
Post by: Fat Cerberus on March 28, 2015, 07:14:03 pm
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.
Title: Re: Sphere SFML v0.90
Post by: Radnen on April 18, 2015, 10:41:30 pm
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.
Title: Re: Sphere SFML v0.90
Post by: Fat Cerberus on April 18, 2015, 11:07:04 pm

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.
Title: Re: Sphere SFML v0.90
Post by: Radnen on April 19, 2015, 02:39:16 am

Oh definitely, Duktape can never hope to even touch Jurassic without a JIT...


Oh I know, it's just weird to see Jurassic take so long on this. It's just weird. And don't worry about speed (I do because I'm weird like that). You actually have the best engine so far! :P

I've put out a word on Jurassic, see if he gets back to me about that, but I'm not sure it can be helped. He is slowly adding ECMA6 features to it though, so I guess there will be a newer version... sometime.

In the meantime, if I want to continue this engine I'm going to have to think more critically about supporting Lithonite to it's fullest and other quirks I've noticed thus far... but at this point I'm not sure what the benefits are of Jurassic and SFML? I can barely get it to run on Windows and cross platform is just not going to happen anytime soon. <sigh>
Title: Re: Sphere SFML v0.90
Post by: FBnil on June 07, 2015, 10:17:13 am
I applaud your efforts Radnen, but yes, if we are going to pull off another release, we will need consensus about the engine (the editors, I like them to be numerous, as each user using them can see which one is more comfortable. For *.js coding I do not use the editor, I use notepad++, the graphics I edit in other programs, and paste them into the editor. Especially with fonts, where I export to a PNG, edit it, then use a converter program to put that back into a .fnt file. While other would prefer to only use one tool...). But the engine... we should concentrate efforts on one. Especially because our numbers are dwindling.

As you might remember, the big problem with 1.6 was stability of the build. I was never able to duplicate the stability 1.5 had.... even with 1.5 sources. Which meant that the MSVC compiler was either buggy, or I could not find the perfect settings. Even after rewriting parts to remove warnings, the build was never stable. A shame too, I saw Anatoli write the best optimized code for displaying. And was in awe at what the particle engine could accomplish.

I guess goals are lower now, and it is to recreate the Sphere 1.5 functionality. But we have 3 options:

1. Keep going with the 1 man - 1 Sphere fork. I can help with the requested test cases, will start this week.
2. Choose one, and work together on that one to get it up to par. (basically what the Verge team did with IKA)
3. change scope and hope for new users and developers. (very hard to pull off)

I like the fact you are using node.js as networking glue. I like the fact Sphere had networking, and somebody actually made a webserver back in the day....  (doing what node.js does now, but way earlier)
Sphere still is unique. It works like imagemagick, in that you can generate graphic images with external data. Ten years ago, I created performance graphics that way at work. (combined with irfanview batch processing to convert the graphics to smaller jpg's (both in size as well as dimensions))
It works as javascript test case software. Where I coded ITM5 monitors (IBM Tivoli Framework) in Sphere. Using mock input, and knowing the expected output, I used it as testcase-first programming. Then moved the tested functions into the monitor template, builded it, and did the real test with real data. As I could program it everywhere, I could work on the train, and test each change with arrow up + enter (commandline sphere). Fast iteration = Very productive hours.
Granted, there is better software now to do what I did back then with Sphere, but it was used that way, by me, on purpose.
Oh, and a primitive mathjs viewer, where you could actually display values, plot them or save them to file. But now, browsers have come a long way: http://mathjs.org/examples/browser/plot.html

My  main question (better asked in another post, but why not here) is if we have to put efforts into the main branch... making it compatible with the new JS, which has renamed quite a few functions... at least to try to see if it is fast as V8?
Title: Re: Sphere SFML v0.90
Post by: Fat Cerberus on June 07, 2015, 10:36:18 am
The old engine is ancient, not just the SpiderMonkey but the engine itself.  It uses old-fashioned rendering methods which make it inefficient on modern hardware.  Better to put the work into, say, minisphere or TurboSphere which are modern (the former of which is feature-complete with Sphere 1.5) than trying to hammer the old engine back into shape.
Title: Re: Sphere SFML v0.90
Post by: Flying Jester on June 09, 2015, 01:14:06 pm

My  main question (better asked in another post, but why not here) is if we have to put efforts into the main branch... making it compatible with the new JS, which has renamed quite a few functions... at least to try to see if it is fast as V8?


I wrote about my thoughts on this in the Sphere 1.5/1.6 thread. TurboSphere has my experimental work, some of which influenced MiniSphere. MiniSphere is a simpler but still fully featured reimplementation of Sphere, which has better performance. It's tempting to try and modernize the old engine, but not that tempting. For me, at least.

If you want help with integrating newer SM (like SM 40) and either my or Chad Austin's Corona forks into the old engine, I would be quite willing to help! I would also like to help switch to OpenAL rather than Audiere. But I don't want to be the maintainer of the original engine.

I would also gladly help make TurboSphere plugins of parts of the old engine, like the particle engine.

...On V8 and SM...

SM is actually faster than V8 is now. It's quite possible they will leapfrog again. But V8 is a huge mess. It has fundamental flaws that make poorly suited for anything but Chrome (and even then it's questionable). It has a demented build process and its API radically changes every release.
SpiderMonkey is quite comparable, if not better performance, and is a much better designed (and redesigned) VM. That's why I ditched V8 for SpiderMonkey in TurboSphere. It was worth throwing away years of V8 knowhow. V8 is just that messed up.
Title: Re: Sphere SFML v0.90
Post by: Rukiri on June 19, 2015, 04:10:44 pm
I don't post here often, just came to say hi!

Nice work on modernizing sphere, but now that it has sphere 1.5 features wouldn't it be best to move onto other "new" features that have been talked about oh since 2003 but never added?
Title: Re: Sphere SFML v0.90
Post by: Fat Cerberus on June 19, 2015, 04:53:00 pm
See minisphere for that.  It has a bunch of new stuff not available in 1.5. ;D