Skip to main content


Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Fat Cerberus

Script Support / Re: GetVersion Question
Without having access to a machine that old I can only guess at what's wrong, unfortunately. :(

The only thing that comes to mind is the change to backbuffer handling I did in mS 4.6: the engine now uses a fake backbuffer to ensure pixel-perfect output, and your 7300 may not be able to do render-to-texture at all.  In that case Allegro is probably emulating it in software, hence the slowdown.  If that's indeed the case, then there's not much I can do--using Surfaces in miniSphere would be slow for you too, even under 4.5.
Script Support / Re: GetVersion Question
Wow, GeForce 7300 is circa 2005... so that's a pretty old machine then.  The oldest PC I think I have access to is an Athlon X4 635 from around 2010.  I can look into it to try to figure out what caused the performance regression but I don't think you're ever going to get miniSphere to run adequately on that machine.
Script Support / Re: GetVersion Question
CPU-wise, requirements should be on par with Sphere 1.5 (in fact Duktape is 2-3x faster than the old SpiderMonkey used by 1.5).  GPU requirement is definitely a lot higher though, since it's all shader-based nowadays (1.5 is software-rendered unless you use the horribly optimized OpenGL plugin).

In the absence of a dedicated graphics card, I'm going to say the minimum requirement would be a Sandy Bridge i5, circa 2011.
Script Support / Re: GetVersion Question
Hm, not sure what would have caused that.  I made a lot of changes to the internal rendering since 4.5, but none of those should have slowed it down, if anything the upgrade should have made things a lot faster. :(
Script Support / Re: GetVersion Question
That's interesting, Sphere 1.5 is apparently not normalizing the path.  It's been my experience with Sphere 1.5 that the string returned by GetCurrentMap() is relative to maps/, but for some reason you have an extra redundant ../maps/ component in there.  Strange.

In any case if you're just trying to get the filename, this will work regardless of what its directory path is:

Code: [Select]
GCM_SA = GCM_S[GCM_S.length - 1];
Script Support / Re: GetVersion Question
If you upgrade to 4.8.4 then you won't need the version check for this.

To answer the original question though, you were using GetVersion() correctly, it returns 2.0 for miniSphere and 1.5 for Sphere 1.5.  Note that in JS, 2.0 === 2, i.e. there is no concept of an integer type.
Script Support / Re: GetVersion Question
No no, I meant the version number of the engine, not the API version.  Are you using 4.8.4 or an earlier version?
Script Support / Re: GetVersion Question
Which version of miniSphere are you using?  In the latest versions GetCurrentMap() should return exactly the same string in both engines.  I fixed a bug a few versions ago where it would return the full SphereFS path of the map file, so maybe that's the problem you're having.
Albrook is a hell of a map, I even remember having trouble getting miniSphere to load that one properly. :o

Kefka's Revenge in general is a monster of a game.  The fact that miniSphere runs it nearly flawlessly at this point is a testament to my dedication to backwards compatibility. :P
Looks really nice, although your aspect ratio seems off (the tiles are too tall).  I think this might be the cause:

Code: (javascript) [Select]
var wh = screen.width / 2;
var hh = screen.height / 2;
screen.transform = new Transform()
    .translate(-wh, -hh)
    .scale(3 / wh, 3 / hh)  // <-- HERE
    .rotate(0.6, 1.0, 0.0, 0.0)
    .translate(0, 0, -1.0)
    .project3D(120, wh / hh, 0.1, 2.0);

The factors for both axes should be the same, you want to divide by either wh or hh but not both (I tend to prefer the former).  That was my mistake when I originally wrote the code.
Engine Development / Re: miniSphere 4.8.4
The way the Sphere v1 API is set up is actually not very browser-friendly at all.  There is no concept of an event loop in Sphere 1.x so games necessarily do this:

Code: (javascript) [Select]
while (true) {
    /* update stuff */

    /* render stuff */


And of course MapEngine() itself is blocking.  Do anything like that on a webpage, and you lock up the browser/get your script forcibly terminated for your troubles.  To my knowledge there's no function like miniSphere's that you can call in a browser to pump the event loop, you need to let your script return naturally.
Engine Development / Re: Oozaru: Sphere for the Web
Good news: Browsers are finally starting to get support for ES6 modules:

That will remove a big barrier for Sphere v2 in the browser, since .mjs is now the preferred way to write v2 code.  Otherwise you end up needing Babel/TypeScript + a require() shim. :-\
Engine Development / Re: miniSphere 4.8.4
Couldn't Sphere run on the web using an individual's browsers JS engine + an implementation of the API in HTML 5? Yes that would require almost a line 1 re-write of the engine but on the face of it I think that would result in better performance and a more sensible system than trying to port the existing codebase.

Yes, this is exactly what Oozaru is meant to be.  I've just be preoccupied with miniSphere since I'm trying to finalize the v2 API before I write an entire second implementation of it.
Sphere General / Re: Sphere v2 API discussion
I actually wanted to add a function for that like Surface#lock() but I couldn't come up with a way to expose the raw pixel data to JS in a user-friendly way.  I'll revisit it at some point, it might be possible to have it return an ArrayBuffer or similar.

That said, the preferred way to do fancy scaling nowadays is in the fragment shader.  I think I've seen hq2x shaders out there, for instance.
Engine Development / Re: miniSphere 4.8.4
If you ever get miniSphere to work on Android, let me know!  Allegro is supposed to support it but I couldn't figure out their build systems.