Could you give an example of what this would look like? Lists will be familiar to Dialog-users, but these options need to be both easy to write and possible to parse on a Commodore 64 (which is why I didn’t go with something already-standard like JSON).
Does the new style system require an updated version of the Dialog compiler or just the updated Å-machine web interpreter?
You’ll need both an updated compiler and interpreter for (body style $) to work, unfortunately.
1 Like
Please, not s-expressions. Dialog expressions look similar to s-expressions, but aren’t, and having a mix of the two would be horribly confusing.
Using actual Dialog expressions would be just fine – and more in keeping with the rest of the language – whether they’re (rules) or a [list].
1 Like
Sure. I had Lisp s-exps in mind, but no reason not to use dialog list syntax. So something like (and I realise the examples are absurd)
[ bloop [volume 11] [filter-color 244 234 222]] ->
bloop = true
volume = 11
filter-color = [244 234 222]
Basically just lists … where the head (or single item) is the label and the tail is the value, which can be either omitted (default to true), or a single value, or a list of values. Put all of them in a list. parse each item recursively. Etc. No need for any commas and always clear what belongs with what. It’s not really different from your approach BUT it allows an express list format for multiple values for one option, without the need for any magic consolidation into a list.
But I don’t feel strongly about this. Syntax is only ever syntax!
1 Like
Ah, but this puts significantly more restrictions on the keys and values than the other proposal—in particular, it means neither keys nor values can contain whitespace. That’s a problem for the current font system, which frequently needs whitespace in the values.
It looks like the Americans are winning this one, and “color” will be the only officially-supported spelling. The manual will only use “color”. Unless someone has strong objections, though, I’m inclined to leave the “colour” spelling in the compiler as an undocumented feature; it doesn’t seem to be harming anything.
2 Likes
One could allow whitespace in quote-delimited strings:
[[font-weight bold] [font-family "Very Spiffy Font"]]
(I realise that means it’s not exactly in line with syntax elsewhere.)
Thinking about this more, at the moment, there are two syntaxes: regular Dialog code, and the CSS subset used for styles. I’d love it if we avoided introducing a third one. The CSS syntax is ugly, but it makes it clear that you’re communicating with the interpreter, and not writing Dialog code; if that’s the syntax that we’re already using to pass things to the interpreter, maybe we should stick to just that?
1 Like
That would be ideal, but unfortunately semicolons mark the end of the option string. (This was a decision made by Linus—a semicolon marks the start of the alt text, and there’s no way to mark the end of the alt text, so the options have to come first.) What I’m proposing is basically CSS syntax with commas instead of semicolons, as the closest thing I can get.
I agree with the objective of keeping as close as possible to something that’s already there. One question: is it essential to make the semicolon mark the start of alt text? Backwards compatibility is good, but … sometimes it’s better to change something once rather than live with it for ever.
Not essential, but I don’t want to break backwards compatibility unless we really have to.
Before 1a/01, the format of a resource definition was:
(define resource EXPR)
protocol://filename.whatever
; %% Semicolon marks the end of the filename and the start of the alt text
Alt text can contain any characters at all. , ; : \\
In order to maintain backward compatibility while adding option strings, 1a/01 changed this to:
(define resource EXPR)
protocol://filename.whatever
, %% Comma marks the end of the filename and the start of the options
Option string can contain anything except semicolon
; %% Semicolon marks the end of the options and the start of the alt text
Alt text can contain any characters at all. , ; : \\
And now I’m proposing:
(define resource EXPR)
protocol://filename.whatever
, %% Comma marks the end of the filename and the start of the options
key1: value1,
key1: value2,
key2,
key number 3: value number 3
; %% Semicolon marks the end of the options and the start of the alt text
Alt text can contain any characters at all. , ; : \\
If we changed the meaning of the semicolon, it would be possible to make it be full CSS, but internally it’s stored in a very different way from the full CSS in style classes, so I think having some syntactic differentiation there is good. That way, users won’t be surprised when it behaves differently in edge cases. (In particular, the option string is not parsed by Dialog, it’s stored as a string instead of as a list of key-value pairs like style classes are.)
But I also would prefer not to break all existing Dialog code unless we really, really have to. If we invalidate existing code, there should be a really strong reason for it. And to me, being able to use the semicolon in option strings isn’t sufficiently strong.
1 Like
And for reference, the things that option strings are going to be used for in 1b/01:
- For sounds, the option string specifies a channel name, and whether it should loop
- For fonts, the option string contains arbitrary key-value pairs used when embedding into the CSS
The former exists in 1a/01 already; the latter is a new capability in 1b/01.
Personally, I think filename, key: value, key: value; alt is the cleanest syntax for this. It’s not going to come up very often—I don’t think anyone except me has ever used option strings in Dialog so far. And this way, people who don’t need to use option strings don’t need to change all their existing code.
(An alternative would be filename, key value, key value; alt. Nothing I’ve done so far requires spaces in keys. This is how it was in 1a/01; the colons were added for readability.)
Plus, keeping the special syntax to a minimum makes it easier to parse option strings on the C64. So far, none of this matters on C64, since it can’t do sounds or fonts. But if it does, I think “scan forward for a ,, skip any whitespace, look at the key, if it’s not recognized repeat this process, stop if you hit a ;” is much easier for retro hardware to do than nested S-expressions or quote marks with escaping. (So I will half-jokingly ask: if you propose a more elaborate syntax, are you volunteering to support a parser for that syntax in 6502 assembly?)
1 Like
The C64 does support sound and fonts, just not ones that are compatible with modern web technologies.
A “font” for the C64 is a 2K (256 characters times 8 bytes per character) character set, and swapping these in and out is how a lot of games do their graphics. Having a PuzzleScript-like syntax for defining your own characters would be fun; failing that, at least being able to feed in a bunch of numbers, possibly in the same format that a 6502 assembler would use, would be a handy thing someday, but I wouldn’t rank it among the top priorities. You’d need to mate that up with the Unicode map to be able to use all of the resulting characters.
A “sound” is a SID file, which gets played through the rather nice synthesizer chip that the C64 and 128 have. You create these with note tracking software; the big issue is that the CPU has to play them, which complicates the interpreter a bit. Some of the Telarium games back in the day had nice SID soundtracks, and mentioning that just gave me an earworm to the theme from Dragonworld.
(By “the C64 does support,” I mean that the hardware supports it, not the current version of the C64 Å-machine.)
Yeah, I should say it doesn’t support MP3s, TTFs, and so on. The aambundle program actually has an elaborate font embedded into it; when it turns a .aastory into a C64 disk image, it takes all the Unicode characters in that .aastory’s character set, looks them up in its internal font, and uses that to build a custom font in C64 format.
So in theory it wouldn’t be too hard to let people define their own characters for it! Just pick the most suitable Unicode character, encode the shape you want as a bunch of 0’s and 1’s, and let aambundle take care of the rest. It just hasn’t been done for anything beyond the most common characters Linus ran into.
1 Like
My current WIP riffs off the classic mainframe STARTREK game, and it’s tempting to try to define custom characters for spaceships facing in any of eight directions. I’d need to have at least 16 characters free to get away with it… but really, I need to get the thing working before I worry about chrome like that.
Still, defining custom characters, yay.
Are the line and box drawing characters from the built-in PETSCII character sets also in mkfont’s internal font? Those would be obvious things to throw in, and having corresponding facilities on the web (and hypothetically in interpreters) would be useful to have. My current workaround is hyphens, vertical bars, and plus signs, which works, but real boxes would be nicer.
(And now I’m having to resist the temptation to try to write a game in Toki Pona, using sitelen pona instead of the Latin alphabet.)
3 Likes
It doesn’t look like it—it’s got ASCII, Latin-1, a couple typographical things (en-dash, em-dash, curly quotes, euro sign), and custom characters for drawing a progress bar. But the box-drawing characters wouldn’t be too hard to add! They just need to be drawn in fontdef.txt, like this:
+00c2
...##...
.##..##.
..####..
.##..##.
.######.
.##..##.
.##..##.
........
Each .aastory file defines its own custom character set; the first 128 characters are ASCII and control characters (some of which the C64 interpreter uses for its progress bars), the next 128 can be any characters in Unicode[1]. So aambundle takes that character set and cross-references with fontdef.txt to build the font. I think everything in PETSCII is now in Unicode, so they’d just have to be added to fontdef.txt and everything should work.
Currently only the BMP, but that’s a compiler limitation, not an Å-machine limitation. ↩︎
Oh, we do have a pixel drawing utility! That’s fantastic.
Yeah! I’m actually amazed at how well aambundle is structured. It takes a whole bunch of easily-readable plaintext files and packs them all into one convenient executable. If you want to adjust the internal font, you can just poke at the ASCII art in a .txt, and the build process takes care of all the rest.
1 Like