Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 21 Mar 2003
Offline Last Active Oct 29 2015 05:47 AM

Posts I've Made

In Topic: fragment texture sampler for vector3 field

12 June 2014 - 01:32 AM


Do you really need 32-bit precision to represent direction vectors?


I'd honestly be surprised if 8-bit textures weren't sufficient, and there are always half floats if you really need them...



I think so. This is for ray-marching, so accuracy is pretty critical. I suppose I can experiment a little on that front. 

In Topic: fragment texture sampler for vector3 field

11 June 2014 - 04:39 PM

hmm might be able to use float components in my texture


glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA32F, 960, 800, 0, GL_RGBA, GL_FLOAT, data)


something like that.


16mb texture, for fragment ray directions.


32mb if I also want to map the fragment ray origins.



In Topic: Network Game Design / Architecture Question

05 June 2014 - 04:26 AM

The simple way :

- Client sends inputs to the host.

- host processes inputs.

- host calculates the game state (positions of objects).

- host sends game state to clients.


Example : The original Quake networking (for LAN games).

Advantages : simple.

Disadvantages : lag becomes a serious issue. Round-trip latencies will make the client input laggy.




The way it is corrected :

- client reads his inputs, and calculates a local prediction of the player position.

- client sends inputs to the host, as well as his local prediction calculation. The input+prediction packet is marked with a unique number (aka Sequence Number, aka SQN).

- client also stores the input+prediction packet in a buffer.

- Host receives the client inputs+prediction+SQN. 
- host calculate the real player position, using those inputs.
- host then compares the player location with the client prediction.
- if a difference is detected (within an arbitrary margin of error), the host sends a correction packet back to the client (containing corrected_position+SQN).
- client receives the correction packet.
- client looks up the original input+prediction packet in his buffer, using the SQN. 
- client substitutes the predicted position with the corrected position.
- client then replays his input stack from that point onwards, to adjust his current prediction with the server correction.
Example : Counterstrike, Quake 3, Unreal Tournament, Team Fortress...
Advantages : Nullify the input latency, by allowing the client to locally predict the effect of the player's inputs. 
Disadvantages : client will experience jitter and rubber-banding when a discrepancy between the client prediction and the server calculation is detected (i.e. two players jumping on top of each other). 
looksy here.

In Topic: Why is it that some say that open source multiplayer games are less secure?

08 May 2014 - 08:05 AM

Open source makes finding exploits a lot easier. If you play it fast and loose, it'll be a lot quicker for hackers to find exploits within the code or even your design assumptions. If your game isn't particularly secure but the code cannot be reversed engineered easily, it can take more time. Ultimately, if your game is popular, you will be found out either way. 

In Topic: How to spawn objects near players?

02 May 2014 - 07:06 AM

Simplest is a grid (voxel in 3D) representation. It's easy to compute, easy to query, very fast. It take comparatively more memory. Spatial hashing is kind of the same principle, with better memory footprint. 


There are other spatial partitioning structures. Physics engines use them all the time, on 1,000's of interacting and static objects (check out NextCarGame / BeamNG). 


The other common strategy is using portals / PVS (Potentially Visible Set). You build a list of areas that are potentially of interest from another area.