Stranded Optimization and Saving

ID:115745
 
Jul 11 2011, 4:25 pm
I'm going to be talking about two issues that's bothered me with Stranded.



CPU USAGE:
Stranded has had CPU issues most of which came from a oversight I made and was slightly aware of. Dealt with optimizing things and such.

How ever the new light system seems to be a burden to a lot of people's systems as well not to mention the world generation is a lot. Luckily saving/Loading seem to be fairly light (at least with a fairly fresh world).

I'd appreciate it for who ever to download it and enjoy it to leave by a run-down of their CPU usage: 1. during generation, 2. after/doing nothing, 3. moving, 4.saving/loading. My PC is fairly capable of handling a big work load so much so I wasn't aware of the CPU leak issue that I fixed.




Saving Issue: This issue is an oversight more or less. A player brought it to my attention that his world was merely sand and water and not much else. I deduced that he must have closed his world during a save. So I edited the window and made my own close button.

If your host or playing by yourself it saves the world then exits you. If your just a player it just saves your file. The same issue as before of messing up saves can still happen in an unexpected crash or closing via task manager.



Here's a screenshot of Stranded's new window. Granted it's identically the same save for the top bar, but I think editing/adjusting anything default/standard gives more character to a BYOND project.
Jul 11 2011, 4:40 pm
#define DEBUG

Then run the profiler to see what processes are taking up the most CPU.
Jul 11 2011, 4:59 pm
Thanks, I wasn't even aware BYOND had such a feature.

However, I know what has caused the CPU leak and fixed it. The thing is now the World Saving/Loading and especially World Generation seem to be especially straining.

I just want to know if it's playable and such. The point of making the high-score kept skills was so sporadic hosting wouldn't effect a player since I have no hosting capabilities.
Jul 11 2011, 5:12 pm
I'm hosting but I can't provide stats because its on my remote server. Join it and see for yourself.
Jul 14 2011, 10:36 pm
Well, as for the saving. BYOND keeps running if you click the X to save. It does this until done. If you try to open the game again while this is still going on it causes problems. I actually made a saving system that is more or less instant. If you would like I could test it with a 1000x1000 map and if it comes out a good speed send it to you?

Also, for the lighting I had this same issue a long time ago. I resolved it somehow... I think I had the turfs have a lighting variable and this just effected an object overlay. I'm not sure. Also, using set background in all loop proc's helps immensely.
Jul 14 2011, 10:39 pm
Oh! To add. BYOND has trouble processing large save files. So, what my system does is every 1000 turfs are stored in their own save file within the WorldMap folder. Then I simply used the flist proc to get the files, and there ya have it...

Again, if you want you can have a copy of my saving system... No credit needed either.
Jul 14 2011, 10:57 pm
It took a minute and ten seconds rounded to the closest five[to let you know my laptop isn't the best.. Not by far...].

The only things stored are it's icon, overlay, density, opacity, type, and location. Honestly, a lot of this information could not be needed less the game has runtime changes(as I image it does). There was 1,000,000 turfs and it created 2000 save segments. That's 500 per segment. Idk, this could be useful to you. This will be my last post because I'm somewhat blowing up your comments..
Jul 15 2011, 9:57 am
It's fine to blow up my comments, sorry I haven't been checking this frequently I'd like to see your save system and I'd of course give credit.

Jul 15 2011, 10:43 pm (Edited on Jul 15 2011, 10:49 pm)
Well, I did do further testing and it turns out there was a mild oversite. The problem still lies in the DM language's build in save system. What you could do however, is perhaps make a txt file with information in params inside it. Idk, I've been working somewhat diligently on this and getting almost no where. It takes about five minutes to store 300x300 turf informations. The thing is once a savefile gets so big it causes massive lag, and also the new() proc for a savefile causes lag too even if the file already exists. One solution I've come up with is to create the estimated files before they are used then store them in a list. However, once the list gets to a 253 count an odd error occures. Blasted DM... I'll try to look into this some more for you since I somewhat got your hopes up. I'll do this over the next two days not just for you but myself as well. A speedy map saving system is something I've been wanting for a LONG time now. I thought I had one but it turns out I didn't. It was slightly faster then the typical method and doesn't allow for server lock up however lag is very obvious while it's doing it's stuff..

As said, I'll probably comment back on here in two days to tell you I wasn't able to find a solution... Sorry for me jumping the gun.

*edit* Oh, and if you'd like once I'm done with my "research" I'd still be glad to hand over a copy of the system I currently have. I suppose anything is better then nothing.
Jul 16 2011, 3:02 am
Ok, you should probably know the current save system only stores the vars I need as text strings, none of which are icons. Not sure if that helps.
Jul 21 2011, 12:34 am
Sorry it's been more than two days... I kinda got lazy. I'm exploring an idea to use TXT files instead of the build in save system. It seems to be coming along smoothly. Idk, I got lazy again just now(it's 6 in the morning so I gotta sleep soon). I'll see what I can do about the saving system over the the next several days though. It seems it would still take about a minute to save 1,000,00 though.