I looked at using CMake for Frotz and came away with the conclusion that it’s too complicated for what it would do for Frotz and would cause problems for building on old systems. What sort of sound backend are you thinking of? My project to hire Mark McCurry was derailed by a death in the family. I’m working right now to get that back on track.

I looked at using CMake for Frotz and came away with the conclusion that it’s too complicated for what it would do for Frotz and would cause problems for building on old systems. What sort of sound backend are you thinking of? My project to hire Mark McCurry was derailed by a death in the family. I’m working right now to get that back on track.

I was looking at the different sound systems currently in frotz, and it has three of them. Two for curses (libao and plain OSS) and one for sfrotz (based on SDL_mixer.) I was thinking about replacing all three with just one that is used for both frotz and sfrotz, and uses SDL (in audio-only mode in the case of curses frotz and possibly dfrotz.) This would also get rid of SDL_mixer, which is rather limited and can’t play multiple audio streams at the same time. OSS support would be handled automatically by SDL.

I wrote some audio code for my own projects, which I extracted into a small library a couple years ago and I would just import that into frotz. It’s a rather thin layer on top of the underlying decoding libraries (like libvorbisfile) and automates mixing and resampling. It can play audio streams directly from within other files (no need to extract “chunks” from blorb files and such) using SDL’s RWops. Basically you just point it to something and call play():

However, it’s a C++14 library, and since you mentioned you intend to support very old systems, I now am not sure if this is actually something that can be added to frotz.

If you think it can be added nonetheless (as a replacement for sfrotz’s audio system only, and as an option for curses frotz and dfrotz) it’s certainly possible to keep using a handwritten Makefile. It’s just that it’s difficult to work with. Not that CMake is a prime example of good design, mind you It’s more like something people have to use rather that something they want to use.

Dannii:

I’ve only just started using CMake, but I’d say go ahead. It’s not like it prohibits the classic Makefile from being used by those who’d prefer it.

That would mean two separate build systems have to be maintained. That’s not something I would recommend.

I looked at using CMake for Frotz and came away with the conclusion that it’s too complicated for what it would do for Frotz and would cause problems for building on old systems. What sort of sound backend are you thinking of? My project to hire Mark McCurry was derailed by a death in the family. I’m working right now to get that back on track.

I was looking at the different sound systems currently in frotz, and it has three of them. Two for curses (libao and plain OSS) and one for sfrotz (based on SDL_mixer.) I was thinking about replacing all three with just one that is used for both frotz and sfrotz, and uses SDL (in audio-only mode in the case of curses frotz and possibly dfrotz.) This would also get rid of SDL_mixer, which is rather limited and can’t play multiple audio streams at the same time. OSS support would be handled automatically by SDL.

I wrote some audio code for my own projects, which I extracted into a small library a couple years ago and I would just import that into frotz. It’s a rather thin layer on top of the underlying decoding libraries (like libvorbisfile) and automates mixing and resampling. It can play audio streams directly from within other files (no need to extract “chunks” from blorb files and such) using SDL’s RWops. Basically you just point it to something and call play():

However, it’s a C++14 library, and since you mentioned you intend to support very old systems, I now am not sure if this is actually something that can be added to frotz.

If you think it can be added nonetheless (as a replacement for sfrotz’s audio system only, and as an option for curses frotz and dfrotz) it’s certainly possible to keep using a handwritten Makefile. It’s just that it’s difficult to work with. Not that CMake is a prime example of good design, mind you It’s more like something people have to use rather that something they want to use.

I removed the OSS code because it rapidly became unworkable when I tried to extend it to MOD and OGG playback. I did implement audio output for the curses interface using SDL, but I decided not to merge it to the main branch because of all the subdependencies it requires. Again, this goes with my mission of making sure Frotz works on old hardware. Libao is much nicer in that regard and will interface with whatever lower-level audio subsystem is available.

One of the old platforms I’m particularly fond of is 32-bit Sparc workstations running SunOS. I’m not clear how or if SDL can be run there, but libao can. I’ll see what the cctalk mailing list has to say.

RealNC:

Dannii:

I’ve only just started using CMake, but I’d say go ahead. It’s not like it prohibits the classic Makefile from being used by those who’d prefer it.

That would mean two separate build systems have to be maintained. That’s not something I would recommend.

One of the old platforms I’m particularly fond of is 32-bit Sparc workstations running SunOS. I’m not clear how or if SDL can be run there, but libao can. I’ll see what the cctalk mailing list has to say.

It’s unlikely that this platform has a compiler available that can compile modern C++ code anyway.