{"id":4440,"date":"2016-04-06T16:59:14","date_gmt":"2016-04-06T14:59:14","guid":{"rendered":"http:\/\/www.kameli.net\/marq\/?p=4440"},"modified":"2017-03-10T00:16:07","modified_gmt":"2017-03-09T22:16:07","slug":"petscii-editors-design-thoughts","status":"publish","type":"post","link":"http:\/\/www.kameli.net\/marq\/?p=4440","title":{"rendered":"PETSCII editors \u2013 design thoughts"},"content":{"rendered":"

After more than two\u00a0years of improving and honing my own project<\/a>, and checking the competition I got the urge to share some of my thoughts on what makes or breaks a PETSCII editor. A lot of this stuff is actually pretty self-evident in the end, but it has taken hours and hours to figure it out. Bear with me \ud83d\ude42<\/p>\n

Not pixels<\/h3>\n

When comparing a PETSCII editor to a generic paint program there are plenty of similarities, but also notable differences. Instead of tens of thousands of individual pixels we’re dealing with a relatively low-resolution grid consisting of predefined symbols. On the one hand it is easier to deal with text, since tools such as lines, ellipses and curves are rather useless, but on the other hand there is a constant need to effectively choose and alternate between\u00a0the available symbols, which requires different kind of thinking altogether. In other words, adopting tried and tested methods from paint programs alone will not lead to optimal outcome.<\/p>\n

Among the most powerful features of PETSCII<\/em> (the editor) are smart rotation and flipping of a selected area which take into account the form of the character. I take no credit for these, as it was Tero who came up with the idea in the first place and wrote the remapping tables. Not every character\u00a0can be rotated or flipped, but even so you’ll save a lot of time when working with symmetric forms. See the following image for an example of how “smart” flipping works as opposed to simply moving the characters:<\/p>\n

\"flippi\"<\/a><\/p>\n

Typing vs. drawing<\/h3>\n

In essence there are two main methods to get characters on the screen. The traditional way, typing, was initially the only possible option and is still heavily present in modern-day editors (for example AAE). A mouse is something of a rarity on C-64s and graphical symbols can be conveniently found on the keys, so\u00a0on a real machine typing makes all sense \u2013 but a lot less so on your PC or Mac which has a different keyboard to begin with.<\/p>\n

I’ve included a half-assed typing mode in PETSCII<\/em>, mostly for the sake of actually writing\u00a0text, even though all the symbols can be typed too if it’s really necessary. In any case, drawing\u00a0with a mouse was the preferred metaphor right from the beginning. There are pros and cons to both, but using a mouse definitely makes it quicker to sketch forms in the spirit of direct manipulation. A little but important detail is to show the character before it is actually placed: otherwise you end up constantly undoing the operation.<\/p>\n

Character selection<\/h3>\n

When drawing, a great deal of time is spent on selecting the next character. The first thing to do was to reorganize the otherwise messy character set to group related symbols together (thanks go to Tero again). Jambonbill<\/a> went even further and repeated the same characters multiple times to create visually continuous groups.<\/p>\n

\"char-charts\"<\/a><\/p>\n

A well-organized character selector is a good start, but much more can be done to facilitate an efficient workflow. For example in PETSCII<\/em> the aforementioned rotate and flip operations work with individual characters as well: press a single key and get the next corner for a window or a box. In the same lines I came up with “smart sets”, predefined sets that you can walk through with a keypress. Another little bit that arose from a real need was to let the user quickly shift stick characters (used for various lines) right\/left\/up\/down.<\/p>\n

As a piece of PETSCII\u00a0art is drawn, you typically start accumulating useful characters and their combinations in the image itself. Instead of always going for the selector \u2013 which in Playscii<\/em>\u00a0even occludes part of the canvas \u2013 it makes sense to quickly pick a character from the surroundings.<\/p>\n

Grid<\/h3>\n

You can<\/em> get away without a grid if the images are comparably small, but all in all a well-working grid can be of great benefit\u00a0when selecting regions and aligning symbols with each other. After at least three complete rewrites of the drawing code I’ve eventually come up with the following findings:<\/p>\n