Author Topic: miniSphere 4.5.10  (Read 118948 times)

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: miniSphere 4.5.6
« Reply #1530 on: March 11, 2017, 02:11:17 am »
By the way there's an important change in 4.5.6 for from() queries.  Whereas before for...of over a query would enumerate key-value pairs, now it will only enumerate the values.  This change lets you keep a query around as if it were a "live array":

Code: Javascript
  1. evenNumbers = from(listOfNumbers).where(v => v % 2 === 0);
  2.  
  3. // print all the even numbers in listOfNumbers (live!)
  4. for (let n of evenNumbers) {
  5.     console.log(n);
  6. }
  7.  

That also lets you avoid wasting memory for a concrete array by alleviating the need for .select() in most cases.  Even better, by iterating through a query like that, you maintain the lazy evaluation behavior--as opposed to .select() which needs to run it to completion so it can return an array of the results.  In contrast, you can break out of the for...of early if needed, and the remainder of the results don't need to be processed.
miniSphere 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: miniSphere 4.5.6
« Reply #1531 on: March 13, 2017, 02:34:15 am »
It will soon be even easier to use the threads module when using ES6:

Code: Javascript
  1. import { Thread } from 'threads';
  2.  
  3. class SomeEntity extends Thread
  4. {
  5.     constructor()
  6.     {
  7.         super({ priority: 812 });
  8.         // initialize entity
  9.     }
  10.  
  11.     /* methods... */
  12.  
  13.     on_update()
  14.     {
  15.         /* update stuff... */
  16.     }
  17.  
  18.     on_render()
  19.     {
  20.         /* render stuff... */
  21.     }
  22. }
  23.  

Then:

Code: Javascript
  1. let myEntity = new SomeEntity();
  2.  
  3. myEntity.start();  // starts the thread running
  4. myEntity.stop();   // kills the thread
  5. myEntity.join();   // blocks until thread dies
  6.  

No fiddling with thread IDs! :D
miniSphere 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: miniSphere 4.5.7
« Reply #1532 on: March 14, 2017, 02:35:44 am »
4.5.7 fixes the Sphere Studio project template so it compiles out of the box again.
miniSphere 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Zechs

  • Newbie
  • *
  • Posts: 15
  • Zechsual Intension
    • View Profile
Re: miniSphere 4.5.7
« Reply #1533 on: March 14, 2017, 01:00:28 pm »
4.5.7 fixes the Sphere Studio project template so it compiles out of the box again.
Is this in reference to it not finding the Cellscript file? That was my issue. I haven't had a chance to touch it since, mind you, but I was running into that.

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: miniSphere 4.5.7
« Reply #1534 on: March 14, 2017, 01:40:03 pm »
Yeah, related to the default Cellscript having an "import" statement, which now needs it to be a .mjs file.  The new project had it named as Cellscript.js which caused it to fail.
miniSphere 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Zechs

  • Newbie
  • *
  • Posts: 15
  • Zechsual Intension
    • View Profile
Re: miniSphere 4.5.7
« Reply #1535 on: March 14, 2017, 01:42:49 pm »
Agh, I did look at it and wonder if the filename was the issue, as I remember you mentioning the integration of .mjs. I didn't try it, though it couldn't have hurt.

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: miniSphere 4.5.7
« Reply #1536 on: March 14, 2017, 10:25:53 pm »
New branch policy for the Git repo: Development of the next version (right now planned as 5.0) with on "dev" branch, while "master" will be latest-stable.  Historically I've developed directly against the trunk, which is starting to delay major overhauls; by committing everything directly to master, patch releases only intended to fix bugs end up getting breaking changes too, so I end up holding off on doing them.  Which slows down development.
miniSphere 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: miniSphere 4.5.9
« Reply #1537 on: March 31, 2017, 01:14:06 am »
miniSphere 4.5.9 brings back TypeScript as the ES6 transpiler for much faster compile speeds.  Source map is appended to the end of the transpiled script and read by the SSJ plugin, so that debugging in Sphere Studio should now work properly.  Let me know of any glitches though, as I kind of rushed the implementation. :P
miniSphere 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Beaker

  • Verified
  • Newbie
  • *
  • Posts: 18
    • View Profile
Re: miniSphere 4.5.9
« Reply #1538 on: March 31, 2017, 01:41:53 am »
I'm in the process of porting The Rainis Manuscript over to miniSphere.  It seems very little is actually needed to get it to run, but I have noticed a few graphical bugs involving transparencies and fonts.  It's been a few months since I ran it last since I'm still working on the game proper, but I could try it again if these are not known issues.

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: miniSphere 4.5.9
« Reply #1539 on: March 31, 2017, 02:12:04 am »
I'm in the process of porting The Rainis Manuscript over to miniSphere.  It seems very little is actually needed to get it to run, but I have noticed a few graphical bugs involving transparencies and fonts.  It's been a few months since I ran it last since I'm still working on the game proper, but I could try it again if these are not known issues.

There indeed shouldn't be much effort needed to migrate - almost all of the Sphere 1.5 API is implemented.  I tried to make it as painless as possible to phase in the new features too - in large part you can mix Sphere v1 and v2 functions freely (objects are not interchangeable, however).

