ID:1979424
 Nov 8 2015, 3:52 am
|
|||||||
| |||||||
I'm not sure how feasible this is, but similar to how pixel_x and pixel_y work, it would be nice to change client.step_size to effect how lazy_eye works.
| |||||||
|
Nov 8 2015, 1:25 pm
|
|
Lummox JR
   |
Are you referring to a kind of quick transition effect like in Zelda?
|
I'm guessing it's about how lazy_eye is only tile-based. Does the camera only move in whole tiles when the player exceeds the lazy eye distance?
I know that Forum_account's Pixel Movement library has its own pixel-based lazy eye and smooth follow camera. | |
IMO an approach like FA's is the better way to handle it when you want smooth movement. lazy_eye has been around a very long time and wasn't built to be very sophisticated. I'm not opposed to a feature like this, but it does seem like it'd potentially impact very few games.
| |
I mean, if it was me, I'd add the whole slew of movement options to client and just have it effect pixel offsets, I can think of numerous uses for that, whether or not it impacts a bunch of games or not, is different :p
| |
It's a matter of balancing complexity vs. applicability. I love me some feature creep, but this kind of thing could conceivably make several parts of the code harder to maintain. Features that do that need to earn their keep.
| |
Understandable, but surely you can understand why certain features managing the viewport would be helpful? For example, centering the client eye at the moment between two different things either requires heavy manipulation of the pixel_x/y, or creating an object in the world to "hover" between them and assigning the client.eye to that object instead. With proper "movement" of the eye, you could do something like
step_towards(client,target) and just add the third arg to step_towards to halt it at half of the distance between the two objects. Much much simpler and easier, along with a bunch of other neat tricks I can think of that currently require a load of workaround. | |