SLEPR in Vector

For this week, my goal is to finish all the functions by using c++ code. Most functions are not so complex, but when I tried to write the SLERP function in vector part, I had a problem. SLERP stand for spherical linear interpolation. The purpose of the function is to let the position move smoothly between two points. Usually, this would use on the camera position.

The problem was that when I tried to write this function with two points, there will be no way to know how the route is. In quaternion part, it also has SLERP function. However, it doesn’t have this problem because the quaternions which will use in this function are normalized quaternions, and the route will refer the angle between two quaternions and the origin. Thus, I need to find the other way to write SLERP in vector part.

After researching, I find the thing called spline. It has the similar purpose with SLERP, but it will refer 4 points to decide the route, and the closest spline with our demand is Catmull-Rom spline. It refers 4 points and 1 coefficient to draw the curve. The curve will be drawn between the second and third point, and the first and fourth point is the control points. The coefficient will between 0 and 1 as the ratio.

The chaos before the storm

Continuing my adventures on the treacherous CMake lands, progress was real, the end of the road was in view, but the dark forces never rest, and now Irma was on the way... which was worse than it sounds.

The toolchain I previously found proved to be useful after various tweaks; it was last updated for CMake versions close to 2.8, which is about 10 versions old, but works nonetheless. I have managed to obtain a iOS build system created but I still have some issues to fix, there seems to be some linker issues, but hopefully it's not something too complicated... hope has not been an ally in this journey though. The process involved generating an iOSSetup shell script to attach the toolchain to CMake and setting up some variables to let know CMake where to look. Other CMake specifics have been isolated.

