Skip to main content

News

Topic: neoSphere 5.9.2 (Read 523798 times) previous topic - next topic

0 Members and 16 Guests are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #420
Now that I think about it some more, splicing maps together like this actually seems like a hack.  It's essentially an optimization to avoid loading the whole map into memory at once, right?  Which makes sense, but wouldn't it be better--and simpler--to solve the problem in the map engine itself (whether in script or native, OO or otherwise), where if you have a huge map, the engine can automatically load and unload pieces of it on demand, just like how, when you have a huge, multi-gigabyte file, opening it in hex editor is instantaneous because it only loads a few KB at a time.

Essentially we'd be letting the map engine "stream" the map, while still allowing you to work on it as one huge world in the editor.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #421
It's not all that difficult to make a basic OOP map engine that is fairly simple to use. I did it, or at least got the rough outline of it as the core of the TurboSphere map engine. It's all object based, and it works pretty easily.

I did make persons belong strongly to maps. It's not that bad a thing to do, it works fairly well.

You don't need to make a doesExist method. You just need to maintain an array of persons for the map. If the person is not in that array, they aren't on that map.

But I also believe that the map engine does not belong as a native, core part of the engine. It's one thing to include one, but it's not a core function. Chad Austin came to this realization before Sphere 1.0 was even released. He decided it would be better to expose a simple but well thought out scene graph and scene manager rather than a rigid map engine.

Both those components are a part of Pegasus. I disagree with some others on the necessity of the scene manager. I think it's fine for this:

Code: [Select]

function game(){
    while(true){}
}


to hang the engine. If we subscribe to a Mozilla-style view of JavaScript, where it is the C or Assembly of the web or our games, we need to trust it with tasks we trust C with. Even like managing the event loop.
  • Last Edit: April 27, 2015, 11:06:38 pm by Flying Jester

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #422

It's not all that difficult to make a basic OOP map engine that is fairly simple to use. I did it, or at least got the rough outline of it as the core of the TurboSphere map engine. It's all object based, and it works pretty easily.

I did make persons belong strongly to maps. It's not that bad a thing to do, it works fairly well.

You don't need to make a doesExist method. You just need to maintain an array of persons for the map. If the person is not in that array, they aren't on that map.

But I also believe that the map engine does not belong as a native, core part of the engine. It's one thing to include one, but it's not a core function. Chad Austin came to this realization before Sphere 1.0 was even released. He decided it would be better to expose a simple but well thought out scene graph and scene manager rather than a rigid map engine.

Both those components are a part of Pegasus. I disagree with some others on the necessity of the scene manager. I think it's fine for this:

Code: [Select]

function game(){
    while(true){}
}


to hang the engine. If we subscribe to a Mozilla-style view of JavaScript, where it is the C or Assembly of the web or our games, we need to trust it with tasks we trust C with. Even like managing the event loop.


Totally agree on that last part.

As for the object-oriented maps, let's consider a scenario:
* As you describe, there is an array of entities that each map exposes.
* Someone takes a reference to an entity from that array, and it gets passed around to a bunch of functions.
* The entity reference is ultimately saved somewhere for later use, despite its volatility.
* The map the entity came from gets unloaded. The entity goes with it.
* The object holding the reference has no idea the entity has disappeared and attempts to call methods on it.
* Game goes kaboom due to unexpected, and therefore uncaught, exception ("entity has been destroyed").

This can of course be dealt with by someone knowledgeable in OOP (don't pass around borrowed references), but let's not fool ourselves into thinking a good deal more vigilance is required.  I myself have made mistakes like what I described above.  This is the kind of thing that's likely to scare off novices, which is something we definitely DON'T want.

I don't know, I'm starting to feel like I have a totally different view of "what Sphere is" compared to everyone else here.  Either that or I'm just better at remembering what it was like to be a novice...  Either way, I'm leaving the Sphere 1.x map engine as part of minisphere.  The entire engine is less than 2MB anyway, so it can hardly be considered bloat.  Ultimately what it comes down to is that I'm a fan of "useful defaults": If someone wants to step outside the box that's fine, but sometimes it helps to know where the box is in the first place. ;)

