LATEST CHATTY HEADER
Subscribe to Shacknews Mercury starting at $1/month!
Chrome Shack Community Guidelines Chatty Search
Scroll down to join the conversation.
New to Shacknews? Signup for a Free Account
Already have an account? Login Now
Subscribe to Shacknews Mercury starting at $1/month!
Chrome Shack Community Guidelines Chatty Search
Scroll down to join the conversation.
horrible Edition!!!
Oh god I haven't slept in over 24 hours and I'm sick and I just
Multiplayer Servers!
MercFox1 : shackeast.sytes.net
Shadowdane : shadowdane.shacknet.nu
Chicken Fur : 69.169.149.253
m0rfus (PvP/Mobs on) : morfus.dyndns.org
Haxim (TNT Server) : asplode.dyndns.org
Teamspeak : ts.shackbattles.com:9987
kill me kkill mee
Thread Truncated. Click to see all 199 replies.
For reference, I have a copy of foo/mercfox1 from a few weeks ago; it's 439 mb zipped up.
On my Windows machine, it currently renders the entire map in 4600 seconds.
On my work Linux machine, it renders in about 4000 seconds.
This generates 1,202,568 kb of tile data across 31,371 tiles. And the current map on the server is MUCH bigger.
There is a fair amount of performance difference because I depend on system.drawing, which uses GDI+. GDI+ is pretty slow in Windows for quite a few operations; Linux is using some wrapper around a lib called Cairo which seems to be a ton faster for a lot of operations, Get/SetPixel in particular (GDI locks the bitmap every time Get/SetPixel are called, there are workarounds though). I'm trying to balance the two; optimizing for Linux slows down Windows in some cases and vice versa.
Otherwise the slice stuff is already in the code.
On Linux, I can see almost 50% cpu usage, whereas on Windows it seems the GDI calls are hardware accelerated to some degree, so there might be some transfers back and forth to the video card going on or something - the CPU usage is under 25% (work and home machines are similar performance, quad core nehalems)
The immediate things I can do include changing from PNG to JPG and playing around with the tile sizes - currently they're 256x256 which might be a bit small. Both of these will decrease disk I/O, but I plan to add a dirty tile cache - only update the chunks that have changed since the last render (80% done). If the tiles are too big, it would reduce the efficiency of the dirty tiles.
My complications with lighting is mostly due to my threading model. I have N threads getting chunks and processing them in parallel. They each render to a scratch bitmap then recomposite it into the tile when it's done. If I did the lighting in a naive way, I would end up doing calculations for each light source multiple times, since light sources can spill across a boundary - i could potentially be doing the same calculation 9 times. My current thought is to cache the light calculations in another table, but I haven't worked out the details yet.
Also the save format does have lighting information in it, so I can dump out the base night sky light value for you once I get around to working on lighting.
The post has been reported. Thank you!
You must be logged in to post.
You must be logged in to post.