Wednesday, 7 September 2016

Just a heads up!

Sorry for no Monday update. This week, and next week I'm moving into a new place, right now I'm just setting up so I haven't done too much work on the game.

On the other hand, I did update my graphics driver, and things seem to be running pretty well now ☺.

Anyhow, I'll update everyone once I fully moved in, with proper internet and everything!
Until then, have a fun time!

Monday, 29 August 2016

Weekly Dev Report #10 - Awesome 'til it's not.

Textures! Proper Lighting!

And a little secret for next week!

So, on Monday I added some "Proper Lighting". By that, I mean there's actually a light source now, which follow the player. For the timing being, the player is able to drop the light source to check how the lighting effects everything. The textures were already done, at least the code for them, these textures (see below) were done in the first 3 days of the week. I wanted something pixelated, but still looks good, I hope this does a good job of both. I then made the shader aware of the texture pixels, so the light will light each texture pixel as a whole, and not light it uniformly.
And then, the big awesome happened, but, as I said, it's a surprise! I'm still working on it to be truthful. While working on that though, I've created a directory reader that's able to read from directories, and find files using wildcards. On top of that, I created a configuration file reader that extracts information from simple configuration files. Then...
I tried to implement it into the current program...

'Til it wasn't.

So, I wanted an easier way to manage my models, which was the primary reason why the configuration files exist. So, I made a way, and that didn't exactly work as planned...Two days later and my code is now running again...I think? Maybe? I haven't had any worrisome crashes, but I haven't exactly been testing it out a lot. During this time I've noticed my code drifting towards more of an entity component system. With that, I might be migrating my code to that as it seems to be a lot easier for me to implement a lot of other things then.
Ironically my old engine was ECS, but I really didn't like it....the way I coded it was horrible, to say the least...Lessons learned!


I didn't do everything I wanted to get done this last week, I was hoping for a simple save-load system by this time, but, well, priorities changed. I'll have all week to work on the save-load system. 
And finally, t'is is the end of my blog post. So, go back to work you slackers! And remember, have a good time!

Monday, 22 August 2016

Weekly Dev Report #9 - Segfault paradise!

My Week #9

It generally looked like this:

Where do I start? 
The majority of the work, and the pain causing the above image, involved making a data structure with O(log(n)) time when adding or deleting blocks from it. Took me 4 days to fix the problem.
To elaborate: I was creating a data structure for the pieces of the ship. The structure should've been really cheap in the memory, and could have fast lookup, delete, and insert times. The general idea was a 3D Spacial Tree, which held 3D "chunks" of blocks, with the models inside the chunks. Now...That didn't work...At. All.
So, after taking some time off and relaxing this crispy fried, slightly burnt (read 'burnt to ashes') brain of mine, I came up with a simpler, faster, easier to implement, and not to mention more memory efficient, way of doing things. A 3D "Map".
The 3D Chunks of blocks are basically the same as the previous idea above, but with a 3D map of the chunks, where you could access any chunk by specifying its location in space. If the function returned NULL, then the chunk located there, isn't there. If the function returned something that isn't NULL, and assuming there wasn't a weird bug (Tests have proved it doesn't! ☺), it was returning the actual chunk and it's data. The algorithm is pretty simple, but there needs to be a lot of checks.

So, what else was done this week?

Well, I found out that past me decided NOT to implement a few vital functions in my RenderList class (ie, removing models from it). So that cued in some writing, and rewriting of the RenderList.
My implementation of the RenderList was a list of textures holding a list of models, but all in one list. What that means is that, let's say we have 3 textures (Tex1, Tex2, Tex3). We also have a handful of models (M1, M2, ...). I had an array that basically looked like this: 
(Tex1 starts here)M1, M2, M3, (Tex2) M4, M5, (Tex3) M6, M7,M8;
Now, lets say we wanted to add M9 to the list, and it has Tex2; that would mean finding the end of Tex2 (which was already recorded down), moving the array elements from that end to the end of the array, up by one. Then inserting M9 at the end of Tex2.
Fine and dandy, but what happens if we have 4000+ models, with 4 textures? While the texture count may be low, but if we inserted a model with texture 1 in the list, the entire list, minus the first texture, would have to move. I didn't quite like that. It was messy, and to be honest, not worth the small benefit I'd be saving by keeping everything in one array, if there was any benefit. So I now have it where each texture has it's own little list of models. 
Anyhow, deleting from the previous implementation was causing more segfaults!

Lesson Learned: Simpler == Better

So, a bit late, as typically I'd have my work for this week finished by friday, with a few days to mess around, I finished this on saturday:
Yes, I know...Cubes again....Hey, it was the easiest thing to load and work with!
I also did a little fake lighting by "forcing" a ray of light. Now, my next goal to get is to get multiple pieces in and using the scroll wheel to change them up. That should be relatively easy, so once that is done, implement some basic saving/loading functionality.

It's a nice feeling finally working on the game editor, instead of the engine☺. I continued working on some miscellaneous things on Sunday, namely proper lighting, and I must say, I'm pretty impressed with the results. But that's a surprise for next week! So make sure you come back to see what I've done!


