Re: [freesci-develop] Glutton OS X sound support & wrapper for FreeSCI, was: Concerning C416: No sound on Mac OS X

[Christoph Reichenbach]

Hi,

> After my mail yesterday I stayed up for some more hours and compiled 
> Glutton and ran some tests. Compiled fine but starting SQ4 resulted in 
> the following error:
> While processing relocation block 0007:099e:
> Relocation failed for index 0000
> - No locals
> - obj#0 at 01c6 w/ 4 vars
> - obj#1 at 0218 w/ 4 vars
> - obj#2 at 03de w/ 6 vars
> - obj#3 at 0568 w/ 6 vars
> - obj#4 at 0604 w/ 6 vars
> - obj#5 at 0684 w/ 6 vars
> - obj#6 at 0818 w/ 15 vars
> - obj#7 at 0922 w/ 11 vars
> Triggering breakpoint...
> Missed breakpoint in seg_manager.c, line 747
> (full startup at the end of this mail).

SQ4 and friends (SCI1 etc.) doesn't really work yet; no one has looked
into this for quite a while.

> I have feeling this might be more game/script related than platform 
> related.

Yes.


> > FreeSCI's SDL graphics driver is the slowest graphics driver we
> >have at the moment, and I'm not convinced that our implementation
> >is to be blamed (although I'd be more than happy to see an improvement
> I think there is a decent speed for the graphics (i.e. I don't think we 
> were complaining about speed or so but see my message more down) and I 
> am sure that the additional SDL layer does not improve the speed. I 
> thought SDL was using Quartz or was this planned for a future version? 
> Quartz would be the top speed for OS X, Open GL is supported but its 
> not as fast if I understood everything correct. Is there any other 
> multi-platform graphics engine out there that has currently OS X 
> support?

You could try xlib (there's X11 for OS X, after all). I never got it to
run on my iBook (presumably, my installation is broken), but that's a
different issue.

[...]
> If speed would be an issue and the freesci model does not match up 
> completely with SDL then we could check on implementing a specific 
> Quartz support engine into freesci (that would make it probably the 
> fastest script reader/emulator in the OS X world) but I am not sure if 
> that would not be overkill.

Depends on how much effort you want to put into it. Our gfx output layer
is discussed and documented in src/include/gfx_driver.h if you want to
have a look.

> What other graphics engine that freesci 
> supports right now works really well with it next to SDL? Maybe we just 
> need to port that one.

libggi and xlib are the only portable ones I can think of at the moment.

> >>I personally was thinking of creating a real
> >>preferences file in ~/Library/Preferences, creating a good icon,
> >We already have one (a png file), but it's a little lower in resolution
> >than most OS X icons are.
> We should stay with the same icon preferably, would look nicer.

Makes sense.

> It 
> would not be too hard to take the same one and just increase the 
> resolution.

It would look somewhat fuzzy, though. Well, I guess you can just use
it for the time being, and if someone re-creates one at 128x128, we
can just use that.

[...]
> ScummVM has this too, 'in script/emulator' preferences and game 
> selection. I think this works great for most platforms and it would be 
> the best to give Glutton the same feel for all platforms.

Yes, that would be very useful for the frontend side. On the backend,
platform-specific configuration storage may be useful, but I guess this
would become less of an issue with a built-in configuration mechanism.

> Maybe we 
> should just have a wizard setup for new games externally to Glutton? 
> The wizard would move the game resources to a Glutton sub directory and 
> ask for the initial settings. The rest of the settings or changes to 
> the settings could then be run within Glutton with the general setup.

  "Wizard setup" meaning some interactive external program?
I'm not sure if relocating game resources makes sense on all platforms.
One could reasonably imagine a UNIX system with data resources being
shared (/usr/share/games/sci/...) between different users, or an SCI1.1
game with speech output from CD (and we don't really want to copy the
RESOURCE.AUD or whatever it was called for these games unless the user
really wants that...)

Adding new games might well be implemented within the config screen
itself, or, if it is handled by an external program, that program may
simply write entries to the configuration file.

> >>>Also, would the performance for the adlibemu be better with (real)
> >>>sound cards instead if the basic Apple soundcards? The only card I
> >What kinds of performance issues are you having? Note that there are
> >two well-known problems in 0.3.x which may be related to this:
> > (a) Sound timing is generally quite a bit off-- we don't play notes
> >in advance; as such, timing is off if the sound server process/thread
> >is not scheduled to be run at precisely the point in time it requests
> >to be run. (Yes, this is stupid, and it's why we got rid of the entire
> > sound subsystem in its current form for glutton).
> > (b) The SDL graphics driver (in its current implementation) is quite
> >slow, i.e. you might be blaming the wrong subsystem here.
> You know this just makes want to run FreeSCI under linux to make sure. 
> It sounds (really;) like (a) and (b), the screen builds up not all too 
> fast in Space Quest 3 and the sound is just 'late'. Concerning speed, I 
> am running a 1 Ghz Powerbook and ~700 Mhz PowerMac, so I expected 
> faster (I remember the speed for this game very well, I played it for 
> hours on my XT and 286, its currently running about the 286 speed). 

I have run FreeSCI with very acceptable speed on a SparcStation 5, and
remotely (over a 10 MBps line) on an SGI Indy-- as such, I'm confident
to say that (1) your system performance shouldn't be the problem here,
and (2) FreeSCI's _general_ treatment of graphics should not be a
problem, either.

> What would be a easy way to see where the performance issue is located? 
> You mentioned the connection to SDL, any way to enable some debug 
> screen output to check the speed with and without SDL on OS X?

You can run either with the xlib driver (using X11), or with the 'null'
driver-- you should enable debug messages to ensure that you see
_something_ happening there, though.

> ==Glutton error output======
> Unrecognized game id: 0x07a8f43f, Loading resources...
> Patching "SCRIPT.000": OK
> Patching "SCRIPT.119": OK
> Patching "SCRIPT.120": OK
> Patching "SCRIPT.405": OK
> Patching "SCRIPT.410": OK
> Patching "SCRIPT.514": OK
> Patching "SCRIPT.541": OK
> Patching "SCRIPT.700": OK
> Patching "TEXT.000": OK
> Patching "TEXT.405": OK
> Patching "TEXT.410": OK
> Patching "TEXT.541": OK
> Patching "TEXT.700": OK
> Patching "VIEW.992": OK
> Patching "VIEW.993": OK
> Patching "VIEW.994": OK
> Resmgr: Detected SCI01
> FreeSCI, version 0.6.0
> While processing relocation block 0007:099e:
> Relocation failed for index 0000
> - No locals
> - obj#0 at 01c6 w/ 4 vars
> - obj#1 at 0218 w/ 4 vars
> - obj#2 at 03de w/ 6 vars
> - obj#3 at 0568 w/ 6 vars
> - obj#4 at 0604 w/ 6 vars
> - obj#5 at 0684 w/ 6 vars
> - obj#6 at 0818 w/ 15 vars
> - obj#7 at 0922 w/ 11 vars
> Triggering breakpoint...
> Missed breakpoint in seg_manager.c, line 747

Still SQ4? Sounds like the script isn't being run correctly; try using
the undocumented '-r' parameter to specify the resource layout (I'm
not sure how this works; Lars?).
  It will still be broken, but not completely broken.

-- Christoph