Progress Update #4

Code Update:

    Alright, so I have spent probably way more time trying to come up with a magic heap management based solution to my multi-threading problem but alas I have not been able to come up with anything. so after awhile i waved the white flag and just embraced the already subtle client/server over tones of my code. So how it works now is I've split the physics system into 2 systems, the client physic system runs in the same thread as the graphics system while the server physics system runs in it's own thread. The server physics system handles all physics calculations and calls a callback function for every time an object moves. This callback then creates a list of all the changes in the position of these objects. After it has finished all of it's calculations the physics server will then toss the list at the client. When it's the client's turn to run it adds the new positions for all the objects and then figures out the interpolations for them. These interpolated positions then get rendered to the screen and so far I'm quite happy with how it has turned out.

    I have done some tests to see how well this works. With a debug build (adds a lot of extra work for the system) 1000 objects caused the physics server to run at 1 frame every 10 seconds, while the client ran as a some what tolerable 15fps. So while the game world had significant slow down, the gui was still somewhat usable. In the release build with 1000 objects, the game did 60fps no problems. With 2000 objects in the release build I don't know what the frame rate was but I noticed no slow down. With 3000 objects in the release build the ram usage for some reason suddenly jumped up to 14GBs and then the game crashed when there wasn't enough memory, so that's something I'll probably need to look into later. For now I'm quite happy with the results.

Learning to Art Update:

    I kind of got sick of drawing stick figures over and over again, so I decided to try drawing basic geometric shapes. Where upon I found out that I can sketch circles and triangles just fine, my squares leave some what to be desired, and my cylinder is a horrible abomination of nature. So I ended up drawing cylinders over and over again, kind of like I did with the stick figures. Like with the stick figures they got better as they got smaller over time. So I'm not sure if drawing them smaller counts as that it just might not be that I'm getting better but that smaller cylinders are just easier to draw. After awhile of that I kind of got sick of drawing being just all work, everything I read says it's supposed to be fun, but so far for me it has just been a dull boring grind. So I decided to shake things up a bit and try to have some fun with it. I found an online tutorial of how to draw Bulbasaur and proceed to draw what I've now named Retardasaur. The thing looks like it was severely beaten about the head as some point in it's life. So my plan now is I'm going to draw this over and over again until I get something I'm happy with.

Progress Update #3

Alright, it has been 2 weeks since the last progress update and I'm not entirely sure this is the right amount of time yet, but I'll try to keep up the every 2 weeks and see how things go.

Code Update:

     Last time I said I was going to work on the physics and so what I have accomplished on that front is I have completely separated the physics system from the frame rate. What I mean by this is that I don't have to have the physics advance every frame and is instead able to run at it's own clock rate. How this works is that when it advances it will actually start out with the present state of the world and advance it X amount of time into the future rather then starting out X amount of time in the passed and advance to the present. The graphics system will then look at where an object is and interpolate that over to where it will be (although I haven actually written this part yet, so currently things look like they are jumping around on the screen). While there are a lot of disadvantages to doing this, there are a number of advantages as well, mainly that I'll be able to run the physics system in a completely separate thread from the graphics system. So if there is too many objects that need physics calculated for them, instead of freezing up the game and turning it into a slide show, the game will remain some what responsive and everything will look like it's moving in slow-motion. About half way though I realized that if I don't address the issue of multi-threading now, it would be an absolute nightmare it implement later.

    The problem I am having with multi-threading is it's quite likely that I'll have 1 or more threads trying to read/write to the same chunk of memory at the same time. I can't simply create a mutex for every object because I have no way to tell my physics engine to use them. Also I feel that if your program needs a thousand mutexes then your probably doing something wrong. I also can't have 1 mutex represent all physics objects because that would cause the physics and graphics systems to be constantly waiting for one another, there by defeating the whole point of putting them in different threads. One possible solution I have come across is to use a memory manager that maintains a master heap and a heap for every thread. Periodically it would then copy the delta from the thread heaps to the master heap and then copy the whole master heap to the thread heaps. But this presents me with 2 problems, first it would be super annoying to have to continuously adjust pointers to point at the correct place (although this might be solved by making use of thread local storage). Secondly because of the voxel box terrain, the amount of required ram for each heap could possibly get up to 6GB. So if your computer is like mine and can handle 8 threads simultaneously then that's 8 thread heaps + 8 delta heaps + the master heap for a total of 17 copies of the memory heaps and would require 102GB of ram to run. However it might be possible to solve this problem by grouping similar things together in the heap and then only maintaining copies of what each thread might actually need to read/write.

Learning to Art Update:
    Sadly I discovered a really good book and it has been consuming a large chunk of my free time. As a result I haven't done a lot of artful things.