Appearances now have an appearance_flags var that can control a few properties that don't make sense under any other var name. So far these flags include:
- LONG_GLIDE: Diagonal glides will take just as long as cardinal glides. In essence, the glide speed is based on max(dx,dy) instead of distance(dx,dy), so the atom will move farther (in terms of raw distance).
- RESET_COLOR: When applied to an overlay or image, this flag means that the base object's/appearance's color won't affect it.
- RESET_ALPHA: The base object's alpha value is ignored.
- RESET_TRANSFORM: The base object's transform is ignored.
The color var is undergoing a big change: color matrix support. (I am not extending the /matrix datum to handle color matrices; this will be a job for lists.) I'm very excited about this one, because it took a lot of painstaking, mostly Google-proof research to pull it off, but in the end I finally mastered shaders enough to make this work. This will work very similarly to MapColors(). The big challenge at this point is getting this data into the Appearance struct without a huge memory investment, so this is a work in progress, but the truly hard part--actually using the matrix--works. Color matrices will be animatable like normal colors will, and a regular color value should be treated--when interpolated with a color matrix--like a special-case matrix.
The glide_size value has been changed from an integer value to floating point. This is a big deal, because now you have full control over your glide speed. Want to cross a 32-pixel tile in exactly 10 ticks? Now you can!
I'm planning to add a flag to animate() to allow any matrix interpolation done for transforms to be linear. There are certain special cases where linear interpolation is desirable. What I haven't yet decided is whether this merits a new argument, or if it should be folded into the easing argument--where, ultimately, it feels like a hack.
All of the above adds up to the biggest raft of new appearance features since BYOND 500.
I'd kind of like to look into my concept of a faster client FPS value, if time permits. There's one outstanding bug report on images that relates to this, and needs to be addressed anyway.
In the world of bug fixes--I haven't forgotten about those--I noticed something in the way Dream Daemon sends files (and how Dream Seeker responds) that could be causing unnecessary delays when browse_rsc() is called for a lot of files the client already has. There's also a matter of small-list memory tending to grow over time in certain situations, impacting games like SS13. There are some webclient issues I'll be getting to soon as well, including adding support for all of the new appearance features. Webclient FPS is still on my list of ongoing things to work on.
This past Tuesday was my 14th BYONDiversary. We've been kicking a long time, and of course all this ongoing development is thanks to our Members and donors. If you've never been a Member before, or haven't been in a while, please show some love and help support this great platform.
Happy 14th. My 14th BYONDiversary was back in June. I think there's only 3 of us left from the 2001 heat.