Progress Update #8

once again I've had more unexpected things pop up that i need to deal with, so i haven't had much time to work on this and at the moment it looks like there might be a few more of these updates where i won't have much to show.

Code Update:

    I've started working on a memory manager for the game. The reason is that when your dealing with allocation and deallocation of small bits of memory, fragmentation isn't too much of an issue. But if you need large chunks of memory, you could potentially wind up with large chunks of wasted space. I'm hoping to really did into the chunk system soon to begin work on the world it's self, but for that I'm going to need gigabytes of continuous unfragmented ram.

learning to Art Update:

    I've picked up a book on drawing, so hopefully I won't be wondering around blind anymore and it will speed up my learning.

Progress Update #7

I'm afraid I've been a little busy with other things, so haven't had much time to work on this project the passed few weeks. So Happy New Year to everyone and hopefully I'll be able to make some progress for the next update.

Progress Update #6

    Merry Christmas everyone! Last post I noticed my view count steadily increasing and asked people to leave a post to let me know they were genuinely interested and boy are the results in! The view count plummeted to zero with the number of posts to match! So I think I can safely conclude that no one gives a fuck about me or my project. However I intend to continue to make these posts to document my progress if nothing else, although that may change at some point in the future.

Code Update:

    I have continued work on the character controller and things are starting to feel pretty good in the movement department, but I'm still trying to figure out how to solve a few of the issues I'm currently facing. I was kind of hoping to be able to get version 0.2.0 out for Christmas but then I realized just being able to run around on a flat map pushing boxes is kind of boring, so I'm going to get some terrain generation in there as well before pushing out the next version.

Learning to Art Update:

    Shading is really quite boring, so I stopped working on that for now. I figure I'll probably pick it up again later when I actually have something to shade. Instead I realized that if my end goal is to be able to draw people, I should probably be learning to draw people. So I found a picture of someone standing in the simplest pose I can find and have been trying to draw her. So far the results aren't great but I am seeing improvement with each attempt.

Progress Update #5

I'm noticing my view counter for these post is slowly going up, I'm curious if people are actually reading these posts or if the views are all coming from miss clicks and spiders. So if your actually interested in what I'm doing, go ahead and leave a comment.

Code Update:

    So what I have been working on is the character controller, which as the name suggest turns mouse movement and key presses into character movement and action. I've managed to solve a few issues i was having before, but still a lot of work to do on this front, so I'm going to probably be spending a lot of time trying to figure out how to make this work. As I have been working on it I'm also starting to realize I've been thinking about the relationship between entities and their physics shapes all wrong. I've been thinking that entities having 1 shape that can be used to get their position and rotation information and this is fine and dandy when your dealing with test cubes and simple shaped objects, but is going to really bite me in the ass later when I want entities comprised of multiple physics shapes. Now if this was a game that used simple pre-made animations, it wouldn't be an issue as all I would have to keep track of is the entity position, the animation name it's currently playing, and the time when that animation started, from that I could easily reconstruct everything needed. But as that I intend to make extensive use of procedurally generated animations for things like jiggle and ragdoll physics, I need a better way to keep track of that information then I currently have.

