Hi,
> > > What were you doing in the threads? Just looping randomly, or doing
system
> > > calls of sorts?
> >
> > Hopefully this is covered in my example above.
>
> Almost, but not completely: What was the main thread doing during that
> time?
Main thread was in a message loop using GetMessage() which only returns if
there is a message waiting. Since it wasn't getting any messages since its
window was minimized, the thread was blocked.
> So is there a ProcessMessage() (or whatever) API function we can use if
> PeekMessage() returns that a message is waiting?
Yes absolutely, GetMessage() as mentioned above. PeekMessage() checks for
one, and if there is one, we call GetMessage() to get it for processing.
> Also, since threads seem
> to be interrupted in whatever they're doing to process messages sent to
> their children, what are the conditions for such an immediate (rather than
> PeekMessage()able) interruption? (for PostMessage() like message passing).
>From what I've seen, it's whenever there is a message waiting. If we are
going to write our own message loop however, I will implement that in my
test app and make sure. So I'll get back to you on that one. (a)
By the way, when I say message loop, I mean something like this running as
the server (stolen from Platform SDK, Aug 2001 docs):
// Start the message loop.
while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0)
{
if (bRet == -1)
{
// handle the error and possibly exit
}
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
Looking at that above, I would say that DispatchMessage is what causes the
message to be processed (see (a) above).
> > Just that it's a loss of timing that we don't need, and can get around
> > (probably).
>
> Hmm, how so?
>
> > > Hmm, where is the periodic processing of MIDI data in this model?
> >
> > I'm not sure how this currently happens in the program - does the
current
> > sound server ask for data every so often? If we alter the model to use
our
> > own message loop, we could put that in to occur every so often.
>
> Right now, the sound server never asks for data, it is sent everything it
> needs (song information etc.) and does the following:
>
>
> while (true) {
> t := calculate-time-to-next-note();
> sleep-and-handle-messages(t);
> play-next-note();
> }
OK so what I was thinking is that what is currently sending the sound server
data, instead sends a message to the server either with the data or a
pointer to the data (assuming we won't lose the pointer as previously
discussed). The server then gets the message and plays a note or does a
command or something. Is every note sent as a command or is a block of MIDI
data sent with a command attached?
If a message can be sent to the server whenever a note needs to be played,
then we could make the server implicitly sleep by not using PeekMessage() at
all and just using GetMessage() which only does a round of the loop when it
gets a message. But from what you've said before this is not how things can
work.
> > If the main process isn't what is getting the commands, then no. If the
> > sound server is getting commands and midi data from resources,
>
> This is what's happening, and it's impossible to do it any other way
> without doing very painful timer handling all over the code in unrelated
> program fragments, i.e. by emulating pre-emptive multitasking manually.
Well forget that then. :-)
> There no CPU-intensive tasks in the sound server that I'm aware of.
Good - as you say, avoiding multi-threading madness would be a good thing!
> Anyway, what we have right now is, indeed, a polled server. While the
> 'polling' part could be taken care of by some sorts of messages, what
> we're always going to have is a separate program running asynchronously to
> the interpreter which accepts commands from the main program and sends
> back status information, either by explicit poll (current model) or when
> it's time to send this information (Sierra SCI on IBM PC model).
Sounds acceptable.
> Section 7 in the online docs documents basic differences between Sierra
> SCI and FreeSCI, the functions provided by our built-in debugger,
> savegames, and information neccessary for implementing kernel functions
> (not updated for recent changes in resource management, though).
OK, I'll have to give it another read.
> It is missing:
> 1. Documentation for the sound subsystem
> 2. 80% of the gfx subsystem documentation that _should_ be there
> 3. Our platform-independant tools.c functionality
> 4. A short introduction to the core header files and some information that
> maps functionality to C files
>
> I don't think there's much of a point in describing the program flow in
> general, since that's not much other than "initialize", "load game", "run
> game", and "uninitialize".
No, of course not.
> I think doing 3 and 4 would be most important. 1 might be about to change
> somewhat anyway, while 2 is of little interest to most people
> (apparently) and would require a lot of work to be finished.
Yes I think you're right with those probabilities, but it's a shame that gfx
can't be better documented. Especially if we ever want to get DirectDraw
working on Win32 (and that code itself is largely undocumented).
Regards,
Alex.
