Web UI and Mac status?

I am getting ready to start working on a game, and I’m debating if I want to look into using the web UI but I’m a mac user, and I don’t want to mess with it if there aren’t near term plans to support it in frobtads. Has anyone heard any information about plans and timelines? I can test it out using windows, but I hate the idea of releasing something that people who don’t use windows can’t use.

Also, what are people doing to allow them to switch between the old HTML Tads and the new UI? Just #ifdefine pragmas or working on an abstraction layer that does the switching for them? It seems to me that the latter would be best, but I haven’t looked closely enough at doing it the new way to know if it’s possible.

WebUI will likely never be supported in frobtads in the sense of being able to play those games in a terminal. It’s supported in the sense that you can use frob to launch a WebUI game, and it will print the server address to open in your browser.

I’m not sure what level of support for WebUI Nikos is planning to offer in QTADS. Last time I checked, it was unsupported even in the network server role. The same is true of Gargoyle at the moment; the latest release does not even support 3.1, although I’ve merged that code into the development tree and it will be in the next release.

Online WebUI play is supported on all platforms and in most popular browsers. Free hosting for WebUI games is available, through IFDB and the gs.tads.io service. This approach requires players to have an active Internet connection, but apart from that it’s quite accessible.

I use pragmas and a custom makefile to toggle back and forth between build targets. The abstraction layer is already provided in the form of adv3 and adv3web, provided you use the higher level forms of input / output management, rather than low-level functions like tadsSay.

Full support for WebUI is planned. Can’t give an exact timeline; could be next week, or next month.

Yeah, I meant QTads.

It’s good to know that it will be supported in the near future. I think this has a lot of great potential.

That’s great news!

Unrelated to WebUI (other than not working on it because I’m currently hacking on this one), but maybe useful for Gargoyle: I’ve been trying to improve sound playback, which uses SDL_mixer as its engine. But SDL_mixer has some severe limitations. Like not being able to play multiple music streams simultaneously. Gargoyle works around that by “abusing” the callback for Mix_Chunk samples and using SDL_sound for the actual decoding, but which doesn’t support native MIDI. QTads simply decodes the whole thing, wasting tons of memory and freezing for the duration of the decoding process.

I’ve mostly fixed this SDL_mixer issue now:

bitbucket.org/realnc/sdl_mixer

It can now play music streams on separate channels using the new music functions with the “Ch” suffix (Mix_PlayMusicCh(), etc.)

Just dropping this info here in case you’re interested in using it and want to contribute your own changes. I intend to submit this to upstream.

Very nice. I’m interested in this effort though I won’t have time to contribute for few weeks yet. It would be great to toss SDL_sound; its decoding quality is poor and the “chunked” approach to playback also hurts sound quality.

I thought the single music channel limitation was in place because libmikmod is (was?) not reentrant. If that’s still the case, they may be reluctant to merge upstream given that multiple channels wouldn’t work for MOD playback.

SDL_mixer now supports libmodplug, which is reentrant, has better sound quality and supports more formats than mikmod. Passing “–disable-music-mod --enable-music-mod-modplug” to configure results in using only libmodplug for MODs.

mikmod and timidity are the only backends that don’t support parallel streams. Not much of a problem, since modplug replaces mikmod, and fluidsynth replaces timidity. (But I don’t think any of the IF systems supports more than one MIDI track at a time, since native MIDI was traditionally limited to only one track at a time.)

Hm, this is interesting. I haven’t really even begun thinking of sound, as of yet. Mostly just CSS and graphical interface elements, which could make a big improvement over the dated HTML TADS stuff.

So, is the issue that the server has to merge all of the sounds together and stream it up to the web client? I’ve been doing C++ for a decade or so, and might be able to contribute assistance, if there is a need.

This is for normal, non-WebUI games. WebUI games have to use HTML5 for sound.

If you’re interested in sound in WebUI games, you can take a look at my websound extension. It adds support for HTML TADS style sound tags using SoundManager 2. All the features are supported except fades.

There’s currently a bug with the TADS server implementation that affects audio streaming. Although the VM is multi-threaded and requests for each session are handled separately, within a given session only one request can be transferred at a time. Streaming an ogg / mp3 file will block the UI until the download is complete.

This is slated to be fixed in 3.1.1. In the meantime the workaround is to host the files outside of the story file, and put a full URL in the sound tag rather than a relative URL.