> Recent checkin broke a number of things:
AAGH!
> 1. In timeout(), PostMessage of emap[SOUND_COMMAND_DO_SOUND] does not
> work. I reverted this to just SOUND_COMMAND_DO_SOUND, which does.
No way - unless I'm missing an updated file somewhere on my local copy. emap
is required.
> On the development branch, the emap[] breaks things. In the release
> branch, it is needed.
I will check the difference.
> 2. A sleep() can not be safely inserted in the polling of the high
> resolution timer since the timeSetEvent is so close to the target time.
> I have removed it.
It was exactly your code, rewritten... :) You may have discarded it since I
was using an outdated copy.
> 3. In sound_win32e_init(), the timeSetEvent was reverted back to being
> periodic. We don't do this anymore, see the previous email and checkin
> comments. I have reverted this as well.
Sorry about that - using an outdated copy.
> > 3. In HQ1, Restore a game from the introduction screen ("Continue
Quest").
> > Verify sound still works properly and no warning messages are
displayed.
>
> This is currently broken in the release branch. The first restore fails
> (soundserver restore fails), the second time it works and then the game
> will usually lock up.
>
> Alex, could you please look at this and make the fewest changes necessary
> to fix it in the release branch?
Yes.
Regarding the type changes I made in the devel branch to fix warnings, I
will fix that.
> The problem seems to be a lack of testing before checking in changes, so
> here is a quick testplan that I would like people to run through Before
> checking in changes to the soundservers:
Start rant and rave:
Can I just make a comment about this... in the last two weeks about 2
million (OK, slight exaggeration) CVS check-ins have been made. This has
been directly before release. Not only has this been virtually impossible to
keep up with, but has been particularly infuriating around this time of year
when I at least have had very little time to check and fix things (most if
not all of us do celebrate Christmas and New Year, right?!). I know
Christoph has time constraints on when we can release but geez...
The main problems that have been occurring have been with the event sound
server. As I recall, this was never going to be included in release, and
silly me let it go through! (Thank goodness it's not the default.) I know
Matt has great hopes that this server will work better than polled on Win32,
but quite frankly I doubt it will ever work perfectly. We already have a
polled sound server that works almost perfectly which should have had its
slow sound problem fixed for Win32 as soon as it was clear that the timing
problems for the event ss would be too great to fix very easily.
In the event ss, there are too many variables when selecting a value for
timeSetEvent() (you haven't answered my questions about that yet Matt :) ),
and CPU usage is too high (although I'm sure Matt will be able to get this
down). As has been mentioned by people, there are problems with saved games
which I haven't been able to reproduce since I don't have time to play them
a lot and on occasions reproducible instructions haven't been given to me so
I can see what's happening.
Busting our guts to fix the event sound server directly before release was
IMHO a bad idea and only introduced problems when both Matt and I were
working on the event ss files and many commits were occurring around the
same time. I would have a commit all ready to go, then would go on-line and
find that Matt had made great advances which I didn't have much time to test
with my new code. So I re-diffed, checked things still worked briefly, and
checked the code in. This obviously didn't always work! (Especially when I
buggered up merging the code.) Also, in the middle of code freeze week my
computer fell apart and needed rebuilding which took about 5 days!!
I feel it was particularly a bad idea to focus on the event ss when there is
an MCI solution for Win32 which will fix everything, and is only a week or
two away (I started it a little while ago and have all the info I need to
finish it).
Yes, my commits have been poorly checked. There is no excuse for committing
broken code (especially around release). But hopefully you can see my point.
Can I also just add that I am certainly not blaming anyone here, but perhaps
we got things a bit out of perspective in some areas?
End rant and rave!
Alex.
