The hottest Monday like ever.
It’s very hot here. I don’t like heat.
Today was pretty much one step forward and a giant leap back. I started out implementing level streaming and actually
got the client to connect to a server and receive the terrain data over UDP. But there were massive performance
issues caused by the synchronous networking I implemented, added to lots of overhead from packet resending and
sorting.
I’m currently considering my options, I can either keep poking away at UDP, making it asynchronous and
trying to eliminate the overhead, or I can fall back to good old java 1.1 type tcp/ip. The code would get a heck of
a lot easier, but at the cost of higher network latency. I’m not sure which option would result in the best ingame
framerate. They’re probably about as fast, if implemented correctly.
Fixing the UDP layer to be asynchronous is about as much work as implementing a TCP layer. I think I’ll just go ahead with the TCP thing and see how that plays out. If it sucks, I can always re-adapt the UDP stuff later on.
But actually seeing the level get streamed from the server, in survival mode, was an awesomely motivating milestone. :-D
Oh, and also;
The client uses a lot less CPU in network mode since it doesn’t do any actual game logic or terrain
generation. I think I can use this work to split logic and rendering into two threads in the singleplayer version in
the future. That should make the game run a lot smoother on dualcore computers.
