On Sun, 3 Jun 2001, Stuffed Crust wrote:
> On Sat, Jun 02, 2001 at 07:51:16PM -0700, Matt wrote:
> > get_command: 11514776, q_command: 11
> > get_event: 639, q_event: 8
> > get_data 6, send_data: 6
> >
> > I can only assume that on a well-functioning system that get/queue
> > functions should have about the same number of calls. Is this right?
>
> No, it's not correct. The main SCI game loop checks for events at
> various points doing the loop. SCI was originally interrupt-driven, but
> we're polling it instead. Similarly, the soundserver not only has to
> check for new commands, it uses the get_command() as its actual delay
> loop. Perhaps your counters should test whether or not
> get_event/get_command actually returns something.
After changing it to only count when there was actual data/events to be
gotten, things looked a lot more sane (get and q's were the same). The
results are the same whether the music plays normally or not. (damnit.)
As I mentioned on IRC, I re-ran a profiling tool. The MCI midiOut* calls
only account for about 3% of the total cycles. Some higher ones include:
gfxr_auxbuf_spread looks like a good candidate for optimization.
gfx_crossblit_16_P does a *lot* of memcpy's. Someone might want to look at
that as well.
While I was playing around in Quantify looking at this stuff, I made a
neat looking callgraph that illustrates sort of how FreeSCI is organized.
This might be helpful (or confusing) to new developers:
http://www.lag.net/~matt/tmp/sci_callgraph_small.jpg
I know it doesn't have everything, but it was really hard to get
everything to be reasonably small. Hope it's at least amusing to some
people :)
--
http://www.clock.org/~matt
