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

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #405 –
Yep, I remember when it all transpired. Just thought that the included version of Allegro was your fixed version, so I thought "hm, maybe it's not fixed after all". Until you clarified that just now.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #406 –
I've decided what I want to do for the configuration editor.  The config tool will be written in JS and run by minisphere as any other Sphere game.  config.exe will be a tiny stub that simply defers to the engine and points it at the location of the config "game" game.sgm.

Unfortunately this does mean that key mappings won't be able to be changed while in-game, but after a short-lived experiment trying to implement a graphical config on the native side (the only way to implement such a thing without interrupting the currently running game), I gave up.  C--or any purely procedural langauge, really--just isn't suited for writing a GUI.  It'd much less painful in an OO language like JavaScript.  Besides, as with Sphere's old config.exe, it's really just meant to be a convenience; the preferred option will always be to implement your own config in-game to ensure UI consistency and whatnot.

On a sidenote, my other attempt at a config tool was in C++ using wxWidgets for a Sphere 1.5-style tool, but 1) wxWidgets is horrendously bloated (it took me 10-15 minutes to compile all the libraries on a 5th-gen Core i3--note that this is a CPU that can run the Dolphin emulator!) and 2) It very quickly reminded me why I hate C++.  So yeah, that was a failure too.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #407 –
So it has become like the startup game, but also like a library that you can add to your game. Neat!
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 1.1b1 (stable: 1.0.10)

Reply #408 –
Just my opinion, having had a long time to wonder about what GUI toolkits to use...

You should take a look at fltk. It is kind of intended for what you describe. It's extremely lightweight, and it makes only a very select usage of C++'s features. It is also extremely cross platform, and still provides easy integration with platform tools.

For instance, you could easily use Fl_x.h's stuff to create a new parent window given a Win32, X11, or Cocoa window handle to have as a child. I was considering using that to frame the window SDL2 creates for TurboSphere, so that I could have an SDL2 OpenGL window embedded in an fltk window that has a menu bar for this kind of thing. You could also automatically use the OS X menu bar instead of a separate one by using Fl_Sys_Menu_Bar.

I despise Qt and WxWidgets because they are ridiculously large and solve simple problems in the most complex way imaginable. I don't like GTK because its maintainers have no commitment to backwards compatibility at all. I rather like fltk because it doesn't have any of these issues. It can look a little dated with the default scheme, but that's really the least of what matters to me. The theme is very usable and simple.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #409 –
I do like the GTK+ theme, if I have to use non-native widgets that's the one I'd prefer by far.  But GTK is pretty bloated itself.  The redistributable last I remember was about 20MB and there's no way to static link to it.  No way I'm carrying around that kind of baggage for a config tool that half of Sphere users aren't even going to touch.  I did take a look at fltk, and while I think most of those screenshots are pretty fugly, it does look very lightweight and simple to use.

But I really think the startup-game-style JS config is the way to go here.  This probably sounds odd given my dedication to doing everything in native, but at the end of the day I don't consider this core functionality; it's just a nice extra.  This way if a game doesn't need it--say, because it implements its own configuration menus--config.exe and the config folder can be left out of the distro.  It's a different situation than, say, the map engine, where at least 3/4 of all Sphere games utilize its functionality in some way and so it's beneficial to have it built into the engine. (And I wouldn't have wanted to have to debug that thing in JS anyway--the MSVC debugger was invaluable during its development).
 

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #410 –
Quote from: Lord English – on

And I wouldn't have wanted to have to debug that thing in JS anyway--the MSVC debugger was invaluable during its development


Fortunately, both SpiderMonkey and V8 can be run so that gdb or lldb can view JS stack frames as though they were native frames :)
Or at least V8 used to be able to. When I was on my way out of the V8 world, it had been broken for some time and there were murmurs of that being removed.

But I found that one major advantage of the map engine in script was simply that it is easier to write something purely behavioural like that in JS. It needs much less debugging because it has fewer bugs in JS.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #411 –
Quote from: Flying Jester – on

But I found that one major advantage of the map engine in script was simply that it is easier to write something purely behavioural like that in JS. It needs much less debugging because it has fewer bugs in JS.


