Skip to main content ↑ ↓
Topic: neoSphere 5.10.1 (Read 8505722 times) previous topic - next topic
0 Members and 14 Guests are viewing this topic.

Re: miniSphere 4.5.6

Reply #1530 –
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) [Select]

evenNumbers = from(listOfNumbers).where(v => v % 2 === 0);

// print all the even numbers in listOfNumbers (live!)
for (let n of evenNumbers) {
    console.log(n);
}


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.

Re: miniSphere 4.5.6

Reply #1531 –
It will soon be even easier to use the threads module when using ES6:

Code: (javascript) [Select]

import { Thread } from 'threads';

class SomeEntity extends Thread
{
    constructor()
    {
        super({ priority: 812 });
        // initialize entity
    }

    /* methods... */

    on_update()
    {
        /* update stuff... */
    }

    on_render()
    {
        /* render stuff... */
    }
}


Then:

Code: (javascript) [Select]

let myEntity = new SomeEntity();

myEntity.start();  // starts the thread running
myEntity.stop();   // kills the thread
myEntity.join();   // blocks until thread dies


No fiddling with thread IDs! :D

Re: miniSphere 4.5.7

Reply #1532 –
4.5.7 fixes the Sphere Studio project template so it compiles out of the box again.

Re: miniSphere 4.5.7

Reply #1533 –
Quote from: Fat Cerberus – on

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.

Re: miniSphere 4.5.7

Reply #1534 –
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.

Re: miniSphere 4.5.7

Reply #1535 –
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.

Re: miniSphere 4.5.7

Reply #1536 –
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.

Re: miniSphere 4.5.9

Reply #1537 –
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

Re: miniSphere 4.5.9

Reply #1538 –
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.

Re: miniSphere 4.5.9

Reply #1539 –
Quote from: Beaker – on

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?

Re: miniSphere 4.5.9

Reply #1540 –
Quote from: Fat Cerberus – on

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:

Re: miniSphere 4.5.9

Reply #1541 –
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.

Re: miniSphere 4.5.9

Reply #1542 –
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?

Re: miniSphere 4.5.9

Reply #1543 –
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. :)
 

Re: miniSphere 4.5.9

Reply #1544 –
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();
	}
}