Have you tried dmp_reader and dmp_writer?
| |
Vermolius wrote:
Have you tried dmp_reader and dmp_writer? Not yet! I'll give them a try and see if it improves my load/saving speed. Thanks for the recommendation. | |
Geldonyetich wrote:
Not yet! I'll give them a try and see if it improves my load/saving speed. Thanks for the recommendation. From my experience, they're better all around but mainly file size. No idea how they will work on such a large map. Efencea's maps were tiny in comparison. | |
After mucking around with it a bit this morning, I can say that dmp_writer doesn't seem to be any faster at saving a 420x420 world than LummoxJr's Swapmap.
That same map would take "about a minute" for Swapmap to save. Breaking out my stopwatch, it seems dmp-writer took about 8 minutes, 27 seconds to save. This is with (DMP_IGNORE_PLAYERS + DMP_IGNORE_NPCS + DMP_IGNORE_OBJS) set. (It took slightly longer - about 8 minutes, 40 seconds - with no arg set. That makes sense, the map had none of any of these, but now it was looking for them.) So maybe I should take back any suggestion that Swapmap isn't good at handling at larger maps: compared to even the very code-light implementation of dmp_writer, it's super fast. Size-wise, however, dmp-writer is tiny. This 420x420 map in swapmap would take up about 18 megabytes, or ~10 megabytes in text mode. (Though this likely included all non-mob information.) dmp_writer's map is just 398kb! (It was only 415kb including mobs, objs, ect on a map that had none.) For my current implementation, it's looking like SwapMaps is a more likely library to use. In addition to the speed benefits, it's also a bit friendlier, containing quite a powerful implementation of features that makes managing maps much safer and easier. There's still one more thing I can try though: a simple savefile. You can't get much more native to BYOND than that! I have to admit, though, while I can do nearly everything else in BYOND, I'm pretty dang ignorant when it comes to using save files. I've a few tutorials open on that now. Even if I am using a library like swapmaps or dmp_writer (which endeavor of avoid the pitfalls of save files) I will need to learn savefiles eventually for all the data they don't pick up. | |
Geldonyetich wrote:
That same map would take "about a minute" for Swapmap to save. Breaking out my stopwatch, it seems dmp-writer took about 8'27" to save. This is with (DMP_IGNORE_PLAYERS + DMP_IGNORE_NPCS + DMP_IGNORE_OBJS) set. Yeah, that's the problem with DM-written saving, but they don't want to give us built-in saving support. Swapmaps also has a bit friendlier. It's hard to mess up a swapmap load/save because it pretty much manages the file infrastructure. If you need to find a map, swapmaps is built to do it. If you need the bounding coordinates, those variables are there. I'm pretty sure dmp_writer tries to mimic the DM savefile format. (What you would see if you were to open your map in a text editor.) There's still one more thing I can try though: a simple savefile. You can't get much more native to BYOND than that! I think that's basically what Swapmap does. | |
Vermolius wrote:
Geldonyetich wrote: Hmm... I might be wasting my time, then. However, a custom job should (theoretically) turn out a lot quicker if I want to super cut corners and convert things into the smallest piece of relevant data before saving them. For example, I might just tweak the Write() procs on turfs to only save their position in a list of turfs that have that type, ignoring all other data. (All other elements would be saved, but separately and with bare required data.) Then, when the game reloads, rebuild everything from this tiniest sliver of data. Seems a bit anal retentive, I know, but when your maps are this big, it might be worth the effort. | |
For example, I might just tweak the Write() procs on turfs to only save their position in a list of turfs that have that type, ignoring all other data. (All other elements would be saved, but separately and with bare required data.) Then, when the game reloads, rebuild everything from this tiniest sliver of data. Results of this: Somehow, even one that just saves coordinate and type of the turf takes longer than Swapmap. Even the process of running down a switch, categorizing all the types, and adding them to an appropriate list takes about half as long as it took Swapmap to load and have the whole world ready. (That's just the sorting - the process of saving or retrieving a giant list apparently takes so long I got tired of waiting. For I know it failed, probably looking for some index one byte at a time and missing it somehow.) Nonetheless, mission accomplished: I learned the ins and outs of savefiles. Now, I'm going to focus on what's important: realizing the game. Thank goodness we've already existing map saving libraries! | |
Probably my very next progress report will have something about saving in it, because that's basically what I've been tackling since my last entry.
I'm getting save support in on the ground floor, a first for my projects, as I can tell that this project is going to need it, and the sooner I'm optimizing those Read() and Write() routines, the better.
In my doing so, I can sympathize somewhat with what you're saying here. A 420x420 swapmap can take up some 18+ megabytes of space. I'm not too concerned about the space, what I'm concerned about is the long saving time: that same file will take a solid minute to produce on my computer.
So I may indeed be looking into an alternate saving routine. Perhaps something completely native to BYOND.
However, Swapmaps will nonetheless be useful for (say) smaller, well instanced areas. That's probably what they were originally intended for - not 176,400 turf behemoths. This is also assuming there's not optimization I can do.
Of course, if my game is good and stable, I suppose I could just save once per hour or something. I'm probably getting sidetracked here from what really needs to be developed: the game itself. Efficiency is good, but I've pigeonholed myself focusing overmuch on it in the past.