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.
Monday, December 10, 2018
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.
Monday, November 26, 2018
Finishing up my first month on Gateware
11/26/2018
Month 1, Week 4.5
Author: Devin Wright
With most of last week being Thanksgiving break, well also having a delay in receiving feedback on the first draft of my API document. The week was mainly spent re-writing and finalizing the document in order to wrap up the month's work. During, the break I spent some time looking into possible leads for controller implementation on Mac. However, I have not made much progress towards figuring out how to use Run Loops with the HIDManager, yet I still believe the Run Loops to be a possible fix.
Since this week will be the first real week of month two, I have begun writing out the shell of my interface so that later this month I can add my test cases and my Windows implementation. The plan is to transfer the interface that was planed in the API document, making changes as needed to adhere to Gateware's standards. I also need to decide on how I want to set up my input code, as Lari had the idea to have them use a multi-byte code so that they can identify more than just what button/axis is being polled. This will be helpful since the interface will provide separate support for certain controllers, and this will provide an easy way to tell if the code is supported by the current function. The bytes in the code can also be used to provide any other information I may need from the input codes.
Month 1, Week 4.5
Author: Devin Wright
With most of last week being Thanksgiving break, well also having a delay in receiving feedback on the first draft of my API document. The week was mainly spent re-writing and finalizing the document in order to wrap up the month's work. During, the break I spent some time looking into possible leads for controller implementation on Mac. However, I have not made much progress towards figuring out how to use Run Loops with the HIDManager, yet I still believe the Run Loops to be a possible fix.
Since this week will be the first real week of month two, I have begun writing out the shell of my interface so that later this month I can add my test cases and my Windows implementation. The plan is to transfer the interface that was planed in the API document, making changes as needed to adhere to Gateware's standards. I also need to decide on how I want to set up my input code, as Lari had the idea to have them use a multi-byte code so that they can identify more than just what button/axis is being polled. This will be helpful since the interface will provide separate support for certain controllers, and this will provide an easy way to tell if the code is supported by the current function. The bytes in the code can also be used to provide any other information I may need from the input codes.
Friday, November 16, 2018
Third week on Gateware Linux research
11/16/2018
Month 1, Week 4
Author: Devin Wright
This week was spent researching and implementing Linux controller support, as well as writing up the first draft of my API document. Having done some initial research on Linux back in week one I had a pretty good idea of where to start. My original lead was to look into the use of evdev for reading event devices created in /dev/input, however when testing the PS4 controller I found that it does not create a event for button/axes input(it does create an event but it is for the touch pad which it treated like a mouse) it does create a joystick though. At first I tried to read from the /dev/input/js files using evdev to no avail. So, I began looking into how to read data from js files and found that Linux has a Joystick API for reading from them. After, creating a demo using the Joystick API I looked into finding a way to detect when new js files were created and deleted and found the inotify API which can be used to get events when new files are added or deleted from a directory. I also created a small demo to test and see if I could create a file directory from using inotify which was a success.
At this point I have started writing up the final draft for my API documentation, and I am also continuing my research into Mac controller support. After, I finish my API documentation if I time before the start of next month I will spend some time going back and looking into controller support on Mac. One thing I want to look at is the proper use of Run Loops which I believe might be one of the keys to fixing my HIDManager implementation.
Month 1, Week 4
Author: Devin Wright
This week was spent researching and implementing Linux controller support, as well as writing up the first draft of my API document. Having done some initial research on Linux back in week one I had a pretty good idea of where to start. My original lead was to look into the use of evdev for reading event devices created in /dev/input, however when testing the PS4 controller I found that it does not create a event for button/axes input(it does create an event but it is for the touch pad which it treated like a mouse) it does create a joystick though. At first I tried to read from the /dev/input/js files using evdev to no avail. So, I began looking into how to read data from js files and found that Linux has a Joystick API for reading from them. After, creating a demo using the Joystick API I looked into finding a way to detect when new js files were created and deleted and found the inotify API which can be used to get events when new files are added or deleted from a directory. I also created a small demo to test and see if I could create a file directory from using inotify which was a success.
At this point I have started writing up the final draft for my API documentation, and I am also continuing my research into Mac controller support. After, I finish my API documentation if I time before the start of next month I will spend some time going back and looking into controller support on Mac. One thing I want to look at is the proper use of Run Loops which I believe might be one of the keys to fixing my HIDManager implementation.
Friday, November 9, 2018
Second week on Gateware, researching Mac controller support
11/9/2018
Month 1, Week3
Author: Devin Wright
This last week I spent looking into implementing controller support for the Xbox 360 controller on Mac OS X. After, discovering last week that Mac's Game Controller framework does not support them I had began to look into IOHIDManager as a potential work around. However, for the IOHIDManager to work the device being detected has to registered to belong in one of the categories available for creating a matching dictionary used for searching for connected devices. The problem being that since the Xbox 360 controller is not detected as a controller by the OS, it is unclear how to search for the controller using the IOHIDManager ( or if it is possible at all). I am tipped in the direction that the IOHIDManager is not usable for reading input from a Xbox 360 controller, as none of the sources I have found have incorporated it. Instead all of them use a different part of the IOKIT framework to read the bytes sent by the controller and then interoperate the results. However, as these sources are attached to drivers designed to implement Xbox 360 controller support, I might risk making my Implementation depended on a driver if I follow their implementation, as it is unclear how much they affect the output from the controller.
As of right now I am currently testing available controllers to see if I can find one that work as a MFI controller. So, that I can use the Game Controller framework for proving it as a reliable backup, and if needed move Xbox 360 controller support to a B-Level feature to be implemented when I have more time to look into it. Since, I still have to look into and implement my demo of controller support on Linux, as well as write up my API documentation. For Linux I am looking into using the edev library, or a library that wraps up its complexities as it is a fairly low level library. However, no testing has been done yet to see what the library will support, and Linux documentation is scarce.
Month 1, Week3
Author: Devin Wright
This last week I spent looking into implementing controller support for the Xbox 360 controller on Mac OS X. After, discovering last week that Mac's Game Controller framework does not support them I had began to look into IOHIDManager as a potential work around. However, for the IOHIDManager to work the device being detected has to registered to belong in one of the categories available for creating a matching dictionary used for searching for connected devices. The problem being that since the Xbox 360 controller is not detected as a controller by the OS, it is unclear how to search for the controller using the IOHIDManager ( or if it is possible at all). I am tipped in the direction that the IOHIDManager is not usable for reading input from a Xbox 360 controller, as none of the sources I have found have incorporated it. Instead all of them use a different part of the IOKIT framework to read the bytes sent by the controller and then interoperate the results. However, as these sources are attached to drivers designed to implement Xbox 360 controller support, I might risk making my Implementation depended on a driver if I follow their implementation, as it is unclear how much they affect the output from the controller.
As of right now I am currently testing available controllers to see if I can find one that work as a MFI controller. So, that I can use the Game Controller framework for proving it as a reliable backup, and if needed move Xbox 360 controller support to a B-Level feature to be implemented when I have more time to look into it. Since, I still have to look into and implement my demo of controller support on Linux, as well as write up my API documentation. For Linux I am looking into using the edev library, or a library that wraps up its complexities as it is a fairly low level library. However, no testing has been done yet to see what the library will support, and Linux documentation is scarce.
Thursday, November 1, 2018
First week on Gateware and Researching controller input
11/1/2018
Month 1, Week 2
Author: Devin Wright
I spent the first week reading through the documents and source code of the Gateware project. Also, I started my research into implementing controller support library for Gateware. I found that on the Windows OS there are three APIs for controller support; Xinput, Directinput, and RawController(which has a child class called Gamepad for handling hand-held controllers). RawController will not be a viable option as it is only available to UWP apps, and Gateware currently runs as a win32. For now Xinput seems like the best choice for windows as of right now since, Directinput is harder to set up and even though it works with more controllers than Xinput it is unsure yet if the other OSs will be capable of the same. With this knowledge I made a small demo to test Xinput, it worked as expected and was very easy to set up meaning that Xinput will be a viable way to implement controller support on Windows.
This week I continued looking into controller support on Mac OS X. At First I believed that It could be implemented quite easily using the Mac Game Controller framework. However, when I went to implement the demo for it I discovered that the framework only works for MFI(Made for IPhone) controllers which our targeted controller(Xbox 360) is not supported as one. With that dead end I began looking for an alternative approach, and with what I have found so far it appears I can use the Mac's IOKIT/HIDManager framework to read input from the controller as a HID device, and then translate it into the values representing the state of each button on the controller. Currently I do not know a lot about this framework, however it seem like a viable way to get the input that I need.
Month 1, Week 2
Author: Devin Wright
I spent the first week reading through the documents and source code of the Gateware project. Also, I started my research into implementing controller support library for Gateware. I found that on the Windows OS there are three APIs for controller support; Xinput, Directinput, and RawController(which has a child class called Gamepad for handling hand-held controllers). RawController will not be a viable option as it is only available to UWP apps, and Gateware currently runs as a win32. For now Xinput seems like the best choice for windows as of right now since, Directinput is harder to set up and even though it works with more controllers than Xinput it is unsure yet if the other OSs will be capable of the same. With this knowledge I made a small demo to test Xinput, it worked as expected and was very easy to set up meaning that Xinput will be a viable way to implement controller support on Windows.
This week I continued looking into controller support on Mac OS X. At First I believed that It could be implemented quite easily using the Mac Game Controller framework. However, when I went to implement the demo for it I discovered that the framework only works for MFI(Made for IPhone) controllers which our targeted controller(Xbox 360) is not supported as one. With that dead end I began looking for an alternative approach, and with what I have found so far it appears I can use the Mac's IOKIT/HIDManager framework to read input from the controller as a HID device, and then translate it into the values representing the state of each button on the controller. Currently I do not know a lot about this framework, however it seem like a viable way to get the input that I need.
Monday, June 18, 2018
Linux Window Bug Still Exists
Date: 6/18/2018
Author: Tyler Murray
The previous week, I been trying to fix a bug on Linux side that existed before the day I started Gateware. The bug is that the user will have to click on/off the windows generated to have the application proceed through the unit tests. During this week I managed to fix a lot of these hangs, now all that remains to one hang spot. By removing XFlushs & XSyncs it no longer wipes the events in the queue of the server side. Which caused some of the hangs since the xlib functions we were using required a reply by the server and if the server was wiped then it never knows about needing to send a reply. Secondly I had to go through and place XLockDisplay/XUnlockDisplay functions in GWindow & GOpenGLSurface since you need to make sure the display AKA the server connection doesn't get altered while functions that use the display are being used. Otherwise the application will hang since the display was changed/altered/being used else where when it reaches a display function.
But if you place these Locks and Unlocks our GListeners and Linux's Event system won't work properly. Removing the locks/unlocks the event systems + GListeners work but reintroduces the hangs. I have to do more research to find either another solution or a way have these locks/unlocks and have the event system to still be responsive.
This week, I have to start writing documentation, such as "The Release Process", "Windows Memory Leak Detection", Mac Memory Leak Detection", Linux Memory Leak Detection", ".GitKraken Tips", and any other documentation needed to be created as the week progresses. After I finish the documentation and the Presentation, I will like to go back a try to solve this bug before I leave.
Date: 6/18/2018
Author: Tyler Murray
The previous week, I been trying to fix a bug on Linux side that existed before the day I started Gateware. The bug is that the user will have to click on/off the windows generated to have the application proceed through the unit tests. During this week I managed to fix a lot of these hangs, now all that remains to one hang spot. By removing XFlushs & XSyncs it no longer wipes the events in the queue of the server side. Which caused some of the hangs since the xlib functions we were using required a reply by the server and if the server was wiped then it never knows about needing to send a reply. Secondly I had to go through and place XLockDisplay/XUnlockDisplay functions in GWindow & GOpenGLSurface since you need to make sure the display AKA the server connection doesn't get altered while functions that use the display are being used. Otherwise the application will hang since the display was changed/altered/being used else where when it reaches a display function.
But if you place these Locks and Unlocks our GListeners and Linux's Event system won't work properly. Removing the locks/unlocks the event systems + GListeners work but reintroduces the hangs. I have to do more research to find either another solution or a way have these locks/unlocks and have the event system to still be responsive.
This week, I have to start writing documentation, such as "The Release Process", "Windows Memory Leak Detection", Mac Memory Leak Detection", Linux Memory Leak Detection", ".GitKraken Tips", and any other documentation needed to be created as the week progresses. After I finish the documentation and the Presentation, I will like to go back a try to solve this bug before I leave.
Monday, June 11, 2018
Fixing Linux GWindow bugs related to xlib API
Date: 6/11/2018
Author Tyler Murray
The previous week, I implemented the feature of getting the last event that was called in GWindow. Now do to a known bug in Linux that requires the user to maximize, minimize, click on windows to progress through the unit tests. This bug will affect the testing of the GetLastEvent unit tests since touching the windows will interrupt what event was last called. During this week I read up on xlib and figured out that the functions we were using to get the width, height, top-left of the window need to wait for a replay by the server. (xlib API system works like a client-server relationship).
This week I'll continue reading the xlib book and look into Properties. The previous developer worked with Properties to determine the events that need to be called, So if I can read up on this and understand his code I can maybe change these existing functions by changing and reading from the properties instead of calling the functions that hang up the system,
Date: 6/11/2018
Author Tyler Murray
The previous week, I implemented the feature of getting the last event that was called in GWindow. Now do to a known bug in Linux that requires the user to maximize, minimize, click on windows to progress through the unit tests. This bug will affect the testing of the GetLastEvent unit tests since touching the windows will interrupt what event was last called. During this week I read up on xlib and figured out that the functions we were using to get the width, height, top-left of the window need to wait for a replay by the server. (xlib API system works like a client-server relationship).
This week I'll continue reading the xlib book and look into Properties. The previous developer worked with Properties to determine the events that need to be called, So if I can read up on this and understand his code I can maybe change these existing functions by changing and reading from the properties instead of calling the functions that hang up the system,
Monday, June 4, 2018
All Memory Leaks Crushed and the Start of a new Feature
Date: 6/4/2018
Author: Tyler Murray
In the previous week I was successful in getting all the memory leak clean on Linux side, thus being the last piece in the puzzle for cleaning all the memory leaks. Release R4F is now out for user use that not only contain memory leak fixes, but many GAudio bug fixes too. After this my next task is to add a simple feature where the user can call a function "GetLastEvent" to get the last event that was called by the winproc() and be able to use this function to determine the states for the window.
My goal/plan for this week is to finish this feature and have it work on all platforms, then preform a release. Currently i'm running into a bug where the Maximize and Resize events will only be called if certain conditions are met. For an example if you minimize then maximize you would think the last event would be "Maximize" but its "Resize". To get the Maximize event after you call minimize you will then have to change the window style to Windowed Boarder then call maximize. I hope I can fix this problem without needing to follow these conditions. If I can get finished on Windows it will be a nice base to go by when working on Linux since it has a similar function like Windows that runs like winproc(). Mac side maybe another story, needing to do more research on that.
Date: 6/4/2018
Author: Tyler Murray
In the previous week I was successful in getting all the memory leak clean on Linux side, thus being the last piece in the puzzle for cleaning all the memory leaks. Release R4F is now out for user use that not only contain memory leak fixes, but many GAudio bug fixes too. After this my next task is to add a simple feature where the user can call a function "GetLastEvent" to get the last event that was called by the winproc() and be able to use this function to determine the states for the window.
My goal/plan for this week is to finish this feature and have it work on all platforms, then preform a release. Currently i'm running into a bug where the Maximize and Resize events will only be called if certain conditions are met. For an example if you minimize then maximize you would think the last event would be "Maximize" but its "Resize". To get the Maximize event after you call minimize you will then have to change the window style to Windowed Boarder then call maximize. I hope I can fix this problem without needing to follow these conditions. If I can get finished on Windows it will be a nice base to go by when working on Linux since it has a similar function like Windows that runs like winproc(). Mac side maybe another story, needing to do more research on that.
Monday, May 21, 2018
GAudio Bugs Crushed and Now Back to Memory Leak Detection
Date: 5/21/2018
Author: Tyler Murray
The previous week I manage to narrow down and discover the cause of the bug that caused the "pause" & "resume" functions on Linux's GAudio side to fail/crash. In the functions they are using a function from PusleAudio to pause and resume the stream. But this function returns an operation of which wasn't being accounted for. Second reason is that there is a structure that handles these "operations" but these structures are only created within the scope of the function so when a function end that structure is out of scope. So overall, in the streamSound loop was never getting notified that a sound is being paused or resumed so it continued as so, but the stream would still pause/resume. Which caused the application to stall out. Making the structure declared once as a global and assigning it operation member appropriately fixed this problem.
My goal/plan this week is to finish to Linux memory leaks. As of right now I managed to clean all of them except the ones that are within GAudio. This is good news and bad news at the same time because for some reason Valgrind, my Linux memory leak detector is having problems when I run it with GAudio's unit tests. This week is going to be interesting, hopefully I can solve the problem, if not I will have to find another means of memory leak detection.
Date: 5/21/2018
Author: Tyler Murray
The previous week I manage to narrow down and discover the cause of the bug that caused the "pause" & "resume" functions on Linux's GAudio side to fail/crash. In the functions they are using a function from PusleAudio to pause and resume the stream. But this function returns an operation of which wasn't being accounted for. Second reason is that there is a structure that handles these "operations" but these structures are only created within the scope of the function so when a function end that structure is out of scope. So overall, in the streamSound loop was never getting notified that a sound is being paused or resumed so it continued as so, but the stream would still pause/resume. Which caused the application to stall out. Making the structure declared once as a global and assigning it operation member appropriately fixed this problem.
My goal/plan this week is to finish to Linux memory leaks. As of right now I managed to clean all of them except the ones that are within GAudio. This is good news and bad news at the same time because for some reason Valgrind, my Linux memory leak detector is having problems when I run it with GAudio's unit tests. This week is going to be interesting, hopefully I can solve the problem, if not I will have to find another means of memory leak detection.
Monday, May 14, 2018
GAudio Bugs on Linux
Date: 5/14/2018
Author: Tyler Murray
The previous week I was able to fix the bugs related to GAudio & GFile on Windows side. Now getting ready for the release process I encountered bugs that formed on Linux side do to the fixes I made. This will prevent me from continuing the release process until all bugs related to GAudio & GFile on Linux, Mac, & Windows are fixed.
My plan is to use GitKraken to show me the differences between commits so I can narrow down what added code caused the problem on Linux. Once Linux side is fixed, I will have move to mac side, run the unit tests, and fix any bugs that show up. Finally go back to windows to check if the changes to mac & Linux caused any problems. Basically any changes done to one side I must recheck all sides.
After this release, my next task will to go back to fixing Linux memory leaks.
Date: 5/14/2018
Author: Tyler Murray
The previous week I was able to fix the bugs related to GAudio & GFile on Windows side. Now getting ready for the release process I encountered bugs that formed on Linux side do to the fixes I made. This will prevent me from continuing the release process until all bugs related to GAudio & GFile on Linux, Mac, & Windows are fixed.
My plan is to use GitKraken to show me the differences between commits so I can narrow down what added code caused the problem on Linux. Once Linux side is fixed, I will have move to mac side, run the unit tests, and fix any bugs that show up. Finally go back to windows to check if the changes to mac & Linux caused any problems. Basically any changes done to one side I must recheck all sides.
After this release, my next task will to go back to fixing Linux memory leaks.
Tuesday, May 8, 2018
A New Bug & Linux fixes
Date: 5/7/2018
Author: Tyler Murray
The first week of the third month of final project, my goal
was to work on fixing the memory leaks on Linux side. I manage to fix two
errors on Linux side before a team has report bugs in GAudio. The two fixes I
made are related to structures not being “zeroed-out” before using them. Now
switching to a new branch to focus on fixing the GAudio bugs and pushing a new
release as soon as possible. The reported bugs are
- Master Volume is never initialized.
- Calling stopStream() after calling pauseStream() causes the app to stall.
- No documentation on what index is what channel in all SetChannel-like functions.
At the end of the first week I got “bug” 1 & 3 done
pretty quickly but bug 2 on the other hand took me a bit to narrow it down. I
figured out that the pauseStream() calls a XAudio2 func to stop the stream and
if the stream is stopped it never seems to exit the while loop in the
streamThread. So far, my current fix for the problem is to call the XAudio2
func to start the stream if the stream is stopped. This fix allows it to exit
the while loop thus making it exit the loop. Now all is left to do is to double
check if the audio truly stops when the stop function is called. My goal for
this week is to finish up the GAudio “bugs”, update the doxygen documentation
since I added more comments in the code, and push out a release with the fixes.
Then after the release return back to the master branch and work on Linux
memory leaks again.
Direct2D_Support bug fix & problems on Mac
Date: 4/16/18
Author: Tyler Murray
End of the second week of month two. My goal is to fix the DIRECT2D_SUPPORT
bug where it prevented the user from using the graphics debugger. Mid-Linux bug
fixes I had to switch gears to windows side into it GDirectXSurface. After
getting the bug fixed I have to then do a release which entails making sure all
platforms pass the unit tests. Which has lead me to my current problem now. Mac
side is getting a crash when running the test so this week I’ll have to track
the source of this problem and fix it then move to Linux fix that and then
finally do a release.
Finding the Direct2D_Support bug wasn’t hard since it was
little code to look through and figured it out quickly it was an additional
device flag being set that caused the problem. After fixing Window side still
was able to run and pass all unit tests. Now on Mac side it failed the unit
tests, and my plan is to go to the previous commits one-by-one to find where
the error first occurred and track it down that way.
Problems on Linux
Date: 4/09/18
Author: Tyler Murray
Second week of month two. My goal is to fix any errors on
the Linux side and then locate and clean up any memory leaks found. The problem
I’m facing is running Linux side normally and with memory leak detector
(Valgrind) it outputs different results. Normally it shows it passes each test
but with Valigrind it fails some.
So, prior to this week I fixed the problems on the debug
side of Linux that was causing failure in the unit tests. There was an allocation
with memcpy() to a double void ptr which caused problems to come later in the
unit tests. Another problem was a thread error where the bool used to exit the
thread loop wasn’t being changed when the thread was “done”. Fixing this allows
me to run it with Valgrind which shows 2 errors, both in GAudio when using the
filepaths given in the unit tests. Valgrind also states that there are 87 leaks
in the project. My goal this week to look into the filepath errors in GAudio
and see if fixing them reduces the number of leaks. I’ll will be doing more
research in Valgrind, and Linux-side filepaths.
Hunting Memory Leaks (Mac)
Date: 3/27/18
Author: Tyler Murray
First week of the 2nd month of Final Project. My
goal is to locate and clean up any memory leaks found on the Mac side of
Gatware. The problem that going to come up is learning another coding language
(Objective-C), Find code or some way to help me locate the memory leaks, and
what is causing the leaks.
After doing some research I learned the very basics of
Objective-C which will allow me to go through and understand what is going on.
Also while doing my research I came to a solution of what I can use to help me
locate the memory leaks on the Mac side. When you run Gateware on profiling
(aka Debug mode) It will bring up an application called instruments which has a
variety of tools you can use while debugging. One of those tools being “Leaks”
of which you guess it, helps you locate memory leaks in your program. After
giving that a run I was able to see five memory leaks. As of right now I was
able to clean-up four out of the five memory leaks. Three being within GAudio
and one being in GWindow’s unit test.
The last one is still a mystery since it says it
NSAutoreleasePool related. I checked all the pools being created and all of
them are being drained (aka freeing the memory). For the rest of this week I’ll
be doing some more research on NSAutoreleasePools and Objective-C memory
management to hopefully help me narrow were this problem is coming from.
New Feature & Memory Leak Fix in GInput
Date: Monday 3/19/18
Author: Tyler Murray
The second week of Final project, my goal is to implement
support for Direct2D/BGRA into the GDirectX11Surface and fixed the memory-leak
in Ginput’s init function. The users where getting memory leaks that were their
fault. Also, some other users want to use Direct2D and we don’t support it with
our GDirectX11Surface.
After doing some research I was able to support Direct2D by
adding the BGRA & VIDEO SUPPORT flags to the deviceFlag and adding a flag
to the initMask structure. (Used to determine what features you want when you
call the init function) Then I written a section of the GDirectX11Surface Unit
test to test if the Direct2D support works. After running the unit test it will
open a window a draw a circle.
GInput’s Memory leak problem was caused by not freeing the
memory allocated before the end of the function. There was malloc() without a
following Free(). After this simple fix the memory leak in GInput’s init
function has been dealt with.
Hunting Memory Leaks (Windows)
Date: Monday 3/19/18
Author: Tyler Murray
The third week of Final project, my goal is to locate and
clean up all memory leaks on the Windows side of Gateware. The problem is going
to have to be pin-pointing actually where they are and what are causing them. I
need to do some research on tips of tracking Memory leaks and the CRT Library.
After doing a bit of research I was able to use the CRT
Library and a bit of code to detect how many memory leaks are present. I
excluded all unit tests, then started adding one at a time back into run
against the Memory leak detection code. I was able to narrow it down to the
following Libraries. GLog, GOpenGLSurface, GWindow, and GDirectX11SurfaceTest.
Most of the memory leaks were caused in the unit test either not decrementing
refCount correctly or having a creation function in a TEST CASE with multiple
SECTIONS thus the creation function was called more than once and had no
pointer assigned to the allocated memory. GLog and GOpenGLSurface where the
only ones where I had to fix the issue in the Library itself. GLog’s Custom
Creation function didn’t clean up it memory if it was a fail case.
GOpenGLSurface’s refCount wasn’t atomic and had no incrementation call for gWnd
in its SetGWindow().
Monday, May 7, 2018
Previous Blog Location
Hi Everyone,
This is the new blog that Gateware Developers will use to talk about their progress in the project, the previous blog used by developers can be found here.
This is the new blog that Gateware Developers will use to talk about their progress in the project, the previous blog used by developers can be found here.
Subscribe to:
Posts (Atom)