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.