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.
Hi! Welcome to the forum for Platinum Arts Sandbox Free 3D Game Maker. I currently have the forums locked as I am attempting to properly update them.
In the meantime please join the new Discord Server!
If you have any questions please e-mail me through the Platinum Arts website.
In the meantime please join the new Discord Server!
If you have any questions please e-mail me through the Platinum Arts website.
DEVELOPMENT POLL: Names or Indices?
- Captain_Ahab
- Member
- Posts: 98
- Joined: June 10th, 2009, 5:12 pm
- Name: Richard
Re: DEVELOPMENT POLL: Names or Indices?
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.
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.
This is not a url, clicking it is pointless
Re: DEVELOPMENT POLL: Names or Indices?
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.
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.
This is not a url, clicking it is pointless
Re: DEVELOPMENT POLL: Names or Indices?
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.
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.
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"
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.
Still need to add some post-init checks; mostly to avoid having savegames bail out from reading an invalid script hash and the like.
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.
I was able to make the maps fully backwards compatible, so yay, no need to redo their spawns.Hirato wrote:Backwards compatibility will be completely and irreparably broken; you will need to PLACE ALL OF YOUR ENTITY SPAWNS AGAIN
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.
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.Hirato wrote:Increased Memory Usage (minimal)
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"
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.Hirato wrote:Decreased Performance (minimal)
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.
Completely false, they're technically even stricter now, bwahaha~!Hirato wrote:Less strict conformance checks!!
Still need to add some post-init checks; mostly to avoid having savegames bail out from reading an invalid script hash and the like.
This is not a url, clicking it is pointless
- kddekadenz
- Member
- Posts: 423
- Joined: July 17th, 2011, 11:02 am
- Name: kdd
- Contact:
Re: DEVELOPMENT POLL: Names or Indices?
Wow, thank you a lotHirato 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.
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
Kelgar is an advanced RPG beeing developed in Sandbox
-
- Support Team
- Posts: 2458
- Joined: April 27th, 2010, 5:31 pm
- IRC Username: CP
Re: DEVELOPMENT POLL: Names or Indices?
Cool, a dedicated RPG spinoff.kddekadenz wrote:Here is the github link for other people to check out the changes: https://github.com/Hirato/lamiae/tree/object-hashes
Julius wrote:Contribute to http://www.opengameart.org NOW!
Save the wiki!
Re: DEVELOPMENT POLL: Names or Indices?
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
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
- 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... - -1, -2, and -3 are no longer valid ammotypes, use mana, health, and experience respectively
- anywhere else you use -1 to define a "null" or "invalid" merchant or faction or whatever, the new value is "" or ()
- 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.
This is not a url, clicking it is pointless