Hi,
> > Primary goals: > > * Auto-detect version number from Sierra's executable > > The first one won't always be possible. Later games used lzexe or > something like that to compress things down. Some SCI1 games also used relatively strange version numbers. > And barring that, are we > just planning to grep for the version string or something? That was the idea I had originally, yes. It's sufficient for SCI0, at least. > Perhaps a better idea would be to create a database of the md5 checksums > of the sciv.exe/sierra.exe, and look up the interpreter that way? The Sarien approach? This would be more versatile and thus better suited in the long run. It'd also be possible to use both, but this would only be useful if we wanted something that works quickly, and we don't really need it all that soon. I guess the md5 approach is better. We could still use the grep approach internally, to collect md5 -> version mappings. > > * Add PCM output support and one driver to use it > > -- These two are urgent, IMHO. Even if it's just Tandy support... > > Heh. Screw Tandy support; I'm shooting for PC speaker emulation. :) > > Do you want me to check in that skeleton for the pcmout driver? If the API is documented (in the header files or such), this would be helpful. > Now I'm not really sure how to go about this in a low-latency manner, > especially as there needs to be synchronziation with the game.. Low-latency support will neccessarily be platform dependant. We'll need support for: a) Playing a single, pre-existing PCM b) Mixing (concurrent stuff) c) PCM output based on (parametrized) functions (PC speaker, Tandy...) (c) could be implemented with a callback mechanism using a function variable such as: int (*f)(byte *buffer, int bufsize, int rate, foo_t buftype /* might not be neccessary*/, void *state); ...where 'state' could, for example, point to two ints int storing the frequency and how long that particular tone should continue to be played (for sawtooth or square waves), and the return value indicates whether the function would like to have itself (and its state) unregistered. This could introduce problems if we use that function to read from the sound server state, but I guess it'll generally be possible to just register a function each time we want to play a note. Not sure if this is the best approach, though... it also binds the pcm output mechanisms to the sound server process, but I guess that's where it belongs. > (Oh, for a bit of tracker wisdom..) > > > Bonus goals: > > + Add glx graphics driver > > -- Volunteers? > > Hmm. Pure glx? We could always use SDL's hooks into OpenGL to make it > more more easily portable. OK, make that 'gl' instead of glx, adding glx/sdl/wgl input and initialization code afterwards. > But I don't see glx really gaining us > anything.. Could be faster on some setups if done well, particularly because it handles Z buffering (which is why we have to blit manually most of the time). llap, Christoph