Then Irma came (or at least was "said to come this way.") The forces of evil that I have been fending off were not happy with my progress, they were angry. This halted my work as I prepared for the storm and helped out friends and family to prepare. At this point I still did not believe it was going to come this way or that a category 1ish would not do much harm, i was a fool. I was stopped in my tracks for 3 days straight after the full might of the evil horde (of wind gusts) that left me in darkness and hampered my ability to move, I was stranded in with no power, transport and with a bunch of yummy treats and water (but no soda.) After the storm passed I had to continue my work on my side hustle (aka PCP online class) in which my fellowship had disbanded (apparently they don't care for a few points of teamwork) I understand tho... they were making us do weird stuff.

Now it is time to fully charge into the end of the road, and see what lies there.

Revenge of the iOS deployment

After the unix wars, there was supposed to be calm times, little did I know that Irma had plans for me, especially before it arrived. The iOS conundrum was not over, it was only beginning, as confusion led to worse problems, the purpose was to release to the App Store... the war never ended. I started research on the project and did some progress, until I reached a dead stop; this required a new layer of complexity that I had not dealt before; certain legal requirements that brought me to a dead stop. The battle was lost. I did do some testing on the app that surfaced some important bugs like menu problems with actions and responses, text misspellings, and other functional issues. Bugs were reported, hopefully someone will look at them before its too late.

After this I continued my work with the iOS CMake build system. I found some supporting works that were already on the works that might prove useful. These were based on a deprecated and abandoned project that aimed to give CMake full functionality on iOS, but was abandoned long ago. Luckily someone continued this work, although it still seems to be old enough to be useless. Time will tell.

Unit Test and Modification

After Listing all interfaces, I need to connect my library with CMake so CMake can compile my library. Thus, I need to add my library name in the CMakeList file. The other thing which I did in last week was to create the unit test file. So far, my functions are not doing anything. They just turn false because I should check that project can run my unit test, and the most effective way is to let all test functions only return false.

This part did not take me so long to finish it, but there were some things that Lari wanted me to modify and add to my library. Lari wanted me to add some constants and Macro code in my library. Those things will make me easier to write my code and make my code look more organized. Lari also wanted me to modify my vector, matrix and quaternion struct. Using union in my struct could let the structs more flexible. The struct will not only have one form. Users could specifically edit the data of the struct.

Listing Interfaces

This is the second month of the final project. For this month, my goal is to finish the UnitTest of math library. However, the code will be temporarily written in c++, and the next month I will start to change the c++ codes into the low-level language, such as Assembly or SIMD, for improving the speed.

The first week, I was working on listing all my interfaces. In math library, I separated it into three parts which are vector, matrix and quaternion. Most functions are the basic calculations. The complex functions will leave to the physics and collision library. When I listed all interfaces, I also needed to comment those interface to explain the functions to users. Thus, that cost most time when I did this work.

When I listed all interfaces, I also found some functions which I listed last month for research paper were needed to modify. For example, the addition and subtraction function could be concentrated to one function. Also, there are some functions which I missed last month, such as LERP and SLERP functions for vector and quaternion. 

The Unix Wars

During my adventures in the lands of CMake, I was finding my way into an iOS deployment of CMake, but soon the path became a fork, and confusion arised. I was pulled momentarily to work on an iOS deployment for the MedicalVR team, which involved the deployment of an app to a mobile iOS device. This took me way longer than I should have, due to an error of my part on understanding the difference between a .xcworkspace and an .xcodeproj. Luckily someone already went through this on their team and got me out of that bottomless pit. The app was deployed with no errors or tweaks necessary, although I do have to say, I was actually making progress in solving the most simple problem in the most complex of ways... if that means anything.

There was also the linux conundrum; issues were popping up with Linux when it came to libraries that used pthread and X11, these were the result of CMake not knowing it had to search for these libraries nor did it know that they were "REQUIRED." After some good man hours, the problem was resolved.

Currently I'm making progress in CMake once again, an actual build of iOS is being generated, although tweaks to the actual code will be necessary on all fronts. Hopefully sooner rather than later, we will have a CMake build fully working for iOS.

The Return of CMake

During my arduous time learning to fend off the demons that dwelled in the (then current) CMake implementation, I ended up learning more about deep Wolfram code, losing my grasp of the true enemy at hand: Implementing a CMake build system for iOS. I did manage to finally vanquish the demon that wasn't allowing CMake to generate the build system; the implementation called for a function named "Find_Library" that dug out some unnecessary pathing that was already being set by previous libraries that were already linked to the framework in question (Cocoa.) Not only that, but some "curly" or "side" quotes that CMake hates were adding to the issue as black box bugs through the dynamic libraries being linked to the Cocoa Framework. The demon was exorcised.

Initially I didn't have a clear understanding of what CMake was actually doing (not to my knowledge at the time at least,) but thanks to some guidance, I realized the error of my ways. I thought Gerard's build system for MacOS would be sufficient to bring these libraries to the iOS platform, but soon I realized that this was no amd64 or i386... it was Darwin's ARM.

In my search for a solution to this new problem, I got tired of building the MacOS build system by manually calling the shell script that did the work by getting to the directory path and executing through Terminal, so after some hours of research and development, I managed to get a shell script working that only requires an initial permission grant, and then compiles with a double-click, the unaware future warriors that dare explore the lands of CMake will thank me in the future, if they knew what I did, that is.

Now I keep wandering these lands, in search for the holy grail (by that i mean an ARM build system toolchain working properly, "holy grail" sounds better now, doesnt it?) but at least this time, I know where to look, kind of.

The new era of CMake

After the new implementation of CMake, it has come to be of great importance to learn the process of deploying and maintaining the new environment. After adapting GLog to the test environment I saw no reason to generate the porting tests if in the end there would need to be a subsequent test within the Gateware library.

In the meanwhile, I've also had no luck with the Gateware Xcode project. During the last days of Gerard and Nic, they managed to fix some of these issues for me. These fixes were temporary though, as a branch change was enough to bring me back to the starting point. These issues seem to be related to different macs being used. As far as this goes, Gateware just doesn't seem to want to build properly on my mac.

Currently I'll be continuing my research on CMake for the purposes of iOS porting, maybe this will help me pinpoint the root of these issues or shed some light to what is causing these errors, especially if its specific to my Mac.

Window Event Loop Processing

Month Four : Week One

This week I encountered an issue that my teammate Andre brought to me while he was trying to integrate GWindow into his first month code demo. His demo is a simple OpenGL rendering application,and this week he was working on the Win32 version of it. His window was being created just fine and OpenGL was successfully initializing on my GWindow window, however the window was accepting no user input. The cursor was stuck spooling, no window buttons could be pressed, and the keyboard input the window was supposed to be catching wasn't working at all. This was distressing because it worked fine in the test suite, and I couldn't figure out why the window wasn't handling its event loop.


Eventually I remembered the issue I had working with Linux and Mac OSX's event loop, and how I had to manually process all messages in the loop after important operations to flush the event queue and continue the program. I decided to add a new function to the GWindow interface, ProcessWindowEvents. This cross-platform function will read in and handle all queued messages in any platform's event loop and then break and continue. The user will call this function once per "frame" of their program, probably along with the main game loop. The demo app is working just fine now and my library is better because of solving this issue.

OpenGL Initialization on Linux

Month Four : Week Two

By this week Andre and I had decided to work a little more closely together and essentially make his month one code demo and my demo App the same thing. Once Andre got OpenGL initializing and some a multicolored background rendering on screen, he handed it off to me to get the libraries working in it. I soon discovered the method of initialization on Linux is much different that Win32. On Win32, it is possible to create and show a window without and rendering setup, and then initialize OpenGL or DirectX with the already created window. This is impossible with the X11 window system that Linux uses; X11 is old and somewhat less user friendly that Win32, and it just so happens that in X11 it is impossible to edit the Visual of an already created window. The Visual in X11 is an object that holds properties pertaining to the rendering of the window. The real issue with this was that my GWindow was not using any OpenGL libraries or includes during its X11 initialization, so all the work I did trying to link OpenGL to my GWindow was for nothing. By this point I had wasted a decent amount of time and wasn't sure where to go. Fixing this would mean fundamentally changing my GWindow OpenWindow function to allow OpenGl window creation during a month where my GWindow is supposed to be final.


In the end with some guidance from my mentor Lari we decided that it was fine for the demo App to not use my GWindow at this time for the purposes of the postmortem. That task has been pushed off to further down the line after the presentation goes well, and it could possibly even be the basis of a new class. A GWindow3D that derives from GWindow and specializes in OpenGl, DirectX or even Vulkan window creation and rendering could be a worthy project in the future. For now, I've decided to keep the GWindow code commented out in the demo and just implement GInput, GLog, and GFile. I know how the GWindow3D class would work, and even if I don't get to implement it I may be of some help when someone tries it in the future, even if I have since graduated.

Wasting Time Trying to Be Fancy

Month Four : Week Two

This week I got myself stuck in a hole trying to use the backbone of the already created Gateware Demo Application to create my new Demo app, phasing out SDL_2 and replacing it with GWindow. I wanted to use as much of the old code as I could because it had an animating sprite, used great separation of concerns and displayed smart use of OOP principles which would give an end-user a great example for the kind of game that could benefit from our libraries. Unfortunately, the more code I copied over and used, the more I began to realize it may not work. The whole architecture of the program was so dependent on SDL that my stripped down GWindow library couldn't be sufficiently worked into the flow of the program without a serious amount of changes. This meant I would have little time to start something new AND learn some OpenGL to render some test shape myself.

At this point I had wasted too much time on the App, and needed to get something working ASAP.  Luckily, my teammate Andre was working on making his first month code deliverable by rendering a shape on screen in OpenGL. I decided to work with him and use the rendering functionality of his much simpler demo app and then integrate the Gateware libraries into it. I realized it was more important for the end-user to see how the libraries work in the demo App than worry about animations and sprites and time like the older demo App did. In the end the App came out better and more cross-platform ready that the old App would have been, and was completed in half the time.

CMake, iOS and porting.

Continuing my travels, I had to scout out the mysterious evil called CMake and even though I found out the monster not to be such a fearsome beast, from afar, I am still being warned of its dangers; the way it works and requirements of the language it uses don't seem to be too foreign to my knowledge, although there seems to be more than meets my eyes when it comes to deeper understanding and workings of the compilation/build process.

On the iOS front, however, things have become simpler as research cleared the way. I ran into some issues with obtaining the proper path to the app directories but with some help I jumped that fence pretty quickly. After understanding the file system, there weren't too many problems when it came to testing and porting GFile methods in the separate test environment, only some small required changes for directory initialization and string handling together with a handful of preprocessor if statements and includes.

Now it's time for the trial by fire. Adding Unit tests to the library. I don't have much knowledge of how these test work but it shouldn't be too difficult, and deeper knowledge of the Gateware library itself is due. Onwards, to glory!... or at least the succesful test of GFile in iOS.

OpenGL is pretty cool!

It's been a while since my last post, but I've spent most of my time doing some research on OpenGL and how to get it working. I was pretty nervous about how I was going to get it set up at first since I've never had to work with it before, but it turns out that it really isn't that bad.

One of the major problems I had trying to get it initialized was just figuring out how to properly include and link the required libraries. Honestly I'm glad that that was my main problem, because once I got that solved, setting up the actual code was a breeze. I was also very surprised to see what little code it takes to actually set up the OpenGL system compared to DirectX. I have a feeling that I'm going to be using OpenGL instead for quite some time.

As a status update, I've already tackled OpenGL on Windows and Linux and am currently working with Mac. My goal is to finalize at least the Windows & Linux versions so I can spend more time with Mac, because so far it has proven to be the most challenging.

Stay tuned!

Vacation away from cmake, putting problems on hold

This weekend, I will be in Atlanta for DreamHack. During this time, I will be enjoying myself and forgetting the problems that wait for me to get back. This week, I've solved two major problems and now only have restructure and build processes left. The first problem was that the problem couldn't figure out what certain binary headers were being used. I had to link the cocoa framework to each library in order for each to run properly. This was done by going to the build settings for each product and adding link binaries to libraries (if this action is unavailable, there is a plus sign on the upper left part of the display below the build settings selection which would give you the option to add the option). The second is that CMake is not capable of adding frameworks to this option and that's what i've given up on as my research on this topic has lead me to believe that it's simply not possible. I'm linking this website for reference to the main point of this argument. (https://cmake.org/Bug/view.php?id=14185) 

I don't think there is anymore I can do besides adding them manually so right now I will be pushing this up to the git and finish up on the structure that CMake builds this project. Afterwards, I will be done with CMake and move on to completing documentation on usage and layout of the CMake system that has been incorporated into the project. We'll see if the lead wants anything else or to devise a way to develop a way to add the option to the link libraries. I'm still looking for different ways to get around that second problem but I don't have any hope.

Figuring out iOS' file system.

In my efforts to work on porting the GFile library to iOS, it has proven challenging for me to get a grip on apple's obfuscated file system for iOS. Although there are many ways to handle file I/O, there seems to be very few that allow raw access to directories and reading/writing to these, not to mention apple's security protocols that do not like random access to these locations. Some of apple requirements have made me wonder if maybe I would end up rewriting these libraries instead. Time will tell.

During these travels, I have stumbled upon many great ways to manage files for all my future needs on this environment, none that would make my life easier though, at least not in the near future. On the bright side, Apple has proven to be a merciful and understanding software god when it comes to documentation, so hope is not lost.

Also ran into some issues with the gateware libraries themselves, which led me to generate a separate test environment while I figure it out. Not a huge setback for now, but I know that sooner rather than later I will have to wrestle my way in there... 

In the meanwhile, time to learn about CMake... yay...

Apple, CMake and a Flamethrower.

To start off, I would like to say that I had a week hiatus for development due to July 4th so coming back in had a slow start up. With that said though, Mac is truly the neediest of all the three platforms by far as I have discovered this week. Currently, we have generated a XCode project using CMake and the source files we've been using this entire time. On failed build 1, XCode was giving an error about the variable atomic being undefined which sounds ridiculous. Atomic, for those who don't know, is a variable in C/C++ systems which describes a certain variable as multi-thread safe as it could be locked and unlocked using mutexes. Atomic is a base system type name, all you need to do is be using a C/C++ environment and include the System's Atomic library. In the project, we were including atomic on the top but it was still not being recognized. Took me a day to figure out that CMake had to set the flag "-std=cxx0". With that set, atomic was being recognized but we had a second problem which was user-defined variables in the header were not being recognized in the cpp. The truly worse thing was that it didn't make any sense that it didn't recognize it when EVERY OTHER PLATFORM WORKED PERFECTLY FINE THIS WAY. After my rant, I checked to find out why it was doing this and noticed that the .mm files (which are files specific for Apple and XCode) was including the cpp within them. As a way to avoid circular inclusion, we took out the cpp and the build was successful. HOWEVER, the errors were still there and the cpp still could not recognize certain variables. I don't know why but after including the header file did the variables suddenly become known. So, we are now including the header file in an #if(_APPLE__) statement. A little more work has to be done but we're almost finished. All that is left is simply finishing the linking of all the libraries, testing the test suite, creating a script for command line building, and creating documentation. That's it. It's the end. I'll be posting a final post on my feeling and thoughts about CMake a week after being finished.

Gateware Graphics: DirectX Research/Refresher

This first month is all about research, so I decided to start by getting DirectX out of the way first, since I am already pretty confident with my skills in that API. Since I have been working with DirectX for about 4 months now, I spent most of this time trying to simplify the process of initializing a basic graphics setup.

With that regard, the main challenge I faced was trying to figure out how to make my setup work with the existing GWindow class, seeing as it can get pretty complicated since it's already optimized for multi-platform. However, I soon realized that I literally only need to utilize 3 function calls from GWindow (in order to complete the initialization, event handling is another story). Currently I am still exploring GWindow to see exactly how the event handling is dealt with, and how I can incorporate similar techniques with my setup. I plan to have all of this sorted out before the end of this week, so I can begin my journey through OpenGL.

Stay tuned.

Mac Development : 2

Month Three : Week Four


        This week I encountered a big issue with the Mac of development that really brought development to a standstill. The issue is that in order to kick off the event loop for an application on Mac, you must call [NSApp run]. This function will begin to take in and process message coming into the window. However, the big kicked is that on Mac this is a blocking function, whereas on Windows and Mac the window can be created and its events handled on a separate thread without blocking. This meant that my OpenWindow function on Mac never returns because it calls [NSApp run] at the end to open the window and start the loop. Initially I figured I could just launch the window on a secondary thread, but the I got hit with the realization that any Cocoa function MUST be called on the main thread of the application no matter what. This is a big problem because the entire test suite resides on a secondary thread to begin with.


       The answer for this one was first to figure out what [NSApp run] really does. By looking directly at its source code I was able to discover it was simply getting the next message from the NSApp and sending to off and then updating the window. So, I created my own [NSApp run] equivalent that does the exact same this but breaks when the event queue is empty so the thread can continue running. However, this didn't fix the issue completely because getting the next event is a Cocoa function which must be ran on the main thread. Through a lot of research on this issue I finally found to separate ways to send a whole block of code to the main thread from any other thread. By using this method of code dispatching and my custom run function I was able to sufficiently mimic the functionality of the Windows and Linux side GWindow.

Mac Development

Month Three : Week Three


        These next two weeks are dedicated to developing the Mac implementation for GWindow. I was two days behind at the beginning of this week because of the issues I encountered with Linux and the bug we all fixed as a group. The main issue I ran into for Mac this week was the fact that the message Loop for Mac is handled very differently from Windows and Linux and  I was very unfamiliar with the Objective-C language I would need to use to complete the Mac side of GWindow.


       First I looked at the Mac side of the libraries that the other Gateware members had already made. Through this and some Cocoa documentation I figured out that the WndProc functions I created for the Windows and Linux side of the message loops for GWindow are handled by a custom object called a Responder or a Delegate in Mac. Essentially a delegate is like a listener that you attach to an object you'd like to receive events from (like a window). The delegate is then filled with overridden event catching functions like windowDidResize windowDidMove. Inside these functions is where I fill out my custom GWindow events and pass them along to my GWindow's listeners.

       However, just writing the delegate wasn't enough. Now I had to figure out how to connect them to my window which is being handled in a different file and even a different language. It turns out .mm and .cpp can be included directly into each other, and my GWindowDelegate was declared in the .mm with the class declaration and then assigned to my window with [window setDelegate:GWDelegate]. In the end, it took a a lot of official Cocoa documentation reading and testing things out in a separate testApp to get things to work correctly.

Linux Development : 2

Month Three : Week Two


        This week the main issue I ran into was dealing with the X11 window event system. The event loop is running on its own thread so it is hard to tell when a window call is going to be processed and have the changes made be visible to the user. This meant that an X11 function may be called successfully, but the Test-Suite would keep moving on to the next test before the function was completed, making the test-suite get off track and start failing.

        Like most operating systems, when an X11 event is sent  it enters a queue that processes messages one by one until the queue is empty. For the purposes of my library, I need the results of the functions I call to be in effect before the program continues on. Because this was not occurring I was experiencing very frustrating bugs that were not immediately obvious. For instance, when minimizing or moving a window or messing with its borders, the window would not react for several seconds but the function would return true because the action was successful, it just wasn't visible yet.

       By looking through some example code of other window handlers it became apparent that most X11 calls could be followed by XFlush() which will flush and process every message in the queue. By adding an XFlush() and sleep(1) after every X11 call that edits a window I was able to make sure that the functions were completing and actually changing the window before my program is allowed to move on, which resulted in successful tests.

Linux Development

Month Three : Week One

        This month is all about Linux and Mac development. The first week I decided to start with Linux because I am most familiar with it and was fairly confident I could deliver on time. The major issue I encountered was just the fact that X11 is rarely used by itself by an end-user, and because of this there is not a lot of useful documentation or example projects that display correct usage of many common window functions that I need to implement. Most posts tell me to not use raw X11 and to just use a toolkit, which does not help me at all because I am essentially trying to be the toolkit.

        The manner in which this issue manifested itself most often was when messing with the fullscreen functionality of the X11 window.  X11 has no easy to use fullscreen toggle or even a good way to check if the window is currently fullscreen. The most frustrating and time consuming way this would inhibit me is when I would manage to get the window fullscreen, nothing short of a user pressing the maximize button could get it out of fullscreen mode. Resizing, unmapping, taking the border off, nothing worked. Which essential meant if the window ever became fullscreen it would be impossible to restore it to its normal size through code. It took lots of trial and error to eventually discover that it is much easier to create a custom ClientMessage and fill that message with the information to set the window to fullscreen or out of fullscreen instead of trying to manually resize it. There is a massive list of properties that denote every attribute of an X11 window, and it is possible to peek and edit these properties by grabbing their ID's using Atoms and then putting them into a set or delete message and sending that off to the window with XSendEvent. Eventually I discovered that fullscreen mode on an X11 window is denoted by two properties being set on the window,  _NET_WM_STATE_MAXIMIZED_HORZ and _NET_WM_STATE_MAXIMIZED_VERT.

By grabbing these two properties and sending a property delete message to the window, I was able to get the window to exit fullscreen mode set itself to its proper internal size. Once I was able to get the window out of fullscreen it was trivial to do move and resize it.

Month #1 of Gateware research for mobile; Android Research

The great little green android man... little did I know that to work with this guy I had to assemble it first. Thanks to google and its Android Studio, at least it came with a manual.

Android is definitely not as user friendly as its competitor, especially since it's on its own world, and in this world, the language spoken is Java. Apparently google noticed this poor patched up robot dude and reworked him enough that now they have one of the best developer resources library I have ever seen.

After I got hold of these resources it was very easy to get a grasp of deployment in their environment, giving me a warm feel that if any questions arise (or android parts fall off) I'll have their resources waiting for me.

Month #1 of Gateware research for mobile; iOS Research

I joined the gateware team with the task of porting as many existing libraries as possible into iOS and Android, starting with iOS.

I've never gone too far into apple's development environment until now, and to be honest, I was very surprised to find a very organized and resourceful environment. It definitely had that apple feel of giving you as much as they can to help you, but this time, without abstracting the deeper layers of complexity that come with software, at least, not as much as they would like to. 

I also had to dive pretty deep into the world of Objective-C, and was amazed. Once you get used to it, it's easy to see the reasoning behind their choices of syntax and functionality. I was also surprised at how simple it is to combine it with C++, although thinking in low-levels, it shouldn't be that complicated given that they both are, in their raw form, C.

All in all, I have found new respect for apple after going through this experience, and am sure I will appreciate them even more in the near future.

Learning the Inner Workings of Audio Part 1: RESEARCH

For the past 48 hours, my life have been succumbed to study. I have been tasked with making a multi-platform Audio Engine for games, or simply a Audio Library whose focus will be for playing, loading, and editing sounds/music for games. To do this I will be using existing first party libraries to do the heavy lifting while the library I create will be able to reference those existing libraries when needed.

But enough about that, onto what I learned.

Generally, gaming audio files run on their own threads at run-time and usually sounds needed for a level are pre-loaded into memory prior to actually playing the file and unloaded when it is no longer needed. Have you ever noticed your game freezes but the background audio is still playing fine, this is the reason why.  One of the most commonly used file formats used in games is the .wav file due to its heavily documented and easy to read/write file format. This knowledge is needed since some api's such as XAudio2 doesn't actually handle loading the data itself but rather once the data is loaded, it accesses the necessary hardware to play that sound. This is not universally accepted as CoCos2d, another api designed specifically with games in mind, handles all the loading and playing of files itself.

Another common thing I found among different api's was the use of  Instancing and Asynchronous Callbacks. For sounds that may stay for the length of the game such as background music, an instance of sound kind of audio device is create which manages the audio specifically for the background music. A separate instance of an audio or several instances of an object might be used just to handle specific sound effects.  This way the BGM and sound effects can vary in volume and other things as the player wishes.  Callbacks are used mostly with streaming the audio so that huge music files aren't loaded into memory all at once and they are asynchronous as to not block the rest of the gameplay while its waiting for some feedback to play a sound

Well that's all for today, next time I'll be delving more into XAudio2 and how one loads and plays a sound with it. Until then, you can read up more on XAudio2 on MSDN.

In the meantime, You've activated my trap card! Goodbye!

Linux, Cmake and I

So, through the efforts of Google and Stackoverflow, we have found a majority of answers to my CMake wall. The days are growing closer to the end of the Linux Project. I have already created the main project of Linux with CMake using Unix Makefiles. That was the easy part, the hard part was getting definitions to stick in the Codeblocks project for use such as -lpthread. Passing in the right one with the right call was actually tricky because it was a case of rinse and repeat on which one it belonged to such as linker or compiler flags. Then, I also had to add compiler flags to represent the libraries in c++11. I hit a wall on Thursday on how to make two separate projects targeting different architectures such as amd64 and i386. After I left work, I have an epiphany because I only think about work after I leave work. My thought on how to do this is to first create two folders in the Linux folder. After going into a folder, CMake would then check the folder it's in and build the project according to the folder. We will see how this works on Monday. Other than that, Linux will be done and I will be starting on Mac. Let's hope for the best.

Linux may just kill me.

Last week, I finished the Windows Toolchain for CMake and put it into the project. This week, however, a series of unfortunate events have kept me from finishing the Linux Toolchain. Monday, I wrapped up output directories for the Windows Toolchain. Tuesday, I had to restart a new Linux Virtual Machine because my old one got corrupted and I lost the project on it. On that same day, a team using our project came up to me and said that the input manager library of ours was not working correctly. After I brought this up to the rest of the team, the bug was reported and appointed to be fixed on wednesday which is what I did all day for Wednesday. Thursday was really my only work day as I established the Linux Project and started working on the Linux side of the toolchain. Friday, I had meetings all day long which took up a majority of my time. All in all, the work I have done for the Linux side of the toolchain just comprises of CMakeLists in each folder, Compiler directories, and output paths for the source files. At the moment, it is giving me an error on locating a file in the source folder which is there.

CMake, Windows and a whole bunch of Text files.

This week, I've been working on porting all the scripts and files from the test project into the actual project. The walls we've run into are, believe or not, just linking errors and property settings. These things are easy to change but hard to notice prior to the error. Now, the biggest wall/hurdle that had to be overcome was the inability for a single project created with CMake to target multiple platform types on visual studios such as x86 and x64 platform. The solution we used to make this work is simply the generation of two different projects at build time. One would be an amd64 project and the other will be an i386 project. As of right now, from all the research and forums I've read, there is no way that a CMake project could have both them either now or in the near future. With this knowledge, I will continue to use this method for the other two platforms which are Linux and Mac but the problem remains as if this method would work on either platform. This upcoming week, we shall take up the Mac platform so expect my blog next weekend to be an overlook on that progress. As of right now, CMake is currently producing a working project for Windows where both x86 and x64 Visual Studio projects are being created with their outputs of libraries are directed.

Integration and Testing CMake

The starting of moving CMake files and toolchains into the actual project proves to be as difficult as I knew it would. I think I might have to create two different CMake projects in the same directory. One directory would be for the creation of the libraries and the second project would be for the creation of the unit tests project. The unit test project will prove to be the most difficult to set up since it has a dependency on the first project being built so I might have CMake require the library directory to be full. On the other hand, setting up the first project is also proving to be a problem as the cache that is created is not able to find the compilers for visual studio which is really annoying. I've been digging through youtube videos and google to find my Holy Grail for a toolchain that has an output to dlls. Just like the Monty Python version of King Arthur, I found nothing but a french fortress which is an error on compile time. I think it might be just the compiler settings not be correct or the inability for the path to reach the compiler in visual studio. My goal for the following week is to fix the bug and hopefully finish the Windows build as I still have two other target platforms to code.

CMake, Mobiles and Command lines.

So, this week has been a compilation of all things CMake as my objective for the new month starting Monday is to get a working build for the project. All in all, I can say that I'm much closer to a CMake Toolchain that can target Apple, Linux, Windows, Android, and iOS with minor tweaks. As I said in my last post, Android is a huge beast that is hard to conquer since it needs the Android SDK and C/C++ NDK in order to work with our project. Now, I've decided to use Android Studio as the target IDE for it has Make files built in and already CMake/Gradle already installed. The only project is that Android Studio has the huge hurdle of not being a Generator for CMake. What I've decided to do is generate the files as make files and then, using the internal CMake files and Gradle system that Android Studio has, build the project using those through Studio. Now, the only way to do so newer programmers and novice to the CMake system can be able to get a working project without completely ruining anything or spending  12 hours on it is to create scripts and batch files so that the entire process can be handled in the console/terminal of the current platform. Though, I haven't tested this out yet because I had to put this part of the project on hiatus since the ever-approaching deadline. My attention is focused elsewhere, an actual working toolchain that can be used on a static folder that will build on any three of the main target platforms which are the Windows, Mac, and Linux. In this retrospect, I've made tremendous progress. I've officially created a batch file that can take a  source folder and build a visual 15 project without needing a target. All a person needs to do is simply run the batch and it will run CMake without any more input. I've created a script for Mac which is currently not working due to CMake being unable to find the C compiler even though I am telling it the location of the compiler. My work on the Linux machine has been lost since my Virtual Machine crashed on me and the snapshot of my work is corrupted. I need to rebuild the system all over again. Summarizing all of this, this past week has been both nerve-wracking and enlightening. I come ever so closer to accomplishing my task but yet feel so far away from it. Next week we start working on actually putting work into the live project server. I will post about this again next week on my progress.

Integrating GWindow Tests

Month Two : Week Three

        This week was a week of frustrations mostly because I was working on something that was slowing me down and keeping me from starting windows development. After the completion of my unit tests last week I was tasked with getting those tests running in the CodeBlocks and XCode environments. This is when I realized that my task for week one of integrating the unit tests into the main repo was not only for Windows, but for the other two platforms as well. I had intended to integrate the unit tests for Mac and Linux while I developed the implementation for them, therefore only the Visual Studios solution was integrated at this time. However, the issue was that to get my GWindowTests testing, I now needed the unit tests for XCode and CodeBlocks to be integrated as well. Because I h ad not allocated time for these tasks, I knew they were going to get me behind.

        The issue within the aforementioned issue is that I was still somewhat unfamiliar with the CodeBlocks and XCode IDE's and trying to import a project from one workspace to another without Linker errors requires in depth knowledge of the IDE's project settings. This meant that integration would not be a quick process and would require a fair amount of research and testing. Even integrating the unit tests in my most familiar IDE, Visual Studios, took more time than I had initially allotted for it. This worried me because initially I thought I was ahead of schedule and ready to start windows development, when really I was essentially still working on my first task for the month.

        For this problem, the only solution was time. I started with Linux and spent a lot of time inside the CodeBlocks IDE exploring and researching how the project was set up for the initial stand-alone test suite. After getting myself acquainted with the project settings, I looked for a way to port the project straight into the existing Gateware workspace. Unfortunately, for whatever reason, CodeBlocks has no built-in way to import one project into another which meant that I had to create a new blank project and then add and edit the files individually. This was very time consuming because of the sheer amount of options that had to be set. Many times I was sure I was done only to find another change somewhere I had overlooked in the stand-alone that I had not mimicked in the new project.

        This process repeated itself almost exactly when I began integrating the XCode projects. I was even less familiar with this IDE but I got lucky and it ended up not taking any longer than the CodeBlocks integration. Really the solution besides spending lots of extra time in the IDE was going back and forth from stand-alone tests project settings to the newly created test project settings and making sure they matched up in every case. This was difficult in XCode and CodeBlocks because these IDE's do not support having multiple instances of themselves up like Visual Studios does. At the end of the day, I got both projects integrated and by the end of the week I was only about three days behind where I expected to be, which isn't a terribly unmanageable gap. Even though I was unclear of my expectations for week one, I was able to overcome the extra work by staying on task and working a little extra.

CMake and iOS Programming

So, CMake and iOS development can be a handful. While generating a XCode for iOS development, CMake leaves out a lot of settings. Working on those settings afterward can be frustrating and will take some time. It is through the CMakeLists.txt where all the breakthroughs happen as we can change all these settings through it and it's variables. The main problem I've actually encountered were the signing of the application. Since iOS development needs to use the app store for development. The application needs to be signed in order to be built and pushed to a device. The next problem following this is that in order to get an application signed, you need to be a certified iOS developer. With the linking of both the certifications and profiles to the application comes the hair pulling thought of "Why do I have to do this?" The current error that plagues me is just an incorrect signature.

Merging and Testing

Month Two: Week Two

        This week, after completing the merging of the unit tests and the main repository, my main task was to begin the test-driven development side of our project. This means I was tasked with going into the unit tests and adding in my new GWindowTests file. In this file I will utilize the interface I wrote for GWindow to create tests for each function that will prove the library is functioning correctly.

        The main issue I encountered was a flawed understanding of the Broadcaster / Listener we are using to communicate operating system messages to the end-user. I understood that my GWindow was a broadcaster and the end-user would derive their own listener from our GListener interface, but I didn't understand how the messages were actually being generated and sent. I needed to find a way to test the messaging system of my library, but without this knowledge I really had no idea how to go about it.

        I started by looking at the interface my GWindow is derived from, the GBroadcasting interface. It has a RegisterListener function which only adds the id of the listener to a map; I couldn't see anything really about messages or sending or receiving. Next I checked the OnEvent function of the GListener which is run every time the Listener receives a message. I saw within this function the Listener was reacting to GBufferedInput events based on the id of the event passed in. This gave me a hint to go one step further and figure out where OnEvent is actually being called. Because of the parameters of OnEvent, I knew that message had to be sent from whoever was using this function.

        Turns out the real cause of the trouble was that a file called GBI_callback.cpp was hidden inside the external dependencies drop-down in one of the many projects in our solution. I had never seen this file before, but it turns out this file actually holds the WndProc for GBufferedInput which captures all the Win32 messages sent to the broadcaster. At this point I saw that the Win3I2 message was being translated into our custom Gateware messages and THEN sent off to each registered Listener with the OnEvent function. Using this knowledge, I added my own if statement that is only true if the sending interface is my GWindow. From here I just increment a simple number to check if the window is maximized or not. At this point I have completely completed my test cases and am moving on to porting the tests to Linux and Mac and starting development.

Android, the headache

Android is an operating system that many phones use. From Samsung Galaxies to Samsung Note Tablets. This makes Android a largely used platform which means it should be heavily supported, right? Wrong. There is currently only 2 IDEs that are well-known and stable for developing on the Android system; Android Studio and Eclipse. Both of these are highly acclaimed and are mostly used for developing for  Android. In order to use them though, both of them need another package though which is the android sdk. Android Studio comes with the sdk in its base install while eclipse android needs it to be installed with it. Now, after the sdk is installed and located by both of these IDEs, the true challenge emerges. Android uses the programming language java which is fine as java is an established language that has been used for a long time. What doesn't use java is the toolset that the Gateware team is making which there lies the problem. In order to make the toolset work with either IDE, we need to convert the java into C/C++. To convert java to C on either IDE, a package called android NDK must be installed. Only after both of these are done could a person work using C or C++ in order to work on Android. My problem is not coding in either language but to set up either IDE to be in this state using the CMake system. CMake can not install the sdk, nor the ndk, nor does it currently generate either Android Studio or Eclipse Studio projects. So, where do we go from here? That is the question soon to be answered as of all of this information was researched just this week.

Second Month, 1st week: Cmake Linux and Mac standalone

This week, worked on mac and Linux standalone system. The Linux system is working currently off of a console line system using curse CMake GUI. At the moment, the Linux system produces a Codeblocks - Unix files.The Mac system is currently running the CMake GUI system to build the system files. All of them are currently using the same source files and all of them are based on .cpps and C++ programming. Both CMake systems are working perfectly fine with the GUI systems. Working on writing a multi-platform CMake text file and cache that can run on all the systems without being changed. Plans after that are to make all of these files based on the console/terminal windows and away from the GUI systems.

Month Two, Week Two

Issues With Merging Unit Test and Main Development Repository

Author: Nic Russell

Posted: 5 May 2017


        My first task this week was to incorporate our Unit Tests from our Test Suite into our main Gateware repository so that the tests are closer to the source code they depend on. Also, this will allow us to automatically build the Unit Tests after each build of the libraries which will ensure our tests and libraries are always up to date with each other.

         The issue at the moment is that the library and include directories have changed significantly because of the new file structure of the Gateware repository. The Visual Studio solution was not looking in the correct place for the libraries once they were built and therefore could not build its own source code. I have never had so many separate projects with their own build settings and esoteric preferences in the same solution before, and it is difficult to keep them all in order.


        The problem is that the Gateware repo was never designed to have another solution added to it, so the file structure has become a little muddled and I am still working with it to try and find a stable, easy to navigate structure. One issue I had was with the #include directories. The new structure of the repo made the old #include directory path deprecated, requiring me to remove some "..\..\" to get the path to look in the right repository. I then had to use more relative pathing in the source code itself to fix the #include path.

The next issue will be almost certainly be solved somewhere in the project settings, because the error I am currently getting is that the file "Gfile.lib" cannot be opened. First, I checked the lib directories and saw that the relative pathing was looking much too far back into the repository, to the point where it was looking for .lib's on my desktop. After taking out a few "..\..\" I was sure the path was correct because I could see the necessary .lib's and .dll's inside the folder I pathed to. However, The error was still occurring, so I began meticulously checking the Test Suite preferences to make sure any changes there were reflected in the new Gateware repo. After that, the error was still occurring. I have since added additional lib paths in the preferences. I started taking out .lib's and .dll's from the working Test Suite to try to mimic the error in the working repo, which I was able to do. The error would occur when the Library Directory preference was not set correctly, meaning it could not find the .lib. However, the current Library Directory IS looking at the correct .lib's, so at the moment I am a little lost.

        As I keep working on this I plan on trying to try using preprocessor definitions to set up the lib paths and hopefully that will be more explicit linking and the project will find the correct libs.

Month One
Author: Nic Russell
Posted: 2 May 2017

        Month one of the Gateware final project consists of picking a library to research and then gathering all necessary information required to build a multi-platform version of that library. The deliverables for month one is a research paper describing the purpose and per-platform findings of your individual research, as well as a workable demo of the basic functionality of your program on each platform.

        My library is a window creation and manager library that must be able to handle creating, moving, resizing, and destroying a window on the Windows, Mac, and Linux platforms with a single interface. This required me to become something of an expert in the respective window API's for each platform. The win32 API for Windows gave me the least trouble just because I was already familiar with the structures and routines required to create a window. The only extra information I needed to gather was the id's for all the window messages I would be handling in my program as well as how to extract relevant window information from the events.

        Linux research presented much more of a challenge because I wasn't actually sure what the lowest level end-user accessible window API was for Linux. It turns out it is the X11 library, but the issue with that is it is highly recommended for almost any application to use a wrapper around X11 that handles some of the more esoteric or difficult to use structures and routines. However, for our purposes we must not use any 3rd party packages so that our end-users won't have to download anything but our libraries. X11 is a bit less professionally documented than win32 because there is no official licensed documentation. The only reliable resource for X11 other than a textbook is a blogger's personal documentation project for X11 that is thankfully free to use online. Utilizing this X11 bible I was able to find all the creation routines event messages and data extraction I needed to build a quick demo.

        Mac research was even more slow-going because I have never owned or really used a Mac at all, so just simple things like navigating the IDE and GUI for Mac slowed me down considerably. As far as the research goes, I quickly realized that I would have to learn a new language for Mac development. I picked Objective-C over Swift because it is at least a little closer to C style than swift. The lowest level library that Mac uses for window creation is the Cocoa library, which has expansive professional documentation and demo applications available for research. It didn't take too long to get a workable demo of a window up, but it took much longer to figure out the messaging system and events as they are much different than win32 or X11.

        Overall throughout the month I was able to create my three demos from the pages of notes I took on all three platforms. These demos consisted of a single file that opens a window in whatever style I choose, and allows the user to move, resize, maximize, and minimize the window. This is essentially all my library needs to be able to do, but the tricky part will be developing the back-end to work for any platform with one codebase. With all the information I accumulated I had no trouble writing a research paper with plenty of code examples and per-platform information that highlights the issues to take into consideration when building one interface for these three very different API's. The most important part of the research paper is the Suggested Interface section, in which we write out what we think our interface should look like. Based on my instructor's initial approval of my demo interface, I feel I am well prepared and ready to start building the test suite for my library and eventually actually develop the library itself.