Client frame rate

Page: 1 2 3 4
Jun 7 2015, 12:59 pm
I don't see any reason that server fps needs to go above 20 or so if we can get client-side interpolation to run at 40 or 60fps.
Jun 14 2015, 10:29 am
I could see some reasons to go above 20FPS server-side, but those cases would be rare, very rare, and would only be effective in specific setups/situations, like at a LAN party. Especially once physical latency starts rearing its ugly head past 50ms, you'll start encountering pretty heavy jitter and possibly out-of-sync/lost commands.
Jun 14 2015, 4:05 pm (Edited on Jun 14 2015, 9:18 pm)
BYOND runs on TCP. You don't lose commands or go out of sync. TCP by default orders and refires commands.

40fps is my preferred way to work right now, but if I could drop the server down to 20fps and the client framerate to 40 or 60, I'd be amazingly happy.

EDIT: It should be noted, however, that I agree that 25ms is too small a granularity for players to reliably control. Macro repetition should probably be avoided in DM if you go above 20fps or so, because average latencies can get up to 50ms and 90ms across the net.

I tend to use onPress/onRelease approaches with input state management, which means movement will be a maximum of 2-4 frames late, and movement stopping will be 2-4 frames late. I'd rather a slight "loose" feeling than a jumpy feeling.
Jun 15 2015, 7:48 am
+1 For this. It seems like it would take a lot of work off the server while still maintaining quality for the clients.
Jun 15 2015, 10:46 am
In response to Ter13
"BYOND runs on TCP. You don't lose commands or go out of sync. TCP by default orders and refires commands."

Very true, but there's still packet loss to handle via error correction. That adds up to resource usage on the server.


"40fps is my preferred way to work right now, but if I could drop the server down to 20fps and the client framerate to 40 or 60, I'd be amazingly happy."


My timing method might seem strange, but give it a shot. I've found it to be very useful and balanced for user vs. world code.

world
    name = "Anthro Esoterica"
    view = "27x21"
    icon_size = 32
    fps = 30
#define TILE_WIDTH  32
#define TILE_HEIGHT 32
#define TICK_LAG    0.3 //set to (10 / world.fps) a define is faster, though


Plus:

atom/movable
    var
        move_delay = 4 * TICK_LAG
        tmp
            last_move = -1000
    Move(atom/NewLoc,Dir=0,step_x=0,step_y=0)
        if(src.loc && get_dist(src,NewLoc)==1)
            if(last_move + move_delay > world.time)
                return 0
            . = get_dir(src,NewLoc)
            if(. & . - 1) //diagonal condition
                src.glide_size = sqrt(TILE_WIDTH**2 + TILE_HEIGHT**2) / move_delay * TICK_LAG
                //hypotenuse glide
            else if(. < 4) //n-s
                src.glide_size = TILE_HEIGHT / move_delay * TICK_LAG
                //glide value must be based on the adjacent
            else //e-w
                src.glide_size = TILE_WIDTH / move_delay * TICK_LAG
                //glide value must be based on the opposite
            . = ..(NewLoc,Dir,step_x,step_y)
            if(.)
                last_move = world.time
            return .
        . = ..(NewLoc,Dir,step_x,step_y)


I'm using someone else's code, but it's modified to where it provides near-equal performance from any machine from a hyper-threaded 3.2 GHz P4 to an Intel Atom 1.6 GHz to 733 MHz PIII Tualatin. As long as you've got ~512MB RAM, you should be fine to run this. There are still sync issues for mobs, but nowhere near as bad as say SS13 and derivatives thereof.


Jun 15 2015, 10:47 am
In response to Ter13
Also, if someone could remind me where this original code came from so I can put it into my credits file, I'd be most gracious and gratified.
Jun 15 2015, 1:51 pm
Also, if someone could remind me where this original code came from so I can put it into my credits file, I'd be most gracious and gratified.

You are talking to him.

http://www.byond.com/forum/?post=1573076

Also, your TICK_LAG value is wrong. it should be 0.333, not 0.3.
Jun 15 2015, 6:54 pm
0.3 provides better animation and tile glide vs 0.333.

You'll have to pardon me, I'm an ASM/demoscene programmer by trade.

The way I've got your engine modified now, you could roll CandyTron if you just added a 3D renderer.

Sadly, you'll have to deal with the bass-ackwards hell that is FORTH if you worked with my code that's further down.
Jun 15 2015, 8:01 pm
In response to Khyberkitsune
Khyberkitsune wrote:
0.3 provides better animation and tile glide vs 0.333.

Yeah, but you wind up with inaccuracy over a significant number of frames.

The way I've got your engine modified now, you could roll CandyTron if you just added a 3D renderer.

Wat?
Jun 15 2015, 8:10 pm
Thankfully the inaccuracy does nothing to my 'game,' given this being a graphical update of a text social game with no combat, etc.! Having a mob being able to maybe be a tile ahead now and then whilst walking really isn't much of a big deal.

Now, on Candytron.

https://www.youtube.com/watch?v=P1lL-NBpels

Just watch.

I don't have it done in 64k of code like these guys. It's more like 3MB. >.>

Your engine is far more extensible than I imagined. It took a LOT but just for fun I tried to see if it could be done.

I can get 'bout 3FPS with a single untextured model. :D
Jun 15 2015, 8:15 pm
In response to Khyberkitsune
Khyberkitsune wrote:
Now, on Candytron.

https://www.youtube.com/watch?v=P1lL-NBpels

Just watch.


Jun 15 2015, 8:24 pm
That is a KILLER reference!

But seriously! I had no idea this engine could be so easily extensible!
Jun 16 2015, 6:22 am
In response to Ter13
Ter13 wrote:

That about sums it up.
Aug 21 2015, 9:11 pm
*crickets*
Aug 21 2015, 9:35 pm
Just to clarify, Pomf, I wasn't planning on implementing this right away. I was floating the idea as a trial balloon. I suspect it'll be feasible, so I want to start working in that direction, although I think 509 is an unlikely target. (However, I might try to get the backend var and message support in for 509, so that it'd be easy to activate in a later beta of the same major build if I got the concept working. I'll have to see.)
Dec 21 2015, 4:47 pm
This is still a great idea
Dec 22 2015, 10:50 am
Yes, We would love to see this kind of thing at ss13, we have to make systems to live raise and lower fps based on server load, because we want it to be as high as possible for client reasons.
Dec 23 2015, 2:18 am
I'm late to this thread but this sounds incredibly useful.
Dec 23 2015, 8:18 am
In response to MagicMountain
MagicMountain wrote:
I'm late to this thread but this sounds incredibly useful.

Apr 30 2016, 2:20 pm
Lummox JR wrote:
However, a prerequisite is finishing DSification of the webclient, which would have to come first for this to work. So this isn't an immediate plan, but something I'm looking at for down the road (hopefully not very far).

Maybe this could be a feature goal for 511, along with gamepad support, since the main obstacle is out of the way (DSFication of the webclient).

Edit: Oops, didn't realize this was mentioned in a recent status update. Good stuff.
Page: 1 2 3 4