Skip to main content

News

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

0 Members and 20 Guests are viewing this topic.
  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.6.0
Reply #1755

OH!  You also have to set DUK_OPT_HAVE_CUSTOM_H I think.  I've made that mistake before, too (you'll want to define that for the normal build too or glitches may happen)
Fixed :)

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.6.0
Reply #1756
Surfaces now support setting a transform, allowing projections to be used in Render-to-Texture operations:
https://github.com/fatcerberus/minisphere/blob/master/docs/sphere2-core-api.txt#L894-L903

Now I'll have to give it a workout by getting it to draw a cube. :D

The implementation could probably be optimized better, but it gets the job done and works as designed.  The specific issue is that the engine explicitly sets the render target for every drawing operation.  That probably isn't a big deal in practice for most 2D games but won't scale well at all for more advanced 3D.  From what I've seen Allegro tries to lighten the load a bit by avoiding state changes if they can be avoided (reusing shaders and whatnot), but the way the engine is set up, it also explicitly swaps out the modelview and projection matrices every time, which entails a lot of uploading matrices to the GPU.  That kind of thing can't be good for performance. :P

edit: @Rhuan: By the way, when you say "fixed", do you mean that SSJ works now...?
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.6.0
Reply #1757

Surfaces now support setting a transform, allowing projections to be used in Render-to-Texture operations:
https://github.com/fatcerberus/minisphere/blob/master/docs/sphere2-core-api.txt#L894-L903

Now I'll have to give it a workout by getting it to draw a cube. :D

The implementation could probably be optimized better, but it gets the job done and works as designed.  The specific issue is that the engine explicitly sets the render target for every drawing operation.  That probably isn't a big deal in practice for most 2D games but won't scale well at all for more advanced 3D.  From what I've seen Allegro tries to lighten the load a bit by avoiding state changes if they can be avoided (reusing shaders and whatnot), but the way the engine is set up, it also explicitly swaps out the modelview and projection matrices every time, which entails a lot of uploading matrices to the GPU.  That kind of thing can't be good for performance. :P

Sounds like good work, well done.

On the performance point, if you're redrawing something surely there's a good chance it's moved and hence you need to change a matrix?

Quote
edit: @Rhuan: By the way, when you say "fixed", do you mean that SSJ works now...?
Yes that is what I meant sorry for being unclear.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.6.0
Reply #1758
The modelview matrix (Shape#transform) of course changes for every object drawn, but there's no need to set the projection matrix and render target every time.  In most cases those are going to be the same throughout a frame.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.6.0
Reply #1759
After the feature-packed release of miniSphere 4.6, I'm taking a break from adding more features to do some internal refactoring.  A lot of the original code doesn't match current naming conventions and coding style, and internal objects don't always align with their "official" names in the API, making them harder to find at a glance.  So I'm taking the time to get things up to speed and hopefully make the code a bit easier to maintain going forward.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.6.0
Reply #1760
The Socket API is getting an overhaul.  Instead of a Socket object there will be Client and Server objects.  Server works as before, but Client is reusable and you'll be able to connect it to a different host at any time, or reconnect it if it gets disconnected.  It's kind of annoying that you can't currently reuse a socket that got disconnected.  I know that's normally how BSD sockets work, but Sphere should be at a bit higher level than that.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.6.0
Reply #1761
I was browsing your github and saw https://github.com/fatcerberus/minisphere/issues/153

Are you still thinking of replacing duktape? How big a job would it be?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.6.0
Reply #1762
That's a big reason for the recent code refactorings, actually -- I'm trying to decouple the actual implementation of the engine parts from the JS hooks so that swapping out JS engines in the future is just a matter of rewriting the hooks.  If you look at most of the Sphere v1 implementation in vanilla.c, the JS functions do a lot of actual work themselves and they shouldn't.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.6.0
Reply #1763
What would the benefits be of swapping the JS engine, is it just about access to newer features or is it about speed or some combination?

(I haven't run into any real speed problems in miniSphere apart from:
a) the galileo ones you've fixed for your next release and
b) when I wrote a stupid piece of code that called array.sort on an array with 50 elements 50 times per frame - and yes I mean per frame not per second...).

