Right now, global images are like, super easy to implement. However, there are some issues with this (and other methods):
1. You have to optimize it yourself: Last time I checked, I think I heard that images are created on the client no matter where they are? So you have to soft-code it so that it only sends the images once they are near view, if you use it like that.
2. Like #1, network overhead will also occur once someone logs in and gets sent all those images unless you soft-code it so that only those near view will get their images sent.
3. There are no client-sided follower object types besides images and overlays, and overlays don't have a lot of the features images do, but images are per person.
4. Animating overlays are impossible. Transforming overlays only work when you remove and add them back, which costs more CPU than you might think.
5. Manually creating an /obj object that follows the player takes way too much CPU usage.
So in short, I want images that work like objects in terms of viewing or overlays that work like images in terms of editing/animating. This is not necessary, since I have workarounds, but it's worth a shot. I'm totally crazy about even 1% CPU usage on "simple" things like that... Not saying that it takes 1% CPU to do these things. (Also, I super want caching animations so I won't use 0-2% CPU upon changing animation directions depending on the animation [I do use lists to define the animation, and it still has too much good ol' overhead. Plus I wonder if I'd run out of memory if I make too many animations. At that point I'd totally have to create them at runtime or something, which would up the CPU usage. Or I could make it read animations from files, and then cache them and then clear the cache when too much memory is used. But I doubt I'd get to that point. Sorry I'm rambling inside a ramble.]. 'Cause it has to set transform on all those images, gaah. I also wish for an option for animate so that it doesn't set the variables on the server at all, just sends it over to the client and lets the client do it. But those are totes not feasible I guess.)
ID:1919257
 Aug 17 2015, 7:52 am (Edited on Aug 17 2015, 8:12 am)
|
|||||||
| |||||||
I know it is difficult, that's why I put simple in quotations, because it seems like it would be simple, but really isn't. Also, I'm only changing rotation (rotation and color soon, but not now), so I don't need to use the appearance trick (changing 1 var is better, according to the reference). I already knew about the appearance trick. The animations I use are not simple spin animations, but full-on walk/run/etc animations, and since there are different icons for all of the clothing choices and such, I can't even really use the appearance method anyways, I think. I just wish animate would recognize when I already put the same matrix in. I guess I could soft-code that, actually, if it is actually faster to do that even with one var. But that'd only make improvement if animate() doesn't set the appearance of the object on the server unless that's super fast too. I think I'll try that and see if it makes a difference. What would be super cool is if BYOND had a 2D animation system like Unity, where you can rotate and edit icons and either generate icon_states for a set of icons (for customization of characters, and particles!), or generate client-sided appearances that it uses when you set the animation. I already soft-coded one, but that's server-sided 'cause it requires animate() (or generating icons, which is client-sided, but takes WAAAAY too long when exporting, so I opted for animate()).
A global visibility setting for images is just what I want, crossing my fingers for that one, but it's not as important as my other feature requests. EDIT: I did the caching appearances trick, with one variable, it didn't even help, it may have even hurt it a little bit, I can't tell. But I'm keeping it so that I can use it for when I put color in. I also noticed that it wasn't the reference that had that appearance trick, but anyway, I saw it somewhere. I think it was a post by you. | |
It's more difficult than you might think, because overlays and underlays are implemented as lists of appearances--not as flexible lists that might include an appearance and an object. The only way I can see this working out is if I were to extend appearance in such a way that it could point to an object, but that seems like a can of worms.
Some kind of global visibility setting for an image--such that the image would get sent with the object, not sent manually--seems like it'd work out better. Even there I'm not totally sure how I'd do that yet, but I think that's probably the way to go.
The reason animate() has to set the vars on the server is that it has to generate the appearances it needs. If you have a lot of vars to change at once, you can always save a little time by caching the appearance and setting that directly in the animation--if that appearance has all the settings you want, that is, like the same icon/state and everything else. Obviously you can't cache a spin animation for one object and expect it to look right for a very different object that has a different icon.
Pro tip for animations that spin: You can do a full revolution in three steps instead of two. If your time is divisible by 3, just rotate by 120° each time. If not, you can probably find a different way to split it up. You can also cache those matrices so you don't need to create them anew each time.
One thing I would very much like, that isn't currently feasible, is a way of chaining multiple var settings so that they'd alter the appearance in one shot, avoiding a lot of lookups and stores in cases where several vars are changed. (Even better, I would like a way to optimize compiled code so it would call this routine.)