A Stable Rendering Engine, and some new features

Today is a big day for Wawacraft:Evolved. Today is the day that a stable rendering engine has been created, the day that we can now reliably render things, and a day that is ultimately a step further into the esteemed minimal environment of a Wawa cube.

After several days of rewriting the mesh class and WCRL(the official moniker for the set of rendering classes and methods created for Wawacraft:Evolved), I finally got the mesh rendering working, and established a rendering method that I call instantaneous rendering.

Instantaneous rendering is a system that I have devised for Wawacraft after I wrestled with OpenGL and lazied out,and it is a system that involves refraining from rendering as much as possible, and a system that instead relies on establishing the important details of a 3D Scene. What happens is that in the game's code, a "render-friendly" mesh is kept in memory, and an integrated OpenGL rendering environment is established for a short time in order to render for a short time a "snapshot" so to say, of that mesh. This is as opposed to traditional games, where a mesh object is simply binded to the game data for the model, and used whenever necessary, or often times, added to a render queue, and rendered alongside every other object in the scene.

Now you may think this is a baloney system, and it is. There's a reason it's not exactly established, and that is because while it is more memory efficient to instantaneously render the mesh, only using the memory for a short amount of time, it is also quite the performance intensive action, because OpenGL is specifically built to work with reserving GPU data for an extended amount of time, with the memory optimization being done by removing the load on the memory for the real-time graphics. I definitely need a rewrite on the mesh class back to its old form, now that I understood what the issue was plaguing it. Speaking of it, let's talk about why I rewrote my mesh class 4 times.

So my mesh class so far isn't very efficient or intelligent. It uses instantaneous rendering, which isn't very smart in the long term. That is because it is the 4th revision of the mesh class, with all the previous implementations being very much better than the new implementations. However, in a series of bad debugging, I instead chose to rewrite the mesh class as a clutch instead of actually at least searching for the issue behind the problem at hand. I initially had a sane mesh class, but for some reason, when I set the glVertexAttribPointer() attributes, I instead found that linking the pointer to the list of attributes by sending in a pointer to the first element of the vertex array doesn't work anymore. Some implementations I've studied used it, and so I had to use the function std::vector::front() to the pointer of the vertex. So now I have to rewrite the mesh class back again to the beginning of the vector. However, I have implemented some cool features in my new WCRL after 4 rewrites to important elements.

Optionary color overlaying, and simple alpha-blending!

That means we can make textures meshes use the color attributes as an additional visual effect, and alpha blending means we can use textures with alpha components to implement transparent regions, allowing for visual effects such as making sprite billboards with characters that look as if they are not quads moving around in a 3d environment. In fact some games utilize transparent quads to simulate grass and vegetation. You can notice this in the old Call Of Duty games.

But wait, there's more! Textures also now have the choice of being loaded with different interlacing options, which allows for either linear gradients between the pixels, or absolutely no gradient between them, which means I can make the game look pixelated, or allow it to have gradients when loading images. It's not exactly the best choice to interlace low-res images, nor is it to remove interlacing on large-res images.

What this Means!

Well, this means we are one step closer to creating a functional 3D environment, and creating a Wawa cube just like in the development of the original Wawacraft!. I only really have to study matrix multiplication, which I already understand to some degree, and study how 3D projection math really works, which I also somewhat understand due to writing a basic from-scratch wireframe 3D renderer in SFML previous to this. That renderer did not use matrices, as I had not yet understood them, but I read some books and gained some knowledge, which now means I sorta understand it.

I can barely explain it due to how I visualize it quite weirdly, but the idea is is that every element of the first matrix is equal to the sum of all the respective elements of its row multiplied with their corresponding elements within the second matrix's column, of which progresses for each row in the first matrix. Due to how this is, matrices can only be multiplied with matrices of similar dimensions, or with only one column, which makes it easier. What I also learned is that a column vector, like the one I studied in school last year so we could learn basic 2D transformations, is also applicable to be a matrix!

Now one thing that I'm not sure what to pick on is whether I would like to implement all the projection mathematics on my own, or using the often coupled library GLM, which handles creating projection matrices for you instead of you dealing with the math. I figure that the GLM approach would be faster and more stable in the long term, but I can't shake the feeling that I would find it a more satisfying/fullfilling process to create my own mathematics systems for the code and write all the projection math myself. I already have the supplies to, and it would be relatively impressive to say that I coded the 3D myself, but given that most people who play games don't really care if your 3D library is in-house or extended, and that it would be defeating of the point of a library to write your own library instead of making your own and expecting said library to be used. It is foolish but I take enjoyment in the bragging rights.

