Skip to main content

News

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

0 Members and 3 Guests are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere SFML v0.65alpha
Reply #90
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.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

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

Sphere-sfml here
Sphere Studio editor here

Re: Sphere SFML v0.65alpha
Reply #92

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 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?

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.65alpha
Reply #93


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.  ::)
  • Last Edit: July 25, 2013, 08:17:44 pm by Radnen
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

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

Re: Sphere SFML v0.65alpha
Reply #95

@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.

Re: Sphere SFML v0.65alpha
Reply #96
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, 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).

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere SFML v0.65alpha
Reply #97
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...
  • Last Edit: July 26, 2013, 02:39:39 pm by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

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

Sphere-sfml here
Sphere Studio editor here

Re: Sphere SFML v0.65alpha
Reply #99
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?

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.65alpha
Reply #100
@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.
  • Last Edit: July 29, 2013, 01:16:10 am by Radnen
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Sphere SFML v0.65alpha
Reply #101

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).

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

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

Sphere-sfml here
Sphere Studio editor here

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere SFML v0.65alpha
Reply #104

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