ID:2127554
 
(511.1351)

I don't know if it's placebo, but it feels like setting client.fps to 100 is noticeably smoother than setting client.fps to 60 (even though my monitor's refresh rate is 60 Hz).

Pixel gliding seems to be working absolutely perfectly, too, as far as I can tell. I haven't had any network lag to test with, though.
I just realized something.

Everyone should set client.fps to as high as possible (currently limited to 100 at compile-time), so clients always render as frequently as they can; which is what most modern games do.

It's kinda silly that there isn't an option to set client.fps to 1#INF or client.tick_lag to 0 (this makes it default to world.tick_lag), which would mean "render as frequently as possible", taking physical refresh rate into account.
what would we set world.tick_lag to? I tried setting client fps to a higher number and world fps to 10 with world.tick lag 1 but it's not working out cause i use a lot of sleep(world.tick_lag) in my loops for movement and stuff

also looks like my movement frame rate is acting weird playing for a second after I stop moving when i set client fps to 100 and world to 40. Just noticed its moving on the spot a couple of pixels for some reason

edit:nvm that movement thing doesnt look like its related to fps/ticklag
There may be several reasons for 100 FPS to look better than 60 FPS. One compelling one is that tick speed is measured in integer milliseconds, so 60 FPS is 16 ms whereas 100 FPS is 10 ms. 16 isn't a factor of 1000, nor of 100 which is the server's default speed, so it won't end up exactly even.

Generally I would suggest going with 50 FPS instead. Values of 10, 20, 25, 40, and 50 are good choices because of their even divisibility into 1000.
In response to Lummox JR
If we had a way to just ensure a redraw every refresh (if necessary), no one would have to worry about roundoff error.
In response to Kaiochao
Sounds like requestAnimationFrame(). Possible feature request?
In response to GreatPirateEra
GreatPirateEra wrote:
Sounds like requestAnimationFrame(). Possible feature request?

No. The client runs no procs; therefore this would make no sense in a BYOND context.
In response to Lummox JR
Lummox JR wrote:
There may be several reasons for 100 FPS to look better than 60 FPS. One compelling one is that tick speed is measured in integer milliseconds, so 60 FPS is 16 ms whereas 100 FPS is 10 ms. 16 isn't a factor of 1000, nor of 100 which is the server's default speed, so it won't end up exactly even.

Generally I would suggest going with 50 FPS instead. Values of 10, 20, 25, 40, and 50 are good choices because of their even divisibility into 1000.

client fps at 100 still looks wayway smoother than setting it to 50
Values of 10, 20, 25, 40, and 50 are good choices because of their even divisibility into 1000.

You should add this comment to the reference and F1 command
I stand by my statement from several months ago, something VERY wrong is happening at the repaint level that's causing BYOND to miss frames and update when it isn't supposed to.

It's like that time that I swore up and down that I was seeing /image objects and screen objects redrawing independently of the FPS and doing other really messed up shit, and Lummox said it wasn't possible... Then it turned out that it was actually happening?
In response to Ter13
Ter13 wrote:
I stand by my statement from several months ago, something VERY wrong is happening at the repaint level that's causing BYOND to miss frames and update when it isn't supposed to.

It's like that time that I swore up and down that I was seeing /image objects and screen objects redrawing independently of the FPS and doing other really messed up shit, and Lummox said it wasn't possible... Then it turned out that it was actually happening?

Jesus Lummox just give this man the source to BYOND and let him work on it with you, no offense.
In response to Ter13
Turns out Dan already implemented client-side FPS, but set the flag to false before leaving to disable it, along with enabling the flag that makes the VM slow on purpose. /s
Heh. Tbh, i wouldn't mind working for lummox for free in my spare time. I'd really want to focus on the IDE and the UI portions of the language though, which imo are the weakest areas.
In response to Ter13
Ter13 wrote:
Heh. Tbh, i wouldn't mind working for lummox for free in my spare time. I'd really want to focus on the IDE and the UI portions of the language though, which imo are the weakest areas.

Lummox, pls. pllsssssssssss. I will advocate for this man til i die.
In response to Kumorii
Kumorii wrote:
Ter13 wrote:
Heh. Tbh, i wouldn't mind working for lummox for free in my spare time. I'd really want to focus on the IDE and the UI portions of the language though, which imo are the weakest areas.

Lummox, pls. pllsssssssssss. I will advocate for this man til i die.

I second this! Quick everyone rally the would be game makers, the veterans of old, even the rippers, and rip lovers if any would dare venture into this forum for you! We must petition to have this happen!
No one would be against it lol I don't think that's the issue
pls lummox
no. chill.
Real talk: Ter is too volatile/unstable to be a representative of BYOND.com. Lummox is wise to ignore this derail.
when i had client fps set to 100 it was extremely smooth but a lot of players said they were crashing frequently so i lowered it and they stopped crashing
Page: 1 2