You always amaze me Makeii.

https://dl.dropboxusercontent.com/u/14221897/files/ Experiments/FlameTest.zip

Careful. There's apparently a memory leak regarding matrix manipulation in this example. Don't run this for extremely long periods of time.

I was tweaking around with the blend_mode and came to love BLEND_ADD, of course I am sure that BLEND_SUBTRACT and BLEND_MULTIPLY will also come in handy.


Does look a bit unnatural though.

After a few tweaks it looks a bit better.

Damn, but that looks good! How 'expensive' is it in terms of object count and processing needed?

Creating objs every tick really isn't that expensive, and you can avoid moving them a lot manually if you use animation.

In Makeii's flame example, using animation to spin the flames would bypass the need to keep transforming them, which would also prevent the creation of lots of new Appearances. The pixel movement as-is can't be done with animation, but I'm sure it'd be possible to find a compromise on that too.

Also just to let you know, the leak in the code came from reading atom.transform, a leak that was missed in 500's beta tests (probably because it's not all that common to read from atom.transform anyway). Assigning a fresh matrix each time rather than reading atom.transform would be enough to prevent that, but then so would animate() if you're willing to accept linear (or otherwise eased) scaling changes.

To be honest I am interested in the expenses in terms of network traffic. Would using pre-made image object types be more efficent in terms of it.

For example:

Versus


While the animate() is client sided, the server still has to give it instructions on how to animate. Correct me if I am wrong.

Well, I take it the traffic is minimal indeed, but in terms of creating a large amount of image objects and on a regular basis and for a larger number of players, I'm trying to find out it's cost.

Well, I'm heading to work, but I suppose I'd want to take a deeper look into it.

In general I'd be interested on how the data send in a client-server relationship in BYOND format would look like, what shortcuts it takes to minimize data-traffic etc.

I'd be happy to get some insight into this.

Here's a little bit of info on how BYOND networks objs and animations:

1) Each tick after turfs are sent, objs and mobs in view are analyzed and changes to what each client has seen are checked. A message for each (one for mobs, one for objs) is sent, which includes changes in layering, dirs, step offsets, pixel offsets, a few other stats, and most importantly the Appearance. Multiple copies of either message may be sent if too many objects have changed for one message. If any Appearance is new to the client, it's sent before this message. Quite awhile back, I decoupled pixel offsets from Appearances for objs and mobs so that this process would be a little cleaner on the network.

2) After the obj and mob updates are sent, pending animations for each client are sent. The animation info includes the start time and loop info and the object it belongs to, then for each stage there's a from and to Appearance (sent in advance if the client hasn't seen it yet--this includes the pixel offsets), easing, and time.

The animation message itself is quite compact, and the obj/mob map messages are relatively compact as well. Appearances can have a little bloat to them, depending on their contents, though in the grand scheme of things I don't think they're all that big. With animations, the "to" of one stage is usually the "from" of another anyway. Appearances are only sent if the client hasn't seen them yet, which the server keeps track of. (The client will also tell the server if it has let go of an Appearance it wasn't using anymore.)

Makeii's flame demo should be pretty good on new Appearances once all the rotations have been generated, since the alpha and rotation basically are tied right in with how long the particle has existed and they're the same from particle to particle; all that's changing is the pixel offset. Basically he'll only ever have 255 or 256 of them, not counting the background. The pixel offset and Appearance changes for each obj will be numerous however, and in his case will result in several obj map messages being sent to cover all those changes.

A version that relied strictly on animate() might need fewer Appearance changes and would also result in just one obj change (and one animation message) per tick; however it seems likely that new Appearances would also be needed to cover the pixel offsets in the animations, so maybe that would be a wash.

It might be that using the version with animate() produces too many new Appearances. With an animation of this type, that's bound to be an issue. Particles of other types might handle animate() much more smoothly.

Nice work.