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.