Closed FloooD closed 13 years ago
and i was worrying about 4.8mb/s causing lag
Well, our typical VPS's are around a few hundred times slower than industrial grade stuff :P
haha well they're faster than this netbook right? that's what i've been using to compile/test
haha, writing code on a netbook? boss. It'd be better if it was with the google netbook :D (no offline access and no text editors, good luck there :P)
eh... write it on paper hahahah nah i'd prolly write on my phone (palm pre plus). well it has vi and ssh in the terminal :D
anyway stupid question: is unsigned short array[150][32][2] guaranteed to be contiguous?
yes unless it exceeds the max available memory, in which case it should just fail
k screwd the function replacing with memmove(&lcbuffer[1],lcbuffer,sizeof(short)_(LC_BUFFERSIZE-1)(MAX_CLIENTS)*2)
eh gonna make player[id].x a pointer to lcbuffer[0][id-1][0] so that u dont have to copy a bunch of crap every frame ;p
k done
alright... what's the most efficient way to do this shit
lag compensation requires the server to store the past locations of every player for... say 300 milliseconds
a simple implementation (what's being used right now): add a buffer array to every player's struct. on every frame move each value of the buffer upwards... ya
so at 500 fps, 150 copies per player per frame * 32 players * 500 frames per second = 2.4 million copies per second. (as u can see its a quadratic relationship to fps :P) ew.
this method fails to take advantage of two things:
currently im thinking about something like this: getting the x coordinate of player id 21, 123 frames ago: lcbuffer.x[21][123] but would it be better to do lcbuffer.x[123][21]?
im not too familiar with how memory works so idk edit: u could just do a single memmove per frame if x and y are in the same array i.e. lcbuffer[123][21][0] for x, lcbuffer[123][21][1] for y
which makes those two things i wrote above kinda pointless ;p