One spot of really good news is that as of the 510.1346 release, the webclient is performing a heck of a lot better across the board, now that it skips drawing on animation frames between actual client ticks where nothing has updated.
Gamepad support has continued right along, with more work done on the macro UI so that setting up your own mappings should be fairly straightforward. I have a few question-mark items still on my list under this, so I've set them aside for the moment to focus on some other things. I'll button the rest up soon enough.
(I told Tom about the way gamepad foo is being mapped using the macro system. He thought it sounded cool, although that's probably because he didn't see the code, and also if he did see it it wouldn't be his problem. Remember, kids: lack of accountability is fantastic.)
Other features for 511 have been progressing nicely. Parallel animations are now a thing, and they are awesome. I wish I'd done them a long time ago. By using parallel animations, you can animate multiple vars on the same object, in different ways, all at the same time. You can even animate the same var in parallel, for some cool effects. Here's a fun little spiral I did:
// counter revolution
animate(src, transform=matrix(108,MATRIX_ROTATE), time=3, loop=3)
animate(transform=matrix(-108,MATRIX_ROTATE), time=4)
animate(transform=null, time=3)
// translation
animate(src, transform=matrix(64,0,MATRIX_TRANSLATE), time=30, flags=4)
animate(transform=null, time=10)
// revolution
animate(src, transform=matrix(-108,MATRIX_ROTATE), time=3, loop=3, flags=4)
animate(transform=matrix(108,MATRIX_ROTATE), time=4)
animate(transform=null, time=3)
The object first rotates clockwise; at the same time it moves outward from the center and quickly back in; also at the same time, it rotates counter-clockwise. Each of those transforms is interpolated like normal on its own, and all three get multiplied together. Result: the atom follows a spiral path, while keeping its orientation.
Or you could use something like this for a few explosive particles:
// calculate px,py,pz first; all are from -1 to 1 except pz is 0 to 1
animate(particle, pixel_x=px*64, pixel_y=py*64, time=pz*15)
// the first fall of the bounce easing takes up 1/2.75 (4/11) of the time
animate(particle, pixel_z=pz*16, time=pz*4, easing=QUAD_EASING|EASE_OUT, flags=ANIMATION_PARALLEL)
animate(pixel_z=0, time=pz*11, easing=BOUNCE_EASING)
People have been wanting this for a while, and it turned out to be easier than I was hoping. Yay progress!
Of course this means I'll probably have to figure out a good strategy for avoiding appearance churn when animating particles. The new mutable appearances probably won't get the job done in that department, since the issue is that so many new appearances have to be created for the animation process. I may decide to try shoehorning temporary appearances in, trading network bandwidth for CPU. Or maybe not. I may have to see how it shakes out and make a decision in 512. Also I have half a mind to create something missile-like that can be animated but won't act like a true obj.
SS13 peeps, I haven't forgotten var optimization. It's still way up high on my list.
This Sunday is Father's Day, so give your dad a hug or INSERT MANLY SPORTS THING HERE, and share some steak or ribs or something while the weather is nice. And with wedding season crashing upon us--as we speak I just got an invitation--better practice your dance moves, too. (Don't worry, folks; I won't be dancing. Nobody wants to see that.)
