Slow progress

I've been sick for a week then struck a heatwave, I hate high temperatures and working without any kind of air conditioning is horrible, so I've only been working on memory usage and trying to eradicate all garbage, other than that it's been quite quiet.

Oh I have been searching for more ways to improve the terrain generation and looking for ways to add water and there has been some success although I've yet to implement any (except for one image below of random generated canyons) but it's looking promising.

Gameplay and more terrain generation

So I've more or less finished the refactoring and I've begun adding some gameplay elements starting with foraging items from the ground and proceeding from there to some basic survival mechanics, crafting and building, after that I'm adding some neutral and hostile npcs with which the player can interact with. I'm also trying out some different terrain types to see which I should use and so on.

Samuli also has modeled some house parts for the game and I'll be adding them once I have programmed building.

PS: I'm still updating the task list at Onwards

Latent optimizations

So I've been refactoring the project and changing most of the integers to long so I can generate larger maps is going well, there were some hiccups here and there but it's still an ongoing process.

I also noticed some potential optimizations in the chunk rendering part which I've now added, I noticed these because I changed the cube array in the chunk to the length of 4096 from 2048 to take advantage of the previous optimizations (which I mentioned here Rivers, streams and more optimizations), the change was a double edge sword as the chunk rendering took twice the amount of time to render a chunk, fortunately I noticed that there were some potential optimizations as it sped up the rendering from 5 to 11 times faster.

I've also reduced memory usage by hundreds of megabytes depending on how many chunks are possibly visible, I only removed index an int variable and a vector3 position from the cube class as they can be easily generated if needed, as I mentioned a chunk has 4096 cubes and over 8000 chunks can be visible, the amount of memory needed for position and index is massive.

One down, thousands to go

So I finished creating the GUI based on Samuli's concept art and I can now start working on the gameplay... not.

I found a memory leak in the terrain generation that's resulting either in garbage collector not clearing or it's something I've done, I'm guessing both, so I have to trace it which means refactoring the terrain generation, although this prevents me from continuing the gameplay, but good news is that I can modify the terrain so I can create the actual size I was planning.

I was also planning in adding the cube unwrap which I've talked for so long now, but it dawned on me that the normals in the mesh would suffer, rendering a cube properly would need all 20 verticies otherwise I would need to rotate the angle of the normals and I have no idea what that would look like...

Rendering problems

So I had noticed in the beginning that there were problems with the GUI rendering transparent textures, the textures were missing either pixels or were rendered in the wrong order.

I used a transparent cutout shader to display the textures "properly", but there were problems of course, specifically because I used alpha testing to render the opaque pixels from the texture while writing to the depth buffer. In the next pass of the shader I turned depth buffering off and prevented any pixels from the depth buffer from being written again, after that I had turned alpha blending on and it wrote the transparent pixels. It all seemed fine and dandy but it did cut some of the more transparent pixels off.

I removed the first pass and now I only have the second pass in the shader (the shader is close to an unlit transparent but with vertex coloring) and it seems to render fine, expect for the sorting of the triangles in the mesh, which I had to add in to my mesh rendering. The only problem with it was with the rendering order with other gameobjects, they were either always shown on top of the GUI or the GUI renderers din't show over the others renderers even if they were closer to the camera. 

This was really weird and I looked everywhere for this problem, I though that the problem was in the mesh as the unity's cube mesh would render correctly with the same shader and this puzzled the hell out of me. Finally I found the answer and it was in the material, more precisely in the renderQueue member of the material. The renderQueue was set to 1 every time a texture is changed by script in the material (maybe by modifying other members in the material as well), the number in the renderQueue is the same tag as the shader's Queue tag which are:

1. Background, 1000
2. Geometry, 2000
3. AlphaTest, 2450
4. Transparent, 3000
5. Overlay, 4000

The renderQueue tag is set automatically if the material is modified by unity, but if it is modified by script it will set it to 1 which is nothing and it would result in a very chaotic rendering order, by setting the renderQueue to 3000 would result in a correct rendering order with other gameobjects.

Moving on

I finally finished the new GUI framework which took ages to complete, but now I can finally have an easier and less frustrating time creating the GUI for this project. I've also tried to make the framework as user-friendly as possible while being flexible and able to do complex GUI's.

I've also began creating the GUI for the game using the textures and concept art I received from Samuli, when it's done I can continue working on the gameplay for the game, specially the character's skills.

I'm also eager to change the chunk size to 16 * 16 * 16 from 16 * 16 * 8 as well as adding the cube unwrapping so I can reduce the vertex count.

Upgrading

I recently upgraded from unity 4 to 5.4 and to my surprise the game is running more smoothly specially around trees.

Why I only now upgraded to unity 5 was because I did not believe it would boost the game in anyway specially in how unity handles custom mesh data (I wish unity would take arrays as references or at least give an option so that I can give it an array with an integer to let it know of how much of the array I'm using so I don't have resize the array every time...).

I also began to reprogram the GUI for the game, because it was lacking in features and it was quite a pain to work with, why I don't use an existing GUI is because I know what I want from it and I can optimize it for that purpose and to make it work the way I want it to. You might think it's reinventing the wheel and you would be right but if people don't at least study or try to create something that has already been done they don't advance as a programmer, besides I've already done this once and I can create modding support and modding tools for it at the same time.

I've also been thinking if I should sell the GUI in the Asset Store, but I'm not sure if anybody will buy it and if it's worth all the hassle to get it into the Asset Store. I also been thinking if I should join Patreon and if I do then I'll just share it for free there...

More on the GUI, it will be fast, responsive, automatic scaling and relocation based on resolution, it will have buttons (with a delegate, mouse over, down and normal textures and a tooltip), uniform and sliced scaling, text (which is rendered from a bitmap), able to use a texture and render it in a circle with a varying central angle and to create a drop down menu with menu items hidden outside the menu even when scrolling, the GUI will be stored in an XML file and if the GUI was not saved it will be also serialized to the scene or prefab so no changes will be lost, also because it can be saved into an XML file changing the GUI while the game is running is possible and it's possible for the user to change the GUI, this of course can also be disabled, the GUI can be modified either via the scene or script.