Month: 4 Week: 4 (Final Week)
Several bugs were found during the last week in preparation for presentation and the release. Luckily enough, with a little bit of crunch time I managed to resolve some of the bugs that were connected with Audio systems (my main concern) and attempted to help my teammates with issues I had some knowledge about.
Biggest problem of the week was GAudio3D failing in release on Windows problem due to compiler AND having some issues with stack memory on Linux. While the stack memory allocation issue was fairly straight forward (prevented the allocation falling out of stack and properly transfered data from 1 array to another); the other issue was not so simple. The bug only persisted on Windows and only in release which was impossible to track without some rewriting which brought the issue in the debug - then I found out the crashes were caused by base GAudio class accessing GAudio3D resources in destructor, and due to order of destruction - derived class (GAudio3D) was destroyed before base (GAudio).
I implemented a "hacky" solution to explicitly separate base class event generator from derived class event generator. The functions to access base generator were overridden in derived class for direct access (since the exposure of the base class is restricted to Protected) and the actual generator of GAudio3D was created separately. This allowed GMusic3D and GSound3D to explicitly connect to correct event generators during creation and this resolved the crashing issue. (All GAudio and GAudio3D classes are now operational and stable on Windows, Mac and Linux.)
Several bugs were found during the last week in preparation for presentation and the release. Luckily enough, with a little bit of crunch time I managed to resolve some of the bugs that were connected with Audio systems (my main concern) and attempted to help my teammates with issues I had some knowledge about.
Biggest problem of the week was GAudio3D failing in release on Windows problem due to compiler AND having some issues with stack memory on Linux. While the stack memory allocation issue was fairly straight forward (prevented the allocation falling out of stack and properly transfered data from 1 array to another); the other issue was not so simple. The bug only persisted on Windows and only in release which was impossible to track without some rewriting which brought the issue in the debug - then I found out the crashes were caused by base GAudio class accessing GAudio3D resources in destructor, and due to order of destruction - derived class (GAudio3D) was destroyed before base (GAudio).
I implemented a "hacky" solution to explicitly separate base class event generator from derived class event generator. The functions to access base generator were overridden in derived class for direct access (since the exposure of the base class is restricted to Protected) and the actual generator of GAudio3D was created separately. This allowed GMusic3D and GSound3D to explicitly connect to correct event generators during creation and this resolved the crashing issue. (All GAudio and GAudio3D classes are now operational and stable on Windows, Mac and Linux.)
No comments:
Post a Comment