Linux is strange

Over the last week I've been digging deep into GWindow on Linux to find and correct memory leaks that were pretty wound into it. Plus it all being on Linux meant some strange complpications came into place, such as spending a day proving that the library was the source of a leak only for me to be unable to replicate the error the very next day. All that combined with the sheer quantity of memory leaks made it difficult to trace case by case instances and so I struggled.

As I continued over the week I found myself getting more and more accustomed to the memory leak tool valgrind and reading it got easier. I learned new functionality for it that allowed me to trace problems more specifically and started getting a more solid idea of just how GWindow's functionality is implemented and where the inconsistent pieces were. It turned out that Linux's event system used a different heirarchy than Windows or Mac and so threads were being launched but never checked on again. From that point I was able to start cleaning up small leaks and on the same path found a way to stop the vast majority of Linux's GWindow leaks. In my solution with only GWindow enabled there were still two leaks left to handle, one not relating to GWindow, but I have a new assignment now so they'll wait another little bit yet.

Unit Tests for new GatewareX interfaces

I begun writing unit tests for GEvent interfaces: GEvent, GEventGenerator, GEventReceiver, and GEventQueue using catch2 which is an open source header-only framework for creating unit tests. Here are some code:

TEST_CASE("GEventGenerator core method test battery")

{

GW::GReturn gr;

GW::CORE::GInterface emptyInterface;

unsigned int listenerCount = 0;

GW::CORE::GEventGenerator eventGenerator;

SECTION("Testing Empty proxy method calls")

{

REQUIRE(eventGenerator.Observers(listenerCount) == GW::GReturn::EMPTY_PROXY);

REQUIRE(eventGenerator.Push(GW::GEvent()) == GW::GReturn::EMPTY_PROXY);

REQUIRE(eventGenerator.Register(emptyInterface, nullptr) == GW::GReturn::EMPTY_PROXY);

}

SECTION("Testing Creation/Destruction method calls")

{

REQUIRE(eventGenerator.Create() == GW::GReturn::SUCCESS);

REQUIRE(eventGenerator);

eventGenerator = nullptr;

REQUIRE(!eventGenerator);

REQUIRE(eventGenerator.Create() == GW::GReturn::SUCCESS);

}

// Now we can begin checking valid proxy method calls

REQUIRE(eventGenerator.Create() == GW::GReturn::SUCCESS);

SECTION("Testing Valid proxy method calls")

{

REQUIRE(+eventGenerator.Observers(listenerCount));

REQUIRE(+eventGenerator.Push(GW::GEvent()));

CHECK(+eventGenerator.Register(emptyInterface, nullptr));

REQUIRE(+emptyInterface.Create());

}

}

So far I've been pretty successful on writing new unit tests, the biggest thing here is that debugging through the unit tests gives me more understanding of the new event system. Which I will have to tell Chris about so he can document on it.

Hello

My name is Jadon Lindburg and I will be working on 2D rendering.

Powerman 5000 once said, "When Worlds Collide" (The end of my collision detection research)

For the past few weeks, I've been researching a lot of information on collision detection and subjects related. It's been an extreme struggle to really hone in on the most used functions a collision detection library should have, which ones are going to get the most use from the Gateware users, and what's within the scope of this project lifetime. Collision detection is a huge subject in itself and ultimately I had to really get a lot of feedback from our LSA and poll both Full Sail students and instructors. In addition to that, I then had to use that information and propose an interface I think is user-friendly and follow coding standards and architecture.

Time quickly when by until I had to finalize my thoughts and research into something I was confident with to provide an adequate collision detection library interface. I have 13 shapes and 11 functions to make some huge number of combinations which can be seen below. Most of these functions are overloaded and only account for the float type implementation (there is a double type implementation) which comes out to a huge amount of writing the complete proposed interface. I would be crazy to meticulously write each function line by line, but, as a programmer, I'm lazy and opted to generalize as much as possible to make a function to generate the interface. All that was left was to change specific pieces here and there while checking for mistakes.

This new architecture has me both scared and excited

As part of the porting team my job is to port Gateware to the new architecture but I also have to document it so future Devs can make sense of it and that's where my fear comes in. I have to make sense of the new architecture and know it from the inside out and even though I am excited for this challenge there is a small part of me that doesn't know if I can do it but I will do my best so we can move Gateware towards the future.

GFile Interface change complete

    Added new functionalities to the GFile interface, now it supports getting folder count and folder names. Unit Test for all functionalities pass on all platforms, Lari gave me the green light to integrate into Alpha branch. I will now resume my research/test in my file concatenation tool.

GAudio and GAudio3D big progress achieved... on Windows

Month:1, Week: 4

Huge progress has been achieved in the last couple of work days. The biggest bottleneck for my progress was resolving memory leaks (and race conditions) in GSound for over two weeks. After the issue was resolved, I managed to fix the memory leaks from GMusic, GAudio3D, GSound3D and GMusic3D in a single day!

3D Audio libraries are derived from the base class, so without working base class no progress could be done on 3D. After the base class got fixed, 3D contained a lot of issues but from my almost 3 weeks of experience of GAudio allowed me to figure out a solution fairly quickly.

The next big challenge comes from implementing the fixes on Linux and Mac as from what I saw these platforms experience similar (if not the same) issues. The problem comes from the usage of Audio libraries which are not cross-platform, so I would need to learn the nuances of those for each platform again. For example, I learned that XAudio2 (Windows) is not thread-safe, so the EndEvent would cause way too many issues as the XAudio threads were not synced to the GAudio thread(s).

I will start by implementing unit tests and possible solutions from Windows to Linux and Mac. This would allow me to see if any improvements were achieved and will try to take a next step after. After the memory leaks from GAudio and GAudio3D on Linux and Mac get resolved, I will start working on extra features of GAudio3D.