Skip to main content

News

Topic: neoSphere 5.9.2 (Read 521823 times) previous topic - next topic

0 Members and 6 Guests are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.2.3
Reply #585

I just realized I may be able to fix the "invalid base value" issue when variables are declared overwriting Sphere constructors.  I don't actually have to--it's a very bad practice I don't like to condone, but Duktape's error message for it is so obtuse that working around it is actually preferable at this point.


And... it's fixed as of the latest master commit. ;D
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • FBnil
  • [*][*]
Re: minisphere 1.2.3
Reply #586
continue: FBnil was trying to install from source MiniSphere on his brand new Debian8 upgrade.

Ok, got it running.

Debian installs Allegro in /usr/lib/x86_64-linux-gnu/ and those were 5.0.10 and overruled the 5.1.10, so after a
Code: [Select]
apt-get remove liballegro5.0:amd64
it finally compiled! Checking the fog demo... nice work! However, still buggy. You see, the fog layer also needs to stay in sych with the background layer, so if I move, it is not scrolling in respect of the player, but of the other background.
So starting the fogdemo, when I move left/right, the fog seems to be following the player, instead of following the ground.

MiniSphere Source is clean and understandable. Still need to peruse it to commit an index map into memory. I like what I have seen so far! Kudo's Bruce!

I am impressed with duktape. At under 3Mb uncompressed source, compared to the 20Mb bz2 compressed tarball from spidermonkey.

