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

Re: minisphere 3.3.0

Reply #1245 –
Yes, I think this system would necessitate entities remaining in existence until they are explicitly destroyed, say by calling person.dispose() or something.  They could then be part of the state saved in a gamesave, so that NPCs moved e.g. as part of a cutscene would remember their position when the file is reloaded.

If memory usage becomes an issue, it would of course be possible to load and unload the associated assets for an entity on demand.  This way you don't end up with hundreds of spritesets or whatever loaded simultaneously using a gig of RAM.

Re: minisphere 3.3.0

Reply #1247 –
The great thing is that it will be built on top of my threading framework (require("threads")) and Scenario (require("scenes")) so that will no longer need to be hacked in to work with the old-style update/render script system.  Everything will cooperate out of the box. :)
 

Re: minisphere 3.3.0

Reply #1248 –
Following up on the Scenario and threading integration, I'm thinking there will be no concept of a person command queue in the engine itself.  Persons themselves will simply have a basic set of actions they can perform: Change sprite direction, move one step in a direction, animate sprite.  These actions would be performed immediately (like calling QueuePersonCommand() with true as the last parameter), and any command queue-like functionality would instead be handled through Scenario.  This way Scenario won't feel "bolted on" like it does with the Sphere 1.x map engine (well, pretty much all 1.x map engine extensions are like that, it's just the nature of how it functions)

Re: minisphere 3.3.0

Reply #1249 –
Quick question, having built an SPK, how do I package the game to be executed as a standalone project, with customized settings, etc.?

Re: minisphere 3.3.0

Reply #1250 –
Not sure what you mean by customized settings, but minisphere associates itself with SPK files on installation, so you can just distribute that.  If you really want to distribute the engine with it, it should be enough to zip the SPK along with minisphere.exe and the system directory, just like you'd do with Sphere 1.x (minus the 8 or so DLL files).

To clarify: When you run minisphere.exe, if there's a single SPK file in the same directory as the engine, it will run that automatically.

Re: minisphere 3.3.0

Reply #1251 –
Customized settings like "not using fullscreen by default" or setting window size to scaled 800 by 600, etc.

Additionally, where are the saves for packaged games located (both on windows and linux)?

Re: minisphere 3.3.0

Reply #1252 –
Not sure how you changed the scaling, since minisphere is hardcoded to use 2x scaling for 400x300 and under and 1x for anything higher.  Unless you compiled the engine yourself?  As for disabling fullscreen, that's a Sphere Studio option, and not (currently) customizable for the engine (which in fact has no persistent settings).  The way you start the engine in windowed mode is to use the --window command-line option; this is what Sphere Studio does when you use that setting.

What I may do for minisphere 4.0, is add an optional setting in game.json which allows the game to specify whether it prefers to run in a window or fullscreen.  For a lot of games fullscreen is overkill.

Re: minisphere 3.3.0

Reply #1253 –
Quote from: mezzoEmrys – on

Additionally, where are the saves for packaged games located (both on windows and linux)?


For Sphere 1.x games, all writes to a packaged game are virtualized to [Documents]/minisphere/.spkcache.  This is the same for both Windows and Linux.  Note that for Sphere 2.0 games this won't be possible and you will have to use the ~/ SphereFS prefix.  But it'll be a few more months still before you have to worry about that. :)

Re: minisphere 3.3.0

Reply #1254 –
I did it: I got the Sphere 1.x and 2.0 APIs to coexist.  This means minisphere 4.0 will retain Sphere 1.x compatibility.  Yay!

Pulling this off required a few compromises I'm not too thrilled about, but it does avoid me having to rewrite half of the Spectacles codebase, so... well, can't win 'em all.  The cost of maintaining compatibility:

  • I had to remove the constructors for Sphere 1.x types, as most needed to be repurposed for use in the Sphere 2.0 API.

  • The startup script continues to be run as global program code.  The plan originally was to run everything as a module, like Node.js does, but doing so breaks Sphere 1.x scripts which assume that declarations outside of any function are global, whereas top-level variables in a module are module-local.

  • Sphere 1.x "legacy objects" and Sphere 2.0 objects are not interchangeable.  You can't pass a Sphere 2.0 Color object to a Sphere 1.x function, and vice versa.  This is somewhat inconvenient and a potential minefield for migration, but I can't find any way around it as the semantics sometimes vary wildly.  Sphere 2.0 Colors are floating point, for example, while Sphere 1.x uses 8-bit colors (0-255).



