Can we get a transform matrix per client? This would essentially act as a root transform node for all rendering done on the client.
Optionally, the ability to animate() the client's root transform would be awesome, (albeit animating the eye object can already be done to some degree)
This would make dynamic screen shaking and spinning a little bit easier and less CPU intensive, as well as allow us to use the new easing functions on the client's camera.
ID:1379861
 Sep 18 2013, 11:45 pm
|
|||||||
| |||||||
|
Sep 18 2013, 11:48 pm
|
|
Flysbad
 |
I support this idea.
|
I've thought a little bit about this already, but there are a few problems I'd need to work out:
1) It would be difficult to tell how much extra map to send the client for this purpose, and games using the feature would also need to expect a little extra load from sending and rendering bigger map sections. 2) There's code that snips out any out-of-bounds icons, provided they're not the base to an overlay that's in-bounds, before any sorting or drawing occurs. This would have to be modified quite a bit to handle client.transform. 3) It's unclear how this should impact clipping and screen objects. For instance, I would probably expect the final view to be clipped the same as it is now, but screen objects to be unaffected by client.transform. Depending on how the drawing and blitting gets done, this could be complicated. Would we draw to one surface without rotation, and then rotate on blit? If so that means we'd have to rotate screen objects the other way to make that work, and that could introduce some weird artifacts. Rendering directly in rotated form might be fine, though, although I could see it too being potentially artifacty. The #1 problem I see as a smidge more difficult than the others: Because animations are client-sided, the server will have a harder time getting a handle on when it should go back to sending smaller map pieces after a change to the transform matrix (if it should at all). Ideas are of course welcome. | |
Hm...
I can agree that client.transform would be difficult, but animate()ing certain variables of client shouldn't. For example, animate()ing client.eye to move to different coordinates or mobs would be rather cool. animate(client, eye = locate(5,5,1), easing = SINE_EASING|EASE_IN) | |
Being able to animate a client's pixel_x/y would be enough to have that kind of functionality. If you set the eye at like (1, 1, z), you can pretty much put it wherever you want by just setting pixel_x/y to absolute pixel coordinates. I'm pretty sure there was a performance issue when using high pixel offsets, but it was resolved.
| |
Necromancer powers activate!
 Would it be possible to implement this in a very limited functionality? Is there a way to capture what the output shouldbe before using present() and then applying a transform to that, so that things like clipping large mobs and the like aren't an issue? 1) It would be difficult to tell how much extra map to send the client for this purpose, and games using the feature would also need to expect a little extra load from sending and rendering bigger map sections. Perhaps something could be set up to allow rendering of the larges possible area, and use that when determining what to display, allowing the edges to be cut by the window? For example, if the map is of a 200x200 box, and this option is turned on, then the client will render a 283x283 area, so that when the screen is rotated to 45 degrees there are no blank spaces? Liked the idea and I want to see it implemented, even with just client.eye transforms instead of client transforms. I think we're essentially talking about the ability to do something like this https://www.youtube.com/watch?v=r1gUc-WMhfI with the map. | |
I'm unsure how the extra space issue could or should be handled. That's still something I need to ponder on, but I'm open to any ideas that might make it easier to figure out.
If something like client.transform were animated, which I expect would be desirable, that would complicate the issue. | |
I'm not sure how taxing it would be to just have it render the maximum size possible depending on rotation, but I see what you mean.
I personally don't think it needs be animated, though it would be nice. Being able to rotate the clients view alone would open up a lot of potential. Being able to animate it would just make it look nicer, not sure it's entirely necessary. | |
Bravo1 wrote:
I'm not sure how taxing it would be to just have it render the maximum size possible depending on rotation, but I see what you mean. Bigtime taxing. Without taking scaling or skew into account--which also matters--you're talking about rendering more than twice as many tiles. (In a square N×N view, it'd be ceil(N*sqrt(2)), so the total number of tiles in view would always be more than double.) If this can be handled in a deliberate way by the game so it can choose its own overage, that would be for the best. | |
Could make it an in-game variable so the programmer gets to decide how much extra padding to provide any used transforms. Another option would be to calculate it given an x by y square being applied client.transform and calculating the new widest x and y of the quad and then figuring out how many tiles that winds up being.
| |
MisterPerson wrote:
Could make it an in-game variable so the programmer gets to decide how much extra padding to provide any used transforms. Another option would be to calculate it given an x by y square being applied client.transform and calculating the new widest x and y of the quad and then figuring out how many tiles that winds up being. That would probably be best. If you leave it up to the designer, they could decide whether or not to go big or small with the display size and what to show. We're not asking it to be fast as much as we're asking for it to be possible. As for over double, depending on the project, that might not be an issue. Let's say you normally render an 11x11 area. With this option, you could safely and constantly display 8x8 tiles, or 7x7 to keep them centered. It is a much smaller area to deal with, as you said, over half your total view is lost, but projects usually don't have an issue running with client screens that are up around 15x15. Ultimately I'd say it depends on the project. You obviously can't go about rotating and working on a huge screen, but with client transforms you could allow for more control over exactly how the display is seen, as a whole. When it comes to doubling how much is being displayed though, is this more of a client side issue or server side? I can understand it being an issue for the server to deal with, but for clients I doubt it would cause much issue, at least not as much as other more complex systems can (like bullet hell projectiles). | |
Bravo1 wrote:
I think we're essentially talking about the ability to do something like this https://www.youtube.com/watch?v=r1gUc-WMhfI with the map.With atom.transform, we can already do that much, especially if the screen isn't filled with turfs. gif | |
That's my primary issue though, I'm talking about doing it where you can take an everyday map with turfs all about and rotate and play with it as if it were one solid plane (along with everything on it).
Kind of like the player just turning their screen... if that makes any sense. That is a really damn cool gif though, how does that all work? | |
Everything you see is in client.screen.
All the turfs determined to be visible to you are compiled as overlays on a single "pivot" object. Each turf is offset based on its relative position. Then, the "pivot" object is transformed according to your viewing angles; first, the top-down rotation, then an isometric rotation (slight vertical shrinking). Due to all the turfs being overlays, there's no mouse interaction with them. Then, the non-turfs are each drawn as individual screen objects with their own relative positions, directions, layers (based on closeness to the camera), etc. The first several times I played with rotating views, I gave every single visible object a screen object counterpart and transformed each one (back then, we didn't have atom.transform, but we were both working with icon rotations at the time so you'd probably know how much fun that was). It's a lot faster if you pile things onto a single object and transform that, but you lose mouse interaction. | |
Just to do some necromancy on this thread.
This would still be nice to see, and I think this might also tie into what this request is after. http://www.byond.com/forum/post/2657912 | |
