It's hard to believe it, but build 512.1442 seems to have finally gotten us off the roller coaster of never-ending bug fixes. The previous issues with the ongoing movement overhaul have been ironed out, which leaves room to create a whole bunch of new issues in bringing that project to the finish line.
Because nothing is imminent, this is the first Friday in quite a while I haven't had to do another release. So no more taunting the Friday release curse!
The last stage of the movement overhaul is going on now, and as predicted it's a big one, impacting a lot of code. I am so, so glad I did the preliminary work of moving a lot of things into structs that weren't before, and simplifying routines that compared bounds. That simplified a lot of this process, which would have been ten times worse otherwise.
Currently where I'm at with the movement overhaul involves changing up the routines that handle turf overhangs. An overhanger is an obj or mob whose step offsets and/or bounds have it covering another turf besides its official loc. Internally, step_x/y get "normalized" in certain conditions so that the movable should always be covering its official loc. (I could, and should, improve on that normalization.) But its bounds hang it over any other turfs, those end up in obj.locs as well and likewise it appears in their contents. That overhang logic was all based on integers, so it needs to be changed to support floating point. Anything over about 0.001 (actually 1/1024) away from an integer will be considered valid; anything within that bounds will snap to an integer, just to avoid headaches.
The client of course will know nothing of floating point offsets. It isn't worth the hassle to throw that logic in there, so as far as the client is concerned objects all have integer steps and step sizes. I may decide to change that in the future if it turns out games using a higher client.fps benefit from additional precision, but for now it stays as-is.
I'm still thinking ahead to 513 features, trying to come up with some ideas for that. But I'd also like to sneak more filters into 512 while the proverbial iron is hot, like perhaps a bloom filter which has been requested already, and also I'd love to add radial blur, conical blur, and ripples. I have an idea how to tackle bloom filters, but I need to get some feedback on what approach to take. I'll discuss that more on today's Patreon post, but because it's not under-the-hood stuff it's open to non-Patrons to view as well. (Comments are welcome on either post: that one or this one.)
Thanks everyone who's contributed to BYOND this month as a Member, donor, or Patron. I love you guys and deeply appreciate the support! All this feature work I keep doing, along with projects to optimize and keep making things better, is for you.
Jul 27 2018, 12:20 pm