Skip to main content

News

Topic: Sphere 5.5.2 (previously miniSphere) (Read 418295 times) previous topic - next topic

0 Members and 2 Guests are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1710
If it helps, here's a comparison of the implementations of FlipScreen() and screen.flip():
v1: https://github.com/fatcerberus/minisphere/blob/v4.5.11/src/minisphere/vanilla.c#L1851-L1856
v2: https://github.com/fatcerberus/minisphere/blob/v4.5.11/src/minisphere/pegasus.c#L1224-L1230

The only difference is the framerate variable used, which for v1 defaults to 0 (unlimited) while screen.frameRate (v2) defaults to 60, and that screen.flip() resets the clipping rectangle afterwards.  So maybe the lack of frame limiting in v1 by default was what was causing your issue?
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1711
Idea for new feature: 3D rendering, complete with projection support, camera, etc.  Sphere has always been a 2D engine, but it would be a nice bonus if we could also do basic 3D stuff with it.  Things like loading model files, etc. could be added in time.
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: miniSphere 4.5.11
Reply #1712
I wonder if a maximum frame rate shouldn't be enforced even in v1, like eg. a default frame rate of 240 or so. I've managed to lock my entire system up once just by accidentally getting it stuck in an infinite loop. (Note: I don't remember how it happened, just THAT it happened.)

...Actually, scratch that. That might have been a loop without any rendering/flipping going on at all. I dunno. Just something was weird.

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.5.11
Reply #1713

Idea for new feature: 3D rendering, complete with projection support, camera, etc.  Sphere has always been a 2D engine, but it would be a nice bonus if we could also do basic 3D stuff with it.  Things like loading model files, etc. could be added in time.
I was going to ask for 3D the other day, doesn't feel like the API needs much expansion (other than allowing us to fiddle with transformations more as already mentioned) the main thing that would need work I guess is the rendering code under the hood.

As in you can already set Z coordinates BUT if you keep them between +1 and -1 they seem to do nothing and if you go outside of that range then the shape isn't drawn.

Re: miniSphere 4.5.11
Reply #1714
Is it currently possible for a game to set the window icon?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1715

As in you can already set Z coordinates BUT if you keep them between +1 and -1 they seem to do nothing and if you go outside of that range then the shape isn't drawn.


I never figured this out myself.  I guess something to do with the Z buffer?  It caused a few bugs in the past where I forgot to zero a vertex buffer in the engine and ended up with nothing getting drawn.  It took me a while to figure that one out. :P

It looks like most of the useful 3D utility functions are not in Allegro 5.0.  So I'll need to require 5.2 or later.  A non-issue for windows releases (allegro is static linked), but may be a problem for Linux.  We'll see.
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1716

Is it currently possible for a game to set the window icon?


Not at runtime (yet); any custom icon should be 32x32 and packaged in the dist as icon.png.
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.5.11
Reply #1717


As in you can already set Z coordinates BUT if you keep them between +1 and -1 they seem to do nothing and if you go outside of that range then the shape isn't drawn.


I never figured this out myself.  I guess something to do with the Z buffer?  It caused a few bugs in the past where I forgot to zero a vertex buffer in the engine and ended up with nothing getting drawn.  It took me a while to figure that one out. :P

It looks like most of the useful 3D utility functions are not in Allegro 5.0.  So I'll need to require 5.2 or later.  A non-issue for windows releases (allegro is static linked), but may be a problem for Linux.  We'll see.
My current build of minisphere 4.5 for mac is a) statically linked and b) already using allegro 5.2 :P so non-issue for macos support.

Re: miniSphere 4.5.11
Reply #1718


Is it currently possible for a game to set the window icon?


Not at runtime (yet); any custom icon should be 32x32 and packaged in the dist as icon.png.

That's fine, that's what I meant.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1719

I wonder if a maximum frame rate shouldn't be enforced even in v1, like eg. a default frame rate of 240 or so. I've managed to lock my entire system up once just by accidentally getting it stuck in an infinite loop. (Note: I don't remember how it happened, just THAT it happened.)


As long as a script is calling FlipScreen() or DoEvents() regularly, or using the Sphere v2 event loop like in the example project, then you will always be able to close the window even if the CPU is pegged.  Of course if you have an infinite loop that doesn't do any event processing, that will cause problems, but there's not really anything miniSphere can do about that.  JS is single-threaded so it comes with the territory, unfortunately.
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1720
So I was going to fix all the spriteset bugs... but then I found out, Sphere 1.x does this for all functions that accept a spriteset parameter:
https://github.com/sphere-group/sphere/blob/master/sphere/source/engine/script.cpp#L1199-L1660

Over 450 lines of code just to read in a spriteset argument.  You see, Sphere 1.x does something very strange with spriteset parameters that it doesn't do for any other object: It reconstructs a native spriteset from the properties of the spriteset object passed in--as opposed to just having the object carry a native pointer and reading that back (like miniSphere does).  This should be a lot of fun to try to emulate.  I was originally going to fix it for miniSphere 4.6, but now I'm thinking it might be better to hold off on tackling that one.  It's not going to be fun, I can see that already.
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1721
Here's a peak at all the enhancements and fixes that'll be in miniSphere 4.6:
https://github.com/fatcerberus/minisphere/blob/master/CHANGELOG.md

And here're the release notes (listing breaking changes):
https://github.com/fatcerberus/minisphere/blob/master/RELEASES.md
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: miniSphere 4.5.11
Reply #1722
Well, a lot of the lines in that function are because one: Sphere 1.x does all GC rooting there manually (and does a lot of unnecessary GC rooting), and two: Spritesets don't have actual constructors/classes, so it is literally doing this in the most complicated way possible.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1723
Yeah, I noticed all the GC rooting.  It should honestly have been enough just to root the spriteset object itself and then all its properties would be guaranteed to be reachable for the duration of the call.  Even then I'm not sure any GC rooting was necessary at all.  Oh well, it's very old code, I'll give it a pass. :)

Anyway, the main point I was getting at is that Sphere 1.x reconstructs an internal spriteset object on-the-fly every time it accepts a Spriteset as an API parameter.  That's not going to be fun to replicate because the structure goes 3-4 levels deep in spots and Duktape's API is stack-based like Lua.  It can be done and it's not even really challenging, just extremely tedious.  Unfortunately, there do exist games that rely on the behavior, so I'll bite the bullet sooner or later.  Just not now. ;)
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.5.11
Reply #1724

Here's a peak at all the enhancements and fixes that'll be in miniSphere 4.6:
https://github.com/fatcerberus/minisphere/blob/master/CHANGELOG.md

And here're the release notes (listing breaking changes):
https://github.com/fatcerberus/minisphere/blob/master/RELEASES.md
Is there any chance of getting direct access to transformation matrices and setting vector uniforms added to 4.6?

I'd really appreciate it if possible.