Sunday, November 13, 2016

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.

No comments:

Post a Comment