This has been a very good week for development, at least when I've been able to tear myself away from a couple of annoyances that kept dragging me off task.

I've been working a lot with Yut Put regarding the ongoing issues he's had, as one of the bugs that he reported that I thought would be fixed in 512.1413, wasn't. And in fact a new bug appeared. However there was a legit fix regarding images in that release, so I went to considerable lengths hunting down the other problems.

As it turned out, I think the actual cause of the "random icons" bug is an out-of-memory issue on the client, manifesting in really weird ways. This game has a lot of icons you see, and with too many of them loaded up at once--especially when using images, even if they're not in view of the client but are in client.images--it was causing DS to load up way, way too much memory. Thus I embarked on a quest to reduce that memory.

One thing I've wanted to do for a long time is reduce the footprint of icons in memory by sharing like frames. That is, if you have an animation that has the exact same picture repeating in several places, or various kinds of states like death, firing a weapon, etc. that might share common images, it only makes sense to combine them. So I made some changes under the hood to allow the DMIcon struct and its attendant structs to handle this, and then put some code in the client to look for repeated frames and simply share them if they're found. It's only doing this on a per-icon basis right now, but that's still pretty good.

However, that was only half the battle, because I also had to enact a new hash algorithm. The one we've used traditionally just wasn't good enough speed-wise for this task, so I had to find one that would do the trick.

As a result of the highly experimental nature of these changes, I opted not to do a release today. I think Monday is a much better choice. However, I can report that at least in the case of Yut Put's game, total memory consumption dropped by about 2/3. Considering some of that was server memory, the client-side consumption went down even more dramatically. This is huge.

Additionally, I've been looking into some odd Dream Maker bug reports, and a lot of those impact the parser. id:2351771 is turning out to be especially difficult to fix in the parser's current form, which means I'm going to have to do some radical changes there as well. In the process I discovered a couple of things about 512's raw string parsing that needed fixing, so those fixes will go into the mix too.

So it's been a pretty interesting week, not all of it in the ironic ancient Chinese curse sense of the word. Some really good things are happening under the hood for 512. If you'd like to keep those good things happening, don't forget to show your support by becoming a Member or hitting up the donation box. It's much appreciated!