I guess I could use GLM for the moment, and follow the tutorial, and use it for an extended period of time until I actually feel the need to write my own 3D rendering algorithm or feel that GLM is very limiting(This will never happen). I think why the choice of writing your own 3D Library as opposed to the much harder(and perceived impossible) task of programming your own 3D projection is easy for other people to decide on and hard for me to decide on is that I know I could realistically succeed with any two of those options, and that I'm already biased to rebuilding things from the ground up despite the difficulties associated with that, and because of my central philosophy of being dependent on yourself to the greatest extent. But we'll see what decision I decide to take, and how well I implement it. After all, it's all just the exact same math, right?

Wawacraft:Evolved Art?! Let's Go!

So in celebration of Wawacraft Evolved getting ever so closer to success, I had the fun idea to redo the sprites for Wawa and his friends in 32x32 instead of 17x17. You heard it correctly, the old Wawacraft game loaded Wawa and Uni sprites of the resolution 17x17. That in my opinion isn't a good resolution, and while I'd love to use the old wawa & uni sprites, I think it would be more fitting of a game with the subtitle Evolved to have some more developed art.

I was actually already envisioning some similar images, except they may have had many more gradients and some muted dark atmosphere to these drawings in some way. Not dark as in throw a bunch of blood there, but a gritty or unpolished look to these to make them look as if I just edited a real life photo of the characters. I would definitely be better at this with the block textures for the game, I already have the idea of muted colours in my mind, but the characters are so vibrant in a way that it becomes hard to make their textures feel unpolished. Some might say that the very fact that your art is not the best makes it unpolished, but what I mean when I say it's unpolished is that it should have an aged look to it. Not super intense image compression artifacts to it, just a bit aged, or like the look of amateur pixel art.

I made the color combinations of this as real gradients, which definitely makes it look quite vibrant, and the eyes and mouth are not the best, though I like how they looked in my old drawings. In some of the character sketches for Wawacraft, Wawa had a more cartoonish look, with the mouth of well a cat in most cartoons. And he had this special sort of beard-like think around the bottom part of his cheeks, but I think I didn't have enough space for them.

Regardless, I hope you enjoy these drawings of wawa, but I don't. I will have to redraw them.

One last thing, I finally have the opportunity to add Floppa and Ploobie, who are essential parts of the gang, in this new game! Yay!

Conclusion

Much like most other updates, I have a lot to be proud of, and a lot to fix, and a lot to do. Well, I'll see you in the next update then!

Textures! And a bit of rambling...

Hello again! Wawacraft:Evolved is still a thing I am working on, but not as actively as before. Now, Don't let this little date mark fool you, I was already done with making textures on the 30th of July, but I just was too lazy to make an update. But don't worry, I have great news!

We Have Textures!

Yup. I got textures working, and now we can see Wawa's face plastered on top of a triangle. What does this mean? It obviously means we have succeeded! I have multiple snapshots of the progress I have.

So despite what I previously had in mind with graphics libraries. OpenGL doesnt actually load any textures from files. It actually requires to load from raw, hardcoded data in the form of a c-style string. This isn't exactly the best kind of way to store your images for ready change, and in the previous game, I could load in texture resources as separate files in a resources folder. Luckily, there is a library built to load in images from the filesystem and into the code as raw data that OpenGL can interpret. This library is called stb-image, and much to my surprise, was all but one header file.

Programming in the texture interpretation was quite easy. And it wasnt as hard as I believed it to be. Just do the necessary loading functions, and supply the image parameters for interpretation(how many color channels? RGBA? Resolution? etc.). And all of this is quite the success. We truly are reaching ever so close to an interactive 3d environment with a cube of Wawa. But one last thing remains that I have had a lot of issues with this whole time.

The source code has no foresight.

In my early development of the original Wawacraft, I had rewritten the entire game about 3 times before I settled on leaving the code as it is now. Refactoring is my biggest fear, but for Wawacraft, it's quite obvious that I will have to rewrite the game from the ground up multiple times. What does this include? The rendering library of course.

