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.
Wednesday, August 30, 2017
Monday, August 21, 2017
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.
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.
Monday, August 7, 2017
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.
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.
Tuesday, August 1, 2017
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.
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.
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.
Subscribe to:
Posts (Atom)