ID:102597
 
Redundant
Applies to:DM Language
Status: Redundant

This feature has already been implemented, or is already achievable with existing methods.
Duplicates:id:650493, id:108174
It would be nice to have a built-in variable that would let you rotate objects. Instead of using the Turn icon proc and requiring the server send a new icon to all clients you could just set object.angle = 45 and it would be drawn on every client as being rotated 45 degrees. This would also allow for the icon to be drawn outside of its 32x32 box. Currently this is very awkward to do and requires that the server do a lot of the processing. Clients should be able to figure out how to draw a rotated icon given the base icon and angle.

It would also be nice to have a similar setting for clients. Similar to how pixel_x and pixel_y give the client's eye a pixel offset, you could set client.angle to rotate the client's view.

These features would be handy for many reasons but would be especially handy for racing games and space games.
object.angle +++++++++

client.angle would be a bit awkward in my opinion. It would be interesting using tanks-style movement with it, but BYOND's 8-directional movement would be pretty confusing. I guess you could use it for drunk effects or something. Still, +++++++++
To be complete, it'd make sense to also have atom scaling values, giving us a matrix of transformations: translate(rotate(scale)))
client.angle would be a bit awkward in my opinion

It wouldn't make sense for most games. I had in mind a racing game. Instead of The map staying still (in terms of rotation) and the player's icon turning you'd turn the map and have the player's icon stay still.

I suspect it might have some technical problems. Turning the view makes some icons that would be outside of your normal viewing range become visible.

To be complete, it'd make sense to also have atom scaling values, giving us a matrix of transformations: translate(rotate(scale)))

Yes, that would be nice too. I would hope that these kinds of things (alpha too) are options in whatever graphics API you use (directx?) so you'd just need DM variables to expose these settings.
It would be better if you called it atom.rotation; out of the few different engines I've used, it seems more standard. Regardless, a full set of different transformations would be really useful.
Status: Needs Discussion

I don't think this needs any discussion at all, my space MMORPG(Yes MMORPG, not just Online RPG) has been on hold for a while because of this, and I'm considering moving to C++ if I can find a C++ programmer instead; mainly because of this turning issue. Just hurry up and add it ASAP. It's badly needed and has been for a long time now! :(

(Along with proper pixel collision detection for big icons.)
I'd have to agree here. No pun intended, but way to much responsibility is currently placed on the server. This actually hinders games in that the server is overwhelmed.

There has been talk before of switching the movement system from tile based to more pixel based but I understood previously byond had some original design goals.

With some cpu responsibility shifted to the client side however then you hit some other interesting problems that need dealt with. It can be seen in many games that are written in languages like c++. But client side calculations invite everything from clients becoming crackable, to having to deal with sync issues.

I vote yes for the feature but I definitely don't expect it ASAP. It'd take much discussion and beta testing.
Can't you already offset the view and/or rotate it? I remember being able to do this before.
Warlord Fred wrote:
Can't you already offset the view and/or rotate it? I remember being able to do this before.

Yeah, but only by one of BYOND's directions, and it looks really bad in most maps.
Would be helpful.
I would love this feature. It would lower the rsc of my games a lot. I pregenerate a lot of icons using different angles of the same icon to allow for turning.
I support this!
Bump!

It'd be nice to know the status of this particular update. I've been making a lot of top-down perspective projects with pixel movement and pixel-precise mouse tracking, like shootah. I only need to draw a single frame of something and it can be rotated at startup, but the more things there are to do this to, the longer startup is going to take.

It'd be very nice to have client.angle as well, for vehicle-style controls(up-forward, down-backwards, a/d-turn).
support
Bump then
Continued from the other feature request...

Tom wrote:
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 reason that using quads matters, I think, is because the same transformations in DirectX aren't available if you use sprites. It's not that drawing a quad is faster (though I wouldn't be surprised if it was), but drawing a rotated quad is faster than rotating the icon's bitmap to create a new texture, loading the new texture, and applying it to a non-rotated sprite.

Also, this is likely not the bottleneck because people simply avoid this feature. It probably wasn't the bottleneck when the operation was done server-side, people just avoided icon operations like the plague.

The problem is that our rendering concept uses icons instead of operations. ...

That whole thing is the problem. Icon operations are useful for generating icons and saving the output to a .dmi. For effects that are purely visual you should be using the GPU. There's no need to rotate the texture that you're applying, you just apply the same texture and rotate the geometry.

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.

This would be a very useful feature that leads to more useful features. There are worse roads to go down - like getting stuck in cycles of website updates =)

Falacy wrote:
Preferably, this should also rotate the atom's bounding hitbox.

That'd be a good feature to have, but it'd be best to have them as separate variables. There are many cases where the rotation is a purely visual thing and rotating a bounding box complicates a lot of the calculations (ex: determining when to call Cross() or Enter()).
Just to throw in my $0.02, I feel like these requests pertaining to the atom.rotation, atom.scale, atom.whatever operations for icon requests should boil down pretty much to supplying us with a way to set a transformation matrix, then having these other variables be shortcuts for modifying the transformation matrix for those that don't like matrices all to much and it will open up doors for people that are matrix-friendly. Also, it would be easily expandable as necessary to make-up for whatever transformations you don't have shortcuts for in a library or whatnot because we can access the transformation matrix. D4RK3 54B3R mentioned in passing that if he had access to a transformation matrix then he'd be jumping all over that for some pretty cool 3D effects.
I feel like these requests pertaining to the atom.rotation, atom.scale, atom.whatever operations for icon requests should boil down pretty much to supplying us with a way to set a transformation matrix, then having these other variables be shortcuts for modifying the transformation matrix for those that don't like matrices all to much and it will open up doors for people that are matrix-friendly.

Exactly. This is exactly the kind of feature BYOND should provide - a simple way to access lower level functionality. I suppose having access to the transformation matrix is fine for the sake of completeness.

Ideally, in the not-so-distant future, BYOND will be capable of executing DM code on the client so you can do something like this to make an object rotate:

while(atom)
atom.angle += 5
sleep(world.tick_lag)

And since it runs on the client, it doesn't use any bandwidth to repeatedly send updates to the client. Being able to change the color, opacity, or transformation applied to an object would let you create some nice looking client-side effects that currently can only be done by bloating the .rsc file and by using extra bandwidth. Imagine if you wanted to make an asteroids game where asteroids rotate at different speeds. Currently you'd do this by creating a variety of animated icon states. With features like this, you could write a stupidly simple client-side proc that creates variable speed rotations.

D4RK3 54B3R mentioned in passing that if he had access to a transformation matrix then he'd be jumping all over that for some pretty cool 3D effects.

I'm not sure how you'd create 3D effects with this. The transformation is specific to the atom - the same transformation is applied to the atom by all clients. For a 3D display you'd need to ability to represent objects differently to different clients.
In response to Forum_account (#17)
Forum_account wrote:
I'm not sure how you'd create 3D effects with this. The transformation is specific to the atom - the same transformation is applied to the atom by all clients. For a 3D display you'd need to ability to represent objects differently to different clients.

I assumed it would actually be a single-player demo, but the hope is probably also there that a change like this would also be applied to the /icon and /image datums separately, the latter of which would allow these effects to be applied to specific clients differently.
Depending on how it works, you could use client.screen to render something like Might and Magic.
Page: 1 2 3