Not much else to say, I hope you enjoyed reading this, people on twitter are going to get a new little view now, and everyone else, if you're not following me on twitter, why not? You'll get the news when it's actually new and not a few days old! 
But anyhow, enough of my ranting, I'll be back next week. Until then, have a good time!

Monday, 15 August 2016

Weekly Update #8 - Monkey Business

What? Monkeys?

Yes, Monkeys...or rather monkey

Well, as those on Twitter would know, I was a day late to give you guys this screenshot:

Well, whoops! Despite being a day late, this screenshot shows many improvements that someone may not notice. First of all: vertex colors are back! Second of all: I'm supporting 4 materials in this screenshot! Well, kinda. Technically it's 4 sets of geometries with just one vertex color applied to every vertex, but, with some fancy work, it may become 4 seprate materials!

Wait? Vertex Colors? Where's the textures?!

The textures are still in the code, and can be used, I just was lazy and didn't texture map this monkey, but because of that, I added a new feature that was lost with the addition of textures! This new addition is rather important, because I may decide for a low poly art style with minimal textures, if any textures. Now this isn't the final decision and I may be adding fancy graphics the likes you'd never seen before! BUT as of right now, textures may not be a thing.

Okay, so you did that on Tuesday, what about the rest of the week?

I did some code cleanup. My event handling code was pretty much temporary, and well, because of that, it wasn't exactly meant for much, and I'm getting to the stage where I needed more stable, reliable, and robust code. So I cleaned that up for the past few days. Now my code looks all clean and pretty! Oh, and it's more flexible, who doesn't want that?
Saturday (yes, I work weekends too) I decided to add this little nice piece:
This shows a major improvement to the direction of where I need to go. I now can use multiple shaders, made a ghost shader for a preview before placing the head. The monkey heads, and therefore any model I can load into the game, can now be rotated and placed by the player. I've also fixed a bug with the shader loading which would've been frustrating to find later on.
Then I made a little "Snap to Grid" function, which can work for any uniform grid size (Okay, it's a fancy round-up function that rounds to the nearest whatever-number-you-want). That's pretty much it, Sunday I took the day off and read about data structures to excite me for the next week, leading to:

The Final Words

This week, I'll be implementing a data structure with theoretical access times of O(log2(n)) where n is the number of blocks in the ship. This is for adding and deleting, and modifying, the ship data. It'll be primarily used for collision detection, where I can ask "Where's all the pieces which intersects in the radius of R in a sphere located at P location?" For other not related functions, the data structure will be different (Like rendering, which is just a plain ol' list!).
Anyhow, that's it for this week! If you didn't come here from Twitter, make sure you stop by @nightlonegamer to get daily updates about what I'm doing, what others are doing, and twitter only content! (Yes...I know...That was a shameless plug. I don't regret it )
And as always, have a good time!

Monday, 8 August 2016

Weekly Dev Report #7 - Almost Codeless!

Almost Codeless? What?!

What do I mean by that?!

This last week was a scramble of what parts I was actually going to use. Remember last week when I said I'm going to be using panels? (and a huge list of other stuff claiming you could make anything?) Well, in theory you could've. In practice (using Blender 3D modeling software) it wouldn't have worked. So I endlessly worked on finding a solution to this problem. 
First I tested just simple panels, like the ones shown below. Then asking some friends, it would seem like building ships with small panels like these would be, first of all pain staking, and second of all, a huge time sink. Sure there's lots of people who'd LOVE to build a ship with these pieces, with me included! With the other features I plan on releasing, spending half, if not most, of the game time just building the ship? Not what I'm planning (of course, if so inclined, you still can). So I made room-sized blocks, kinda like the blocks most other building games would use, like big LEGO bricks. I really enjoyed that idea, but I wanted some variety where the doors, windows, etc would be placed. To do that I needed to make the walls switchable, so I modeled that. Then it hit me!

What if I used wall sized panels?

Using the exact same panels I mentioned above, but scaled to fit a wall, and not a small section of a wall, I could allow for a highly customizable ship but fast (ish) to build! While I won't allow scaling, all these pieces can be easily used together and be placed together just by rotation (of multiples of 90 degrees). For some wall pieces, there will be doors and windows variants too, that'll fit the whole wall.
Without further delay: The Pieces!
And yes, there was 219 test pieces, if not more.

That was the first 4 days! What about the rest?

I've been editing my exporter for blender, that's where most of the work has been put into. I've gotten the blender exporter is working (barely). So all this morning I've been working on making my importer for the engine. And guess what? The engine doesn't know what to do with no textures! Kinda my fault for assuming we'd always have a texture. In some cases, like a low poly art style, we actually may not have textures, just vertex colors. So yeah, dealing with that mess is, well...a mess.
I have many ideas on how to fix this, but I have to test them out. The current idea I'll be testing out is the idea of having a "blank" texture. First it'll just tell the shaders not to use a texture (if I can do that easily enough with my code), if that doesn't work, I'm just gonna have a single white pixel texture, and then multiply the vertex colour with the texture.

Final Words

Well, this week has been fun and unexpected. I've rewritten 90% of my model exporter to be kinder to the eyes, and brain. I've also found a nice (sarcasm) little quirk about my engine that I need to fix!
After sending this up, I'm gonna have fun with making a "no texture" feature...Until next week!
Have a good time!

P.S: Sorry, no 2 screenshots this Monday. Once I get the importer working I'll tweet it!

Monday, 1 August 2016

Weekly Dev Report #6 - First Monthly Report!

It's August first!

The first of the month!

What does this mean to all the people reading this? A little discussion of what's up ahead, including this week's update!

So, first of all, what did I do this week? Well, I wish I could answer that with sleep, but due to real life stuffs, sleep wasn't exactly on my list of todos. What I did do though is made sure that we can use more than one model. Mind you, currently it's just the same mesh, but the theory works the same with different meshes. I also made it load and use multiple textures, which was of great help. I've, frustratedly, made a "simple" algorithm to sort, whilst adding, a model. The engine is sorting models by textures, so we're not going "Texture1" then "Texture4" then "Texture1" again, and then "Texture2". Nope! It's sorted by "Texture1" "Texture1" "Texture1"... "Texture2" "Texture2"... etc.

With all these changes, I made the Render List class (Finally!), the Model class (not 100% finished), and a few other helper classes. I've also made it so certain geometries (faces, groups of faces) can be toggled on or off, as seen on the image below.
I've also replaced almost every "printf" function with "logM"/"warnM"/"errorM" (Log, warning, error, messages) macros so my output looks less like a mess and more like:
[LOG][@src/Graphics/Model.cpp - 240] Something happened
(Not a real logM message by the way)

I did some other house cleaning work on my code as well, don't exactly remember what, but my code looks a lot cleaner...and less confusing.

So, picture time!

Here is the image showing 3 faces (Geometries) toggled off, to be hidden. In this image I've disabled backface culling, which is normally on.
Cubes! So many Cubes!

What About August?

This month I'll be more focused on getting some sort of "building system" in place. While last month I worked on getting the basics up and running, and most of it is. This month I'll be working on loading models, which, for the sake of ease, I'll be using a custom file format, a format I used in a previous engine attempt, with a slight change to accommodate with the new features of this engine. The exporter will be written for Blender, and will be free, so once the first public alpha comes out, I'll provide that for those who are good with Blender and an image program of their choice. After that I'll be slowly working on the building aspect, making it simple and easy to build, almost anything, using panels, steel structs/bars, I-Beams, etc.

The building system should be pretty easy to use, certain pieces will have many degrees of freedom, though snapping to certain angles, I will allow a bit more fine-tuning the angles as well. Some pieces will have more limits placed on them as well, to disallow them being "misplaced" (upside-down computer screen anyone?). Many things will be able to be scaled, some will be made out of several pieces so that the inside part can be scaled, while the frames stay the same width. Again, scaling, as well as rotations, will have their limits. I don't want to hassle the player to exactly measure out a 3.4562m x 1.503m piece. So in that case, they'd be limited by 3.5 x 1.5 meters.

Exact details on the pieces, and how they'll be placed and used won't be disclosed yet, as it's subject to private testing, feedback, and how much they annoy me haha.

This first editor will not be available to the public.

Final Words

I hope you guys like this new format, I may stick with it for future posts, as it's nice, and hopefully easier to read. Any suggestions? Please comment! I would love to get a little community feedback here and there, see what the audience wants. The best thing I can do right now is just type what I think, who knows, maybe that's what you guys want? I don't know, I can't read minds! 
But, alas, I best be going, so, as always, have a good time!

Monday, 25 July 2016

Weekly Dev Report #5 - TEXTURES!

Oh, did I say, last week, that I was working on the player moving? Well, I did that too, on the 19th, and also on the 19th I implemented some basic texture, basically, a failed checkerboard pattern:
Yeah, I fixed that soon....Anyhow, on the 20th I actually bit the bullet and worked with libPNG and my lovely little graphics program to get this:
Lookie! TWO screenshots in one Dev Report! Lucky you guys! Note: not final textures. Not final models...Not final anything!

I've also changed some background code for the models, and the loading of them.

Next week I'll be working on the model format, making things easier to work with and render. I want it to be simple and easy to use for myself, and anyone else looking at the engine. Currently it looks like this (model side, not talking about textures):
Make MeshBatch (The thing that actually deals with GPU-Program communication for meshes)
Make Model (Variable)
Tell Model about MeshBatch.
Load an actual model in the Model.
Make the Renderer.
Then in the game loop:
For each Geometry in the Model, Render it.

A lot of the steps will be the same all the time, so I'll be shorting this to:
Make ResourceManger;
Make Model(s) and load it from ResourceManager.
Make a RenderList.
Tell RenderList about Model(s).
Then in game loop:
Tell RenderList to Render.

The ResourceManager will, well, manage all the resources, models, textures, anything else I can think of. It'll also deal with all the little things that programmers (or rather, myself) don't want to do with every single resource. Also, if I decide to release this to public, for learning purposes or any other, people won't be overwhelmed by everything this engine provides, or doesn't provide.

Anyhow, nothing else new I can think of so, like always, have a good time!