ID:2376827
 
It's been one of those "interesting" weeks, with lots of different items clamoring for attention and a big question as to which mini-project I should tackle next.

Earlier this week I released 512.1427 with the brand new wave filter, along with a lot of important miscellaneous fixes. Some of those fixes were to issues I discovered myself, and it's nice to catch something and fix it before the rest of the user base runs into it. The wave filter is pretty awesome, so I hope it'll see good use in some games.

One of the bigger things I took on this week was examining var memory and init time for objects, because as I mentioned previously (more details in last week's Patreon post), InitObjectVars() was marking some vars as "changed" that didn't actually differ from their prototypes in any way, and it was because we actually had no reasonable mechanism for the var lookup fallback to go to the prototype and figure out what the var's value should be. So I put in an optimization that should help memory by avoiding the need for a bunch of turfs or whatever to expressly set certain vars that could simply be looked up from the prototype. Total savings in SS13's /tg build: about 11%. Honestly I'm shocked it wasn't higher. However it appears not only is there a memory benefit, however modest, but there's a speed boost as well because objects aren't having to initialize a bunch of vars.

So a few things are on my radar right now. A huge one is that there's a bug report on the null-conditional operators, as it seems a line like a?.b += c fails spectacularly. Even a?.b = c, which does work, doesn't really work the way I want it to because of the way it's pushing the expression to the stack. So that's not great, and it's something I need to deal with.

With the a?b += c case, things are really complex, because if(a) a.b = c isn't strictly equivalent; I think it should always interpret c, even if it isn't used (e.g., if it's a proc call or an expression with a side-effect). I'd actually be fine with it the other way, but I know either one is going to bite me in the butt so I'd rather do it in the way I think is most internally logical. The problem is figuring out how to rewrite the assignment operator, and also the math-and-assign operators, to handle this correctly. It may, in the end, need a new instruction code to do this the right way.

Another item on my mind has been maptext. People have requested for ages that I add some kind of metric support to that, and honestly I'd really like it too. Problem: maptext is a client-side feature, and metrics are server-side. The ideal way to handle this would be for the server to do this all on its own, but for Linux that would involve using something like the FreeType library, and holy crap is it hard to figure out how to incorporate that into byondext. A secondary option would be for the server to talk to a client, and have metrics strictly be client-based; the benefit of that is, if for some reason the right font isn't installed, the metrics will accurately determine what that client sees. I might end up doing something like the secondary option just because even though it's a mite slower, it's going to be client-correct and (this is the important part) a crapton easier.

There are also a few other bug/feature items figuratively sitting on my desk, that I'd like to get to soon.

Thanks everyone who's been supporting BYOND with your Memberships, donations, and through Patreon. All this feature creep is for you guys. Now go out there this weekend and show your dad some appreciation--or if that's not an option, adopt someone else's.
Send me a message if you want to implement FreeType into BYOND.