There's really only a handful of stuff that's not implemented, mostly some esoteric APIs like Complex() and a few surface blend modes (because they're impossible to implement with the OpenGL fixed-function pipeline), but otherwise everything should work correctly.  There shouldn't be any issues with fonts though; what kind of bugs did you encounter there?
miniSphere 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Beaker

  • Verified
  • Newbie
  • *
  • Posts: 18
    • View Profile
Re: miniSphere 4.5.9
« Reply #1540 on: March 31, 2017, 03:02:34 am »
There indeed shouldn't be much effort needed to migrate - almost all of the Sphere 1.5 API is implemented.  I tried to make it as painless as possible to phase in the new features too - in large part you can mix Sphere v1 and v2 functions freely (objects are not interchangeable, however).

There's really only a handful of stuff that's not implemented, mostly some esoteric APIs like Complex() and a few surface blend modes (because they're impossible to implement with the OpenGL fixed-function pipeline), but otherwise everything should work correctly.  There shouldn't be any issues with fonts though; what kind of bugs did you encounter there?

In the case of the font, it seems to either switch to a default font instead of the font loaded, or just not draw the transparencies of the font.  As far as I can remember, the only special things done to the font was possibly a color mask and doing the zoomblits.  In the case of the images, it seemed to be transparencies with zoomblits (basically, everything is a zoomblit).  Doing a quick re-look, I can't find the transparency with images problem, but I found a new bug wherein the restart(); function doesn't seem to reread the .sgm file like Sphere 1 does.  Sort of.  The first restart to change resolution works well enough (it doesn't work the same with the 320x240 option, but I assume that was deliberate), but the later restarts which were added to get around out-of-memory issues of (hopefully) yesteryear cause the engine to restart at the options menu instead of going to where it left off.

I also noticed some other differences as well with I think off-by-one pixels when drawing lines of text character by character vs drawing all the characters at once (a bit hard to explain, I'll have to send you a demo to explain that one).  When I finish the rest of the game, I can move over into doing the port fully, and give you a comprehensive list of the things I find.

In terms of the fonts, here's some screenshots:

Sphere:


miniSphere:

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: miniSphere 4.5.9
« Reply #1541 on: March 31, 2017, 03:13:47 am »
I'll give this a better look tomorrow but you don't need to rewrite the .sgm file to change resolution in miniSphere (in fact the whole SGM format is deprecated, although Cell will still generate one to ease migration).  You can simply call screen.resize(w, h) to do that on-the-fly.
miniSphere 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: miniSphere 4.5.9
« Reply #1542 on: March 31, 2017, 11:45:42 am »
I think I found the font bug.  I'm assuming your fonts are RFNv1 (version = 1 in header)?  Sphere 1.x and miniSphere load RFNv1 fonts differently, due to a misinterpretation of the RFN spec on my part.

RFN specification:
https://github.com/sphere-group/sphere/blob/master/sphere/docs/internal/font.rfn.txt
It *does* say 255 is opaque while 0 is transparent, but I missed that part and only saw "8-bit grayscale".

Sphere 1.x:
https://github.com/sphere-group/sphere/blob/master/sphere/source/common/Font.cpp#L150-L153

miniSphere:
https://github.com/fatcerberus/minisphere/blob/master/src/minisphere/font.c#L136

In other words, Sphere 1 treats the single grayscale pixel as the alpha channel, while miniSphere treats it as a white level (which is normally what "grayscale" means).  So you lose your transparency as a result.  What I can't figure out is why the translucent pixels seem to be completely missing in your screenshot - if this is indeed the cause, then those pixels should be rendered, just opaque.

edit: Actually, I don't think that's the problem in this case (the bug still needs to be fixed of course)--if that were the issue then the font would have been rendered with a black background, which doesn't seem to be the case here.  So I'm not sure.  Could you maybe send me a copy of the .rfn font file so I could try to diagnose what's going on?
« Last Edit: March 31, 2017, 11:54:28 am by Fat Cerberus »
miniSphere 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: miniSphere 4.5.9
« Reply #1543 on: March 31, 2017, 12:33:22 pm »
Regarding that out-of-memory thing: That should no longer be an issue.  Sphere 1.x used to run out of memory all the time because it only initializes SpiderMonkey with a 5MB heap.  Duktape doesn't have that issue since it will just allocate memory directly as needed.  And its garbage collector is pretty aggressive (most objects are freed the second they fall out of scope).  So unless you have gigabytes of assets loaded simultaneously, I doubt you'll have an issue. :)
miniSphere 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Beaker

  • Verified
  • Newbie
  • *
  • Posts: 18
    • View Profile
Re: miniSphere 4.5.9
« Reply #1544 on: April 01, 2017, 11:00:27 pm »
It's a problem with drawZoomedText.  Using drawText will render correctly with the semi-transparent pixels, but drawZoomedText with zoom set to 2 or 1 will not draw them.


https://rpgmaker.net/users/Beaker/locker/main.rfn

Code: [Select]
// main.js automatically generated by Sphere Studio
// Vanilla compiler plugin
font1 = LoadFont("main.rfn");
font2 = LoadFont("main.rfn");
var c = CreateColor(255,0,128,255)

font2.setColorMask(c);

function game()
{
var txt = "SeT GQwWoO!";
while (true)
{
font1.drawZoomedText(0,0,2,txt);//renders without alpha
font2.drawZoomedText(0,20,2,txt);// ..

font1.drawZoomedText(0,40,1,txt);//also renders without alpha
font2.drawZoomedText(0,60,1, txt);// ...

font1.drawText(0,80,txt);//Render correctly
font2.drawText(0,100, txt);// ..

FlipScreen();
}
}

 

anything