Hi,
> > To see if we can get the best performance, I'll compare using the
Windows
> > timer I mentioned with the QueryPerformanceCounter() function in a
separate
> > thread. The latter gives a resolution of 3579545 counts per second on my
> > machine, which is a lot better than 1000!
>
> That sounds a bit better, yes. But won't there be some sort of price to
> pay for this?
That's why I want to compare them. :)
> > That sounds OK, but how will we know if it's a sound command or event
> > without comparing it with each possible message? Are you suggesting only
two
> > basic messages (apart from timers) with the command stored in wParam and
> > data in lParam?
>
> There are actually three parameters that have to be transferred, although
> we should be able to encode it in the 64 bits we have available if we
> wanted to.
> 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'.
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.
Cheers,
Alex.
