So im not sure if this belongs here or in Dev. help, but I thought it would receive more of an open audience here since it would give the impression I am not simply seeking c0dez.
Anyway, I have been using vitual maps(swapmap library) alongside normal .dmm maps in my project for a while now. Recently(3 hours ago), I decided to scrap the .dmm maps altogether and have the game dynamically allocate new maps/instances for maps as and when needed.
So I went ahead and re-factored/phased out all the .dmm references untill the game solely relied on the swap map library. All in all it seemed for the best as I ad cut the .dmb down to 600kb from 1mb and also released 2mb from the .rsc
Thinking I had done the best thing ever since 2010, I went ahead and uploaded to cloud so I could test things live so to speak; my God, I have never seen so much lag for simply walking on a map.
The old .dmm maps had a size of 200*200 and would run at like 3% cpu whilst doing menial tasks like mob/Move(), but this swapmap of size 100*100 was causing and I kid you not 55%! cpu. I am not even exaggerating, and this was just 1 player... adding an additional player made things worse rising to like 90% at times.
So my question/reason for posting really is WTF is this happening?, Testing things on a smaller swap of size 40*40 showed acceptable cpu usage, profiling the code showed that Client/Redraw() was the culprit behind this heavy cpu usage?, but surely that would not bog the server(admittedly I have no clue about how networking works here)
Are .dmm maps special? is there a way for me to fool dream daemon that the swap maps are actually .dmm maps so it will handle things accordingly, My theory at this point is that dd is spamming Redraw() for each swapmap tile, whereas the .dmm tiles are all preset to be drawn once and saved or something.
To witness the lag:
http://www.byond.com/games/JeanSqribe/ShinobiArtsOnline
main map: 100*100
test house: 40*40
#shameless plug ^_^
ID:1474508
 Jan 19 2014, 2:17 am
|
|
But BYONDs default map format does not allow me to:
->Create maps on the fly ->Edit maps on the fly ->Save and unload those edited maps at will -> Remove unused maps(although this probably doesnt affect anything) Basically all those features are necessary for my game's vision. I want my players to make their own worlds, and the game will be in a constant state of development. BYONDs .dmm maps are static and that shuts down all those Dreams of mine The view is indeed fullscreen, and it updates resolution based on the clients monitor size, as for client/Redraw() ill try and find it/what its doing to my maps :/ Edit: Redraw() is a proc from some radar library, I had thought it was native since I have never seen it spike this way. Probably related somehow. | |
Then you're just going to have to deal with issues like these. Until BYOND gets a native method of saving/loading maps, it's never going to be fast or efficient.
I tried making a game like you suggested before, and I even made my map saving/loading features that was a hundred times quicker and more efficient than swapmaps. I still could not get satisfactory results as far as efficiency was concerned and eventually decided against making this game because BYOND is just not suited for it. | |
Yea I also have a nice efficient system for saving/loading maps, this is probably why I never really noticed anything when running swapmaps alongside the .dmm monoliths. I guess you are right though, I thought this would be the version to try this sort of thing with all the multi-threading that is being thrown around lately.
| |
My guess is, Swapmaps probably loads maps differently to how they're handled as dmm files. I'm taking a guess here, but this radar library you're using is probably looping through things on the map, and since you've used Swapmaps to load the map I'm going to take a guess and assume there is a lot more on the map as opposed to using a dmm file.
Try disabling the radar library and see if that fixes things, if it does you've found the problem. | |
It is part of the problem but not entirely, my other project which is a mapmaker for swapmaps also has the same lag issues when loading the 100*100 map. I never noticed before since the map maker by default has a small view size, it seems rendering a large portion of a swap-map to the screen is the issue here.(also guesses on my part)
| |
Swapmaps is slow at loading and saving maps. This is an issue you cannot get around. It will take several seconds to load or save a map that is 100x100 in size (depending on the computer, it could easily take 10-20 seconds).
Your options for this are... 1. Get a better server to run the game on. 2. Make your own map saving/loading functions (this might improve saving/loading times, but not significantly) 3. Make maps smaller, smaller maps save/load faster. That's all. Unless BYOND gets native map saving/loading functions, you're just going to have to deal with the fact that it takes a long time to save or load maps. This is exactly why I decided to not work on a similar project. | |
the 100*100 map is created at world/New(), so ideally it is ready when any player joins. By rendering I meant the map itself being displayed on the players screen. Anyway I have decided to revert to having the .dmm map to serve as the landing site; and include many smaller maps for player expansion.
surely its not the server's fault, as my own quad core pc was also having similar issues. Thats how I managed to find out about client/Redraw() Hey if we all gave up on these things, who will be the first to make it? (: | |
If the problem is displaying the map causes lag, then what is your view size?
As I previously said, swapmaps may load/save maps differently to how a dmm file does. And large view sizes combined with a lot of things in view can cause lag. If thats your issue, make the view smaller. | |
I will play around with the things. If anything I think its about time Lummox made a swapmaps 2.0 that taps into his multithreading updates :)
| |
To my knowledge multithreading only really effects interfaces and displaying maps on screen right now. The issue with swapmaps being slow is 100% down to reading and writing files.
If multithreading could effect swapmaps, it already would (it's not like you need to add special code to make it work or anything, you know?). Like I said, if you want to save/load maps faster, you need a better computer, save/load smaller maps or make your own function to do this that is more efficient. If your issue is displaying a lot of stuff on screen/using a large view size, then make the view size smaller. | |
when they release the flash client, I will start to worry about this seriously. It's not really worth all that effort at this moment of time.
The ammount of time spent on working on a byond project is inversely proportional to the satisfaction you get whether or not you ever finish it. Sucks but true | |
Making your dream isn't all fun and games. Sometimes it's a lot of hard work and effort. Sometimes your dream will always be just that, a dream.
It sucks, but that's life. | |
I like when stuff like this happens because an unexpecting developer expects that the development platform (byond) should be able to do something like this in softcode but its just not possible. It just takes a good example to show the developers "Can't you see that we need access to this or that?".
I hope they get a look at this post! I've spoken with the Devs at length about getting dynamic maps put in, its just a matter of how and when I guess because they are definitely interested! | |
The only other thing I could imagine causing this is simply you have a large view size, and your maps are packed with a lot of overlapping detail. A screenshot of the game would make it easy to figure out if this is the case. (I haven't taken a look at how swapmaps works internally, but it may handle saving/loading turfs with overlays differently)
I will say this. You're better off using BYONDs default map format. Saving/loading external maps is not efficient. The file sizes are usually huge, saving/loading them is a slow process (that becomes exponentially slower as maps become larger), and it requires a lot more hassle just to get this system set up and working.
What you're trying to do right now is reinvent the wheel. Except your wheel looks more like a square.