As for the non-interchangeable objects: While it's technically possible for the engine itself to treat, say, Sphere V1 and V2 Image objects equally (since they are internally the same type), it will never be possible for them to be interchangeable to JavaScript code as the methods and semantics vary.  So to me it made the most sense just to have the engine treat them as distinct and incompatible right out of the gate.  This way there's no confusion on users' part where old and new objects are compatible in some situations but not others.

So yeah, that's where I'm at right now.

Re: minisphere 3.3.0

Reply #1255 –
It occurs to me that the post above may have given the wrong impression.  While objects are not interchangeable, it's completely acceptable to mix Sphere 1.x and 2.0 code (even rendering code) in the same codebase.  You can even use Sphere 1.x drawing primitives (Rectangle() et al.) and then call screen.flip(), which will honor the current screen.frameRate.  Same for using Galileo in code that calls FlipScreen() and SetFrameRate().

What you can't do is stuff like this:

Code: (javascript) [Select]

var ss = LoadSpriteset('scott.rss');
var image = new Image('images/scott.png');  // Sphere 2.0 Image object
ss.images[0] = image;  // Error: expects a Sphere 1.x Image


Or this:

Code: (javascript) [Select]

var surf = CreateSurface(100, 100, Color.Black);  // Error again: Color.Black is a Sphere 2.0 Color object


Thus it can sometimes get awkward when using the classic map engine in Sphere 2.0 code because you pass Images and Colors around so much and it gets tempting to try to pass in the new-style objects you may already have on hand.

Re: minisphere 3.3.0

Reply #1256 –
Damn, you're going through lengths to retain compatibility, and I have to say, that's really admirable of you to do. As well as clever, as it doesn't splinter the specific versions of Sphere someone needs in order to play Sphere games, old or new. :)

Re: minisphere 3.3.0

Reply #1257 –
New feature: The RNG object.  Unlike in previous versions where this was a singleton, in minisphere 4.0 it will be much more flexible.  You can create multiple generators and have full control over their state, allowing complex tricks to be done with the random number generator (time travel-like game mechanics, for example).  You could also use this to save and restore the state of the generator(s), to deter save scumming.

To illustrate:
Code: (javascript) [Select]

var gen = RNG.fromSeed(812);
var state = gen.state;
var x = gen.next();  // ~0.028
var y = gen.next();  // ~0.758
var gen2 = RNG.fromState(state);  // you could also set gen.state directly
var z = gen2.next();  // ~0.028 (!)
var w = gen2.next();  // ~0.758 (!!)


This is a very low-level API which gives you direct access to the underlying generator (xoroshiro128+).  All the convenience methods from previous versions like RNG.uniform and RNG.string have been moved into a JS module "random" that you load using require("random").

Re: minisphere 3.3.0

Reply #1258 –
By default does it use the clock? Or do you have to put a seed each time? Just curious. Also is the state the same thing as returning the 812? Because to me it seems redundant when you could just store the seed and reuse it, unless there's more going on behind the scenes.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: minisphere 3.3.0

Reply #1259 –
There is RNG.Default, which is seeded from the clock, and `new RNG()` will likewise use the clock as a seed.

The seed and state are different things.  The seed (812 in this case) determines the specific sequence that will be generated and is just a number.  The state is a 32-character hexadecimal string you can use to resume the generator from exactly where you left off (to prevent save scumming, this is what you'd store in the save file).  You can't do this with the seed alone because the seeding algorithm is not reversible.

Note that if I had stuck with Mersenne Twister, the state would have been a 2.5KB string!