There should be a rotation variable that can be applied to atoms to accomplish the same effect as Turn(), without needing to pointlessly create, modify, and assign a new icon file to them.
A quick search for directx rotation makes it seem like such a feature would be simple to implement
http://www.riemers.net/eng/Tutorials/DirectX/C++/Series1/ tut8.php
Preferably, this should also rotate the atom's bounding hitbox.
ID:650493
 Apr 9 2012, 2:22 pm (Edited on Apr 9 2012, 3:14 pm)
|
|
I second Darke. :)
| |
This has been requested before, but I'm pretty sure it requires them changing to quads instead of sprites. I don't think that sprites can be transformed the same way quads can. Using quads, it'd become trivial to add other vars like this to control the object's size, color, opacity, etc., and it'd all be rendered on the client by their GPU (not as an icon operation that's done on the client's CPU).
| |
Graphic processing handled by graphics cards? What is this wizardry?
| |
Forum_account wrote:
This has been requested before, but I'm pretty sure it requires them changing to quads instead of sprites. I don't think that sprites can be transformed the same way quads can. Using quads, it'd become trivial to add other vars like this to control the object's size, color, opacity, etc., and it'd all be rendered on the client by their GPU (not as an icon operation that's done on the client's CPU). Java does have the capability to apply Affine Transformations to drawn Images with its standard libraries, though I'm unsure if images drawn in Java are "quads" or not. But either way, good to know that this has been brought up before. | |
SuperAntx wrote:
Graphic processing handled by graphics cards? What is this wizardry? You jokingly called it "wizardry" but that's exactly the problem. The BYOND staff doesn't have anyone who is familiar enough with DirectX that this is just wizardry. I have a feeling there's a *ton* of work being done on the CPU that could be handled by the GPU. Think about how wasteful it is to do a rotation as an icon operation, generate a new texture, send the texture to the GPU, then render it on a sprite instead of just texturing a rotated quad. Not only does this make the rendering slower than it should be, but it takes CPU cycles away from executing DM code. Since there are now reasons to use higher framerates this will only be a bigger and bigger problem. | |
The problem has nothing to do with quads vs sprites. That is a trivial change that would add nothing currently because the drawing isn't the bottleneck, as I pointed out in the other thread already.
The problem is that our rendering concept uses icons instead of operations. Prior to last year (I think), dynamic icons (eg, Blend()) were generated server-side but now that is done mostly client-side through a stack of commands. That does open up the option of preserving the stack and having the operations repeatedly applied at draw-time instead of once, when the dynamic icon is first received. I imagine that would work well for many common cases and the big advantage is it would require no adjustments to the language. The disadvantage is that it can get tricky in certain cases, such as when you are rotating an object incrementally (increasing the dynamic stack with each new call), or in operations where caching would be useful. This is where the coding can get complicated. The alternative is to add transformation variables to be applied to existing icons, as per the original feature request. That of course just begets more feature creep. | |
Maybe it would work fine in addition to your idea, since a transformation matrix is very closely related to what you're requesting here.
A transformation matrix would allow us to create some pretty neat effects with sprites, like skewing.
I hate to be putting it like this, but the use of transformation matrices to transform sprites client-side would even allow us to create some crude 3d graphics (transforming specialized textures into quads or triangles to achieve the effect)