Story time:

    Earlier this week I started working on another programing project and for it I needed to work with a part of the Windows API that I've never touched before, so I went looking on MSDN for some example code. After a bit of searching I found a page that said the example code that I needed was part of the Windows SDK. I pulled up the Windows SDK and couldn't find any example code anywhere, so I thought, it's probably just installed without something checked in the installer, I'll just reinstall it and that should fix everything...Windows SDK broke super hard. Except for a few tools, the Windows SDK directory was completely empty. After a few more uninstalls/re-installs, I decided to bite the bullet and try a manual uninstall. I quickly realized that the uninstaller doesn't so much uninstall as just delete a few files and call that good. It left a complete mess everywhere, there must have been at-least one registry entry for every single file in the SDK scattered all about the registry. I gave up trying to delete them all after a few hours and looked for other solutions. Where upon I discovered the SDK has a repair tool hidden away. Running it restored most of the missing files, but I was still missing some of the Windows API headers and libraries as well as all the crt headers and libraries. Now I'm not entirely sure the crt is supposed to be part of the Windows SDK before Windows 10, but I ran a search on my hard drive and the files where no where to be found. After a few hours beating my head against the wall trying to figure things out, I finally turned to others for suggestions where upon someone suggested using a virtual machine. I installed the SDK on a virtual machine and got all the Windows API files I was missing, but no crt files. I did a lot of googling in hopes of finding a solution. Most sources I found said I was just in the SDK while some others suggested that it might actually be part of Visual Studio it's self, I checked visual studio's install folder and no crt files anywhere. I also know that I was able to compile and run programs just fine before messing with the SDK, so it must have been part of the SDK. At one point I got frustrated and realized I has just been yelling at bing for a solid 10 minutes. The only lead I could find on a source of crt header and library files was Microsoft's new ucrt (yet another version of crt that Microsoft is trying to force on us because that worked so well all the other times they did it), so fine, white flag raised, how do i get it? It's part of the Windows 10 SDK. So i grab the Windows 10 SDK and install the damn thing. It gets to about 97% done and then stops and rolls back the install. The resulting novel that was the install log report contained a typical cryptic Microsoft error message that took me an hour or so to find the meaning of. The error in a nut shell was basically "your not running Windows 10", which it seems like a real dick move to do when the web installer (I'll discuss my disgust for web installers some other time) is at 97%. This left me in a bit of a pickle, because I needed those files, but I quickly thought of a solution. While it was installing I changed the permissions of it's root folder to block everyone from being able to delete files or folders so that it couldn't actually remove anything when it started rolling back. This worked perfectly and gave me the files I so desperately needed. I took the files, shoved them in the appropriate locations and then compiled my program, SUCCESS!!! The program compiled with no problems and so I ran it. It died with a missing the ucrtbased.dll error message, this confused me because I always statically link the crt as a way to doge the weirdness caused by Microsoft continuously creating new versions. so to see if I was accidentally using the dynamically linked crt libraries, I removed them. I then recompiled my program and again it compiled just fine. When I ran it again it complained about missing the ucrtbased.dll. Really puzzled at this point, I removed the static crt libraries to see what would happen when I compiled it. The compiler complained about missing the static libraries when I tried to compile it again. My only conclusion is that for some reason the statically linked libraries still require the dll, which is something I've never encountered before. But after i don't even want to know how much time, I finally got it working, so that's enough for now, I'll deal with it another day.

Learning to Art Update:

    For arting it up, I've been working on shading. I'm not entirely sure how useful shading will be exactly, but I'm sure it's a good skill to have none the less. For it I found out about and made my first tortillon (no idea how to pronounce it) and it's really good, possibly even too good. The thing is so good at shading that I kind of feel like using it now at my skill level, it would become more of a crunch then a tool, so I have sat it aside and have been trying learn how to shade without it. I do however seem to have come full circle and am once again trying to learn to draw strait evenly spaced parallel lines.

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.

Progress Update #2

    Alright, so it has occurred to me that I may have been a little over excited about this and possibly posted the game before I should have and weekly updates might be too much. So I'm renaming them to progress updates and will probably be doing them not weekly from now on. Although not sure how often I should do them, monthly sounds like too much time in-between while weekly sounds like too little. So anyway, lets get into it.

Code:

    I've got serialization to where it needs to be for now, so I have turned my attention to the physics system. The physics implementation in Alpha 0.1.0 was really hackish and while it will probably still be hackish for a number or releases going forward, I'm currently working on making it less so. Hopefully by the next release I'll have the ice skating issue solved.

Learning to Art:

    Nothing really exciting here, still making lots of stick figures. Although I have noticed they are getting smaller and more consistent, so hopefully that's a good sign.