screen objects don't support pixel x/y. although i don't really understand why this is necessary, the only way to animate () translations for screen objects is to use a translated matrix. But what if you wanted to animate from WEST,NORTH to CENTER,CENTER?
the feature is pretty simple. if an object animate()s its screen loc, and both the start and end screen locs are in the format of sx:spx,sy:spy, then the object's screen_loc is animated over time
because screen_loc is technically a numerical value, this should be a simple addition
ID:1868550
 Jun 8 2015, 9:42 am (Edited on Jun 8 2015, 10:54 am)
|
|||||||
| |||||||
|
Jun 8 2015, 12:45 pm
|
|
Exentriks Gaming
 |
I remember this is how it originally was and it was really convenient, the only problem was that it would reset back to its original position when animate() finished. Lummox considered it to be a bug and took it out. :|
|
Animating screen_loc would be awesome, although it's not actually as simple as you think. There are some internals in DS that dictate how screen_loc is parsed, and how each icon is mapped to the client-side tile system.
Long story short, I couldn't figure out an easy way to do this when I first implemented animate(), but I agree this is really needed for completeness and would like to revisit when I can. | |
In the meantime, you can still use transforms to do "WEST,NORTH" to "CENTER,CENTER" by calculating what the equivalent pixel coordinates are, based on client.view and world.icon_size. If you're worried about things not staying anchored when client.view changes, you'll still have to recalculate the positions of your pseudo-anchored stuff, but softcode is better than no code.
| |
Big bump!
| |
I dunno how screen_loc is parsed in the internals, but if it has to be parsed every sub-pixel of the way with animating, that would defeat the purpose of the way the animate() proc works.. right? (since it's intended to be on the client rather than the server)
| |
screen_loc is parsed into a struct, that contains a map name and two other structs: the corners of the range covered. HUD objects are added to a special class that keeps track of them by tile, so something with a range over a number of tiles gets added multiple times.
At map display time, HUD items are handled on a per-tile basis and so the already-parsed screen_loc is used to find the items that should be displayed on that tile. It's not a great system, but it's legacy and hard to rewrite, so I haven't yet. My recommendation is to use transform if you want to animate HUD objects' positions. | |