It's also easily adaptable by the community. ;)
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 1.1b1 (stable: 1.0.10)

Reply #412 –
Quote from: Radnen – on

Quote from: Flying Jester – on

But I found that one major advantage of the map engine in script was simply that it is easier to write something purely behavioural like that in JS. It needs much less debugging because it has fewer bugs in JS.


It's also easily adaptable by the community. ;)


That's true, but also remember that, as discussed in this very thread, due to subtle, easy-to-take-for-granted design choices (such as that infamous edge script triggering double-snafu I hit) it's already pretty extensible as-is.  Your Blockman game is proof of that. :D  And Lithonite...

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #413 –
Quote from: Lord English – on

That's true, but also remember that, as discussed in this very thread, due to subtle, easy-to-take-for-granted design choices (such as that infamous edge script triggering double-snafu I hit) it's already pretty extensible as-is.  Your Blockman game is proof of that. :D  And Lithonite...


Well that's because of SetUpdateScript and SetRenderScript. Basically it let's you "have at it", that coupled with the copious number of getters and setter available to you, there's little that can stand in your way. That said it's still not 100% flexible and even Lithonite would have been easier to code / maintain if it knew to hook into certain areas of the engine easier. There's a lot of hack code too, as a result of Sphere's map API. But it is rather open.

I mean, most maps are indeed very simple structures. You have tiles, layers, entities, zones & triggers. Some objects have obstruction, some tiles have animations, some layers move or parallax. It really covers everything.

That said there currently is no way to exclusively draw a map wherever you want. It'd be nice to treat maps like a standalone object, such that you can muck with it's properties after loading, and draw portions of you choice of the map, wherever, whenever. That's quite hard in Sphere since you are limited to one map per screen. There are double camera tricks, but it can only happen on the same map... unless you write your own map loading call.

I want an engine where I can load up and string maps end to end, with some dynamic calls. Allocate some maps, and deallocate those of which that are out of screen, and then reload them when you are near again. I used this tactic in other game engines to create 'infinite' maps. Maps without borders, but are loaded by stringing maps end-to-end dynamically. The performance benefit is obvious here since you aren't loading a 999x999 sized map all at once.
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 1.1b1 (stable: 1.0.10)

Reply #414 –
If the config tool is contained within a single script, game devs could opt to run it within the game itself too, like

Code: (javascript) [Select]
RequireScript("sphere-config.js");
SphereConfigMenu();


And even customize it to their own likings if they really wanted. :)

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #415 –
Quote from: DaVince – on

If the config tool is contained within a single script, game devs could opt to run it within the game itself too, like

Code: (javascript) [Select]
RequireScript("sphere-config.js");
SphereConfigMenu();


And even customize it to their own likings if they really wanted. :)


That's actually a really good idea, I'll have to include the config core as a system script now. :). I was thinking it would look something like the Xrossbar menu on the PS3, with an optional game-specific background taken from the game.sgm root, similar to how icon.png is now.  This way if a dev chooses not to make their own config, the default one won't completely clash with whatever they make.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #416 –
Quote from: Radnen – on

That said there currently is no way to exclusively draw a map wherever you want. It'd be nice to treat maps like a standalone object, such that you can muck with it's properties after loading, and draw portions of you choice of the map, wherever, whenever. That's quite hard in Sphere since you are limited to one map per screen. There are double camera tricks, but it can only happen on the same map... unless you write your own map loading call.

I want an engine where I can load up and string maps end to end, with some dynamic calls. Allocate some maps, and deallocate those of which that are out of screen, and then reload them when you are near again. I used this tactic in other game engines to create 'infinite' maps. Maps without borders, but are loaded by stringing maps end-to-end dynamically. The performance benefit is obvious here since you aren't loading a 999x999 sized map all at once.


