02/18/2019
Month 4, Week2
Author: Devin Wright
This last week was spent trying to convert an old Windows OpenGL demo to work on Linux for use in my postmortem. While doing this I ran into a lot of linker errors due to ether missing or incorrectly linked libraries. After, fixing most of these errors on the computer running Linux Mint, with some help from Lari, we were left with a linker error where it was trying to link to -l+. However, -l+ was not being included in the projects linker settings, so we tried to create various other project types and were getting the same error. So, we tried using a different IDE we switched from Code::Blocks to Eclipse. After, some more work I was able to get everything to compile in Eclipse, but we wanted to fix Code::Block as it would be a lot of work to switch everything over to the new IDE. So, we tried switching our compiler from GNU GCC to Clang, but Clang was having a problem with including pthread and wouldn't work. We also tried wiping and upgrading all of the related software including Code::Blocks to no avail. Then on the verge of just wiping and restoring Mint on the computer, I found that Code::Blocks has global linker settings and in there was the -l+ that was breaking all of our Code::Blocks projects and somehow survied the purge of Code::Blocks, after deleting it everything compiled just fine.
The plan for this next week is to focus on writing up documentation for future Gateware developers and end users. This will be in the hopes of helping dev out of the sticky situations that exist on Mac and Linux. Such as the understanding of runloops and similar API on Mac, or the lack of resources on Linux.
Monday, February 18, 2019
Monday, February 11, 2019
Finshing up GController
02/11/2019
Month 4, Week 1
Author: Devin Wright
Mac is now integrated and passes all of the unit tests, as it turns out all inputs received from the device input callbacks have unique usages(an ID of sorts) that can be used to identify the input. However, the usages are unique per controller, so I mapped both the PS4 and Xbox controller in an array of input codes and index into it using the usage and the controller id. Also, it turns out that I was receiving axis events they where simply received as misc input rather than an axis input. Integrating in the code from the demo into GController caused some issues as most of Mac's implementation was done in a separate .mm file, however, most of this was solved by moving the shared function to an .hpp, and making a wrapper class to connect back to the main GeneralController class.
This week will be spent doing some final testing for GController, as well as creating demo applications for Mac and Linux for the postmortem. GController should be ready for what will likely be my final major release for it by the end of the week. For the demos there is an old demo application on the repo, however, it appears that it was designed to work solely on Windows. Which mean I will end up having to rip out a lot of incompatible code in order to get it to work. Before I do that though I will have to look further into it to see if will be worth the time as the demo appears to be heavily direct-x.
Month 4, Week 1
Author: Devin Wright
Mac is now integrated and passes all of the unit tests, as it turns out all inputs received from the device input callbacks have unique usages(an ID of sorts) that can be used to identify the input. However, the usages are unique per controller, so I mapped both the PS4 and Xbox controller in an array of input codes and index into it using the usage and the controller id. Also, it turns out that I was receiving axis events they where simply received as misc input rather than an axis input. Integrating in the code from the demo into GController caused some issues as most of Mac's implementation was done in a separate .mm file, however, most of this was solved by moving the shared function to an .hpp, and making a wrapper class to connect back to the main GeneralController class.
This week will be spent doing some final testing for GController, as well as creating demo applications for Mac and Linux for the postmortem. GController should be ready for what will likely be my final major release for it by the end of the week. For the demos there is an old demo application on the repo, however, it appears that it was designed to work solely on Windows. Which mean I will end up having to rip out a lot of incompatible code in order to get it to work. Before I do that though I will have to look further into it to see if will be worth the time as the demo appears to be heavily direct-x.
Monday, January 28, 2019
Returning to Mac OsX
01/23/2019
Month 3, Week 3
Author: Devin Wright
At this time, I have finally gotten the IOHIDManager to work so that I can detect connected controllers and receive input. The big piece I was missing to get it working was that I had to launch a separate thread that had to both create and init the IOHIDManagerRef, and then call CFRunLoopRun() which blocks the current thread and uses it to process the messages for the IOHIDManager. I also did all of this within a class which seemed to be a necessary step as I had another demo beforehand that was implemented in a similar fashion but did not use classes, however, I am not 100% certain of this. The working demo was also created as a command line tool (Macs version of a console app) rather than a Cocoa App which may have had an impact as well but this is untested.
Now that I can detect the controllers I have to find out how to properly read input events from the controllers. As of right now, I know how to register to receive the events from the controllers, however, I do not have a way to tell what button is sending the event. Also, currently I am not receiving axis events from the PS4 controller. So, I am looking to see if I can get the information from the IOHIDElement received in the input event function. Otherwise, I may have to look into reading the output reports from the controller, the problem with that is they will most likely be unique for both the PS4 and Xbox controllers making a general implementation more difficult.
Month 3, Week 3
Author: Devin Wright
At this time, I have finally gotten the IOHIDManager to work so that I can detect connected controllers and receive input. The big piece I was missing to get it working was that I had to launch a separate thread that had to both create and init the IOHIDManagerRef, and then call CFRunLoopRun() which blocks the current thread and uses it to process the messages for the IOHIDManager. I also did all of this within a class which seemed to be a necessary step as I had another demo beforehand that was implemented in a similar fashion but did not use classes, however, I am not 100% certain of this. The working demo was also created as a command line tool (Macs version of a console app) rather than a Cocoa App which may have had an impact as well but this is untested.
Now that I can detect the controllers I have to find out how to properly read input events from the controllers. As of right now, I know how to register to receive the events from the controllers, however, I do not have a way to tell what button is sending the event. Also, currently I am not receiving axis events from the PS4 controller. So, I am looking to see if I can get the information from the IOHIDElement received in the input event function. Otherwise, I may have to look into reading the output reports from the controller, the problem with that is they will most likely be unique for both the PS4 and Xbox controllers making a general implementation more difficult.
Wednesday, January 23, 2019
Finishing the Linux implementation for GController
01/23/2019
Month 3, Week 2
Author: Devin Wright
This last week was spent implementing GController on Linux. I ended up running into a few roadblocks while adapting the code from my Linux demos. First, the js files that were planned to be used to read input from the controllers change formats between the different Linux distributions. This wasn't too much of a problem as I had already looked into using evdev to read from event files instead. The reason I planned to go with the js files was that I originally thought that the PS4 controller did not create a usable event file, however, with further testing, I proved that I was wrong. The other major roadblock I ran into was that evdev didn't have an obvious way to check if an event file belonged to a controller. I ended up looking through the libevdev wrapper library for an example of how to do this. It turns out one of the ioctl request (EVOCGBIT) in the linux/input.h is caple of returning an array of long bits that holds what type of events the device is capable of.
With the Linux implementation being almost completely finished, these next two weeks will be spent on the Mac implementation. Mac will definitely be the hardest to implement as I still do not have a working demo to start from. Currently, I am looking through the apple demos to see why their work and my do not.
Month 3, Week 2
Author: Devin Wright
This last week was spent implementing GController on Linux. I ended up running into a few roadblocks while adapting the code from my Linux demos. First, the js files that were planned to be used to read input from the controllers change formats between the different Linux distributions. This wasn't too much of a problem as I had already looked into using evdev to read from event files instead. The reason I planned to go with the js files was that I originally thought that the PS4 controller did not create a usable event file, however, with further testing, I proved that I was wrong. The other major roadblock I ran into was that evdev didn't have an obvious way to check if an event file belonged to a controller. I ended up looking through the libevdev wrapper library for an example of how to do this. It turns out one of the ioctl request (EVOCGBIT) in the linux/input.h is caple of returning an array of long bits that holds what type of events the device is capable of.
With the Linux implementation being almost completely finished, these next two weeks will be spent on the Mac implementation. Mac will definitely be the hardest to implement as I still do not have a working demo to start from. Currently, I am looking through the apple demos to see why their work and my do not.
Friday, January 11, 2019
Begining the Linux implementaion of Gateware
01/11/2019
Month 3, Week1
Author: Devin Wright
This week was spent writing out the implementation for handling Xbox controller vibration on Windows, removing 32-bit from support from our cmake files, and starting on the Linux implementation of GController. I had previously added the interface for the vibration support before the break, then I spent the first two days back writing out its unit test, implementing the Xbox version of the methods, and tested it to make sure everything works. After, that I began removing 32-bit support from the cmake files. This had to be done since as of the Mojave update for Mac Os 32-bit is no longer supported, and the cmake was unable to create a solution for Gateware on Mac. This was done by removing the calls to create 32-bit files from the "command line" files (.bat, .command, and a unix executable for Windows, Mac, and Linux respectively).
When it comes to implementing Linux there is a lot less work compared to implementing Windows since most of the groundwork has now been laid. For Linux, I mainly just need to integrate the code from my Linux demos, and then just make whatever changes are needed to get them properly running. The idea is to have a thread for each controller being processed and have these threads handled by the loop running the inotify events. The controllers will then be handled in their own event loops where their input will be processed and stored in the controllers' array.
Month 3, Week1
Author: Devin Wright
This week was spent writing out the implementation for handling Xbox controller vibration on Windows, removing 32-bit from support from our cmake files, and starting on the Linux implementation of GController. I had previously added the interface for the vibration support before the break, then I spent the first two days back writing out its unit test, implementing the Xbox version of the methods, and tested it to make sure everything works. After, that I began removing 32-bit support from the cmake files. This had to be done since as of the Mojave update for Mac Os 32-bit is no longer supported, and the cmake was unable to create a solution for Gateware on Mac. This was done by removing the calls to create 32-bit files from the "command line" files (.bat, .command, and a unix executable for Windows, Mac, and Linux respectively).
When it comes to implementing Linux there is a lot less work compared to implementing Windows since most of the groundwork has now been laid. For Linux, I mainly just need to integrate the code from my Linux demos, and then just make whatever changes are needed to get them properly running. The idea is to have a thread for each controller being processed and have these threads handled by the loop running the inotify events. The controllers will then be handled in their own event loops where their input will be processed and stored in the controllers' array.
Monday, December 10, 2018
Writing the GController unit tests and beginning Windows implementation
12/10/2018
Month 2, Week 3
Author: Devin Wright
The goal of this week was to write out the manual unit test for GController. The unit test are used to test the methods of the Interface to ensure that the correct results are received. This includes passing invalid arguments to see if the method can handle them without crashing. Currently the unit test are lacking since they currently rely on the use of a physical controller. This mainly prevents having dynamic connection test where controllers can be added and removed in a specific order. For testing the results of the input and connection methods when a disconnection happens. This will be possible to add later down the road when I find a way simulate a controller on Windows.
At this point I have been implementing the Windows portion of the GController library and it currently passes all but the event based unit tests as there is currently nothing in place to send the events to the registered listeners. This is simple to do however, since all future implementations have to do this as well I am trying to find the best way to abstract the process into a function that will be to handle the events based on the Controller_States ( a struct that holds the input data and connection status). After, setting up the event system I will go through and clean up my code while making sure all my memory is cleaned up and that all the methods are thread safe.
Month 2, Week 3
Author: Devin Wright
The goal of this week was to write out the manual unit test for GController. The unit test are used to test the methods of the Interface to ensure that the correct results are received. This includes passing invalid arguments to see if the method can handle them without crashing. Currently the unit test are lacking since they currently rely on the use of a physical controller. This mainly prevents having dynamic connection test where controllers can be added and removed in a specific order. For testing the results of the input and connection methods when a disconnection happens. This will be possible to add later down the road when I find a way simulate a controller on Windows.
At this point I have been implementing the Windows portion of the GController library and it currently passes all but the event based unit tests as there is currently nothing in place to send the events to the registered listeners. This is simple to do however, since all future implementations have to do this as well I am trying to find the best way to abstract the process into a function that will be to handle the events based on the Controller_States ( a struct that holds the input data and connection status). After, setting up the event system I will go through and clean up my code while making sure all my memory is cleaned up and that all the methods are thread safe.
Friday, November 30, 2018
Writing the GController Interface shell
11/30/2018
Month 2, Week 2
Author: Devin Wright
This last week was mostly spent writing the interface shell, I also spent some time looking into how to simulate a Xbox controller on Windows for the use with the unit test in the future. The time spent on the shell was to transfer the interface from the API document while making any necessary changes, writing out the Doxygen comments, creating the .cpp file, and defining the input codes for use with the interface. For the unit test it appears we will have to use a driver in order to simulate a virtual controller that can be detected by Xinput. There are a few options to do this currently I plan to look into using something like ViGEm or Vbox as possible options.
With the shell of the interface written out I can now begin writing the simple form of unit tests that won't require the virtual controller. The virtual controller won't be worried about until around the fourth mouth after everything else has been fleshed out. After, creating unit tests for both the regular function calls and the events it will then be time to begin implementing the functions of the interface so that they can pass the unit tests.
Month 2, Week 2
Author: Devin Wright
This last week was mostly spent writing the interface shell, I also spent some time looking into how to simulate a Xbox controller on Windows for the use with the unit test in the future. The time spent on the shell was to transfer the interface from the API document while making any necessary changes, writing out the Doxygen comments, creating the .cpp file, and defining the input codes for use with the interface. For the unit test it appears we will have to use a driver in order to simulate a virtual controller that can be detected by Xinput. There are a few options to do this currently I plan to look into using something like ViGEm or Vbox as possible options.
With the shell of the interface written out I can now begin writing the simple form of unit tests that won't require the virtual controller. The virtual controller won't be worried about until around the fourth mouth after everything else has been fleshed out. After, creating unit tests for both the regular function calls and the events it will then be time to begin implementing the functions of the interface so that they can pass the unit tests.
Subscribe to:
Posts (Atom)