Maybe some day I'll write a replacement map engine for Sphere in JS.  But I'll be perfectly honest, I haven't yet felt the need to do so.

As for the stage manager: I honestly have no clue what the thing is.  I saw it when I was perusing the Pegasus repo and even read the code, but I still have no idea what it's supposed to do.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #423
I'm not saying that I don't think we should include a default map engine. Just that, for TurboSphere, I want it to be implemented in terms of the engine's API, and not exist as a direct part of that API.



As for the object-oriented maps, let's consider a scenario:
* As you describe, there is an array of entities that each map exposes.
* Someone takes a reference to an entity from that array, and it gets passed around to a bunch of functions.
* The entity reference is ultimately saved somewhere for later use, despite its volatility.
* The map the entity came from gets unloaded. The entity goes with it.
* The object holding the reference has no idea the entity has disappeared and attempts to call methods on it.
* Game goes kaboom due to unexpected, and therefore uncaught, exception ("entity has been destroyed").

This can of course be dealt with by someone knowledgeable in OOP (don't pass around borrowed references), but let's not fool ourselves into thinking a good deal more vigilance is required.  I myself have made mistakes like what I described above.  This is the kind of thing that's likely to scare off novices, which is something we definitely DON'T want.



I guess to me I don't really see why this would be all that different than if you used the name of a person that had been destroyed in a previous map in the 1.5 API.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #424

I guess to me I don't really see why this would be all that different than if you used the name of a person that had been destroyed in a previous map in the 1.5 API.


It might just be my pragmatism kicking in.  If all I have is a primitive type (string, integer, whatnot) for a reference, I fully expect the thing it references to be pulled out from under me and I'm more likely to remember to check for existence at critical moments as a result.  Object references I treat as essentially being the object they reference, so I don't expect it to suddenly disappear without my knowing about it.

Maybe I'm just weird. :P
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #425
In that respect, though, the person does still exist. If they are no longer attached to a map, they could be placed back on a map, and it would work fine. It's just that you can't be sure if they are on a map unless you know what map they should be on. Since there can be a lot more to a person than what the faux-constructor exposes, this is a chief strength of this approach.

But in this scenario, you would be expressly drawing and updating certain maps. So you do know which maps are active and when, and you could find out pretty easily if the person was a part of an active map.

In my implementation, they could also (probably to some bad effect) be in multiple maps at once. But I haven't considered the issue of really drawing and updating multiple maps yet, other than seeing it's possible. Perhaps at that point, recursive map/person objects would be better? Or to only have a person reference their map and not the other way around? I have no idea.

Doing it as you do, making persons not attached directly to maps works better with this, then, since there is just a single list of persons that are active and updated with maps. If you were to reference the person's owning map from the person, too, that would (I suspect) be a simple way to support multiple simultaneous maps.

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #426

Now that I think about it some more, splicing maps together like this actually seems like a hack.  It's essentially an optimization to avoid loading the whole map into memory at once, right?  Which makes sense, but wouldn't it be better--and simpler--to solve the problem in the map engine itself (whether in script or native, OO or otherwise), where if you have a huge map, the engine can automatically load and unload pieces of it on demand, just like how, when you have a huge, multi-gigabyte file, opening it in hex editor is instantaneous because it only loads a few KB at a time.


I know what you mean, my Sphere Studio does that fast loading (well, technically it stores the integers into memory but that's far cheaper than the grid of tiles. I create these buffer zones, totally inspired by Google Map and I draw those on screen only when they come into view, but they always keep a weak reference to the tiles that belong to them).

That said, yes I am in support of better map streaming, but I still think that you are getting messy with sprites on far corners of the map, and managing huge obstruction grids, but to be perfectly honest I don't know how bad the performance drain really is. I just wonder if you can reference an entity by name and they better exist, even if they hadn't been loaded in yet since technically they are on the far side of the map and not yet "streamed in". This is why performance might be na issue which is why I wanted to go with the cell-like structure that even 3D games like Morrowind used when loading neighboring maps. With the programmer managing the cells there's no illusion to their existence, you'd know if you streamed them in.

I mean Morrowind had to deal with the same issues: referencing an entity on the far end of a map and then waiting until they suddenly deallocate. I've seen this happen and maybe it's a partial cause to the Crash to Desktop people witness. But most of the time even though the reference to the object goes away most classes seem to handle it just fine (damage does nothing, arrows pass through them, minimap indicators disappear, etc.) but then again you may also be right that it could be due to discipline.

And you are right again in that Sphere should be easy to learn. But many things are easy to learn and difficult to master (take StarCraft for instance). I think we can add a more advanced OO API in addition to a functional API like we have, that's all.

In fact, I have made an OO implementation of Sphere person's by wrapping all the get/set method.

[gist=563ba8a4bc6c199877a9][/gist]

I'll say the gist feature is my #1 favorite feature of these forums.

I'll also add that since entities are names I use a cache table in addition to the above so I can always reuse the API without creating more classes (though in reality this is very lightweight).
  • Last Edit: April 28, 2015, 02:08:28 am by Radnen
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

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #427
That's why I think the streaming should be handled in the map engine itself rather than the user splicing them together manually from outside.  The map engine is in a much better position to handle difficult cases such as you describe (entities outside the current "load window", etc.) as it has more complete information.  Anything done from outside involves a lot more guesswork.

That said, the Sphere map engine is very lightweight: a map is essentially just an array of integers, a tileset (usually not a huge image) and some entity data.  Even a 1000x1000 map is about 4MB worth of tile indices per layer and a single tileset.  There's basically no benefit to streaming it from disk when you have multiple gigabytes of ram to work with.
  • Last Edit: April 28, 2015, 02:20:36 am by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #428

That said, the Sphere map engine is very lightweight: a map is essentially just an array of integers, a tileset (usually not a huge image) and some entity data.  Even a 1000x1000 map is about 4MB worth of tile indices and a single tileset.  There's basically no benefit to streaming it from disk when you have multiple gigabytes of ram to work with.


Yes I know it's no much but I guess I'm more concerned that a bigger map means someone out there will attempt to update 3000 entities simultaneously. But then I guess that's on them then. ;)

Then the only thing I'll add by saying I liked the cell approach better than streaming it all in is because you can grow your maps infinitely in any direction. With one large static map, you kind of pigeon-hole yourself into that size. But I guess maps can always be grown to the right and bottom if needed.
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

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #429
The main advantage to the cell approach that I can see is its potential for dynamism: splicing in a different map depending on different factors.  SMB1 World 7-4 type stuff.  So it's not entirely without merit. :D
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #430
Celled maps also give a team project benefit, I mean try merging someone's 1000*1000 sized map with your edits. This can be facilitated with a merge tool, but it can be tricky to pull off.
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

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #431
@DaVince Just tried the latest version of Sir Boingers that you sent me via PM, I see you upped the framerate to 60.  This made the gameplay very smooth, but apparently had a subtle effect on the jump physics that makes it harder to control.  But no crashes.  So yeah, it must just be that you have a stock version of Allegro on Linux that still has the buffer overflow bug.  Apparently Allegro 5.1.10 is coming out soon, though. :)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #432
Good to know. And yeah, the physics are a thing to be fixed, the first thing I needed to fix was setting a sane framerate though. :P

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #433
What would be a good thing in the engine to be able to configure?  Right now all I can think of is the key/button bindings, which hardly seems worth the effort.  I need more stuff to be able to work up the ambition to do it. :P
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #434
Fullscreen mode and screen multiplication size would be nice. Also video filter, if you ever implement something like that anyway.