My first issue is WCRL. I have named the headers and code that I will use for rendering things on an abstractified layer on top of OpenGL and its subservient libraries "The WawaCraft Rendering Library." It won't be built like a library, but it could just as well serve for the base for a framework for abstractifying GLFW and OpenGL for anybody who wants to use it. WCRL right now is not a good library. It loads in shaders by embedding shader code into the file, which is not at all good practice. It also can only load a specific file from a specific path, hardcoded in it. And on top of that, the use of C-style structs and helper functions instead of C++ Classes with encapsulated functionality was a really awful compromise I had to make in the previous update to get any rendering working, otherwise I would get a thousand segfaults.

One thing that I think I wont change is the windowing system. That had no relative issues, and is very much important. I don't thing that needs a rewrite. But regardless, if I am going to ever reach the Wawa Cube in perfect form, I will first have to rewrite WCRL to be better, and more elegant and flexible. That way if I ever need to change anything, I wont need to jump back into primitive rendering from scratch all over again.

Some cool ideas I wanna talk about

In this post I have shown you a picture of Shawa. I was starting to think of how the advanced game would be like. I have a vision where the game will randomly throw you to battles against bosses in a convenient time. You would have to defeat these bosses to get XP and expand your character's skill tree. That will incentivise players to do more things in the game, and trigger boss fights.

And also, I never liked fighting mobs in Minecraft. I think they are an annoyance in general, and the benefits of fighting them are minimal. You do not get much XP for fighting these mobs, and most people only head to the bosses if they want to progress in the game. The mobs are an annoying afterthought that makes the game a bit infuriating to play. The idea of only having bosses to fight, getting a real incentive to fight these bosses (i.e. XP, expansions in the skill tree) as well as most importantly, the ability to run away and fight the boss another time when they are more prepared, will make combat in the game better. That way there is less annoyance, and instead places the incentive of challenge on the player, by programming them to always prepare for a boss battle when playing regularly, and looking forward to meeting the boss, it creates a good loop.

This however does mean I need to create enough bosses to fit the skill trees, which is a lot of bosses. That needs creativity. Wawacraft is exactly the kind of game where this isn't a problem. Why? Because most games like to keep narrative consistency or a half-serious story. This makes the player expect the game to take itself seriously or at least keep a common story, and sometimes makes the game boring. But Wawacraft isn't that kind of game. Wawacraft is, and I will continually refer to it as, a lopsided feverdream game. This means that any and every boss idea is a good enough boss. Here are some good ideas for different bosses that I have had in mind:

Shawa

A cone with Wawa's texture splattered over it as a boss. It should look somewhat like the shawa blooper earlier in the update. It's attack pattern I think will be that it circles in orbit around a point that approaches the player straight on using some pathfinding. Shawa rotates also around his Z axis whilst orbiting, and the closer he gets, the stronger an image of the blooper becomes. The image layering thing is actually similar to what happens in Slenderman when you look at slenderman for too long, except now the opacity of the screen becomes higher the closer Shawa becomes to you, and if he touches you, you lose health continually.

the Real Wawa(which I will refer to as Oh The Misery or OTM for short)

A picture of the actual Wawa, the Oh The Misery cat as many call it now. OTM will chase you and upon reaching a certain distance will explode into many smaller OTMs, who also chase you but now even faster and their explosions less powerful. OTM will also have a song that plays while you are fighting him. His boss theme will be Enemy by Imagine Dragons but in an epic MIDI remix to avoid legal issues.

The idea to beat this boss is by outsmarting it. Run close to OTM, and continually have OTM explode into smaller versions until you can chop off each small OTM individually and finally destroy it.

I got this idea from an older game prototype I had called The Museum, which was a game that also featured Wawa before Wawacraft was a thing. It was called The Museum, and I planned for it to have the gameplay of a horror game where you search for items and the monster searches for you. All of it would take in a museum, and I had the idea that the player could fight against Wawa, and when they shoot them, it bursts into smaller wawas, which makes it harder and harder. I actually have a real video of The Museum before I gave up trying to do sprite billboards in the raycasting engine. But this Idea will live on.

The Helicopter

