Platinum Arts Sandbox - Free 3D Game Maker Forum

I would want high performance and low memory requirements.
Should I have trouble remembering which file uses which index, I write a short bit of documentation to remind me as well as a nice header section within the file itself.
A standardized numbering system helps.

as I've explained numerous times, the memory and performance costs are quite minimal.
in a world where 4+ GB of RAM is the norm and where sandbox at its standard operation (with the highest quality stuff) uses way less than a quarter of that, surely everyone can spare a handful of megabytes.

Hmmm...
It'll be hacky, but I think I can retain backwards compatibility, I'll need to start keeping a game side version which is also stored in the maps to update things accordingly, but for now we can assume the absence thereof indicates that it's the old version that needs to be imported accordingly.
Working under that assumption, I can transfer the "index" field as a string into the entity itself.

I'll see how it goes.
Poll's closed, I'll start playing with it, and it seems the majority favoured doing it.

Okay, I've got the first iteration hammered out on git, it needed about 1800 lines worth of changes too, and that's not even including the files moved around.
It's ready for testing if anyone wants to go ahead, but it's not yet on the sandbox SVN, I'll do that once kddekadenz and friends have had some time to test it.

Anyways, I'd like to revisit the cons I provided in the opening post, with an implementation, they don't all hold up.

Hirato wrote:Backwards compatibility will be completely and irreparably broken; you will need to PLACE ALL OF YOUR ENTITY SPAWNS AGAIN

I was able to make the maps fully backwards compatible, so yay, no need to redo their spawns.
I since edited it out to exclude the need to update the game data, but that is false. Game data is about 80% compatible at best; If you explicitly set the factions, scripts, particle effects, and other misc stuff without using the magical "-1" value, you should have very little to worry about. On the other hand, if you primarily depend on the defaults you'll need to update them.

Hirato wrote:Increased Memory Usage (minimal)

It is very minimal; almost all of the fields in the structures are still the same size, but each entry now has an extra pointer (4/8 bytes), and there is also the new hashpool which is a centralised area for all the hashes, this also has some memory overhead, but it prevents successive allocation of the hashes/strings from using more memory; in other words it actually gives us rather big wins as far as that goes.
Memory use is still higher, but if anything, it'll be <1 MB for just about anything people will actually use sandbox for; this'll probably reach a few MB for something "professional"

Hirato wrote:Decreased Performance (minimal)

As strings are used, these need extra dereferencing operations, hashes need to be calculated, and then they are looked up in their respective hashtables, this is probably at least 8 times as expensive as a direct lookup on average, but it's done relatively infrequently, the big and noisy "update" signal aside.
Of course, this gets worse with longer strings/hashes, a hash is much easier to calculate from a 5 character string than one that is 20 characters long.
In the grand scheme of things, it's still really minor.

Hirato wrote:Less strict conformance checks!!

Completely false, they're technically even stricter now, bwahaha~!
Still need to add some post-init checks; mostly to avoid having savegames bail out from reading an invalid script hash and the like.

Hirato wrote:Okay, I've got the first iteration hammered out on git, it needed about 1800 lines worth of changes too, and that's not even including the files moved around.
It's ready for testing if anyone wants to go ahead, but it's not yet on the sandbox SVN, I'll do that once kddekadenz and friends have had some time to test it.

Wow, thank you a lot
I'm currently downloading it and will test it in the next days (probably tomorrow). Also I pointed Thomas to do so.

Here is the github link for other people to check out the changes: https://github.com/Hirato/lamiae/tree/object-hashes

kddekadenz wrote:Here is the github link for other people to check out the changes: https://github.com/Hirato/lamiae/tree/object-hashes

Cool, a dedicated RPG spinoff.

I merged it yesterday, I must be doing something right since I'd swear my framerate is higher by about 5 (81-86 --> 87-90) on "village" - it's probably because I added a hashpool (to save memory) and used it for the reference names among other things, which means there's less (de)allocations to be done every frame.
It should make an even more discernible difference on systems with slow allocations like Windows. As far as memory use goes, it was about 1 MB higher on village, but for large (as in REALLY large games) it should start slanting in favour of the hashes system, but this amount is really insignificant.


It should also be backwards compatible with the following caveats

1. The default scripts have changed - if you rely on them, copy them in or rename them.
   0 --> null
   1 --> default npc
   2 --> default item
   etc...
2. -1, -2, and -3 are no longer valid ammotypes, use mana, health, and experience respectively
3. anywhere else you use -1 to define a "null" or "invalid" merchant or faction or whatever, the new value is "" or ()
4. you now need to use /spawnname <name> to associate a spawn point with an id. when loading old maps, the second attribute is dumped into the id string automatically. saving and then loading the map in an older version of sandbox will cause problems.