I'm posting this week's development news a little early today.
Where we left off last week, 512.1448 was showing as basically stable except for a couple of minor issues, and an undiagnosed problem in SS13 that I still didn't have enough data for. We're basically still in that exact same boat, except that I have a couple of fixes on deck for 512.1449.
So why haven't I released 512.1449? Well, it all has to do with that refactor I started. Truth be told, I'm still changing things deep in the bowels of BYOND, and enough dust has been kicked up that I'm not comfortable releasing just yet.
One of the targets of this refactor is to try to reduce places where a lot of pointless small allocations are done, where a structure gets copied wholesale instead of using a better refcounting model. The new DMString class I've created can certainly have the same string using several different allocations, but when using the = operator or passing it back from a function, it will use refcounts. (Also it will try to use a global empty string where it can. A little overzealous application of that logic resulted in a problem I had to hunt down.)
Along a similar vein I'd like to have better handling of color matrices (I've done that a little bit), possibly transforms, and a few other items related to appearances. On the client end of things, there's a Tmovie structure that's used for handling atom.text; we don't use it very much anymore, but it has to be run through a "text printer" every time the text value is received to create a Tmovie struct, and the Tmovie contains a TmovieFrame array, and when a client appearance is copied (as in animation) the whole Tmovie struct and its associated frame have to be copied too. For obvious reasons I'd like to avoid this as much as possible by refcounting Tmovie, and the printing phase could be simplified by using a hash table to keep track of "movies" already created. So I'm also creating a homegrown hash table.
How much will be finished by the 512.1449 release? I can't say. My main goal here is to make the code a lot more streamlined where I can, and do so in a way that's mostly performance-neutral at worst, performance-positive at best. (Some routines I think will do slightly more work after DMString conversion for instance, but those routines are not used as frequently. For text handling on the other hand, like filling in the values in "I you have $[money] but [item] cost\s $[cost]", I've stuck with the tried-and-true approach because I believe it has a speed advantage.) Overall my concern isn't that I get all the refactoring done right away, but that I get the code in a good place for release.
Thanks again to all our wonderful Members, donors, and Patrons. You guys keep the show going and I'm grateful.
Don't forget, the Game-in-a-Day Challenge 2018 is tomorrow! Developers, get ready to get your code on.
Sep 14, 9:36 am