ID:2399180
 
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.
"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."

That sounds good to me. I use a lot of that stuff in Dark Star. Would be nice to see even a slight bump in performance.
I don't know how much performance would be impacted by the proposed changes; for me it's a little bit more about memory, and just using that responsibly. Nevertheless if you have a lot of nested color matrices (e.g. parent matrix modifies child matrix modifies child matrix, etc.) I think there's a reasonable expectation of improvement along those lines, and likewise if I do something similar for transforms.
If we could get a simplified answer, how far away would you consider the ability to compile a project into a .exe?
The engine is good enough.
It's the platform that's the problem.
How about a webplayer that "just works", it'd change everything.
Then register a byond.io domain for all webplayer "hubs" like Vylocity.com or IOGames.space does
Rebrand yourself a new webplayer based BYOND platform.
In response to Kozuma3
Kozuma3 wrote:
If we could get a simplified answer, how far away would you consider the ability to compile a project into a .exe?

This is something that a lot of people I introduce to BYOND have questions about. People want to know the end-game result of where their project is going, so having a built-in way to do this is really important.
In response to Muhuhu
Muhuhu wrote:
How about a webplayer that "just works", it'd change everything.

As I've said before: "Just works" doesn't mean anything.
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.
Just wanted to say thank you for all of the recent work you've been doing with the engine. It's noticeable.

The engine has gotten a lot better since the last time I was around. It's been fun to toy around with dream maker again and be excited to try out new things. Especially for me, the filters and maptext improvements have been really cool to tinker with.