As Ghtry mentions in post [link] it would be very cool to have a built in map exporting/important feature.
Yes there are a few libs out there that do it but I doubt they are as efficient or bug free as if it was handled internally, right? All you would need is a variable that determines if an atom should be included in a map dump, DmmExport() and DmmImport() instead of having to try to work out how those libs work. :S
ID:133234
 Jan 16 2009, 11:55 pm
|
|
|
Jan 17 2009, 3:04 am
|
|
Android Data
 |
A built-in method would indeed be nice, as it would allow for map loading/saving at a much faster rate than can be done using a library.
|
I agree, and apart from that a map datum would benefit dm too.
You could use different maps and draw them on different surfaces, give them different z levels to display( this would be very, very nice ) and so on. | |
I would love the speed, my own map saving/reading system uses huge amounts of CPU saving a map larger than 100x100.
| |
Jeff8500 wrote:
I would love the speed, my own map saving/reading system uses huge amounts of CPU saving a map larger than 100x100. Mine saves over 100 thousand turfs in 2 seconds. And you guys said I sucked at coding. Which may still be true but still. Beat that. I am not even exaggerating. It doesn't take up any noticeable CPU in world.cpu, or at least not long enough for it to make a difference. I used it to save 3.75 mil turfs (the entire 500x500x15 map) and timed it, it took about 2 minutes. I'm not saying the code for it isn't "crappy", but it does what I want and it does it good. So meh. My intention is not to brag, and I don't want to brag because that is lame, but if telling facts is bragging oh well. But, I confess, all it does is convert some information about the turf into text and then put it into a list then save that list. Like the type and its location. It also saves the Durability var of the turf. And that is it. So it doesn't actually save everything about the turf, just a few things, then when it loads it makes another one with those few saved attributes. | |
My guess would be that you combined BYOND's internal saving with area saving? I wanted to keep my savefile small, and thus, I used a custom map saving system that converts the map into text and then compresses it with Run Length Encoding.
| |
Jeff8500 wrote:
My guess would be that you combined BYOND's internal saving with area saving? I wanted to keep my savefile small, and thus, I used a custom map saving system that converts the map into text and then compresses it with Run Length Encoding. I don't what any of that stuff is =P. I know a few things well, but when it comes to terminology or other things, I know nothing. Time to check the size of the savefile currently so I can give you an example: Amount: 250'000 turfs. Time: 1 minute 37 seconds. File Size: 10.2 megabytes. That took longer than I am used to waiting for 250'000 turfs, but that is because I usually am not the one hosting. I am using a very old 750 megahertz computer, so writing the file was probably really slow or something. Well, whatever my computer's specifications are, its from the year 2000, all I know. Maybe 2001. | |
Dragonn wrote:
Jeff8500 wrote: He first converted the map into a text-based format. He then compressed it with RLE. So if he had an input string of: wwwwwwwwwwwwwwwffffffffffwwwwwwwwwwwwwww (a bunch of a walls, floor in the middle, and more walls) The output from the RLE compression would be: 15w10f15w (15 walls + 10 floors + 15 walls) | |
You can't accurately get a file size for 250000 turfs, as I cannot save that many without using much CPU and time.
Are you only saving turfs, or other objects as well? If I were to save 50 different types of turfs, each with a type path 10 letters long, and they were in perfect rows of 5000, my file size would be only a couple of KB. To figure this out: Num. of types * (length of type name + 2) + (2 + digits of length of number of types in row)*number of rows. Note that types is being used loosely for atoms. The first two is because in 26^x > number of types, the smallest possible whole number x can be is 2 in this case. The second 2 is needed because of how I store compressed data. This is how I save each of the four major types. In our case, we would have 50 types, each with a 10 letter long path, in 50 rows of 5000 turfs each. 50 * (10 + 2) + (2 + 4)*50. We get 1200 bytes. Then you need to add information that heads the file, which we will say is about 20 characters long (even though that is a little longer than what a 500x500x10 map would be headed by). 1220 bytes total, or a little over 1 KB. In a realistic situation, things won't be so perfect, plus I need to save objects, mobs, and areas as well due to a design flaw (I should have made it more flexible from the start). However, it should still be much smaller than 10.2 MB! | |
Dragonn wrote:
Mine saves over 100 thousand turfs in 2 seconds. And you guys said I sucked at coding. Which may still be true but still. Beat that. I am not even exaggerating. It doesn't take up any noticeable CPU in world.cpu, or at least not long enough for it to make a difference. You do suck. At grammar. Which may still not be true but still. All jokes aside, clever and quick map saving can be accomplished with some creativity. What you're boasting is proprietary model, which works excellently for your game doing all it needs to, but that same map saver won't work for another game. In other words, it is tailored to fit the requirements of your game. Only store that data which needs to be stored. | |
Using some cleverness, I could do much, much better - I could save a map, no matter how large, in milliseconds. And the saved map data would be a single integer.
Tradeoff: The map has to be procedurally generated, and loading will require you to re-generate the map. | |
Which means it's not actually map saving, more like map reproducing. It could potentially be a good base for map saving though, but then again only with procedurally-made maps.
| |
Sure it's saving the map. You've stored all the information that uniquely identifies it - think of the procedural generation as a compression algorithm. You wouldn't say a zip file doesn't store its contents because it has to do some work to decompress it - it's just that procedural generation allows you to massively compress the map.
| |
Jp wrote:
Sure it's saving the map. You've stored all the information that uniquely identifies it - think of the procedural generation as a compression algorithm. You wouldn't say a zip file doesn't store its contents because it has to do some work to decompress it - it's just that procedural generation allows you to massively compress the map. Wouldn't that mean that the zip compression algorithm instead stored a key to the data it protects rather than the data, meaning that all types of data are reproducible via key? | |
No, it isn't saving the map. A zip file contains the data of the files in it, just compressed. What you're doing is saving an identifier (or alternatively, the means) to procedurally reproduce that specific map at its initial state, not saving the map's data, so there is not quite any compression or actual saving involved. After all, if it was actual saving, you'd easily be able to save a handmade map, or an updated map (after receiving in-game changes). But this method can only restore the initially generated map, though as said it would be a good base to use to save an updated map; you could save only what has changed since its generation, along with the seed/number for the initial generation of most of the map.
| |
Tom and I have discussed this sort of thing before because it would definitely be an awesome feature, and because there's some code that handles map saving and loading already so it'd be great to make that available in-game. The problems that have come up are 1) the .dmm format may not be up to the task of saving certain maps like ones with heavily nested objects, 2) I don't really understand much of the map loading/saving code, and 3) the new beyond-64K limits are actually not compatible with the existing saving/loading code which is all based on 2-byte IDs, so some changes would probably need to be made. For my part I suspect it'd be easiest to save and load quickly with a new custom format, and with rules like not allowing any turf references outside the saved area to be preserved.
So basically this has come up on the drawing board, but it's not trivial so we haven't come up with a game plan for it yet. Also because it's a larger project in scope than a lot of previous work, it hasn't really found its way into one of the other releases where much of the work involved chasing bugs. Now that we're in more of a big picture mode, features like this become more feasible. I expect this project to be a challenge, but it would be worthwhile. Anyway, I can't offer any promises on whether this will be done soon, in the later future, or ever, but I can tell you the idea has received serious consideration on more than one occasion. Lummox JR | |
Saving in stuff like the DMM format is a far, far less trivial task. Recently, IainPeregrine informed me of something that may allow me to speed up map saving significantly, but I have other things to do first, as well as building up the enthusiasm to actually work on pif_MapLoader again
| |
My library isn't confusing to get working with the basic stuff... though it doesn't save properly right now.
| |
What, precisely, is the difference between the processes used to procedurally generate a map, and the processes used to de-zip a zipfile? It's just code that's taking a unique identifier and restoring the original data from it. You can think of procedural generation as compression via storing the steps required to create something, rather than storing something - it's a perfectly valid compression technique.
Sure, it can't save changed maps in the pure version - if you wanted to do a full-blown procedural saving system, you'd save the seed for the terrain and then save all the objs and mobs seperately. It'd still be damn fast to save and quite small in storage space. If you can modify turfs, too, you'll have to save the modified turfs. I honestly don't understand what qualitative difference there's supposed to be between a zip file and procedural generation. A zip can save anything? Well, yeah. So can procedural generation, if you find the right seed. That is an extremely expensive process, but you can do it. EDIT: Perhaps an instructive example: the SPC sound file format. They're incredibly small. I have the entire soundtrack for Secret of Evermore - 72 bits of music - stored as a 292 KB (That's kilobyte) RAR-compressed set of SPC files. The reason they're so small is because they save the music by saving the instructions required to reproduce it - they're the instructions that should be sent to a special processor the SNES had for generating sound. By emulating the processor and passing it the same instructions, you can reproduce the music perfectly - with very little overhead. They also use samples extensively, so they're a bit like the MOD format in that regard. Anyway, you wouldn't say that an SPC file doesn't store the music in some way - and the process it uses is analagous to saving a procedurally generated map by saving the seed used. The SPC file format is an example of saving via procedural generation. | |