ID:2680377
 
It's been another week of squeezing the code for all the speed it can give me. Things are still improving on both the client and server ends, though I think the next big breakthrough on the client (besides improving the renderer) will need more work than I'm prepared to put in for this next release.

One of the biggest things I did this week was add in a mini-library that should improve the speed of frequent divisions. Two divisions and a modulo are used when converting from a turf ID to x,y,z coordinates because of how turfs are stored, and there are multiple places where division by the icon width or physical height is done. There are still some modulos or divisibility tests in the code that I'd like to improve on, but they don't come up often enough to concern me too much.

It's hard to properly estimate how much SendMaps on the server and GetMapIcons on the client have improved already, but I would tentatively put that at 20% and 10% respectively, though a lot depends on the game. As an example of some of the improvements, sending turfmap updates (a big new chunk of turfs or a full refresh) was taking about 0.14 ms per client before this change in an SS13 test, and now I've shaved that down to about 0.08 or 0.09. Looping through turfs to look for movable changes went down from about 0.17 ms to 0.12, though honestly I feel I'm missing something there and could improve on that further. And I haven't even added the code I was working on for sending movable changes, but that's sitting at about 0.07 ms in my benchmark so I haven't worried about it just yet (though I still plan to do it).

A difficult thing about these numbers is that none of them exist in a vacuum, so the very same comparisons I'm using show an overall savings in SendMaps of about 0.07 ms per client, not a higher number as you might suppose; still that's down from about 0.37 to 0.30 so it's substantial. On the client pre-render the numbers are much murkier, but I getting icon bounds was a major time suck that I've improved quite a bit, and I managed to put a dent in FillPanes section of the pre-render.

My plan currently is to get 514.1555 out early next week after getting some more work in and also running some compilation tests for the Linux build. The gcc compiler has been known to be finicky with me before and is gonna need prodding to accept some of these changes, I'm sure. But after that I plan to switch gears again and get back to particle stuff, because one major thing I want to solve is allowing particles to take on a life of their own apart from their parent object, for rocket trails and such.

My thanks go out to all who've helped this process along by supporting BYOND through Membership and other donation channels. And for those who haven't, remember all this development benefits not just the game developers but also the players, improving your overall experience.

The (moderate) cold and rain are lingering here so it's been pretty depressing out, but hopefully we'll see some proper spring before it's too late. If you've got something better, do whatever you can to enjoy it. I'll see you next week!
Thanks for all your hard work dude... I can always say hooray for efficiency!

Lummox JR wrote:
one major thing I want to solve is allowing particles to take on a life of their own apart from their parent object, for rocket trails and such.

That would be very handy... I've created trails with them by setting the velocity to negate the parent's movement, but it just feels wrong to do it that way...
In response to Magicsofa
Magicsofa wrote:
That would be very handy... I've created trails with them by setting the velocity to negate the parent's movement, but it just feels wrong to do it that way...

I've done it by spawning trails of objects with the particle sets attached to them. Same thing, it feels just... wrong...