While on an assignment by assignment basis they each taught us a specific implementation, design, or engine process. I think there is a larger lens to look at the semester as a whole.

In previous semesters we've written engines where we were instructed on what to do, but for the most part not HOW. While the difficult part for me wasn't the exact implementation of a given feature, it was often times the design or coming up with the sensible decisions on WHERE to place things. By having an existing code base to work within, I had immediate examples for design centric decisions when it came to writing the various systems that we've done.
​
I also enjoyed the "directedness" of the assignments. Because of this, I was able to spend most of my time on the "HOW" to accomplish a goal. Not "WHERE" that has tripped me more than once in the past. I felt like the learning was that much more effective because I didn't spend too long spinning my wheels wondering on the best practices to go along doing something. Since I could just look elsewhere in a different system and see how it was implemented, and try my best to stick to an existing design. By imposing this arbitrary design consideration on myself, I also got experience on working, and sticking to an existing designs. Which, may be more useful if working on a large team.

Of course, the exact topics that we covered were at times completely new to me, so it was great to get my first experience with some of these systems and topics. Although, the best insights I got out of the course were directly related to Engine DESIGN and the thought processes / justifications for doing things a certain way.
I do want to comment on the fact that at the beginning of the semester I had thought the codebase was quite huge. But, at the end I believed that I had a decent grasp on the code base as a whole. I may not know every system intimately, but I had gotten to the point that I knew the DIRECTION to look in for specific things and questions.
 

I return with a new engine feature, basic user interface! User Interface programming and design has been a field that yours truly has had an interest for quite some time. Seeing that we developed very basic on screen sprites, I figured why not try my hand at creating some basic buttons?

My biggest experience with game interface programming has been done via Unity, therefore, many of my design decisions and criticisms of my implementation may compare and contrast directly with Unity's Canvas and UI system. One that I have gotten to know pretty well over the years. Before attacking this, I found it useful to map out the exact capabilities that we'd have to write:

Observations:

• Lack of any mouse control / integration in the User Input System
• Lack of a proper on screen image system
  • ​All we've had so far were 2D Sprites that we've created directly within the Graphics System
• ​Dealing with the fact that our images were in a screen space that uses bounds of [-1,1] for both the horizontal and vertical​

The Buttons are essentially a different type of Sprite but with the needed extra functionality to process click events. The position of the mouse click is passed into ProcessClick(). Which is polled each update, the reasoning for such will be explained later.

I mentioned before that the existing engine had no support for tracking the mouse whether it be it's state or direct position on screen. To get this done, we had to do some digging in the proper Windows API. This required some brushing up on WindowHandles, and putting these functionalities in an appropriate place. We have an existing UserInput system that until recently, was only detecting simple key presses. There, we can no poll if user has the mouse button clicked or not.

The real meat of the challenge was detecting whether or not the user clicked on a given button, in a sensible way. Currently, our process for listening for user input has been to check every frame for user input. Our engine was not event driven. Meaning, the engine wasn't listening for an input event to fire off. For moving our meshes and sprites in prior assignments, we just checked the state of the keyboard every frame. This isn't a bad way, but it is a way to do it, in fact Unity I believe does this. You'd do the following in your Update​ 

After we know how and where buttons clicked are performed, how do we figure out if they've been clicked on our button?! I mentioned above that I made note that we declare the position/size of our on screen sprites via bounds of [-1,1] on screen. This is similar to how Unity's canvas system allows the developer to position elements based on variable screen size. (Unity also allows you to specify the direct pixel offset as well).

Because Windows's calls that give us the mouse position give it to us in absolute pixels, we must convert our screen space bounds of [-1,1] to actual pixels within the window.

Above is the lines where we can compute exactly where is the center pivot of the image in relation to the actual size of the window. The window size is passed in at button creation for this to happen. We do the same to determine the left, right, top, and bottom bounds of the image.

These are then used in a ProcessClick() that will fire off the saved callback specified to fire off when a click is detected.

With the lack of proper mouse support. a true UI system, to get this system working most of it is shoehorned into graphics. Which, while it does work, I really don't like it. Because this is part of a new Interface system. I would have made a proper Interface system, just like Graphics, UserInput, etc. But with direct interface with Graphics. Since of course, they'll need to talk to one another.

This challenge was more of a personal exercise on understanding what needs to go into creating a sensible Interface system. The biggest hurdle was working with a code base that had no regard for the matter, and trying to fit my logic into sensible places that fought with my personal opinions on where things should go while working within a specific time frame.

Below you can find executables that allow you to mouse around and test out the menu for yourself. Unlike prior downloads of the game, movement of the camera, a mesh, transparency, all of that has been taken out. When you click a button, they are specified to log the event to the log file, which you can find in the executable's main directory.

Thanks to those at Hathos Interactive for allowing me to use some assets from their current project for this example!

NOTE: While the site is quite bare, the team will be releasing an update to their current project sometime this winter / early next year.

Recall back to when we first implemented three dimensional graphics in our game engine in week 9's post. One of the challenges we hypothesized was that of depth. As in, who is in front of whom? Well, we're fortunate that for those opaque meshes, the GPU is in charge of who is in front of what based on their world position and just overwrites that pixel with the pixel that is in the front. But what about transparent objects? 

