Through the Jaws of Defeat

So it seems that Allegro does not allow you to update a display from a thread unless the thread made the display. It's due to TLS (security) reasons. Now I understand that we live in a world where memory is protected, and I don't know much about the mechanations of thread management, but that just seemed silly..

That also means that the thread can not alter the graphics on it's own.

I was about to create an experimental fork in Git and refactor the whole game. The plan was to put in a proper input -> update -> render loop. Using a thread appears to be a dead end. Makes sense, the original code base was not designed for one. I should of refactored this mess anyway, and actually set it as a goal at the beginning of phase 2. However, it was working (kind of) and I thought I could cheat with a thread (That I kept commented out for two months. Should of been a warning sign right there)

The "normal" thing to do is to set up an event system that can get polled by the main game. It will simply look in the queue and see if 55 milliseconds has passed and then run a function. Time and time again I try to explain why ROE does not have a main loop, and it's not possible to implement an event queue because there is no central place to poll the queue from.The game is made up of "screens" and each have their own loops, but some loops don't render anything and some don't take user input. It was only when I looked up overlays on Wikipedia did it show an example of this type of linking

                       +--------------+
                       | Root Segment |
                       | MOD1, MOD2   |
                       +--------------+
                               |
                    +----------+----------+
                    |                     |
             +-------------+       +-------------+
             |  Overlay A  |       |  Overlay B  |
             |  MOD3       |       |  MOD7       |
             +-------------+       +-------------+
                    |
           +--------+--------+
           |                 |
    +-------------+   +-------------+
    | Overlay AA  |   | Overlay AB  |
    | MOD4, MOD5  |   | MOD6        |
    +-------------+   +-------------+

This was why I was having a hard time explaining it. The program flow is hierarchical and control does not stay in the root segment. Each part of the game is loaded when it's needed from the HDD and then purged when another overlay is needed. I had long since combined everything into one big executable, but the program flow was the same. The root segment hangs out in memory, and that where my graphics lib hangs out, but nothing really loops there. This is also why, when I implemented the graphics lib with the Allegro wrapper, everything downstream started to "just work" for the most part. The 1Ch thread was independent of this tree and why I thought a thread would be a good idea.

GrafX2 - A common kinship

 So whilst whining about on the internet about my plight, I had another dev get in touch with me. When I mentioned that the game was setup with .OVL overly linking  and I didn't have a "main loop", This guy knew all about this. He one one of the developers that ported GrafX2 from DOS to Windows and used the same exact architecture. He showed me where I could shim in an event handler.

 It took a new function and 4 entry points.... I felt so stupid.

I was about ready to rip apart this whole program and now I have a functioning "inner loop" I guess. Now my next goal is to work on the game proper. I already have to abstract the file system in that part of the code to load/save/create and existing game. I also have to make the Race Builder stand alone so the artist can  make some cool alien bits .