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.