-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PAML Notation Specs? #1
Comments
Whoops! Just saw this now... Pikachu: https://github.com/joedf/PixelArtMarkupLanguage/blob/master/Paml_Viewer/Samples/Pikachu.paml Pretty straight forward, a space is considered a "transparent" pixel. |
I will possibly write a javascript version of this, if anything. |
Thanks!
If you do, please give me a buzz! Keep up the good work. |
Current test Draws in both the html body and the js-console. |
Thanks for the update. I've managed to see it via HTMLLivePreview, and it's really nice: I'll be posting about it on the Cosmigo Pro Motion forum to keep the Pixel Art artists therein updated on this! |
Posted: I was asking about PAML specs because I was tinkering with the idea of creating a PAML export plugin for Pro Motion. It would be quite nice to be able to save Pixel Art works directly to a web usable format — and the example you provided is really nice. |
Nice to see interest in this! I started this because I wanted a text-edible, human readable, pixel art format. |
I see a good potential in PAML for it could serve as human readable middle-format in many cross-graphics contexts. For example, to export pixel art to ANSI Art in applications like BBSs, MUDs/MUSHes, as well as emails and even Voxel art. Also, it could be employed over a variety of text-only protocols, which is quite cool. Pixel Art fits well in the retro-scene, so chances are that whoever still appreciates ANSI Art, BBSs, MUDs, etc., is going to appreciate pixel art too, and in those old standards text-only protocols are still pretty much the standard. The format seems intuitive (html-like tags, When markdown came out, no one really expected that it would eventually boom so fast, and ultimately we ended up having so many markdown flavors that the portability became soon a problem. |
I don't know what BBSs, MUDs/MUSHes stand for, but you are right. I should start defining specs. |
Excellent! Thanks a lot @joedf. As for the colors names listed in htmlcolors.h, are these names taken from the CSS standard or are they arbitrary chosen? Apps will need to handle those correctly. Still regarding colors, besides the six numbers hex notation (eg PS:
Those were (but somehow still are alive) Bulleting Boards Systems, and MUDs/MUSHes were the first generations of online multiplayer games over the Internet during the 80-90s, all text based and relying on Ascii/ANSI art for graphics. That was when home computers where first starting to enter people's homes — when no one dreamed that in 20 years times 1.5Ghz processors would be considered "dinousars", but instead people where overwhelmed by graphics with 320×200 resolution and a 16 colors palette. It was the era of text adventures, when immagination was still the main graphic hardware, allowing you to see beauty in 16x16 pixels images or Ascii characters graphics. Text was dominant, and so were "2nd person thinker games", which soon were replaced by GPU cards and "1st person shooters" requiring little imaginative participation. Connecting to a BBS required a land-line modem (noisy and veeeery slow), and just to connect to the internet you might have to try dialing your provider number over and over again, for over an hour (if you were lucky), in order to find a non-busy line (a provider with 100 users and 20 line was considerd a "big" ISP then). You would buy special gadgets to plug in your phone, so that when the line was busy the number would be dialed over and over again. Back then, sending a single line of text to users in the BBS or MUD would entail seconds of delay ("real time" was an approximate concept). Also, many IPS would automatically cut off your line after 1 hour connection, to give other users a chance to connect; and when you were connected to the Internet no one in the household could use the phone (you know, dishes and shoes fyling across rooms, and that kind of anger stuff). And of course ... you'd have to pay monthly fees to be part of a BBS, with membership card and all! Seach engines came later on, and the internet was a small and unexplored land, with gopher and telnet being the mainstream protocols. Yet, everything about computers seemed truely magic. It was something new, unheard of in the domestic realm; the whole idea that computers could be used for fun instead of rocket-science was revolutionary. Of course, today much of the magic has faded away, and children walk around with 8-core RISC processors in their pockets. Today the idea of having to work within 64Kb of RAM constraints is unthinkable, and generally programming is not so much about code optimization and trying to squeeze information tight in every single bit available. Today RAM and storage are cheap and we can get away with wreckless code and storage waste. In the BBS era loading big Ascii Art would come at the cost of higher phone bills. Pixel Art is obviously still strongly tied to that era and, although the beauty of seeing Pixel Art on CRT monitors is a thing of the past, the good standards of that age are still in use (think of Electronic Arts' IFF 85, which is still used in AIFF today). |
very nice insight! |
I had though so, but wasn't sure about it. Supporting alpha colors might not add any benefit right now if PAML is intended for presenting single sprites on user defined background color, but maybe in the future it might find applications. In that case, the 8 digits hex notation might be worth too ( My worry with the
Yes, browser support is a good added value, also because it's going to work in WebBrowser controls too (WebKit, etc.). Electron could indeed provide a good viewer for PAML, as well a GUI tool for conversion, etc. The only grudge I have with Electron is that often you end up with multiple copies of it, one for every application. Interactive Fiction adventures, which have been using dedicated file formats and lightweight cross platform virtual machines since the 80's, in the last years have seen a new wave of Electron-based adventures created with new Node.js authroing tools. The result is that during the yearly IF contests, where usually you could download all the contest entries in a Zip archive of a few hundred Kbs, now downloads are over 100Mb in size, due to multiple adventures being distributed with the whole Electron package (while the adventure file is still a few Kbs in size, the Electron binaries are something like 900% the adventure size). This led to an expected bloat in the IF Archive which stores all the adventures published since the 70's, which has almost doubled in size since the Electron authoring tools have come out (and probably will be facing unexpected storage problems soon). Somehow, it's a problem that goes beyond mere size, and often is perceived of a violation of the unspoken rules of what old-skool retro gaming was all about. How comes that adventures that have over 800 locations to visit, and can take up to 5 monthes to play till the end, are only 100Kb in size, while new adventures which are short (half hour teasers) and have 20 locations now weigh over 80Mb? All the efforts to create small footprint Virtual Machines that can work on very low-ram computers, and then we see an invasion of adventures wrecklessly stomping over memory and storage. Another issue I have with Chromium/CEF based frameworks are the concerns about privacy and data mining. Electron/Chromium vs SciterA small footprint alternative to Electron is Sciter: Although not open source, it can be freely used in open source projects. It ships as a single shared library, available for many platforms, and can basically do everything Chromium does, but also interface with binary applications. |
Interesting... Also, good point. I am not sure if half transparent pixels would be useful for this art form... |
I'm currently working on some proof of concept plugins for the Pixel Art editing software Pro Motion NG: My intention was to build as a demo plugin a PAML export filter — this being one of the reasons why I'm asking about tech specs, since I'll have to hardcode color names, EOL chars, etc. Although the plugin is going to be mainly a proof of concept and an example of how to implement plugins in various languages, I think it's going to be quite cool to have a Pixel-Art dedicated editor that can export PAML files. At save time, a dialog will popup and ask the user about the pixel scale ratio, since this setting can't be stored in the images or deduced from them. Probably having an inverse filter wouldn't be quite as useful right now, partly due to the pixel scale ratio (which would require restoring original 1-1 pixel), but also because starting from a PAML source the CLI tool is an easy way to obtain a PNG image. But you never know. Surely, converting from image to PAML is the most appetizing feature. I'm really interested in the potentials of this standard. I could have just created a plugin that exports HTML pages (like the PAML cli tool does), but the idea of a dedicated and human readable text-format is quite exciting, for it opens the doors to all of sort of (yet unimagined) uses. So I'm curious to see how it will take off.
|
Valid Color Indices Chars?While sketching the image to PAML export filter, I'm realizing that the spec might also need to establish which are the characters which are employable to represent a color index in the text bitmpap. Assuming that 256 palettes are supported, then Ascii would not provide sufficient displayable character to cover them all. My guess is that a roof of max 64 colors/chars might be a good idea even if UTF-8 was to be mandatory supported. Non Ascii-chars might be difficoult to use in manual edit (and require keyboard alt codes), some UTF-8 chars might end up being badly shown in various tools (cli tools output, diffs, etc.). Sure, 256 color palettes is a desirable goal, but although they might seem very few colors according to today graphics standards, they are actually a lot of colors in the realm of Pixel Art, where 64 colors would cover a good deal of images. The PAML specs should be clear on similar issues so that portability of PMAL files isn't broken. Third party apps could always reduce colors on the fly, bringing the palette colors down to the prescribed limit by using some color similarity algorithm (CIE dE2000, etc.). An export filter would have to come up with some system for deciding which chars to use for each color. Probably a queu or stack would be a good approach, where the nicest looking characters are made available first, and less appealing ones last (eg. Some characters are likely to be illegal to use. Eg The problem here is likely to be that different approaches could be taken to parsing the textual bitmap — eg. loopig through the matrix char by char, or using a RegExs approach instead, and so on. This is an area where implementation specific issues could easily creep in. The difficoult thing is always finding a balance between specs safety and simplicity of use. Too many strict rules could deterr people away, but uncovered aspects could very quickly lead to the profileration of incompatible implementations (see the browser wars, markdown, etc.). Spec Version FieldIMO, this also indicates that PAML files should have a spec revision number field, to allow apps to know which was the standard used for the file creation. Beside a version number, an extra field could be used to indicate wether the standard is being used The Alpha colors could, for example, be labeled as Specs can take years to be ultimately defined, and allowing users and developers enough time to reality-test it is always preferable. Ultimately, a spec should grow around users needs, not the other way around; and as far as PAML goes we're dealing with a cross-realm standard which also bridges the world of graphics with that of Ascii/ANSI text, so it's difficoult to predict what uses and needs are ahead. But some aspects, like those being discussed here, might require immediate adressing. Anyhow, as long as developers know that there is a spec of reference and a drafting process going on, chances are that feedback, proposals and discussions will prevent wild proliferation of standard deviations. |
Very good points made. For versioning, maybe I should add that as an attribute in the paml tag, something like this? |
That would be good and leave room for future updated. Maybe for the version number I'd stick to SemVer is well known and already adopted by many languages, so there are many validation tools libraries in the wild (NPM, Ruby, Python, etc.). It also allows pre-releases and build metadata, so any application supporting PAML would know when they are handling files created with experimental or prereleases version of the standard.
I agree, it wouldn't make sense to enter the realm of True Color or, indeed, anything above 256 color palettes (256 colors being already a challenge in terms of human readable characters to represent them all). Ideally, the range of usable characters should be defined, as it would be good to allow characters that show up properly in monospaced fonts, without breaking alignment (ie wider than usual glyphs), and that most fonts will be able to represent them univoquosly (without fallback glyphs substitutions). I'm sure that there are some Unicode subsets which are common enough to be represented on most monotype free fonts; probably in this context it's worth considering what the average font used in code/text editors will include. |
I like that. Good points made. |
Thanks for the spec update! BTW, I haven't forgotten the PAML export plugin project I had in mind, it's just that I'm facing some problems with the plugin API documentation, which seems incorrect (or old): So I'm waiting for some answers on how to correctly interface to the application, but since that app is closed source I'm kind of stuck until I get some directions from its author. |
Good news, the documentation on PM NG plugins interface has been updated today, so the incongruencies on error handling are now clarified:
So, now that I have all the required info, hopefully I'll find a free time slot in the upcoming week to try implementing a proof of concept plugin to save images to PAML. |
Oh cool! This is exciting to see my old little side-project to potentially bloom into something. 😄 |
Is there a document with the PAML syntax specification?
The text was updated successfully, but these errors were encountered: