On the lossy versus lossless versus uncompressed front, my understanding is that as long as you’re using a good compression and only doing a single lossy conversion, its hard to tell any meaningful difference between the original and the lossy compressed version. Where you run into problems is either using a low quality compression, pushing the compression way past the sweet spot for balancing quality versus file size(320kbps mp3 is near indistinguishable from uncompressed for most sounds, but 128kbps is where mp3 earned much of its bad rap), or doing several lossy-lossy conversions… My understanding is similar holds for things like 24-bit audio samples, sampling rates above 44.1 khz, or using 16-bit color channels, that extra data is an excellent buffer against rounding errors and other forms of signal degradation if you’re doing a lot of processing, but the human eye/ear just isn’t capable of appreciating that extra fidelity.
Still, my inclination is that space and bandwidth are pretty cheap these days, so while uncompressed data files are pretty wasteful, my thought is to default to lossless compression unless space really is an issue* or one runs into a technical issue that forces a lossy conversion.
*Case in point, lossless video is almost unheard of because even with the best compression available, even 24 fps SD video would have prohibitively large file sizes for any meaningful runtime and even with lossy video, we tend to just keep increasing resolution and frame rate to fill available bandwidth and storage space.
I’m all in favor of removing exceptions and special cases from the spec, but I worry about setting an expectation that every interpreter should be able to handle every type of media.
So if we went that route, I’d like to also establish a convention that authors should look at the return value from their Glk image-drawing or sound-playing functions, and take FALSE to mean “the library can’t do it, try something else”.
(Even better would be a “can you handle this particular image/sound resource?” call but that’s a bigger change to the Glk spec.)
It’s quite easy to use media in a Blorb in a web interpreter. While external media are at a disadvantage if the browser doesn’t support the format because the interpreter might not be able to use its own codecs to handle them (particularly when running from file:.) You do have to download it all at the beginning however, so Inform’s new separated mode will be most useful for the rare case 500MB+ game. But more common is a 20MB Blorb, in which case loading it all at once is fine.
And of course the big advantage to Blorbs is not needing to do anything special for online play. You upload the one file and it can be used by people who want to download it for their desktop interpreter, or for people who want to play online.
Thanks for the explanation. However, honestly, i think the idea of having to download the whole blorb at the start is a non-starter once media is involved. what is currently 20MB will soon be 200MB, and the issue would return to bite.
I was thinking another idea would be to “unpack” the blorbs on the server. So that the media could work separately. of course, this would cost additional storage, but the advantage would be a game could be built into a blorb both for web and offline. In the long-run though, this idea sucks in terms of having two copies of the media.
I don’t see any real advantage to having blorbs online even as a convenience. As i understand it, a game can be built targeting the web or to target a blorb. So any game can be built for both without any real problems.
This is fine from the point of view of an author who is releasing a game now. But remember we’re looking at a tech stack which is also intended to support, e.g. using the generic Parchment interpreter at iplayif.com to open a blorb that was uploaded to the IF Archive twenty years ago by an author who never envisioned playing it in the browser at all.
I agree with that, and also that blobs have been very useful in the past. However, what I’m suggesting is that people here should consider the option of discontinuing use of blorbs for future releases of Inform.
The rationale is that blorbs are not the ideal deployment for web serving, so they are no longer a universal solution. In which case, why not drop blorbs for local use as well?
And the rationale for the latter is that, as it stands, the blorb format requires constant revision (as being discussed here). It seems to me, you are making a rod for your own back, and the time and effort would be better spent implementing format support in the interpreter.
Instead, you’d keep blorb for old stuff while new builds would have a story file and a bunch of media files. You’d zip them for deployment, and single-file download. Players would simply unzip the archive and play, or even the terp could do it?
For compatibility, interpreters would still read existing blorbs, but the dev system would no longer write them, except possibly in some compatibility mode that didn’t support newer formats?
Also, you can upload a blorb to the forum, but not an arbitrary zip file. Blorbs are generally considered “safe” in a way that a lot of other files aren’t.
Relatedly, the Glulx VM lets programs access any files stored in the blorb, without giving them full read/write access to the host filesystem.
I’m sorry if that came over as “disingenuous”. that wasn’t my intention. In general though, there will be ongoing pressure to evolve the blorb format, which will, at some future point, hit an existential crisis.
Here’s a quote from the current blorb spec:
GIF and MP3 are not going to become standard Blorb format types.
And does it mean, if mp3 is now added to the standard, it will be mandatory for all interpreters to support it?
What about video formats? At some point there will be pressure to include those as well. And maybe new image formats at some point. I think WEBP should be seriously considered.
That’s a good point about the VM file scoping within blorbs. But really, there’s no need to allow a game to access arbitrary files. The game ought to be allowed to request media using some kind of ID. And perhaps additional story data. the VM should take care not to load anything not of those formats. So i don’t see this as a strong argument for blorbs.
Where does all the js and css go? Not in a blorb presumably. I see this as another “format leak”, which is increasing eroding the existential purpose of blorbs.
But at that point, wouldn’t we need some kind of structure that maps IDs to files of specific types that are considered safe, which are distributed with the game?
At which point we’ve just created Blorb 2, except this time it’s not stored in a single file. I don’t see much advantage to doing it this way.
A lot of interpreters don’t currently support MODs, which are also in the Blorb spec. Presumably those that can easily support MP3s will do so, and the others won’t.
In the interpreter, no? If people want to distribute their games with customized interpreters, it’s good to have the option, but I would prefer that not become a requirement. I like being able to run games in the interpreter of my choice.
Games distributed as zips containing separate media files will inevitably lead to upset players who have unzipped a game into their games folder and overwritten the media files of older games. Especially when Glk right now would want the files to be called “2.png”, “3.ogg” etc. Even if it was changed so that game specific filenames could be used, and even if we strongly encouraged everyone to unzip games into their own folders, it would still sometimes happen. Or if interpreters were changed to unzip the zips themselves, then you’ve just invented a compressed Blorb.
Blorbs aren’t perfect, but they work very well for 95% of IF games. One thing they don’t work well is for streaming multiple large multimedia files in online players, and that’s what the Inform separated resources mode handles.
Well obviously the zips would unpack into a subdirectory for each game. I can’t really see the problem with zips. It’s not like no one has ever seen or used one.
Yes, you’d need some meta data to map IDs to resources, but that doesn’t make it a “blorb2”. My point is that, it’s mostly futile in the long-run to amalgamate all resources into a single runtime file. A single file for distribution, yes, but not run-time.
My argument is that it makes more sense going forward to install a game as a directory with separate resource files, including a story file and probably a file
of meta-data.
This is basically how it works on the web already. OK, running from a single blorb locally has no real problems, except you have to maintain the blorb tools, which i sees as increasingly not worthwhile.
I have no skin in the game because i don’t have to maintain the blorb tools, but you people have to. That’s the drawback as i see it. Time that could be better spent on improving the interpreters. If people here really, really like maintaining the blorb tools, then ok, fine. But it then represents an end in itself rather than a means to an end.
Game engines (e.g. Quake 3) avoid that problem by using a different extension (like .pk3) which doesn’t look like something people are meant to unpack, even though it is really a zip file.
While zip format has many advantages, e.g. lots of existing tools support it, I think the downside is an expectation that any image/sound format you put in one is going to work in every interpreter. A big advantage of Blorb is the limited scope, so you can be sure things you put in a blorb will work in all interpreters.
The thing with zip and other generic archive files is that a well behaved archive puts all of its contents in a single folder in the root of the archive… but plenty of archives just put all of their contents in the root of the archive directly and you end up with archives just spewing their contents all over your working directory if you don’t account for this, especially if you’re extracting multiple archives at once. I’ve ran into this problem often enough I’ve made a bash script that loops through all the zip and rar archives in the working directory creates a folder matching the name of the archive without the extention, and extracts each archive to its corresponding folder and have avoided a lot of messes thanks to it.
But yeah, there’s no real getting around it, either you freeze feature sets forever to maintain compatibility with all maintained interpreters or you implement new features and inevitably break compatibility with some interpreters.
To make this official: no. As Dannii said, that was a case where ADRIFT already had an interpreter and wanted to use Blorb as a package format. We didn’t want to say “no” just because they had WAVs and GIFs in the mix.
I realize this could lead to further spec drift in the future. The Glk API has already seen some of this, with non-spec (but common) extensions that exist solely for Z-machine support. But it doesn’t seem to be out of control.
I guess I’m treating this as “core spec” versus “extra stuff”. “Core spec” may mean just Glulx, but that’s a driving use case.
The proposal here (or in the other thread) is to add MP3 as a core spec format. So we would expect that all interpreters that support sound at all should support both Ogg and MP3. MOD is not formally deprecated, but it’s not in common use either, and we’re not pushing for universal MOD support. WAV remains off in Adrift-land.
(Even better would be a “can you handle this particular image/sound resource?” call but that’s a bigger change to the Glk spec.)
Another possible path is to permit having both Ogg and MP3 versions of the same resource in the same Blorb file. The interpreter would play whichever it could manage. That’s currently not permitted by the spec doc, but it might make sense to add it. (But not right off the bat, please!)
If I had come up with Blorb in the 2010s, instead of the 1990s, I would probably have settled on “really a zip file” as the underlying mechanism. But I didn’t, and I don’t think it’s worth revisiting now.