Re: [Alephmodular-devel] Detangling/de-Mac-ifying

[Br'fin <br...@ma...>]

On May 17, 2005, at 9:54 PM, Chris Pickel wrote:

> Oops, thought Reply-to was set to the list.
>
> On May 17, 2005, at 6:02 PM, Br'fin wrote:
>
>> In the case of AM, this is, I believe, in shell.cpp. However, as a  
>> further snarl. I don't think going with a straight up abstraction,  
>> like I did with some other areas of the code, necessarily gets  
>> what we need out of it. The process of updating the state of the  
>> world and rendering it happens in this event loop. So I want to  
>> add a thread in here. But I don't know enough about threads to get  
>> my brain too well around them either.
>>
>
> Just to clarify, is the thread you'd like to add would be  
> responsible for the rendering? i.e. an update to game state would  
> trigger an update to audio/visual state, and the audio/visual state  
> would update at the same time as the next game state update.

Current thread situation in AM:
Main Thread (Handles Mac Events) - Also handles updating the world  
and rendering the screen.
Input Thread (Runs as a VBL API thread) - Polls mouse location and  
keyboard state 30 times a second, updates input queues
Network thread (I don't know details) - Performs network traffic,  
kind of unimplemented/unused in AM

The specific problem I ran into when doing mousing in AlephOne was  
that GetMouseLoc in OSX was not updated in the VBL thread. So at the  
very least I want one thread to handle Carbon Events while the thread  
that handles updating the world and rendering is dealt with  
separately so the Carbon Events can get processed in a timely fashion  
for capturing various Mouse Moved events.

> I've had some limited dealings with threads before, in the form of  
> boost::thread (this was on Linux), although I used my own mutexes  
> since I didn't quite understand their documentation. However, I'm  
> not sure exactly what the best way to split two event loops apart  
> would be - after all, I believe that you would need to create a  
> readable state for the display loop that would be entirely separate  
> from the writable state of the game loop.

For the time being, Updating the world state and rendering the world  
state need to be kept in the same thread. They're reading off the  
same global world state. Probably a bad idea to modify this during  
rendering right now. Currently the update and render world steps  
happen during a call to idle_game_state() near the end of the main  
event loop.

(I'd love to split this out into a couple levels at a future date,  
setup the concept of world state in terms of where everything is, and  
a second animation state that is driven by the world state, but can  
do bunches of things on its own. And would only be needed by a client  
and not a server.)

> I also find it ironic that the first three people on a thread about  
> "de-Mac-ifying" have mac.com email addresses :)

DeMacifying was the term I decided to use to explain what I was doing  
with AM. It's the process of taking the Mac-OS 9 specific calls and  
pushing them out of the main game code via abstractions which  
hopefully could be implemented on another platform.

As opposed to some extensions in A1 where code is duplicated into  
MacOS and SDL versions of the same file.

-Jeremy Parsons
http://alephmodular.sourceforge.net/