Light Speed

by FIREking
The fastest lighting system for BYOND
ID:1259377
 
The demo in Light Speed uses a world.fps of 60... This is to sorta show the "ooo" and "ahh" of Light Speed. In an online game, you'd want a world.fps of something more like 30

To see Light Speed performance double, change world.fps to 30 and watch the cpu usage drop to below 4% during peak performance (depending on your cpu of course).
Slows down the character's movement speed, I'd also turn the players speed to 10 instead of 5.

_Player.dm

    var/speed = 10
In response to Zecronious
Zecronious wrote:
Slows down the character's movement speed, I'd also turn the players speed to 10 instead of 5.

_Player.dm

>   var/speed = 10
>


That too. Good suggestion. The movement speed is tied to glide speed to have smooth pixel perfect gliding...
In response to FIREking
Yeah I noticed you use movement which is interdependent. Just an weird idea, but is it possible to also make your movement speed dependent on FPS as well?

Then the user would only need to change FPS and still get smooth and quick movement.
Just an idea but I think it makes sense.
In response to Zecronious
Zecronious wrote:
Yeah I noticed you use movement which is interdependent. Just an weird idea, but is it possible to also make your movement speed dependent on FPS as well?

Then the user would only need to change FPS and still get smooth and quick movement.
Just an idea but I think it makes sense.

It doesn't look good when it is independent. Show me an example that's not using pixel_movement. I've tried everything.

It's because they won't separate world.fps and glide_size, in other words... you can't change how many pixels something slides between frames accurately enough for it too look smooth enough without locking on to FPS. (IRL: having the server communicate in frames of 10 MS each, yet graphics draw 60 FPS per second... this isn't possible in BYOND).

If you're designing a game in BYOND, you should be deciding on your FPS from the beginning, and working around that. Getting a game to run well in BYOND is all about working around limitations.

To further understand this, think about the fact that when you tell your character to move to the next tile (in tile based movement) it has already moved there, but the transition of it happening (the animation) happens after the fact. This actually saves you bandwidth and makes your game run more efficiently because there's less packets that are exchanged back and forth. The client tells the server "i want to move", the server makes sure its ok to happen, then the server tells the client "you move here", and then the client animates it happening, because it is built into dream seeker to do that. The second you switch to pixel based movement, the server has to send the client a new packet every time the atom changes pixel location (so this would happen like 32 times in a single 1 tile move).
Sorry but I think you misunderstood what I said. I totally understand that it needs to be an interdependent system in order to get smooth movement.

What I'm saying is that couldn't your library work better if the movement was also dependent on FPS. It's another layer of complexity in movement but it would also mean that players don't need to do two steps when they change FPS, just the one. So a system where you movement speed scaled with the FPS.
In response to Zecronious
Zecronious wrote:
Sorry but I think you misunderstood what I said. I totally understand that it needs to be an interdependent system in order to get smooth movement.

What I'm saying is that couldn't your library work better if the movement was also dependent on FPS. It's another layer of complexity in movement but it would also mean that players don't need to do two steps when they change FPS, just the one. So a system where you movement speed scaled with the FPS.

Sure, but that's the demo part. This is a lighting library. The movement stuff has nothing to do with the library. The light library is entirely contained within the light_speed.dm file.
Yeah was just an idea that for the demo which is included.
The conversion (close enough) is speed = world.tick_lag * 30

If FPS is 60, then tick_lag is 0.16, that times 30 is ~5
If FPS is 30, then tick_lag is 0.33, that times 30 is 10

The number "30" would change depending on what speed you want to scale across FPS... so if you wanted a 20 at fps 30 and a 10 at fps 60, the 30 would need to be 60

I'm not a math genius, but I'm sure there's a ratio for this that makes it work, I just don't know what it is right now and since its not important to me or important for my library, I don't care to discover it. Perhaps someone else reading this can chime in about it, but it isn't a big deal. People should be writing their own movement systems.