FSDL 3.0: Hot New Trends
Inching towards the final stages of the development of the new Frogans Player, STG-Interactive has now started finalizing the Frogans Slide Description Language 3.0 (FSDL 3.0) specifications for publication.
This is the easy part, according to Alexis. It’s kind of like putting up the road signs now that the streets have been paved. Now that the Frogans Player has its rendering capabilities encoded, we’re establishing the means for telling it what to do. Working on the new FSDL feels like coming down the home stretch.
The last version to be published, FSDL 2.1 is looking more and more like that distant cousin that you knew when you were a kid, but who you saw less and less of as you grew up, and now you wouldn’t recognize if you were standing at the same bus stop. FSDL 3.0 is a major upgrade.
From what I’ve seen FSDL 3.0 will be a lot more intuitive, and simpler as well. I think that the new specifications will be a hair shorter than those for version 2.1, but no promises. More importantly, there has been a rethinking about how FSDL-created and associated elements are defined and placed in frogans slides.
In both the new and in previous versions of FSDL, resources, being associated images, vector elements , gradient fills and text elements (respectively SETIMAGE, SETDRAW, SETPIXELS and SETTEXT elements in version 2.1) are first defined so as to furnish something of a resource library. Each resource can then be used as needed, and in as many occurrences* as necessary. Occurrences can be resized, rotated, have masks and filters (e.g. blur, opacity, shadows, color effects, etc.) applied to them, and may be used themselves as masks for other objects.
In prior versions of FSDL the on-screen size of an image, text, etc., wouldn’t be defined until the moment at which they’d be “placed” on the frogans slide, in the CONTENT element, or applied as a mask for an other occurrence, in the MASK element. A CONTENT element occurrence would be sized with respect to an 800 x 600 unit grid representing the surface of a frogans slide (remember that in pixel units, the maximum rendered size of a frogans slide at its maximum zoom is 320 x 240). The size of a mask would be determined as a proportionate to the size of the occurrence that it masked. (The way of defining text resources, while simple, didn’t leave a lot of room for easy reformatting – but I’ll talk about that another day. Let’s just say for now that it’s greatly improved.)
It was agreed that a simpler approach was needed, so we worked towards the idea that the resources should be defined from the start with their sizes among their attributes, and that it will probably be in pixel units with respect to a frogans slide’s maximum zoom size (320 x 240). This follows the reasoning that people who publish frogans will generally think about their graphics and such in terms of the pixels they occupy on-screen and at their maximum zoom size. This runs somewhat counter to the idea that frogans are ultimately pixel-independent, which allows for their real-time resizing on screen, but it seemed to be a better way to go for easy authoring. Not only that, but apparently it has helped for more simple and concise coding in the Frogans Player.
Other neat stuff:
Goodbye SHAPE element, hello anti-aliased exterior contours. – The SHAPE element defined the general mask, or over-all shape, of each frogans slide, without anti-aliasing. This was reasonable before operating systems started moving towards putting semi-transparent objects in the user interface. Now it’s become the standard, allowing windows to have shadows and rounded, anti-aliased corners, widgets that look like they’re etched in smoked glass, and yup, frogans that have shadows, and look like they’re etched in smoked Waterford Crystal (let us not be one-upped by a mere widget). With all this transparency and anti-aliasing going around, the SHAPE element started being more trouble than it was worth.
Exterior shadows. – For the forementioned reasons, it’s groundhog day for frogans.
Type – The typographic fonts that you choose when you format your text will be from the selection of fonts embedded in the Frogans Player, and not those found on your operating system. This assures that the text in your frogans will be displayed exactly as you formatted it regardless of the end-user’s operating system configuration. You can be sure that your type will be displayed correctly if you’re writing in Cyrillic, Navajo, Kanji, Thai, even English. Someone remind me to publish the full list of international character sets one of these days.
Goodbye PID, hello forms. – FSDL 2.1 allowed for the use of a personal identifier (PID), or login, as well as a password if the author wished to restrict the access to a frogans. For instance, when you visited such a frogans a login window would appear where you would enter your PID and a password. With FSDL 3.0, a more flexible system implementing forms that are opened in separate windows has made this feature obsolete.
* I use the word “occurrence” whereas the existing FSDL specifications use the word “content”.