02/25/2019
Month 4, Week 3
Author: Devin Wright
Last week I created the Mac demo for the postmortem, I ended up having to using a separate demo from the one on Linux due to the Linux demo being reliant on X11 and it was more work than it was worth to link in X11 on Mac due to it lacking X11 natively. I also fixed a bug with my circle dead zone calculation, it was missing a check to zero out the final axis values if their magnitude was below the dead zone percentage. This meant the dead zone calculation wasn't eliminating low axis values like is should. Lastly, I fixed a bug reported in GAudio that was overflowing a variable when trying to load in a strangely formatted WAVE file. When reading in unused sections of the WAVE file the section would be read into a long which was usually enough space for the data. However, with a particular WAVE that a user was trying to use it tried to read 190 bytes into the long and overflowed it. So, rather than reading all of the bytes at once I changed it to loop that reads up to a maximum amount of the size of the long until all of the data is read in.
This week I am just finishing up documentation and getting the slides ready for my postmortem. I am also looking into a possible bug mention by someone using the GInput library. I have not confirmed it yet, but supposedly if you press the left arrow key the shift key will be reported as pressed. I will end up having to make a small test project to see if I can recreate the bug.
Monday, February 25, 2019
Monday, February 18, 2019
Code::Blocks and the terror of -l+
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.
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 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.
Subscribe to:
Posts (Atom)