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!

Finally

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!

Monday, 18 July 2016

Weekly Dev Report #4 - Some useful tools


My life this last week.

Quaternions, they're tricky little things. You can kinda guess what I was doing this week, other than making witty comments. So! All my lovely work is now in quaternions, that work! For anyone insane enough to make their own math library, I shall give you the references I used, and sometimes intermingled, to get this lovely piece of work, working!
http://www.cprogramming.com/tutorial/3d/quaternions.html  This was a big help, no doubt about it. If you want something quick and easy, that's where you go to.
http://www.3dgep.com/understanding-quaternions/  Good read, can help you understand quaternions and the math behind it more, there's some more functions there too like dot products of two quaternions.
http://www.songho.ca/math/quaternion/quaternion.html I just liked this one, the format of how it was done, explains a few things too. All these links tell you the exact same thing, though in different ways in some.

Now... Wanna make sure your calculations are right? The following two sites helped me debug the above problem, with my own print() functions for the matrices and quaternions:

And, my so far favourite tool of all time: gDEBugger!

Now What did I Actually Do?

A lot-ish. First, I made the cube, instead of a rotating rectangle, made it rotate on the x and y axis for fun. That was, seriously, the day after the last post. The rotation was using Euler angles though, and I didn't like the idea of impending doom (gimbal lock) so I started with the Quaternion math, spent half a day writing it, spent the rest of the day debugging it, it took me 5 hours to find out the signs were switched....It deserved a comment... (as above). Then I decided to use the keyboard to control the rotation of the cube, cause, why not?!
Then, after that, I started working on separating my code so I can actually load models in! Exciting! Guess what the first model I loaded in? A CUBE! Actually, it was created on the spot with code...I'll have some utility functions to create basic shapes. Later on I separated the huge mass of the hard-coded cube into just rendering and a MeshBatch class, which will be used for having multiple meshes into one VBO, and the mesh Indices into one IBO. After that I finally separated the Shader Program class from the renderer.
I'll taking out all the functionality of the Renderer and placing them in other places. Right now my code is structured so that the renderer does all the work. My method of working, which may not be the best, but it works for me, is make it work first, then separate it into classes later, make sure it still works, and cut it up some more!

Now, for the fun part (My niece gave me that idea, she's reading this as I type it): The weekly screenshot!
It's a cube! Better than a rectangle right?...RIGHT?! Well, since the game will be made outta cubes, for the most part, this is the most important part!....Well, there's the other code too...but....ANYHOW

Next Week: (or rather this week heh) I'll be working on making the camera move around with the mouse and WASD keys (and QE for rotating on the Z axis); anything more is extra and awesome :)

And, like always, have a good time!

(Also, Welcome Twitter users!)

Monday, 11 July 2016

Weekly Dev Report #3. Update and "Why make a game engine?"

Oh hey! I'm on time!
So yeah, I'll be trying to do this on Monday afternoon sometime (my time, might be tuesday morning for all you folks overseas!)

So, what did I do this week? A lot of vector math, matrix math, etc. Nothing to show, other than a spinning square. Oh hey, I did say I'd show progress...Well okay:
Last week! ish....I actually don't have a screenshot for last week and didn't want to delete all the code, so I just modified the shader to show ALMOST what last week was.
This week! So exciting huh? No? Well, that's cause most of the work was behind the scenes. I have it so you can specify matrices values as column major order, the system OpenGL uses. If you don't like that, there is also row major order as well. All the vector and matrix math uses templates so you can just use Vector<float, 3> or Vector<int, 2> Heck, I don't see why Vector<char, 17> wouldn't work! Just...it would be pointless. Same with Matrices, but one must specify in column major order for it to work. Next week the plan is to make sure that I can convert between Vector and Matrix, and also have Matrix * Vector work. Won't take long at all, I'll also be working on Quaternions, so don't expect anything prettier than above for next week, who knows, maybe I'll make a gif of it spinning? 

Now... I can hear a few of you asking "Why make a game engine? You have Unity, or Source, or <insert fave engine here>!" Well, for one: the experience, the pure joy of making something by hand! That's also why I'm making my own *grunt* math library. Another reason is that, Unity, Source, and others don't have the features I'd want, SURE they have a lot of features I do want, SURE I can program the features I want into them....but that would require understanding how they work at a deeper level, when I already understand OpenGL at the level I currently require. Also the game doesn't require too much in way of graphics capability, so using something as powerful as Unity is, let's be honest, overkill.

Would I suggest making your own engine? If you want to make a game asap? The no. You want to make a game that'll sell this next year? Nope! Want to make a game that will impress everyone? Probably not. Want to learn how games are made inside out? Yup, make one then. Have wayy too much free time and want something to keep you busy? Then if you're up to the challenge, do it!

So, Normally I'd say something about last week to tie these two weeks together, but...the only thing that's really the same is the vector math library I'm working on. So, besides that, nothing much to relate to.

While I'm still trying to get comfy figuring what I should say each week, to make this more engaging for you guys, and not just saying whatever comes to mind! (Though, I think that works too hehe)

Anyhow! This is it for now! Don't expect a screenshot next week, unless I've done something AMAZING (ie, not get distracted and did something productive that's for show) Well, I guess I did do something new, seriously the day after I posted this, so screenshot next week! I'll see ya guys next week! Until then, have a good time!