The Helicopter is a helicopter that circles around your general area, and tries to bomb your approximate location. These bombs will come in the form of target-lock missiles. These missiles will lock onto a location, that will be communicated to the player through a stylish yellow-red HUD marking like the one in the final boss of Sonic 2.

The boss music will sort of be like the boss music of Fatman from MGS2. The way to beat The Helicopter is to dip yourself in a half frozen lake in order to trick the lock-on heat targeting. Or you could throw magnets on the floor to attract the missiles. Throwing a ring of magnets around a wide enough area will eventually jam the helicopter's navigation system and the helicopter will come crashing down.

But then a second stage of the boss fight happens. The helicopter stands up and begins fist fighting you. This idea came from a prototype of a scratch fighting game I wanted to make with all the different OCs I had made at the time, and make them fight, called "Puffball And Chicken Legs Fighting" or something of the sort. I wanted to add some silly characters like "The Rock" which is a rock with the face of Dwayne Johnson on it, and of course a fisfighting military-grade helicopter that can deal damage with no hands and no feet as if it has invisible limbs.

Coneman

Cone man is a character that I made before. He is a man who is stuck in a cone, who has blotches on his skin(vitiligo) and hairy feet. Coneman has an RPG launcher. His attack pattern is that he runs about and places himself in the right position to launch RPG missiles at you, after which he has a reload downtime to load in new missiles.

He will spawn at random locations disguised as a regular traffic cone. If you interact with this cone, coneman's arms and legs will pop out, and his head will pop out too, with the tip of the cone acting like a hat that conceals a dark face with only the frowning/sleep deprived eyes of Coneman.

Once you beat coneman you will also gain an achievement that says "Rocket Propelled Traffic Violation." How funny would that be?

Conclusion

In short, theres a lot I have in mind for this game, and a lot of effort I'll have to put in to get what I want. I'd rather talk about Wawacraft in practicality rather than theory. Lets see if this works. See you in the next update.

6000 Segfaults later...

After 6000 segfaults, 3 days with OpenGL, 2 days trying to write a primitive rendering wrapper base for OpenGL and essentially 2 rewrites of said wrapper base, I finally achieved the amazing Triangle of OpenGL!

This is a greater success because of the kind of things I had to do to get it to work. I initially tried implementing the rendering library in C++ style classes. That failed quite miserably and is the the cause of the rewrite. However once I started writing the rendering wrapper with C-style structs and helper functions that passed the polytri struct via pointer, I actually got my successes with it.

Rewind, rewind rewind.

Given that in the last update quite literally 3 days ago, I was using GLUT and not this weird thing GLFW, you the reader are probably quite confused how I reached this state. Well it was mostly about me learning that GLUT was outdated and not the best framework to work around OpenGL with. FreeGLUT and GLUT respectively are apparently only used to make skeleton projects and don't scale well. As well as that, I found that switching to GLUT meant that I'd have built-in input detection and management. That's always a good thing if you are developing a videogame, since half the time you are usually pressing keys to get the game to do things. So I switched to GLFW, and started following the tutorials on https://www.learnopengl.com/. That site was a treasuer in that it actually provided some good instructions on how to get started with OpenGL, and they just so happened to use GLFW. It's a great tutorial series, you should read it if you're starting out with OpenGL or want to get into graphics programming.

What does this mean for your GLUT build?

Scrapped it and threw it in the trash. Started from scratch and configured GLFW, GLAD, and OpenGL. All of those were quite easy to set up for a hard library. I'm actually quite happy I'm learning to fade out of IDEs and start moving towards more close-to-the-metal building systems. Manually writing makefiles for GNU make, running the G++ compiler, from the terminal, and using a basic(Haha, it is Emacs. In no way is it basic) and versatile text editor(Emacs) to write things.

What about the in-house 3D Renderer built from scratch and the 2D primitives library to support it? Are those simply gone now?

When I got into OpenGL, I thought that it would be so flexible that it had both 2D and 3D parts, all fully supported and independent. That was simply not true. OpenGL is a 3D library that can be made to look like its running as a 2D Library. So if I was to start using drawPixel() calls to render each and every pixel on a 800*600 screen with only RGBA colors, I would need to hack at the library, and use the outdated OpenGL classic pipeline, which isn't very well looked upon, nor does it scale anywhere near 800*600 times.

