Hi Alex,
On Wed, 19 Sep 2001, Alexander R Angas wrote:
> > Anyway, IIRC the 'message' is a char pointer typecasted to a 32 bit
> > integer value to achieve some sort of uniquity. By making the text string
> > it points to sufficiently long, we can map the commands to the addresses
> > of individual text string characters (note that we must ensure that none
> > have a negative value), so that we can use simple pointer arithmetics to
> > encode and decode them.
>
> Ummm well we could do that. Thing is, each new message created should be
> registered with Windows, so other apps that might use the same message
> string don't have panic attacks and get upset. We don't have to do this
> since I think we can safely say our messages would be unique with something
> like -{4E7F6EC0-6ADC-11d3-BC36-006067709674} appended to them, but it's
> 'better'.
Hmm, but how is it registerd with Win32? Is this a function call? I used
to believe they were just typecasted char *s, with the text they point to
being purely for debugging purposes...
Anyway, we could still encode and decode manually, with a switch()
statement or something.
> Would we have enough bits if we had messages such as
> UWM_SOUND_COMMMAND-appendage, UWM_SOUND_EVENT-appendage,
> UWM_SOUND_DATA-appendage, and then did bit-packing with the 64-bits
> remaining as message parameters? This would be instead of changing the
> message strings themselves. In the parameters we could put opcodes,
> pointers, etc.
Yes, that's a possibility, too. But it'd be nastier to debug, so I'd vote
for the alternative.
Note that, right now, 64 bits would be sufficient for what we
transmit ATM (IIRC it should fit in to 32 bits easily).
See sound.h and soundserver.h for information regarding our events- with a
less wasteful careful encoding, 'handle' would be 16 bit (32 bit if we
want to keep this useable for SCI32 / the new VM design), signal would
take 6 bit at most, and value won't take more than 16 bits in 16 bit SCI.
We should leave it extensible for 32 bit, though, which would mean
encoding 'signal' in the messages.
llap,
Christoph