Because an object is transparent, we must know what is behind it. This order is very important, and we'll keep in mind the logic of drawing from front to back. Or perhaps more simply, we must first "draw" the pixels that are behind the transparent objects before we draw the transparent objects with their effect. This is crucial as the opaque object's must be on screen in order for the alpha blending to occur properly within the transparent meshes.

Previously in both our application and rendering threads, we had a vector that held the Meshes that would be rendered on screen. But how do we impose order within these structures? We'll have to sort them based on their Z position. We could have approached this by adding the transparent meshes to the same structures that held the rest of the meshes, but for simplicity, we'll just go ahead and make a separate structure that is sorted that only holds transparent meshes. We'll just make sure that these are sorted correctly based on their position's Z value, and that they are the ones drawn last.

Specifically, we do the following:

• Calculate the Z position of the objects, in camera space
  • This is so we know where the objects are in relation to the camera to draw them in the appropriate order
• Draw our opaque meshes first
  • The GPU will handle who goes in front of what then.
• Sort our submitted transparent meshes based on their position in the world
  
• Draw our transparent meshes in this sorted order.

In the screenshots above you can see two cube meshes that use our transparent fragment shader, placed in front of one another to be able to see their transparencies with an opaque mesh in the background.

[W : Move Forwards]
[A : Move to the Left]
[S : Move to the Right]
[D: Move Backwards]
[Space: Move UP]
[Left / Right Ctrl: Move DOWN]

​[Arrow UP : Move Forwards]
[Arrow LEFT: Move to the Left]
[Arrow RIGHT : Move to the Right]
[Arrow DOWN: Move Backwards]
[Page UP: Move UP]
[Page DOWN: Move DOWN]

Prior to this week, in order to build our game assets using the appropriate build tools, this required the use of a lengthy .lua file that contained instructions on how, and when, to build each and every game asset. This file stretched to almost 500 lines of code! It was a direct offender of programming paradigm of being DRY or Don’t Repeat Yourself. It contained dozens of repeated routines that did similar tasks. These tasks included determining if a directory should be created to house our final compiled assets, and error reporting when appropriate.
To mitigate this, we now have our new Asset Build System! The only difference between our game assets are their names / paths and file type. We can contain this data in a more central location, formatted nicely within another .lua file, as shown below:

We contain our meshes into our “meshes” group, shaders into “shaders”, and so on. We can then pass these arguments to functions that determine what type they are, and can feed them to the appropriate executable. In the end, we now have a more versatile asset building system with minimal repeat routines. Also, it can be easily extended to include assets of different types that may be useful in the future if the engine is ever expanded upon.
Another thing to mention, is that the above .lua file containing assets relevant to the game is now contained directly within the game’s source directory. No longer having to be included as a real part of the game engine. This is a forward step in making the clear distinction between game and engine code.

[W : Move Forwards]
[A : Move to the Left]
[S : Move to the Right]
[D: Move Backwards]
[Space: Move UP]
[Left / Right Ctrl: Move DOWN]

​[Arrow UP : Move Forwards]
[Arrow LEFT: Move to the Left]
[Arrow RIGHT : Move to the Right]
[Arrow DOWN: Move Backwards]
[Page UP: Move UP]
[Page DOWN: Move DOWN]

Required References for the Project:

• None!

The MayaMeshExporter is a standalone tool that refers to the Maya libraries set independently on the user's machine! Everything works as intended, as long as the following Windows Environment Variables are properly defined:

• MAYA_LOCATION
  
  • ​The actual install location of Autodesk Maya
    
• MAYA_PLUG_IN_PATH
  
  • ​A reference to the USER SPECIFIC plug in folder for Autodesk Maya.
    

Other Project Dependencies:

• None!

Remember, the MayaMeshExporter is a standalone tool! It's just needed to create the actual .mll file used to export a mesh from Maya into our game engine. You build this project to create this .mll of which you then load within Autodesk Maya.
​

Refer to the previous post concerning the output format of our mesh files. Of course, we must output the data to satisfy the structures defined within the file. This time however, we added texture support. The file, now a .MSH, needed UVs to complete the task. I specifically only output the minimum required data for this file.

Why only the minimum? It's less code maintenance, simplicity, and I don't foresee a much more complex use case for this Exporter for the time being. If in the case that's the opposite, I have no problem coming back and adding more funcitonality, failsafes, and considerations for expandability.

While writing the final format of the data to be exported from Maya, I found it useful to be able to see at every step of the way the actual data being written. In fact, Visual Studio is able to attach to Maya and then when the Exporter/Executable is ran upon scene export, you can debug and step through the process just like anything else! Below, you can see the beginning call to exporting a mesh file via a breakpoint set at the beginning of the process in Visual Studio.

[W : Move Forwards]
[A : Move to the Left]
[S : Move to the Right]
[D: Move Backwards]
[Space: Move UP]
[Left / Right Ctrl: Move DOWN]

[Arrow UP : Move Forwards]
[Arrow LEFT: Move to the Left]
[Arrow RIGHT : Move to the Right]
[Arrow DOWN: Move Backwards]
[Page UP: Move UP]
[Page DOWN: Move DOWN]