So the simple answer is yes, unfortunately. There will be 3D subroutines and 2D subroutines, but they will not operate from scratch. They are in practical terms only quality-of-life code that neatly encapsulates the ugly OpenGL process, and makes it easier to develop the game and scale it. This is the case for any game made with OpenGL.

Maybe one day I will see a port to be made to some archaic architecture or machine, such as in a hypothetical example(Because it usually is quite rare to think of) a machine like the Sega Saturn or i486 CPU architectures or CPU speeds around 400MHz. In that case, I could see a real use case where it would probably be better to roll my own 3D renderer rather than using OpenGL, let alone my own 2D rendering library. But believe me, I have all the right tools to embark on such a project, and I will not hesitate to given the opportunity.

Considering creating a GIT repository for people to see the source code.

In the tradition of the original Wawacraft(in all of its low-optimization isometric glory), I plan to make Wawacraft:Evolved Free and Open Source. Many initial versions of Wawacraft in alpha or beta were lacking up-to-date source code, so I could consider some of it freeware, but because I am the author of that game, and because I never intended to make it "freeware" as it is known more so "free software" and Free in all the terms, I simply do not consider it freeware nor is it freeware in any sufficient way. I never protected the game under a real license however, and just said the only rule to follow when creating any mods or derivative versions of the game, that I be credited in a valid way.

But with all of that said, I probably should be uploading the source code and updating it too. However, it is too basic of a program and indistinguishable from any other starter OpenGL project, that I would rather get to the task to uploading the source of Wawacraft:Evolved. However I will be doing it, so no worries.

One step closer...

With all of that said, we are getting one step closer to the Wawa cube that I promised in the last update. One step closer. See you in the next update. Nya!

Switching over to OpenGL (& FreeGLUT)

So, I did it. I switched to OpenGL, after all that fuss. No API. Just pure OpenGL and FreeGLUT. In hindsight it made a lot of sense. After 3 days of trying to make SFML do something OpenGL usually does, I decided to just bite the bullet and switch my game to function on OpenGL. It's definitely the better choice I made for the long run.

The image you see above is the OpenGL window I spent this morning adding in the game. Speaking of that, let's talk about the fact that I had to throw out all my old code just because we switched to a more primitive API. I had to throw out all that hypothetical 3d renderer code into the bin, and start from square zero. This also includes my 2d renderer. I had to throw it out also. This does give me the opportunity to write my primitives as close to the bare metal and VRAM as it could possible get, but it also means I get to cheat my way through a couple of things. What are those things you might ask? Well, only the barycentric coordinate math needed to make a simple color gradient mix for colored triangles. And also textured triangles if that is what is used.

So lets go over some of our new opportunities now that we have bit the bullet and switched to OpenGL: better primitive rendering, native support for a depth buffer and depth buffer testing, the opportunity to use OpenGL's built in 3d renderer, or simply roll our own 3d renderer on top of OpenGL's 2d rendering abilities. But most importantly, our game's rendering will reach the honored title of sUPer uLtrA Fast. I like some things about OpenGL Over SFML, an OpenGL based API, in that OpenGL uses normalized coordinates for the screen buffer, meaning the center of the screen is labeled (0,0), and not (Width/2, Height/2).

Success?

Yes, success! We made a black window that can close itself if needed, why not call this a success. It's only a minor success, as we need to implement rendering to the screen to consider any form of success.

But what is our next milestone? To make a 3d environment where we can appreciate a 3d cube, preferrably a picture of Wawa on every face.

See you in the next update!

AAARGH!

It's been 2 days I'm developing a 3d rendering engine to use in-house for the game. I have built a majority of things, and for the most part understand almost everything and have - hopefully - made a basic collection of classes and subroutines that will in theory be able to create simple 3d scenes. I've handled the vector transformation of an object from one place, its rotation, its rotation to the camera, and its transformation from the camera. All quite useful things. Just one issue: I don't have a prebuilt depth buffer.

A depth buffer in 3d programming, is an allocated array with the exact same size as the screen. So if the screen, which is a reality in my case for now: is 800x600 in resolution, the array is 800*600 units long. It stores a number in each element, of the depth of the pixel drawn. What does this mean? See, in 3d programming, it's important to hide any surfaces in the back of a mesh from the camera, to create a sensible and realistic image. Otherwise, it will look quite as if the game is drunk, rendering what should be a hidden surface. Think of it like holding an otherwise opaque cube, and suddenly seeing its back face on top of it's front face. You'd feel like you're tripping balls.

