Skip to main content

News

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

0 Members and 18 Guests are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.4
Reply #2070
I had problems a few days ago when I tried a bleeding-edge CC build.  It seems to be in a state of flux right now, best to just git checkout v1.7.1 and build that, or use the official CC 1.7.1 binaries from MS (this is what's in dep/ for Linux).

ExecuteGame() is still buggy, I think.  Once I get SSJ stabilized (breakpoints work now!) I'll look into that next.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.8.4
Reply #2071
Ok, so the segfault on exit was seemingly linked to v1 file output functions, the segfault appears to occur when trying to write data out not when closing down removing the v1 file writing got rid of the segfault.

BUT attempting to use v2 file output I get no output, I'm trying to just do:
Code: [Select]
FS.write("~/output.txt","average m_r = " + avgs[0] + "\n average s_r = " + avgs[1] + "\n average m_u = " + avgs[2] + "\n average s_u = " + avgs[3]);
It takes a very long time to run (measurable amount of time which is weird for writing such a short string) and seemingly does nothing - no output.txt exists afterwards.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.4
Reply #2072
There's a bug with v1 ByteArrays - trying to access them usually causes a crash.  The problem is that they're implemented via a Proxy object and CC won't let me read the host pointer through the Proxy.  I need to refactor it to make it work again, ByteArray could probably be implemented as a subclass of Uint8Array now.

Not sure what's going on with FS.writeFile() but I'll look into it.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.8.4
Reply #2073
I'm afraid I found another error, after using a custom shader you can't use the Font#drawText function or at least it seemingly inherits the shader and some uniforms from an unrelated model I've been drawing (which results in the text not drawing visibly).

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.4
Reply #2074
That would be the lazy shader switches at work.  I'll fix that, but in the meantime adding:
Code: (C) [Select]
shader_use(galileo_shader(), false);

right before this line:
https://github.com/fatcerberus/minisphere/blob/dd31133b8828bd9690a145d7da62aad978f82430/src/minisphere/pegasus.c#L2157

should do the trick.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.4
Reply #2075
@Rhuan I tried the following test:
Code: (JS) [Select]
FS.writeFile('~/812.txt', "The pig ate everyone at 8:12!\n");

It successfully wrote the file with no noticeable delays.  And if I try that from a game without a saveID defined, then I get:

Code: [Select]
JavaScript exception!

ReferenceError: no save ID defined
   at Showcase (:32:3)

So it shouldn't be silently failing, that's kind of weird.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.4
Reply #2076
Debugger bugs, what fun.  See if you can spot what's wrong with this picture (besides game() being called an anonymous function...) :P

Code: [Select]
D:\src\spectacles-i>ssj dist
SSJ X.X.X Sphere JavaScript debugger (x64)
the powerful symbolic JS debugger for Sphere
(c) 2015-2017 Fat Cerberus

starting 'D:/src/spectacles-i/dist/'... OK.
connecting to 127.0.0.1:1208... OK.
establishing communication... OK.
querying target... OK.
    game: Spectacles: Bruce's Story
    author: Fat Cerberus

=> # 0: [anonymous function] at @/scripts/main.js:6
6 RequireSystemScript('persist.js');

@/scripts/main.js:6 [anonymous function]
(ssj) c
UNCAUGHT: Error: The pig ate everything at 8:12
   at Anonymous function (@/scripts/main.js:45:12)
   at game (@/scripts/main.js:45:4)
=> # 0: [anonymous function] at @/scripts/main.js:49
49      Console.initialize({ hotKey: Key.Tilde });

@/scripts/main.js:49 [anonymous function]
(ssj) l 20
     39
     40         persist.init();
     41
     42         var evens = from([ 1, 2, 3, 4, 5, 6 ])
     43                 .where(it => it % 2 == 0);
     44         for (let even of evens) {
     45                 (() => { throw new Error("The pig ate everything at 8:12"); })();
     46                 SSj.log(even);
     47         }
     48
=>   49         Console.initialize({ hotKey: Key.Tilde });
     50         Console.defineObject('yap', null, {
     51                 'on': function() {
     52                         Sphere.Game.disableTalking = false;
     53                         Console.log("oh, yappy times are here again...");
     54                 },
     55                 'off': function() {
     56                         Sphere.Game.disableTalking = true;
     57                         Console.log("the yappy times are OVER!");
     58                 },

@/scripts/main.js:49 [anonymous function]
(ssj) bt
=> # 0: [anonymous function] at @/scripts/main.js:49

@/scripts/main.js:49 [anonymous function]
(ssj) _
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.4
Reply #2077
I've decided to release this as miniSphere 5.0 after all.  I've traditionally done a major version increase whenever a change represents a major paradigm shift:

  • 1.0: ~90% Sphere 1.x compatibility
  • 2.0: Cell, SphereFS, s2gm
  • 3.0: SSj, Linux support
  • 4.0: Sphere v2 API

Since introducing ChakraCore is not just a performance boost but also introduces native support for ES6, allowing games to once again be created without the need for Cell, that feels like enough of a paradigm shift to warrant a version bump.

I'll release the first public beta of miniSphere 5.0 in a week or so.

Since I did promise an API freeze for v5.0, I'm still going to try to achieve that.  We'll see what happens on that front.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.4
Reply #2078
SSj is about 95% feature-complete now.  The ChakraCore experiment was more successful than I ever imagined, not only do I get all ES6 syntax and native modules (which is a big deal--very few engines support these!), I was even able to more or less replicate all the functionality I had with the (surprisingly comprehensive!) Duktape debugger.  The engine is stable enough now that I'm thinking I'll lock it in and merge all the CC stuff into the trunk.  There's still a few kinks to work out before miniSphere 5.0.0 is released (like figuring out how to static-link CC), but overall I consider what's here good enough to be merged into the main codebase.

Once I do the merge I'll start looking at things in more detail, like figuring out @Eggbertx crashes on Debian.  I also need to clean up the codebase at some point, because I did a lot of hacky retrofitting to avoid touching a lot of code.  Changing JS engines was already enough of an upheaval that I didn't want to risk introducing even more bugs by indiscriminately editing things. :P
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.4
Reply #2079
@Eggbertx I can't reproduce your crash on Debian 9.  After struggling with it for a bit (Debian doesn't install or set up sudo by default, which was surprising), I finally got it set up enough to compile and run miniSphere and... it worked fine.  The setup is pretty basic, I just installed:

  • liballegro5-dev
  • libmng-dev
  • ...and whatever I needed to build the engine (git, make, etc.)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: miniSphere 4.8.4
Reply #2080
I reinstalled Debian again just to be sure that I hadn't installed any extra packages that could be interfering and installed LXDE, and after the CD installation was done, I booted into it, logged in, and ran apt install git liballegro5-dev libmng-dev, which installed gcc and all the dependencies. Then I cloned the minisphere, ran make and make install, then I ran minisphere and still had the same issue when I exited out of that.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.4
Reply #2081
Try this:
Install valgrind
Build miniSphere using "make clean all CFLAGS=-g"
sudo make install
valgrind minisphere

Then post the output.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: miniSphere 4.8.4
Reply #2082
Code: [Select]
==2047== Memcheck, a memory error detector
==2047== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==2047== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==2047== Command: minisphere
==2047==
Out of Memory
==2047==
==2047== Process terminating with default action of signal 6 (SIGABRT)
==2047==    at 0x8EC3FCF: raise (raise.c:51)
==2047==    by 0x8EC53F9: abort (abort.c:89)
==2047==    by 0x60EC165: _GLOBAL__sub_I_RecyclerWriteBarrierManager.cpp (in /usr/lib/libChakraCore.so)
==2047==    by 0x400F8A9: call_init.part.0 (dl-init.c:72)
==2047==    by 0x400F9BA: call_init (dl-init.c:30)
==2047==    by 0x400F9BA: _dl_init (dl-init.c:120)
==2047==    by 0x4000C59: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==2047==
==2047== HEAP SUMMARY:
==2047==     in use at exit: 86,856 bytes in 262 blocks
==2047==   total heap usage: 312 allocs, 50 frees, 96,876 bytes allocated
==2047==
==2047== LEAK SUMMARY:
==2047==    definitely lost: 0 bytes in 0 blocks
==2047==    indirectly lost: 0 bytes in 0 blocks
==2047==      possibly lost: 1,800 bytes in 19 blocks
==2047==    still reachable: 85,056 bytes in 243 blocks
==2047==                       of which reachable via heuristic:
==2047==                         newarray           : 1,536 bytes in 16 blocks
==2047==         suppressed: 0 bytes in 0 blocks
==2047== Rerun with --leak-check=full to see details of leaked memory
==2047==
==2047== For counts of detected and suppressed errors, rerun with: -v
==2047== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Killed

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.8.4
Reply #2083
Right, I forgot Chakra and Valgrind don't get along without some coercing (read: building CC manually).  Can you do the same thing with 4.8.4?  You said the Duktape engines were crashing too.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.8.4
Reply #2084
I've decided to release this as miniSphere 5.0 after all.  I've traditionally done a major version increase whenever a change represents a major paradigm shift:

  • 1.0: ~90% Sphere 1.x compatibility
  • 2.0: Cell, SphereFS, s2gm
  • 3.0: SSj, Linux support
  • 4.0: Sphere v2 API

Since introducing ChakraCore is not just a performance boost but also introduces native support for ES6, allowing games to once again be created without the need for Cell, that feels like enough of a paradigm shift to warrant a version bump.

I'll release the first public beta of miniSphere 5.0 in a week or so.

Since I did promise an API freeze for v5.0, I'm still going to try to achieve that.  We'll see what happens on that front.
I was hoping I'd have the map engine ready by the time you were at version 5 but I've spent too much time working this week and haven't made much progress at all - will see what I can do tomorrow, out of time for today. :(

Well done on getting miniSphere running on Chakra though, really good work.


Though I'm still trying to think what would be a good use of all of that power - other than doing 10,000,000s of unnecessary random sums of course :p
  • Last Edit: September 09, 2017, 06:48:57 pm by Rhuan