edit: Also, duktape has been updated: 2015-06-02   duktape-1.2.2.tar.xz   maintenance release (http://duktape.org/download.html)

1.2.2 (2015-06-02)

    Fix harmless MSVC warnings when using DUK_OPT_FASTINT on x86 (GH-172)
    Fix compile error from array fast path when using low memory options (GH-174)
    Fix harmless MSVC warnings for size_t casts on x64 (GH-177)
    Fix potential NULL pointer dereference in duk_is_dynamic_buffer() and duk_is_fixed_buffer() when index is outside of value stack (GH-206)


Oh noes! No ColorMatrix objects!
  • Last Edit: June 10, 2015, 05:17:09 pm by FBnil

Re: minisphere 1.2.3
Reply #587

The layer bug could have been fixed earlier if you had filed a bug, I would say.


To be honest, I didn't realize it was a bug at first, I thought it seemed intuitive enough that it did that. Didn't even think to check it on 1.5, since I was writing a game from scratch targeted at minisphere anyway. It wasn't until I saw your issue that I thought to check it.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.2.3
Reply #588
 @FBnil
I'm pretty sure minisphere should render the fog the same as Sphere 1.5.  At least it looked that way in my tests.  Are you sure you have the latest master from GitHub?  I'm also already using Duktape 1.2.2.  If the copy in your source is older, you have an outdated minisphere build.

As for ColorMatrix objects, I'll add those to the list for the upcoming 1.3 release.  I knew I was missing something!
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: minisphere 1.2.3
Reply #589
I haven't been as excited about Sphere in general as I am now. Getting back into the swing of things. Once vacation starts, I'm going to enjoy figuring out those new functions and making a game!

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 1.2.3
Reply #590
What are we doing wrong with OpenGL? I knew there's something messed up about how we are implementing OpenGL, because if you think about it, it can be used to display vast fully-realized high fidelity 3D scenes in 60fps, but we can barely make it all of our engines run more than 20000+ 2D entities on screen at the same time, quickly.

Take for instance this stupid WebGL test, (it's by no mean 'stupid'): http://www.goodboydigital.com/pixijs/bunnymark/

I can render 200000 - two hundred thousand - dancing bunnies and still got 60fps out of the rendering window!! If there are 4 vertex points per object, then we have 800000 verticies, which is still less than a typical 3D scene has on screen. A good PC can handle billions of vertices per second. But, let's say your computer can handle 1 billion verts on screen per second, that makes 800000 verts take only .0008s or .8ms, plenty of room to handle 16.67ms of time per frame. So of course this runs at 60fps. I'm just shocked we can't get this performance out of our native engines. Is Chrome's V8 coupled with WebGL really that damn fast?

I'm doing everything in the book right with my SphereSFML. I'm sending 1 batch of vertices to the pipeline, with a single base texture (atlas, sprite batch, etc.) and I can't get anywhere close to 60000 at 60fps, let alone 200000! And I'm doing some basic logic rather than just dead, simple images (I'm rotate blitting them).
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: minisphere 1.2.3
Reply #591
I tested the bunny thing, I got to about 20,000 bunnies before the framerate started dropping off, and it actually started to hiccup before that, around 10,000.  Of course this is with the iGPU in my AMD A10-6800K, so I'm sure I could get more bunnies with an actual graphics card.  Full disclosure: Firefox.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.2.3
Reply #592

Oh noes! No ColorMatrix objects!


See here:
https://github.com/fatcerberus/minisphere/commit/a14d2b2bd0c6c2648634b141587cc91c5178d93a

Everything is now implemented except for surface.applyColorFX4() because I haven't figured out how to bilinear-interpolate the matrices yet.  I'll have to look at the Sphere 1.6 source again.

Edit: Holy crud, ApplyColorFX4() is a beast of a function, I have no clue what it's even doing!  It does some crazy interpolation not only on the matrices, but on the pixels themselves.  applyColorFX() was easy, but this... well, remember how I said I wouldn't use code I don't understand?  Yeah, this is a perfect example. :P  I will have to study it a bit more, I'm not just going to paste it in.
  • Last Edit: June 11, 2015, 12:00:37 am by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 1.2.3
Reply #593

I tested the bunny thing, I got to about 20,000 bunnies before the framerate started dropping off, and it actually started to hiccup before that, around 10,000.  Of course this is with the iGPU in my AMD A10-6800K, so I'm sure I could get more bunnies with an actual graphics card.  Full disclosure: Firefox.


On chrome I got 200000(60fps), on Firefox I get 200000(50fps). I notice the test dips more under Firefox, meaning Chromes V8 is indeed faster in a real example or they have a more optimized WebGL context(?). I have a really nice Nvidia GPU, the GTX970 which didn't cost me a whole lot compared to the 980 or the 980ti (which is an inane amt of cash for such little more power1).

It's just weird, that's all. It might be the overhead, and I think it's the Sphere API calls. I think web has a better, leaner link between the OpenGL and the JS.

1. http://www.newegg.com/Product/Productcompare.aspx?Submit=ENE&N=100007709%20600536049&IsNodeId=1&bop=And&CompareItemList=48%7C14-487-087%5E14-487-087-TS%2C14-487-142%5E14-487-142-TS%2C14-487-088%5E14-487-088-TS&percm=14-487-088%3A%24%24%24%24%24%24%24
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: minisphere 1.2.3
Reply #594
The Sphere API is probably it.  A JS function call is much, much more expensive than a native call no matter how you slice it, for a lot of reasons.  arguments object creation is a big one - this document from the Duktape repo was very enlightening and an interesting read:
https://github.com/svaarala/duktape/blob/master/doc/arguments-object.rst
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.2.4
Reply #595
I decided the "invalid base value" fix was too important to hold it back until 1.3 and backported it.  So, well... minisphere 1.2.4 is available for download. :)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • FBnil
  • [*][*]
Re: minisphere 1.2.4
Reply #596
Thanks L.E. did a git pull. Now my techdemo complains that the code is not "strict" enough (back to that then, make all my libs compatible with MS).
And thanks for looking at those ApplyColorFX4() is useful though, as a crud way to emulate lights and shadow.
I do remember there was an explanation for it somewhere. Do you even sleep? I sleep and there are so many messages.

Meanwhile, I used tcc to compile some of the examples of duktape. Then compress them with upx. tcc has its limitations, gcc -os (compile and make the smallest size) is still way better at making smaller files.

"Drunken Wee master" needs BezierCurve .... was that even a function? ... yes... yes it was...
"surface.bezierCurve(c,step,x1,y1,x2,y2,x3,y3,x4,y4) ". I do not even remember these functions...


@Radnen: Maybe you create and destroy object calls each loop? Maybe you require a table where you keep them alive each loop?

@DaVince: Yay! new game from DaVince comming up!

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.2.4
Reply #597
I have... odd sleep patterns.  And rest assured applyColorFX4() is getting implemented.  I figured it out once I started reimplementing it what it was doing, it's simple bilinear interpolation on the individual cells of the 4 matrices.  The way the code is written in Sphere 1.x doesn't make that obvious though.  Needless to say, my version will be much better annotated. :D

Not sure what that "not strict enough" thing is about... Sounds weird.

Bézier curves might be more difficult though.  The thing is, I don't really understand the math behind them and Allegro doesn't (to my knowledge) have a function built in to draw them.

Edit: As of about 5 minutes ago, applyColorFX4() is implemented.  I'm thinking my implementation may not be the fastest thing ever, Sphere does some weird thing with bitshifts that I don't quite understand, and I use fmin/fmax to clamp the pixels, which is probably a massive performance hit (doing int->float->int several times for every pixel has to take a toll).  The base code should be very easy to follow though:
https://github.com/fatcerberus/minisphere/blob/1fe34c2d603a5c49613db212c53ca8a1d3e2ccb7/src/image.c#L318-L381
  • Last Edit: June 11, 2015, 07:50:15 am by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: minisphere 1.2.4
Reply #598
The BunnyMark only gets me as far as ~35000 bunnies before the FPS starts dropping, but then again I'm on a notebook with an NVIDIA GT540m and a 2Ghz Sandy Bridge CPU, so not exactly the most exciting thing.
For me, as long as games perform well, I'm happy, and in that regard minisphere is doing a lot better than original Sphere. (There is a level in Sir Boingers that starts lagging out once I add only a few more cupcakes; minisphere uses about 50% on a single thread at that point and 17% more on another.)

Quote
@DaVince: Yay! new game from DaVince comming up!

Whoa. I'm humbled. :> Now how about you make one again too? I liked your old games and demos. :)

Re: minisphere 1.2.3
Reply #599

What are we doing wrong with OpenGL? I knew there's something messed up about how we are implementing OpenGL, because if you think about it, it can be used to display vast fully-realized high fidelity 3D scenes in 60fps, but we can barely make it all of our engines run more than 20000+ 2D entities on screen at the same time, quickly.


Three really important things I know I don't do are instancing, geometry/compute shaders (or Cuda/CG interop), and LOD.

Either way, TurboSphere can push 50,000 shapes and stay at 60(ish) FPS (So still more efficient than the BunnyMark on my machine). More or less vertices, depending on how they are divided between shapes and groups. I would highly suspect that's because I use OpenGL 4, which means that the single Group.draw() call to draw all those shapes results in only a fraction that many OpenGL calls. This is why the Galileo API is the way it is. It stops you from needing thousands of calls for thousands of sprites. That's also why I dropped the old API altogether. It's really not how OpenGL or D3D or any modern rendering technology works, and it shows.

But we will always be slower than dedicated 3D engines. They will always have specific functions built in, which the engine can be optimized for at the cost of flexibility. I'm more content to lose a little performance be be generally useful :)