What a 3d rendering engine must do is to hide any back faces. This is done through 2 methods, the first necessary, and the second for performance. This method is called a depth buffer. The idea is that for every pixel drawn from a projected 3d point in the world, its distance from the camera(i.e distance along the Z axis), is recorded on the depth buffer. Whenever a new pixel must be rendered on top, we must first check if the 3d point it was projected from is nearer to the camera than the original point. If it is, we render it. If it isn't, we don't render it.

Technically we did not render the pixel, but in performance terms: we did everything we were supposed to do for a pixel to be drawn, but we fell out on the actual DRAWING part of the pixel. So in performance terms: we wasted resources. So the second method is utilized: backface-culling. What does it do? It does not take place in the later part of the pipeline, but rather in the very beginning. It checks the normal vector(in regular people terms: the direction of the polygon) of every single polygon on a 3d mesh for if it faces the player. If it is less than 90 degrees adjacent to the player's direction of sight, it is kept, and if not, it is pruned off of the mesh, as its rendering is already quite useless.

But my problem, is that SFML, a library built for 2d games, does not have depth buffer support. This means one of two things: either I configure my rendering window for OpenGL, and link OpenGL into my project as a library and compiler flag, then write in depth tests for the 3d primitives header, or I make the very slow but easily done in house depth buffer, and begin rebuilding my primitives wrapper into a primitives library on top of SFML.

This of course whispers death into our project's optimization under certain circumstances. If I rebuild the primitives wrapper and rasterize triangles in-house via our drawPixel function, I will have solved my game's 3d rendering problem in theory, but in practicality, I will have also halved its performance. This is because we are rendering pixels not as pixels, but as 1x1 SFML rectangles, which will add a lot of unnecessary bloat to the instructions we send to the CPU.

There is an easy solution to this, and that is to use the OpenGL library to draw our pixel, which is of course much more optimized in OpenGL because we aren't using a hack, but actually rendering a single pixel, with only the considerations of writing a pixel to the screen buffer. This means it all leads back to OpenGL. SFML was just a hurdle in the process.

So my goal for now is to rebuild the primitives library to support my in-house depth buffer, and render pixels with OpenGL instead of SFML, and then rebuild the 3d primitives for that exact use case. Once we do that, then we can try emulating our first test render from the previous update, but FASTER. The biggest boulder of this is building my own rasterization algorithm for triangles, which is fine, until I have to configure textured rasterization, which is also a lot more work. Thankfully, the book I'm studying to build this 3d renderer has a chapter on basically writing all of this from scratch.

The first step!

So here it is, my first step into Wawacraft evolved. I already have a list of things that need to be built before we can get into the fun stuff where I build any gameplay-wise things. So what is it you may ask? Well, I need to roll my own primitives wrapper, and my own basic 3d rendering engine before we can get a 3d game working.

That's sure a lot of work for something most modern APIs like OpenGL and SDL give you! What exactly are you using to make Wawacraft? Good question. I'm using C++, and the SFML multimedia library. I have a lot of experience with it, and I think it will be a good start for the project. If I ever find some issues with SFML, my first idea is to just switch to SDL, as that is a bit more tied to OpenGL and is a more flexible library, whilst trading off simplicity or ease of learning. I know SFML isn't exactly the best library to make a 3d game in(It's a multimedia library for simple 2d games, of course it isn't), but I'm sure there isn't something we can't build on top of SFML to work out the quirks.

Now, the interesting part. What have we got? Well I got my build system working on my linux computer, and I also developed a small primitives library for making use of SFML's graphics capabilities. However, one small issue: SFML doesn't have any in-house solutions for just drawing ONE pixel. This is going to be needed later if we ever roll our own rasterizer, but the only good solution isn't really a good solution, its just sizing down a rectangle and drawing it as one pixel, which is not very quick for something that must be done 800*600 times and even more during our render process. Guess we'll have to rely on SFML's rasterizer.

But with that out of the way, I did build the simple primitives wrapper. It can handle colored pixels, colored lines, and most importantly: solid and textured triangles. Now just to build a 3d rendering engine! That's definitely not an extremely difficult task.