Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 20 Nov 2008
Offline Last Active Jul 01 2015 10:50 AM

Topics I've Started

Server side events and world update

25 May 2015 - 02:43 AM

Hello everyone,


I'm proceeding with my prototype and everything seems to be working fine. Entity interpolation has still some small issues but I think it is something I can skip for now.


My server sends world state updates to the clients 15 times per frame, while the server updates at a fixed 30 frames per second. Some events might happen between the world state sync, and I was wondering if it is usual practice to send these events immediately or if they should be queued and flushed when I send the world update.



Client side prediction

13 May 2015 - 01:06 AM

Hello guys,


in the past few weeks I read a ton of material about networking a multiplayer game, prediction, extrapolation,interpolation and whatever. I tried to implement my own solution to predict the movement of the player-controlled character and make sure it is validated by the server, but I have some jumpy movements that, as far as I understood, shouldn't be there.


What I'm doing right now is pretty simple: every client tick I record the state of the input, assign and incremental ID, and send it to the server. At the same time I simulate the client. When the server receives the command, it simulates it and send back to the client the new position together with the id of the just simulated command. Once the client receives the ACK packet, I assign the server position to the player, and then apply all the commands recorded, starting from the last acknowledged one. World state sync is done with a separate message at lower rate, and does not include the player position.


Simulation runs on both client at server at fixed 30fps for now.


When simulating variable (but still acceptable) latency, the player jumps around a little bit. Is it due to the fact that I should take into account the latency somehow when re-simulating the client commands when I receive the ACK packet?


I thought about two alternatives to solve the issue.


The first one is to set an acceptable distance between the client-side position and the acknowledged one: if we are in this range I keep the client where it is. The server will still be autoritative and all the collision and such will happen correctly, and the client won't notice any jumping around.

Or I could periodically send just the client position to the server, and validate the new position there using simple sweeping to check for collisions and such. As long as the movement is linear from point A to B, it should work fine?


Btw, the prototype I'm working on is something similar to realm of the mad god but with less bullets, just to give you and idea about what I am aiming for ;)




Delta compression

23 April 2013 - 03:52 AM

Hello guys,


in my free time I was delving a bit into multiplayer game programming. I made a simple MMO implementation to try out some concepts, and it is working fine for my needs; for the moment I'm relying on delta compressed messages sent at a fixed rate from the server to the clients whenever an object of interested is changed (interest is based on zones where a player is in ATM).


My question is very simple: now I'm sending a new delta compressed message (or packet if u prefer) for every object that is changed between the last update and the new one. I was wondering if this was a valid approach or if it would be better to send a delta compressed state of the whole region of interest at every server frame.

I believe that packing all the zone state into a single message will make my server logic much more easy to write and debug, but at the same time I fear that I might incur into too much overhead (consider that now I'm delta compressing the data at the binary level and then I'm deflating it again to pack it tightly).


The kind of game I'm working on is a very simple arcade twin stick shooter, with very simple modifiable environment (aka: some static objects can be damaged and then destroyed).


Any thought?



ARM Neon clamping

16 July 2011 - 06:08 AM

Hi guys,

I just started playing around with ARM NEON, and I'm trying to do some simple image processing with it. I was wondering if someone of you knows a way to perform value clamping using NEON instructions.
This is my situation: I have an int32x4_t variable which stores the ARGB components of a single pixel, and I'd like to clamp each component so that it fits to the 0-255 range.
Is it possible somehow to do this operation in parallel using NEON instructions ?


GPU assisted SPH and interaction

15 June 2011 - 01:43 PM

Hello guys,

I was reading some information here and there about how to implement a GPU assisted SPH simulation (2D in my case). However, as far as I understood, all this methods rely on the fact that the data stays on the GPU forever, this way all the simulation can be run on the graphics card and the rendering uses the output of the simulation pass(es) directly.

However, what I'm looking for, is a bit more tricky: I implemented (CPU) a very simple SPH engine on top of a 2D physics engine, and I gave each particle additional information (temperature) that I need to use at the gameplay level. In case have done the SPH on the GPU, this would have required me to read particles information back from the GPU so I could perform all my calculations and run the gameplay accordingly. I'm not a GPU guru at all, but I guess that a readback from the buffer used to store particle's information is too slow to be considered in a realtime game; right ?
So my question is quite simple: how do other developers usually handle this ? Do they implement their gameplay in a way that there is no need to read the data back from the GPU ? Or is there a simpler way to handle this ?