ID:1458183
 
I've been creating a new animation system for a game that makes heavy use of atom.transform for overlays to create a bones-like system that 3D games use often. For the most part, it does not have heavy CPU usage, only small to moderate (0~15 CPU at 60 FPS, the latter being on an animation that makes use of that 60 FPS) CPU usage depending on the animation, FPS, and other factors. However, I want to be greedy and loosen up the CPU usage on the server. Now there are two ways to do this: Client-side functions, or caching the overlays into a single/multiple icon file(s) with multiple/a single icon_state(s), keeping all transformations. Because of the way BYOND works, the former will probably not be created any time soon, so that leaves us with the other option. I wish to get some ideas on how to go about this as efficiently as possible as not to heighten the CPU usage, at least not for long intervals. So the question is: how would you lower the CPU usage of a system like this using DML?
What I did was create a list which holds all these icons, so you can just sort of pick them off. While they're in the list, they shouldn't be unloaded by the game. So it's a faster method.
In response to Laser50
Interesting, kind of what I was thinking of doing. It was along the lines of saving an icon (through code) of each overlay, and an icon_state for each animation for each frame, either dynamically or on the start of the world, and when it is finished, have players use the cached method instead of the dynamic method. This can be done through lists or saving to hard-disk/rsc (through implicitly calling fcopy_rsc), preferable the rsc since this is long-term and icons won't have to be cached again, though this could make for a large download size (which shouldn't be a huge problem.)
Assembling the list on game startup will probably save you the trouble of actually caching it when there's multiple players around. As small as the CPU usage may be while assembling it, it does save you a bit.
In response to Laser50
Yes. The only problem here is saving the transformations. Perhaps I could save icon's transformation using icon.Turn and Scale before saving? Also, it could be tricky to actually save the icons' icon_state's frames. Perhaps there is a better method.
You could save each individual icon_state inside the list with a unique name for each, then just recall said names to retrieve that state when needed? I believe Yut did something like this for Epic and I worked on something like it for another project of mine to improve performance of a system like it. Although mine only supported using Turn/Scale for N/S/W/E/NW/NE/SW/SE states. I never attempted transform() states, but it shouldn't make a large difference. Caching them in a list will also be able to make it so the list is saved and loaded at runtime/shutdown. So icon_states don't have to be generated a second time.
I haven't actually gone deeper into this myself, to be honest. Although I believe that just saving all the states would work best.

(of course, this depends on the amount of icon states you have, 10 wouldn't matter a lot, but 20+ would probably be best to be applied in a 2nd list, to keep them small, and therefor easier to use for both you and code)
Well, what I did was create another BYOND program that takes all the animations and varieties of overlays, converts the transformations to icon edits (matrix.Turn to icon.Turn) right before saving the icon, and inserts it as an icon_state frame and saves it into a .dmi file that depends on the overlay being saved. Afterwards, I need to change my code to reflect the changes. Problem solved!
Of course, that's how icon rotations used to be handled. We don't need to bloat the rsc by doing that anymore.