mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-30 11:32:20 +00:00
d34fa4c642
* 'optimizes' space transitions by like 0.06 seconds, makes them easier to read tho, so that's an upside * ''''optimizes'''' parsed map loading I'm honestly not sure how big a difference this makes, looked like small percentage points if anything It's a bit more internally concistent at least, which is nice. Also I understand the system now. I'd like to think it helped but I think this is kinda a "do you think it's easier to read" sort of situation. if it did help it was by the skin of its teeth * Saves 0.6 seconds off loading meta and lavaland's map files This is just a lot of micro stuff. 1: Bound checks don't need to be inside for loops, we can instead bound the iteration counts 2: TGM and DMM are parsed differently. in dmm a grid_set is one z level, in tgm it's one collumn. Realizing this allows you to skip copytexts and other such silly in the tgm implemenentation, saving a good bit of time 3: Min/max bounds do not need to be checked inside for loops, and can instead be handled outside of them, because we know the order of x and y iteration. This saves 0.2 seconds I may or may not have made the code harder to read, if so let me know and I'll check it over. * Micro ops key caching significantly. Fixes macros bug inserting \ into a dmm with no valid target would just less then loop the string. Dumb Anyway, optimizations. I save a LOT of time by not needing to call find_next_delimiter_position for every entry and var set. (like maybe 0.5 seconds, not totally sure) I save this by using splittext, which is significantly faster. this would cause parsing issues if you could embed \n into dmms, but you can't, so I'm safe. Lemme see uh, lots of little things, stuff that's suboptimal or could be done cheaper. Some "hey you and I both know a \" is 2 chars long sort of stuff I removed trim_text because the quote trimming was never actually used, and the space trimming was slower then using the code in trim. I also micro'd trim to save a bit of time. this saves another maybe 0.5. Few other things, I think that's the main of it. Gives me the fuzzy feelings * Saves 50% of build_coordinate's time Micro optimizing go brrrrr I made turf_blacklist an assoc list rather then just a normal one, so lookups are O(log n) instead of O(n). Also it's faster for the base case of loading mostly space. Instead of toggling the map loader right before and right after New() calls, we toggle at the start of mapload, and disable then reenable if we check tick. This saves like 0.3 seconds Rather then tracking an area cache ourselves, and needing to pass it around, we use a locally static list to reference the global list of area -> type. This is much faster, if slightly fragile. Rather then checking for a null turf at every line, we do it at the start of the proc and not after. Faster this way, tho it can in theory drop area vvs. Avoids calling world.preloader_setup unless we actually have a unique set of attributes. We use another static list to make this comparison cheap. This saves another 0.3 Rather then checking for area paths in the turf logic, or vis versa, we assume we are creating the type implied by the index we're reading off. So only the last type entry will be loaded like a turf, etc. This is slightly unsafe but saves a good bit of time, and will properly error on fucked maps. Also, rather then using a datum to hold preloader vars, we use 2 global variables. This is faster. This marks the end of my optimizations for direct maploading. I've reduced the cost of loading a map by more then 50% now. Get owned. * Adds a define for maploading tick check * makes shuttles load again, removes some of the hard limits I had on the reader for profiling * Macro ops cave generation Cave generation was insanely more expensive then it had any right to be. Maybe 0.5 seconds was saved off not doing a range(12) for EVERY SPAWNED MOB. 0.14 was saved off using expanded weighted lists (A new idea of mine) This is useful because I can take a weighted list, and condense it into weight * path count. This is more memory heavy, and costs more to create, but is so much faster then the proc. I also added a naive implementation of gcd to make this a bit less bad. It's not great, but it'll do for this usecase. Oh and I changed some ChangeTurfs into New()s. I'm still not entirely sure what the core difference between the two is, but it seems to work fine. I believe it's safe because the turf below us hasn't init'd yet, there's nothing to take from them. It's like 3 seconds faster too so I'll be sad when it turns out I'm being dumb * Micros river spawning This uses the same sort of concepts as the last change, mostly New being preferable to ChangeTurf at this level of code. This bit isn't nearly as detailed as the last few, I honestly got a bit tired. It's still like 0.4 seconds saved tho * Micros ruin loading Turns out it saves time if you don't check area type for every tile on a ruin. Not a whole ton faster, like 0.03, but faster. Saves even more time (0.1) to not iterate all your ruin's turfs 3 times to clear away lavaland mobs, when you're IN SPACE who wrote this. Oh it also saves time to only pull your turf list once, rather then 3 times
The code in this module originally evolved from dmm_suite and has since been specialized for SS13 and otherwise tweaked to fit /tg/station's needs. dmm_suite version 1.0 Released January 30th, 2011. NOTE: Map saving functionality removed defines the object /dmm_suite - Provides the proc load_map() - Loads the specified map file onto the specified z-level. - provides the proc write_map() - Returns a text string of the map in dmm format ready for output to a file. - provides the proc save_map() - Returns a .dmm file if map is saved - Returns FALSE if map fails to save The dmm_suite provides saving and loading of map files in BYOND's native DMM map format. It approximates the map saving and loading processes of the Dream Maker and Dream Seeker programs so as to allow editing, saving, and loading of maps at runtime. ------------------------ To save a map at runtime, create an instance of /dmm_suite, and then call write_map(), which accepts three arguments: - A turf representing one corner of a three dimensional grid (Required). - Another turf representing the other corner of the same grid (Required). - Any, or a combination, of several bit flags (Optional, see documentation). The order in which the turfs are supplied does not matter, the /dmm_writer will determine the grid containing both, in much the same way as DM's block() function. write_map() will then return a string representing the saved map in dmm format; this string can then be saved to a file, or used for any other purose. ------------------------ To load a map at runtime, create an instance of /dmm_suite, and then call load_map(), which accepts two arguments: - A .dmm file to load (Required). - A number representing the z-level on which to start loading the map (Optional). The /dmm_suite will load the map file starting on the specified z-level. If no z-level was specified, world.maxz will be increased so as to fit the map. Note that if you wish to load a map onto a z-level that already has objects on it, you will have to handle the removal of those objects. Otherwise the new map will simply load the new objects on top of the old ones. Also note that all type paths specified in the .dmm file must exist in the world's code, and that the /dmm_reader trusts that files to be loaded are in fact valid .dmm files. Errors in the .dmm format will cause runtime errors.