See, if I were writing an engine like Sphere from scratch (i.e. without a base to work from), I almost certainly would have done the map engine in script and included it as a system script (I probably wouldn't have chosen JS though, Lua would have been my first choice I think).  But, knowing what I do now, I'd want a default map engine of some sort built into the engine.  An additional RequireScript() doesn't sound like much to you or me, but let me just say from experience, it's a big deal for someone just learning Sphere.  The first time I used Require/EvaluateScript in a game was something of a rite of passage; it was like I was graduating from "Sphere novice" to "advanced Sphere guy". :P  Don't underestimate the value of being able to do a ton of stuff without importing a single external script--it's empowering and is, in large part, what's made Sphere so approachable over the years.

Moving on: Regarding your ideas, let me just tell you a story.  Everyone thinks they want an object-oriented map engine, but I actually wrote one years ago in C++ and I hated using it.  NPC management was a pain in the ass, and just in general, putting together a working game required a bunch of tedious micromanagement of entity objects.  This wasn't a fault of the map engine itself--it was quite powerful--but simply that encapsulation isn't well suited to managing a map engine with all its various interconnected components.  In minisphere for instance there is very much a circular dependency between the map engine and persons manager that makes it hard to fully componentize.

What it basically comes down to is that OOP relies on the assumption that, as long as someone, somewhere, holds a reference to an object, that object remains valid.  So now, assume for the sake of argument that you do this:
Code: (javascript) [Select]

var townMap = new Map('MarketTown.rmp');
if (/* some condition that triggers this guy being there */) {
  var traveler = new Person("Some Guy", "TravelingSalesman.rss", map);
  // or maybe: townMap.createPerson(...)
}
// some more code and somewhere along the way, a reference to the traveler object is stored
// and persists past map destruction


The problem is, if `townMap` gets unloaded somewhere along the way, `traveler` is implicitly disposed and it's no longer safe to use any references to it.  Even though the object that holds the reference may have no way of knowing that.  This is why I like Sphere's system of decoupling persons from maps and referencing them by name: If all you have is a name, there are no assumptions that the person exists at any given moment, and it's then natural to call DoesPersonExist() first to check.  `person.doesExist()` is more awkward is totally against the OOP philosophy: The fact I have a reference at all and haven't explicitly disposed it should automatically mean it exists.

The alternative, of course, is to make Person objects completely independent from Map objects.  But at that point we're essentially back where we started, just with some fancy constructors tacked on.  And it's *still* not safe for the map engine to automatically destroy them since even in this case, object references are being passed around.

Being able to load and chain together multiple maps via independent objects would be nice, of course, I'm just not sure it's worth all the headaches.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #417 –
@DaVince: I added some console output to the latest builds, including what you suggested, printing out the error message (and file/line) for uncaught JS exceptions.  It also logs loading and unloading sounds, which I'm not sure whether that's being too verbose or not...

Mainly I'm just afraid that too many printf's will be a performance issue.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #418 –
Quote from: Lord English – on

@DaVince: I added some console output to the latest builds, including what you suggested, printing out the error message (and file/line) for uncaught JS exceptions.  It also logs loading and unloading sounds, which I'm not sure whether that's being too verbose or not...

Mainly I'm just afraid that too many printf's will be a performance issue.


It really can be on Windows. The console is silly slow there. Everywhere else, the slow part is the format string parsing.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #419 –
LordEnglish: Hey, all I can say is OOP maps is a solved problem, the way we deal with entities may have to change. That said Sphere's API really does simplify a lot, but it will always be an amateur API in my mind.

That said even if you don't go OOP on maps you can still have a system where you load up a map and draw potions of it on screen, because I know that is a hard problem to solve in Sphere presently.

Code: (javascript) [Select]

// basically you can only call this inside a MapEngine context
// it loads the map, puts it's characters into the same entity batch as the map engine,
// then draws it's tiles and obstructions starting from the specified offset (in this case 640x0)
// functions like DoesPersonExist are still preserved and you still can't make assumptions on the existence of entities.
var map = LoadMap("map.rmp", 640, 0);


The camera is the hardest part to figure out, because now we are giving freedom as to where you put the map. It's easier in fact to tell Sphere to instead, put the map on the edge of another map, moving or removing the edge script and making the camera realize there is in fact more to scroll to.

Code: (javascript) [Select]

// what it looks like using positional constants, which is very much a Sphere-like thing to do:
var map = LoadMap("map.rmp", MAP_EAST);

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