Server now generates and sends an expanded 34x34 heightmap for each
chunk, which includes a 1-vertex border containing height information
from all adjacent chunks.
Client ChunkMesh class updated to consume this extra data, allowing it
to calcualte perfectly accurate normal vectors for all vertices,
including those at the very edge of a chunk.
* Chunks are now rendered as solid, lit meshes instead of wireframe.
* The GLSL shaders have been updated to a directional lighting model.
* Chunkmes now calculates normal vectors for each vertex to enable the
lighting.
* Shader class now has a 'set_vec3' method for sending lighting date to
the GPU.
Bug Fix:
* Resolves visual artifacts and "seams" at chunk boundaries.
Next up:
* To calculate the correct angle for a vertex at the edge of chunk A, we
need to know the height of the terrain in the neighboiring Chunk B.
Since it doesn't have that information, the GPU's making an appoximate
guess. We need to generate and send a small "border" of height data
along with each chunk, I'll do this by increasing the size of the
heightmap array in the network message so it can hold the 32x32 chunk
plus 1 vertex border all around. MAking it 34x34 for each chunk.
Physics and collision system to make players interact with the generated
terraine without falling through the world like lemmings.
It uses a shared bilinear interpolation function for terrain height for
smooth and consistant height queries on the client and server.
A bit of an architectural change before we progress further. Moved
player code into a shared PlayerBass class to elimnate some severe code
duplication while i was getting things working.
Added linear interpolation for remote player movement to provide a
smoother and more visually appealing experience.
Where previously remote players would snap directly to their new coords
on receiving a game state update, making it a bit jerky, now we get a
smoothe ride.
Initial implementation of server-side reconciliation for player
movement.
Clients respect the server as the authoritative source for game state.
In 'process_game_state', the client compares its locally predicted pos
with the state received from the server and snaps to the server's
position if they diverge.
Had to add a defensive check to the server-side Player constructor to
fix a bug where the first connecting client was incorrectly assigned an
ID of 0. This prevented it from sending or recieving any game data.
- Server can handle multiple clients simultaneously.
- Client can see other players in the game.
- Server broadcasts the game state to all clients.
- Client receives the game state and renders the other players.
- Server assigns a unique ID to each player.
- Client receives its player ID form the server.
- Server handles client disconnections.. Kinda... Server is ignoring
SIGPIPE signal.
- Server and client signals are non-blocking.
- Moved player objects off the stack and onto the heap.
* Added Player class to represent players on the server.
* Added Game class to manage the overall game state.
* Server now adds new players to the game state when they connect.
* Server now updates the players position in the game state on receiving
a PlayerPosMessage.