Largely unrelated point - what's your current planned release date for v5? I'd like to have the sprite/map/collisions pieces I'm working on ready before v5 but I've been super busy at work recently and am going to be going away for a bit soon so will likely not be able to get them finished until late august at the earliest.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.6.0
Reply #1764
I have quite a backlog of stuff to implement for 5.0 so it won't be for a while.  See the v5.0.0 tag in github issues for the full list.

As for changing the JS engine, a big benefit would be support for ES6+ syntax without transpiling.  That would lighten the learning curve for beginners because they wouldn't have to learn to use Cell right away.  Also it would likely be much faster for CPU-bound tasks.  You could get more done between frames, for example.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.6.0
Reply #1765
Starting with miniSphere 4.7, the engine will require a shader-capable GPU to start.  Even Intel HD Graphics has supported shaders and the like for years now and about the only thing that doesn't are crappy XP-era Intel chipsets.  Those are veritable dinosaurs these days and if someone still wants to make games for them, well, Sphere 1.5 is still floating around. ;)

Mainly, my motivation is to get rid of all the untested code to support older hardware.  For example if a shader-ready GL context can't be created then the engine disables shaders, creates a fixed-function context and uses slightly different code paths for rendering.  Or if vertex buffers aren't supported, the vertices are kept in a memory buffer instead.  Pretty much all modern machines support these features so it just adds up to a lot of legacy-compatibility code that never gets tested.  Better just to remove it and require a modern machine for a modern engine.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.6.0
Reply #1766

Starting with miniSphere 4.7, the engine will require a shader-capable GPU to start.  Even Intel HD Graphics has supported shaders and the like for years now and about the only thing that doesn't are crappy XP-era Intel chipsets.  Those are veritable dinosaurs these days and if someone still wants to make games for them, well, Sphere 1.5 is still floating around. ;)

Mainly, my motivation is to get rid of all the untested code to support older hardware.  For example if a shader-ready GL context can't be created then the engine disables shaders, creates a fixed-function context and uses slightly different code paths for rendering.  Or if vertex buffers aren't supported, the vertices are kept in a memory buffer instead.  Pretty much all modern machines support these features so it just adds up to a lot of legacy-compatibility code that never gets tested.  Better just to remove it and require a modern machine for a modern engine.
Makes sense - particularly in light of the things you can do with Shaders and Galileo - running in no-shader mode would make the output significantly different for any of my Galileo using code, and assuming we get other people into using this stuff, likely for there's too - so supporting it is just a bad idea.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.6.0
Reply #1767
I'm going to add a legacy support module like legacy.c or something to the source code.  In the process of refactoring the internal sockets code, I realized that the Sphere v1 sockets implementation depends on some "magic" behavior of the socket object (i.e. a server socket magically transforms into client upon first connection), which I then had to work around with special cases in the v2 implementation where that behavior is undesirable.  Removing the magic behavior from the internal socket object of course breaks the v1 API.  I think it would be better to separate legacy support code into its own module so it can't hold back the implementation of new stuff anymore.

Oh, I implemented clipping for surfaces.  In 4.7 you'll be able to call surface.clipTo(x, y, w, h) to restrict drawing to the specified region of the surface.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: miniSphere 4.6.0
Reply #1768
There's a reason that I had proposed for Pegasus (and implemented in TurboSphere) clients and servers explicitly being different (a Socket and a Listener).

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.6.0
Reply #1769

There's a reason that I had proposed for Pegasus (and implemented in TurboSphere) clients and servers explicitly being different (a Socket and a Listener).


Yep, I did the same in Sphere v2 (Server and Socket in my case).  it's just that because I fully support the legacy API too, I ended up implementing "magic sockets" as a feature of the internal socket object, as a special case (because it would have been even more complicated to implement it at the JS interface layer).  Since the "magic" behavior can easily be implemented on top of a more traditional setup though, it'll be easy to refactor it out into its own legacy section of the codebase.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub