Get Info: #graphics

Shibuya Pixel Art Contest 2024

by Matt Sephton — Sun, 14 Jul 2024 16:42:00 +0000

For June and July of 2024 the Shibuya Pixel Art Contest has been running, a welcome return after it not happening in 2023. Entries are open all over the world, but can only be submitted to Twitter using the hashtag #shibuyapixelart2024. You have to include a name for the artwork and its original pixel dimensions (though it’s OK to rescale small artwork so it can be seen more easily). There are special categories for 16×16px and 32×32px artwork, and then a category for anything bigger up to the maximum of 512×512px. Full rules at pixel-art.jp/contesten and there’s still time to enter! Selected works will go on display around the Shibuya district of Tokyo in August and September.

For my entries I thought it would be cool to use different, unexpected software to produce my artwork.

PICO-8

These three entries are based on graphics I created for a game I started making when my wife was pregnant with our first child. We were house bound for a while, waiting for the birth, and I drew these cards using PICO-8 for a game which remains unfinished. At least I finished the graphics!

16×16px = 「花見」hanami card, (link)
32×32px = 「花見酒」hanami-sake yaku, (link)
128×128px = 「花札」hanafuda koi-koi game layout, (link)

The smaller cards shown in the full game layout are just the regular sized cards downscaled to 8×11px in code using nearest neighbour resizing. For all cards the border is drawn seperately. One or the other size of card are most likely the smallest Hanafuda ever pixelled!?

Rorschach for Playdate

This entry was created with Rorschach a creative toy/game I made for the Playdate handheld gaming system. This piece was created by moving the “pen” using the accelerometer and relying on the dynamic ink colour which is relative to the movement. It’s a fullscreen grab at 400×240px, titled 「キクぞく」”Kikuzoku” or “Chrysanthemum”.

It would be tremendously complicated and time-consuming to create artwork like this pixel-by-pixel, or even with dither brushes, unless you had some sort of pressure sensitive stylus. But Rorschach and the Playdate accelerometer makes light work of it.

The final image was my 12th attempt at getting a convincing flower! With many of my earlier attempts I was slow to hide the cursor and beautiful flowers were ruined by rogue strokes of ink after I’d technically finished. Perhaps I should have added the ability to record/playback or some sort of undo to the app. (link)

Deneba artWORKS for Classic Macintosh

I thought it would be fun to use my favourite classic Macintosh drawing app—Deneba artWORKS—to create pixel art using vector shapes, its bundled external tools (plugins), and the infinite fills best known from their appearance in MacPaint. There are only 20 objects in this drawing, which is 200×300px in size and titled 「黄金比」 or “the golden ratio”. (link)

Spiral: flower heads (2)
Resistor: hairs (3)
Bezier: stems, branch, leaves (5)
Arc: shoots, stems, midrib (7)
Round rect: planter (2)
Polygon: planter inner shadow (1)

Plus

Calligraphic pen nibs to get variable line thickness
Infinite fills to get dithered patterns and textures

Bonus!

I was having too much fun with dither patterns, so I drew one more piece just for kicks. This one is called 「生け花」”Ikebana” (“flower arranging”) and was exported at 200% because I miscalculated my document size at the beginning. I drew the shears and then transformed them with Free Rotate and Scale. There was minor pixel touch-up after export, and the final thing measures 400×512px. Otherwise I used the same techniques as above. (link)

Extras Bonus!

And I did one more just before the deadline. This is titled 「ラペルピン」”lapel pin” and is 512×512px and was created using the same vectors and fills technique. I decided to work in Canvas 3.0 rather than artWORKS, simply because it has a way of locking objects. The only new thing I did here is that I created two diagonal line fill patterns of my own for the collars. (link)

And here’s a screenshot of my working area, Macintosh System 7.5.5 running in 1-bit colour at 1025x768 in the BasiliskII emulator. This time I created it on my MacBook Pro with external Magic Trackpad, but sometimes I use my iPad Pro with Apple Pencil.

Emigre typography and graphic design magazine (1984–2005)

by Matt Sephton — Fri, 24 May 2024 20:19:00 +0000

Emigre magazine was a highly influential graphic design publication. It was known for its innovative and experimental approach to typography and graphic design, pushing the boundaries of traditional design norms—for better or worse. The magazine was published from 1984 (year of the Macintosh launch) until 2005, and during its run it played a critical role in shaping the discourse around digital design and typography. It was founded by Rudy VanderLans and his wife Zuzana Licko.

Tell me about it

Emigre is notable for many reasons, and if you’re interested in 80s and 90s design there will surely be something in there for you. I first heard about Emigre when I started work at London graphic design agency Form in 1998, so about three quarters through the run.

Some features that stand out for me personally are:

Early bitmap fonts (1984) and emoji-like pictograms (1986) created by Zuzana Licko
Early 1-bit Macintosh art by John Hersey (1985) and many other lovely period details
Designs by such luminaries as Neville Brody, Erik Spiekermann, and many more
Articles on people like font designer Aldo Novarese
Issues dedicated to the record label 4AD (1988) and The Designers Republic (1994)

Online archives

I recently wanted to read some of the issues again and found a couple of online archives:

Letterform Archive: Emigre Collection (browsable magazines, simplified cross references)
University of Minnesota: Emigre Magazine Index (only comprehensive cross references)

Digital versions

If you want to take the magazine with you today it’s available in the Emigre Fonts app for iPad/iPhone, which allows you to download the issues for offline reading.

If you can’t use, or would rather not use, the official app I’ve converted the issues to CBZ files. Read those with Panels, Simple Comic, CDisplayEx, or another comic reader app of your choice.

Emigre (magazine) at Wikipedia
Emigre entry at Type Design Information Page
Type ‘90 HyperCard Video video of a HyperCard Stack
Designing the Emigre Magazine Index, Jessica Barness, 2016
Merz to Emigre and Beyond Avant-Garde Magazine Design of the Twentieth Century
Verbum “The Journal of Personal Computer-Aesthetics”, Michael Gosney, 1986–

Emoji history: the missing years

by Matt Sephton — Fri, 10 May 2024 20:00:00 +0000

During my research into vintage Japanese drawing software, I came across some devices that had built in sketch or handwritten memo functions. I bought a couple of them to see if they did anything cool or interesting. These sorts of devices are pre-internet, so there’s not much about them online, and they can’t be emulated, so the only way to find out what they do is to get first hand experience by reading the manual or, better, using one yourself. It’s difficult to find these devices in working condition, as most of them have screen polarisers that have gone bad over time, but if you’re lucky you can find one.

1994

One such device I bought was the Sharp PI-4000, from 1994. This is a pocket computer that rolled out of Sharp’s involvement in the development and manufacturing of Apple’s Newton MessagePad. In 1993 Sharp did their own licenced version of the Apple Newton MessagePad H1000, the Expert Pad PI-7000, but just like Apple’s device it wasn’t as successful as they’d hoped. But before that, in 1992, they’d made a device called the PV-F1 which was the first touchscreen-only PDA. After the Expert Pad failure, Sharp took another attempt at the concept and came up with the PI-3000 in 1993. This solved all the problems with the PV-F1, most notably size and cost. The device I have, the PI-4000, was released a year later and features higher memory capacity. The PI-3000/4000 devices could transfer data via infrared, connect to a modem to send faxes, and by the PI-5000 in 1995 could connect to cell phones to send emails. They all use a simplified—but still quite complicated—version of the multi-window operating system that had been developed for the PV-F1.

So I was trying out the PI-4000, the memo function is pretty cool allowing you to draw in different dither shades and pen widths, and use stamps to add symbols to your memo. These are mostly map-related things like road and rail junctions, buildings, and train stations. Pretty cool. Then I tried typing some messages on the device and as I explored the myriad of keyboard input mechanisms I came across something rather familiar (sorry about the awful photo—it’s the best I could do, honest—the screen is very reflective and the pixels are so far from the backing they cast individual shadows!):

At this point, I couldn’t quite believe what I was seeing because I was under the impression that the first emoji were created by an anonymous designer at SoftBank in 1997, and the most famous emoji were created by Shigetaka Kurita at NTT DoCoMo in 1999. But the Sharp PI-4000 in my hands was released in 1994, and it was chock full of recognisable emoji. Then down the rabbit hole I fell. 🕳️🐇

1990

A little more reading, and a tip from my friend @chamekan on Twitter, unearthed the fact that the NEC PI-ET1 in 1990 also contained emoji¹. I also found a collector who owned a device, and we’ll hear more from them later on. The device is literally the coolest thing you’ve ever seen. With system software written by video game developer Hudson Soft its character set features emoji that can be typed inline, and it also features a “montage function” that allows you to create faces for each of your contacts—15 years later we’d see something similar in Mii on Nintendo Wii in 2006. The emoji on this device are a lot less well designed, in my humble opinion, than those on the Sharp devices.

A word about word processors

By now I was in contact with Keith at Emojipedia, who mentioned that he remembered a Sharp device with emoji, a word processor. I found one in the Sharp WD-A521, from November 1990, which featured higher resolution versions of the emoji designs found on my Sharp PI-4000.

There’s also the Panasonic FW-U1S50 from 1990, which contains 110 famiiar emoji under a section called “illustrations”, and also contains another 99 “audio/visual” symbols some of which coincide with modern emoji.

Perhaps there are other word processors from around that time that also contain emoji? I understand from my friend Izumi Okano that Japanese software developer Enzan-Hoshigumi, most famous for their Macintosh software and clipart, had created pictograms for one of the Canoword word processors around 1986. So at this point I’m thinking, why would the emoji on a word processor be ignored on the timeline of emoji history? Was there anything else being ignored?

Before cell phones became prevalent there were pagers, or beepers, in Japan these were known as Pocket Bell. Initially they would only beep and show a number, and people would use “beeper slang” to form words by using numbers whose pronunciation was similar to words and syllables. Necessity is the mother of invention! Eventually pagers would be able to send and receive text. It was perhaps only natural that emoji find a home on these devices, with the most notable being the heart ❤️ emoji. But the date of this transition is 1995, which is earlier than the SoftBank emoji from 1997 but later than my Sharp PI-4000 device.

A note about beepers

As an aside, it’s interesting to understand how emoji were typed on pagers/beepers. They weren’t selected using a picker, which would have required cycling through a huge range of characters, but rather typed in numeric digits which narrows the cycling down to far less characters.

The numeric code: 21 91 15 24 12 23 78
…would map to: カラオケイク？
…which means: KARAOKE?

Wild. Typing text this way must have felt like programming machine code directly in hexadecimal!

What makes it emoji?

I was chatting to a fellow designer, who has designed many emoji in his career, discussing the earlier emoji I had found in my 1994 device. They asked me to confirm that I could type emoji inline with text, giving me the example W😲W, which was his criteria for the symbols to qualify as emoji. If I couldn’t do that, he suggested we could only consider the symbols as icons.

So if I can type them inline amongst text on my device from 1994 that was capable of connecting to other devices and sending messages, then surely they should be considered the first emoji? Why do we, currently, only count emoji as emoji if they’re on a mobile phone? I’m also wondering when these emoji might have been designed. Were they created in 1994 for the PI-4000, in 1993 for the PI-3000, or earlier for another device?

1988

So I kept looking. I was aware of another line of Sharp devices, electronic organisers, known as the Bware range in Japan and Wizard in the USA. These were pretty popular at the time, so much so that the USA device even got it’s own episode of Seinfeld in 1998. I’d come back into contact with these devices just last year as they had the interesting capability of being able to play video games stored on solid-state application “IC” cards. You can play a version of Tetris by BPS that is quite different to the Game Boy version, and both were released in 1989. You can also play versions of Sokoban by Thinking Rabbit, and Fortress by SSI/Victor, amongst others.

Thanks to a collector, Akuji, I was able to confirm that the Japanese PA-8500 device, released in 1988, contains emoji² similar in design to those found on my PI-4000 and on the WD-A521. When redrawing these it was obvious that all the Sharp emoji sets are based on the same master design. (I’d love to know more about the Sharp artwork if anybody knows anything.)

And if you need to see the word 絵文字 (emoji) next to these symbols to be satisfied, then look no further than this table column header in the manual of 1988’s Toshiba Rupo JW95F word processor.

How old is an emoji?

At this point we’ve wiped almost a decade off the creation date of emoji, but can we go further? Is there a way to date a set of emoji? In Japanese 絵文字 means emoji — and it turns out that word has its own surprisingly long history, which I’ll come back to at the end of this post.

If we think about the PA line of devices, the PA-8500 was released in 1988, and it’s predecessor the (emoji-less) PA-7000 was released in 1987. So maybe the emoji set was created around this time? We can get closer by looking at a couple of characters present in the emoji that give us a clue to the date of creation. That is indeed the case with the Sharp PI-4000 and WD-A521.

The characters ○金 and ○ビ (maru-kin meaning rich/successful/winner and maru-bi meaning poor/unsuccessful/loser) were invented by the author Kazuhiro Watanabe in 1984 in his book Kinkonkan which was later made into a movie. These were quickly accepted into Japanese vocabulary, winning the 84年の日本流行語 (Japanese Buzzwords Award 1984). And they are right there in the Sharp PI-4000 emoji, represented as characters enclosed in circles. They were in common use throughout Japan’s bubble-era, 1986-1991, but eventually fell out of fashion and are now considered obsolete. It’s interesting to note that they are not featured in either the 1997 SoftBank or 1999 NTT DoCoMo emoji sets.

1986

Around the same time, the day after I published this post, I did a Twitter search and found an image of the November 1987 issue of ラジオの製作 (“Radio Production”) magazine, which featured a full page on a Sanyo SANWORD personal word processor and its emoji table. That sent me hunting for Sanyo manuals.

The earliest I tracked down was the Sanyo SWP-M21 “Sanword mini S”, a budget personal word processor from 1986. It has the usual cast — smiley face, snowman, fleur-de-lis, pointing finger, weather symbols, faces, hand gestures — but the genuinely fun bit is its 外字 editor. Sanyo let users design up to 94 of their own 24×24 dot characters and save them out to floppy. Build-your-own-emoji on a 1986 home appliance. 🎨

The manual shows off the kinds of things you could make: a cat, a turtle, a mushroom, an elephant, a ship, a hand making a peace sign, a heart with an arrow through it, an orca. The accompanying copy brags 「とてもワープロとは思えないような、ユニークな印刷を楽しむことができます」 — “you can enjoy unique printing you’d hardly think a word processor could do.”

Somewhere out there, there were Japanese homes in the late 80s with floppy disks full of personal pictographic vocabulary — family crests, drawings of pets, in-joke symbols between friends. Almost all of those floppies are presumably long gone now. If anyone has one in a drawer, I’d love to see it. 💾

1984

Once you accept that emoji existed in the 1980s, more things come to light. The Ishii Award 「石井賞創作タイプフェイスコンテスト」 was a typeface design contest organised by the community of type designers in 1970. By 1984 it was in its 8th year. Yutaka Satoh of Type-Labo proposed a typeface consisting of emoji. Because they weren’t on screen they were created by arranging dots in various shapes, but they are recognisably emoji.

Coincidentally, I used a hybrid of this sort of approach when I added emoji to my game YOYOZO in September 2023: I plot the emoji as points but define them on a pixel grid.

In Matt Alt’s book “The Secret Lives of Emoji: How Emoticons Conquered the World”, there is a brief mention of ASCII emoticons on the Japanese internet (JUNET) in 1984, and then it fast forwards to 1995 to begin talking about the Pager, missing a decade of emoji usage in the process.

In the Yakumono typeface, created by Yutaka Satoh (TYPE-LABO), we can clearly see many of the key emoji that would persist throughout the years: smiley faces, food, drink, cigarettes, sweat, umbrella, paperclip, lips, envelope, and most interestingly the (not smiling) pile of poo. This typeface received an honourable mention at the awards. Some 40 years later, I think it’s safe to say it deserved more. 🏆

1979

We can see emoji in the character sets of Japanese home computers such as the Sharp MZ-80K, which included a UFO, smiley faces, stick figures, car, snake, and more. I won’t include them here but you can click the above link to see some in a PDF. 💾

1965

“Full Moon With Face”, also known as BA-90 which was listed in a book of typesetting symbols, published by Sha-ken in 1965. A smiling moon is still present in the emoji set today. 🌝

1959

CO-59 is a character set created in 1959 for exchange of data between Japanese newspapers. In it is included a symbol of a baseball, which again is still present in emoji ⚾️ and at Unicode codepoint U+26BE ⚾︎ today.

Comparing Emoji

I was interested in how the emoji that I have redrawn compared to the 1997 SoftBank and 1999 DoCoMo sets, and an early Pocket Bell, so here’s a little table.

	Sharp PA-8500	NEC PI-ET1	Sharp PI-4000	Pocket Bell R-FAHC	SoftBank	NTT DoCoMo
Year	1988	1990	1994	1995	1997	1999
Quantity (approx)	100	130	170	7	90	176
Resolution	16×16	16×16	12×12	5×7	12×12	12×12

A word about the word

A side discovery: the word 絵文字 (emoji) itself has a much longer paper trail. The earliest citation I’ve found is Kenkyūsha’s New Japanese-English Dictionary, 1954—the standard postwar bilingual reference. It defines:

A settled dictionary headword forty-five years before DoCoMo. “Pictorial symbol” is the second listed sense — more central, by lexicographers’ ordering convention, than “hieroglyphics.”

The word kept showing up in places I wasn’t expecting:

1975: A Sony catalogue describes its ETV-4010 school AV mixing console as having 「パネル面の絵文字、色分け表示」 — “emoji on the panel face, colour-coded indicators”. The 絵文字 are the small pictographic labels on the control panel. Same functional concept as digital emoji, applied to industrial hardware, twenty-four years before i-mode.
1984: The graphic designer Kuwayama Yasaburō publishes a 431-page reference book titled simply 『世界の絵文字』 (Sekai no Emoji / “Emoji of the World”) on global logos, pictograms, and trademark design, spanning the years 1970–1983.
1984: ASCII magazine reviews the Canon PW-10 word processor in its August news section, noting that “各種記号、絵文字をワンタッチで表示することができる” — “various symbols and emoji can be displayed at the touch of a button”. Here are some great photos thanks to Marcin Wichary.
1985: MSX Magazine’s MSX 豆辞典 pocket dictionary supplement, distributed via Japan National Railways station kiosks, uses 絵文字 as the umbrella term in its entry for アイコン (icon), and gently complains that American influence has wrongly promoted “icon” into the same umbrella role.
1988: Toshiba’s Rupo JW95F word processor manual uses 絵文字 as a column header in its emoji-input reference table, no gloss whatsoever — the most casual possible use of a technical term.
1993: Nojima Hisao publishes “絵文字の心理的効果” (“Psychological Effects of Emoji”) in the intellectual monthly 現代のエスプリ. By January 1994 it was being cited internationally in the Pacific Telecommunications Council conference proceedings in Honolulu.

What DoCoMo’s 1999 set did was become the international reference point — which is why English borrowed 絵文字 as “emoji” rather than Sharp’s or Toshiba’s or Sanyo’s much earlier sets. The word’s invention is fiction. Its globalisation via DoCoMo is real, but only in English. 🌍

Conclusion

So what does this all mean? I’d say mostly that the history emoji isn’t as clean cut as you might have thought. You can decide for yourself on what you consider to be the first emoji. It depends on our own personal definition, so there is no right or wrong answer. 😎

Personally, I define the start date of emoji as the point in time when sets of these symbols first appeared for use whilst composing text. I don’t think the timeline should start at mobile phones, as this feels like a somewhat arbitrary decision that dismisses a lot of history. It’s like saying music only began to exist from the moment it could be recorded and listened to without the actual muscians being present. 🤔

As to whether the timeline of emoji history will be rewritten with this knowledge, it’s difficult to say. Much of this falls in the grey area of happening around the time the internet was taking hold, plus most things about the origin of emoji are in Japanese language, so there are unlikely to be sources Wikipedia would consider verifiable enough. The best we could do is quote the pages of the manuals for devices, and for the rest hope that there’s some record in Japanese literature that could be cited.

I won’t be running the Wikipedia editing gauntlet, but if you do please let me know how it goes! 🧨

Terms of use

I painstakingly recreated the emoji sets on this page, pixel by pixel, over many days of hard work. I even went so far as adding a new tool to the pixel art app I use, so as to make the task of redrawing hundreds of emoji a little less daunting. Feel free to utilize the emoji images, just remember to credit @gingerbeardman and include a link to this page. With one exception: I object to the use of these images for the purpose of creating NFTs. Thanks for your understanding!

Printed citations

NEC Electronic Tool PI-ET1, Instruction Manual, p.131, システム外字数 (“Non System Kanji”) ↩
Sharp Electronic Notebook PA-8500, Operating Instructions, p.201, 記号一覧表 (“Symbol List”) ↩

Barbara Nessim at The Ginza Art Space (1986)

by Matt Sephton — Thu, 15 Feb 2024 23:22:00 +0000

At the end of 2023 I bought a one-in-a-million find from Japan: it’s a postcard from Barbara Nessim’s residency at The Ginza Art Space, September 26 thru October 19 1986. This residency came on the back of her breakthrough early computer art that was done on a Telidon system, a type of Teletext graphics system that displayed rudimentary vector graphics.

The postcard artwork is not digital and is dated 6-86. The details on the rear are set in the Chicago typeface designed by Susan Kare for the Apple Macintosh just a couple of years prior.

As well as Barbara’s residency there was an accompanying exhibition “The Work of Barbara Nessim”.

Made in Japan

During her time at The Ginza Art Space, Barbara used an NEC PC-100 to draw new work and printed them on one of the earliest wide-format colour inkjet printers, the Fujix JetGraphy 3000 (I’d love to be able to read this article at ResearchGate). Given the use of early technology and non-archival inks, the prints are prone to fading and are now very fragile.

The choice of PC-100 computer is interesting because its display could be rotated between portrait and landscape. In portrait orientation it had a resolution of 512×720, which is seven times more pixels than the Telidon system and twice as tall as the Macintosh Plus. The PC-100 displayed bitmap graphics so it was more similar to the Macintosh than the vector graphics of the Telidon system.

Colours were limited: the PC-100 hardware could display 16 colours from a palette of 512. The printer used CMYK and could produce around 10,000 colours, some of which printed better than others. This combination may have imposed some limitations as to which colours could, or should, be used.

Below are three examples of the work Barbara produced at The Ginza Art Space: they are Flowers in the Wind, Hand Memory, and The Gift. A description of the creative process is featured in Carol Olsen Day’s article “The Art of Barbara Nessim”, in the October 1988 issue of PC Computing.

What software?

My ongoing research into early Japanese pixel art software shows that Barbara most likely used ASCII’s エアーブラシ “Airbrush” painting software on the NEC PC-100, as it is the only graphics software for that platform I’ve been able to find advertised for sale or featured in period literature.

JINZO Paint: vintage mobile drawing app

by Matt Sephton — Mon, 22 Jan 2024 20:53:00 +0000

At my core I’m a software guy. I don’t really get attached to hardware: in my mind it exists only as a conduit to software. I use emulation whenever I can to benefit from the increased convenience and reliability. But when I can’t… I buy old devices, and with old devices come old problems.

I’m fascinated by vintage digital art software, from my beginnings on Atari ST, though classic Macintosh and vintage Japanese PCs, to handhelds like Palm devices or, in this case, a PocketPC running Windows CE. As with all software, many great ideas have been abandoned in the name of “progress”.

Zen and the Art of Software Design

Japanese art software is notable in a number of ways because their drawing tools evolved differently to those in the West, at least until Photoshop took hold. In Japan the first breakthrough digital art software was the PC-98’s Multi Paint System (MPS, マルチペイントシステム) released by C-Lab in 1992, though an earlier version was released in 1991 as Maguro Paint System, or Tuna Paint System (鮪ペイントシステム) both of which were programmed by Woody_RINN.

MPS introduced the ability to lock colours and prevent them from being drawn over. You might think of it as a mask featuring every instance of that particular colour. You could also replace colours in a similar way. This was done through an intuitive mechanism of a toolbar button or key press to lock one or more specific colours on the palette, which is quite different to the selection or mask approaches popularised by Photoshop and common today.

Regardless of whether or not the method of handling colours in MPS is novel or unique, it was adopted as a standard by most Japanese art software for many years. JINZO Paint (JZP), a digital art app for PocketPC (Windows CE) created by t-ueno (Tomohiro Ueno), was one such app that adopted the MPS way of doing things and I’ve been using it a bunch recently. It offers first class support for drawing in dither patterns, and you can load in custom patterns. If you like HyperCard, NewtPaint, TealPaint, you’ll love it. Jinzo is the Japanese word for kidney, which is also the icon of the app.

If you’re interested in reading about the interface and functions of JINZO Paint I’ve mirrored the manuals for two early versions on my website as the original location is no longer available. A later version supports full 24-bit colour, but removes some useful functions. Regardless, all versions use a similar interface so they’re easy to use once you’re familiar with the general operation. One thing I would say is that the toolbars can be opened and selected with a single tap-drag-release action, which a huge win for usability and one that reminds me of the original Apple Macintosh and Palm OS. If you’re lucky your operating system today will support such fluidity.

For my next trick I will run it on a Dictionary

My Windows CE device is a bit odd because it’s a Brain. These are a range of electronic dictionaries made by Sharp and sold only in Japan. With a bit of gentle coaxing it can be used as a little computer running Windows CE. My particular model is the PW-SH1 which is a 3rd generation device with a high resolution screen whose hinge can rotate 360° so it’s back-to-back against the keyboard, effectively becoming a tablet computer. Some years ago it was figured out that you could sideload apps and even force these devices to open the Windows CE desktop and do all manner of crazy things. Japanese hackers and modders seem to love using these devices to run emulators for old computers like Sharp MZ-series and NEC PC-series. If you want to know more check out the Brain Wiki and if you want to pick up a device here’s a list of them all (browser translation required for those links).

A problem with file selection

Anyway, I noticed whilst using JZP that the file selector would often fail to open properly. It worked the first time but subsequent attempts saw it open and then immediately vanish. The source code to the first two versions is available, and with the help of Brain Hackers’ @watamario15 the reason for the problem was traced. He found that the value of the parameter being passed to the file selector was invalid, and provided proof by modifying the source code to those versions resulting in new working binaries. But with the final full-colour version has no source code, so how do we fix that?

Multiple solutions

The binaries for my device are ARM so there’s good support for debugging that type of code. I fired up Ghidra and started poking around in the earliest, smallest version of JZP. I quickly found the section of code that defined the parameters, helped by the placement of the setup of the strings used in the file selector. A quick tutorial later and I knew how to use Ghidra to find references to data, patch instructions, and save a new binary. The workaround was to set the parameter to NULL, which works nicely but removes the ability for the app to remember the most recently used directory.

However the source is available for the two earlier versions, which I prefer using, so more complete changes could be implemented. Rather than simply nulling out the parameter we could set it to the correct initial value: the root directory. Additional changes were needed to make sure the program would cope with saving and loading from the root directory of the device directly. And finally, just for good measure, the 16-colour version’s extremely slow bitmap saving has been optimised!

Many thanks to @watamario15 for his invaluable help with debugging and his generous source code wrangling. And to Brain Wiki for being such a valuable resource for crazy old software nerds like me!

Keyboard controls

I’ve also added keyboard control to JINZO Paint 16, with standard Photoshop keys to switch tools, plus keys for undo, set zoom, quick zoom (hold space bar), and more. If I get permission from the original author I’ll release a patch.

Repo

My changes to the 16-color version are now available at the BRAIN hackers GitHub:

github.com/brain-hackers/jinzo-paint/tree/16-color

Easter egg emoji: converting pixels into particles

by Matt Sephton — Sun, 26 Nov 2023 20:41:00 +0000

I’m fascinated with Moai so I always try to squeeze an appearance into my games. Moai in video games is a meme, or easter egg, going all the way back to 1983. But my game YOYOZO (out now for the Playdate handheld) is about capturing stars in space using a yoyo, so how could I get a Moai in it?

The source of my inspiration was a trip to Japan back in 2004 (my only one, so far). Visiting in August meant that one of the things we did was go to an annual hanabi fireworks festival, where I saw katamono for the first time. These are fireworks that explode in the shapes of drawings, like a smiley face or a magic 8-ball. I was amazed and the experience has stuck with me for over 20 years. Maybe I could add Moai into YOYOZO by making the explosions appear like the katamono?

I started off by coding the patterns by hand, as a test, but my calculations weren’t precise enough and the whole endeavour quickly grew too complicated to manage by hand. I needed a better, more automated way. The method that I arrived at is what I’ll document in this post.

Pixels as code

Instead of plotting values by hand in code I figured that it would make more sense if I could draw the patterns and then somehow convert them into coordinates. I use Piskel as my Playdate-centric graphics editor. It’s a really useful tool. So I drew a few emoji-like patterns, keeping in mind that they would be converted into a cluster of points and exploded from an origin. This took a bit of experimentation but I ended up with a sort of already exploded look.

To get the pixel data out of Piskel in text form I make use of its “export as a C file” feature. This results in code definitions similar to the below. (I use a script that does some simple regex search/replace to reformat these definitions to be a little more succinct and readable in my Lua code.)

#include <stdint.h>

#define EMOJI-TABLE-11-11_FRAME_COUNT 3
#define EMOJI-TABLE-11-11_FRAME_WIDTH 11
#define EMOJI-TABLE-11-11_FRAME_HEIGHT 11

/* Piskel data for "emoji-table-11-11" */

static const uint32_t emoji-table-11-11_data[3][121] = {
{
0x00, 0x00, 0x00, 0x00, 0xff, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0x00, 0x00, 
0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0x00, 
0x00, 0x00, 0x00, 0x00, 0xff, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 
0xff, 0x00, 0x00, 0x00, 0xff, 0x00, 0xff, 0x00, 0x00, 0x00, 0xff, 
0x00, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0x00, 0x00, 
0xff, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0x00, 0xff, 
0x00, 0x00, 0x00, 0xff, 0x00, 0x00, 0x00, 0xff, 0x00, 0x00, 0x00, 
0x00, 0xff, 0x00, 0x00, 0xff, 0xff, 0xff, 0x00, 0x00, 0xff, 0x00, 
0x00, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0xff, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00
},
...

Pixels as points

With this data in hand, my plan was to convert them into points expressed as an angle and distance from an origin. This way of expressing points is the polar coordinate system so there was no need to invent anything, I just needed to code a function that would take a grid of pixels expressed as (x, y) and convert them to a series of distances and angles expressed as (r, θ).

The way I do this is to read the point data in from a grid of pixels, offsetting that data by half the width and height of the odd-sized grid so that the centre of the grid (0, 0) is the middle of the centre pixel. And finally I convert those adjusted (x, y) values to polar (r, θ) coordinates. This worked really well!

Below is a work-in-progress GIF captured on 14 September 2023, shortly after getting the feature working. This animation also shows an early version of the HUD and debug values for ball size and the length of the beam.

The finishing touches (not shown in the above animation) were to add some small amount of pseudo-randomisation to the initial rotation of the emoji, the initial “colour” of each particle, and changing the coordinates of each point slightly so they appear more organic and move at slightly different speeds. I eventually settled on over a dozen such pixel patterns in the game (how many have you spotted?). Once your score is higher than 50M points every explosion is an emoji! Check out the game manual.

Pseudo-random?

I try to limit my use math.random values if I can help it, or at least use it in controlled way. I already use that for the positions of the stars, so if I also used it for explosions that would mean it would become far less controlled. Controlling the use of random is important in making a game system deterministic, if you want it to react the same way every time.

If you’re wondering how you can get pseudo-random values, the main method I use is a trick I learned from the old arcade game Flicky (1984, SEGA) which is a game I own as a physical cabinet. Anyway, in Flicky there is a diamond that appears under seemingly random conditions.

One of the MAME programmers was kind enough reverse engineer Flicky on my behalf and figured out what makes the diamond appear. It turns out the diamond will appear only if you knock out an enemy cat and it disappears outside of the centre third of the play area and if the x coordinate at which the cat finally comes to rest is even. So, about 50% chance but only if you position the screen correctly during play.

So, taking a cue from that wonderful Flicky logic, I use modulus—which returns the remainder of a division—as my main mechanism of generating pseudo-random values. It ensures a value in the range [0,n-1]. They key thing to note is that if you base it on values in your game system that are constantly changing you can get seemingly random values that have the benefit of being deterministic if the player is skilled enough at repeating their inputs. The deterministic thing is how pretty much all the old school arcade games operated from Pac-Man to Flicky and more.

Common game variables I use are: game tick (my alternative to timer), x-coordinate, y-coordinate, speed, angle, or combinations of more than one of these. I also used this approach in YOYOZO for the starfield particles, and in Sparrow Solitaire for the falling particles that make up the weather effects.

Playdate particles

There are one or more libraries available that can be used to manage particles in a performant way on Playdate. Though I tend to code my own system that is bespoke to the game I’m working on at the time (I start each game from a blank file and use minimal libraries, force of habit). But the important thing for such limited platforms, especially when using Lua, is to use a pool of particles so that you’re not constantly creating and destroying particles which would wreak havoc on performance through overuse of Lua’a garbage collector.

YOYOZO (or, how I made a Playdate game in 39KB)

by Matt Sephton — Tue, 21 Nov 2023 23:59:00 +0000

2023-12-27—Ars Technica: YOYOZO wins GOTY accolade! almost unbelievable to be listed alongside such games as: Chants of Sennaar, Cocoon, Dave the Diver, Humanity, The Legend of Zelda: Tears of the Kingdom, Pikmin 4, Puzzmo, Super Mario Bros. Wonder, Venba and Viewfinder.

A game I made for the Playdate handheld was released today! Go buy it and then come back to read this blog post.

It’s called YOYOZO and in it you control a space yo-yo and have to collect stars in a sort of cosmic ballet. Well, at first it might feel a little like being on a fairground ride, but eventually you’ll become good enough for it to feel like ballet. The concept is based on my memory of a game called Pendulumania that I played 20 years ago.

The most amazing thing about this game, for me, is that launch version weighs in at a file size of only 39KiB. I’m using the KiB unit of measurement which equates to 1024 bytes. I still find it hard to believe as the game contains so much! In this blog post I’ll go into some of the nerdy details.

Playdate?

Playdate is a handheld gaming system with a unique crank input method. I don’t use the crank in this game, but I have done in the past and will do again in the future.

If you own a Playdate you can buy the game now at play.date/games/yoyozo/. If you don’t own a Playdate, well, what are you waiting for?

But…why?

The drive to produce a small game started after I sent the first playable version to testers. Steve at Scenic Route Software, purveyor of quality video games, commented how tiny the game was. At that point it was 18KiB, but had no music or sound effects or polish. There was a long way to go.

Even so, I wondered how doable it would be to build the game out with an eye on keeping file size “low”. I thought back to the days of my youth where whole games would fit on a single floppy disk, with room to spare. If they could do it, shouldn’t I give it a try?

It’s worth noting that even with this mindset, I didn’t make a huge sustained effort to meet the goal. On the contrary, it was just something I simply kept in mind as development proceeded. For that reason, I’m sure there are more ways the game could be made even smaller than it is, with the exact same code and content. For example, I never tried finding the most optimal format for things like music and particle data which are the two largest sets of embedded data.

Finally, this is not a challenge, or me throwing down the gauntlet in any way. It’s easy enough to make a smaller game, be it similar or entirely different, you’d just have to make different choices along the way. This was just me doing something nerdy as an additional constraint on top of the already enjoyable constraints of developing for Playdate.

That said, I think every game developer should regularly make a point of writing code for an underpowered device as part of their own personal development—there are so many lessons to learn.

Reasons

The main reason for the small file size is the fact that the game does not use any digital sound files, and very few bitmap images (the launch card and animation have to be bitmaps, and in-game only the logo and fonts are bitmaps). Game graphics are all drawn using only shapes (lines, rects, circles) and fills (black, white, and dither patterns).
A second reason is that whilst I use the base Playdate Lua SDK, I don’t use any of the additional “CoreLibs”. The only extra graphics functions I needed were for drawing outlined or filled circles, so I use two of my own wrapper functions that are similar to those from CoreLibs/graphics but mine are smaller and more specific. For timers, I use a simple frame/tick system, an approach which has pros and cons, but it’s good enough for me.
A third reason is that I made the tough decision to reduce system assets, which means there is no animated launcher card. This was a tough one, but it added so much to the file size I decided against it.
Finally, I noticed that including data inside your game code often trumps how well you can compress it and store it externally. For example I tried compressing the music data and storing it in an external file, but the game final file size was larger than if I embedded the data in my Lua code. Plus, it’s faster as it doesn’t need to load an additional external file.

Breakdown

I thought it would be cool to outline the main features and how each contributes to the total file size. Note that the sizes are expressed as quantities of the compiled binary, rather than uncompiled source code. It’s also worth noting that a blank project with an empty update function results in a compiled binary of only 147 bytes. Playdate compiles to Lua bytecode.

Content	Kilobytes	%
Main code	19	49
Two music tracks	5.5	14
Three bitmap fonts	2.5	6
Synthesized sound effects	2.5	6
Custom particle system	2.0	5
Animated system icon	2.0	5
Animated system card	2.0	5
Pulp music engine (modified)	1.5	4
Online scoring system	0.5	1.25
How to play instructions	0.4	1
Custom soundtrack capability	0.1	0.25

“Main code” contains: physics simulation, game structure and state management, multi-layered scoring and bonus system, score/stat tracking, loading and saving stats and settings, path recording and playback, animated introduction, plus the following dynamic systems: scrolling starfield, screen shake, music system, sound effects system. All running at 40fps.

Abandoned and removed features

I tried a bunch of stuff during development. Such as asteroid fields or meteor showers that introduced obstacles that needed to be avoided, and black holes that would magnetically attract the ball. But I felt they detracted from the pureness of the concept, so I didn’t go any further with them.
The positions of stars are randomly generated, but I have implemented a fixed “daily” layout in the game, which is really fun. It’s a different experience to be able to play the same layout over and over, improving your execution of the same moves and eking out higher and higher scores. I did plan to reintroduce that option when Playdate Catalog got score boards that reset daily, but by the time that happened I was no longer developing Playdate.

Manual/Guide

I really loved the manuals that came with games in the 8-bit and 16-bit era. So I thought it would be fun to write a manual/player’s guide in the old-school style. I love reading those sorts of manuals, where the developer gives you a little glimpse behind the curtain so you get an understanding of how the game works, with some small hints and tips littered throughout—for the most inquisitive players! If that sounds like your thing, download the manual from the game page.

Timeline

I worked on YOYOZO from September 5th to 27th, submitting it to Catalog on 21st and polishing it for the final week after that. After the game was approved I added online score boards one evening just prior to launch. It was in review and waiting for release longer than it was in development!

The purpose of this section is not to say that developing a game quickly is better than developing one slowly, or vice versa, but rather to show the importance of scoping a game well and then sticking to the plan.

2023-09-05—initial prototype
2023-09-07—playable prototype (3 days)
2023-09-07—quick progress (3 days)
2023-09-09—came up with the name (5 days)
2023-09-14—polishing and balancing (10 days)
2023-09-20—revelatory physics tweak (16 days)
2023-09-21—addicted to my own game (17 days)
2023-09-21—submitted to Catalog (17 days)
2023-09-23—game over replay (19 days)
2023-09-26—layout design using spreadsheet (22 days)
2023-09-26—game over stats screen (22 days)
2023-09-27—final version (23 days)

…and then some waiting until:

2023-10-10—approved for Catalog (36 days)
2023-11-19—added online scoreboards (76 days)
2023-11-21—released on Catalog (78 days)

…so that is 78 days (11 weeks) from initial prototype to being live on the Catalog store!

Credits

YOYOZO is a game by Matt Sephton, with music by Jamie Hamshere.

Thanks to CANO-Lab and Testers.

Elsewhere

2024-10-16—Game Republic 2024 Awards: Best Indie Game Made in the North of England
2024-03-08—Playdate Community Awards 2023: Best Arcade Game
2023-12-27—Ars Technica: YOYOZO wins GOTY accolade!
2023-11-30—Ars Technica
2023-11-24—Hacker Newsletter
2023-11-23—Time Extension
2023-11-22—Hacker News
2023-11-22—Tildes

Early computer art by Barbara Nessim (1984)

by Matt Sephton — Thu, 09 Nov 2023 01:25:00 +0000

Whilst searching for something else entirely I stumbled across these images and was struck by just how beautiful they are. The September 1984 (Vol 9, No 10) issue of BYTE magazine features cover artwork by Barbara Nessim and section pages by Liz Gutowski under direction of Barbara Nessim. Larger versions are at the bottom of this blog post.

They were drawn during a residency at Time Life in NYC, simply because that was the easiest way Barbara could gain access to a colour computer with suitable capabilities: a Norpak IPS-2 Videotex (NAPLPS/Telidon) system. This offered 6 drawing modes (arc, rectangle, circle, line, dot and polygon) and 12 colours, of which half where shades of grey, plus black and white. And at a resolution of 256x200. That equates to a computer system roughly equivalent to an Apple II running a rudimentary graphics application, in fact you could get an add-on card for the Apple II to give it full Norpak Telidon capabilities. The main benefit of the Norpak IPS-2 computer system was that it had pen/stylus input. The system comprised two monitors, one showed the artwork and the other showed the software status menu system. The software was controlled by keyboard and the points that specify the shapes were entered using the pen input.

My first thought was “such cool pixel art!” but a little bit more reading shows that they are actually vector illustrations. NAPLPS is an early graphics format which could represent both text and vector graphics with all coordinates and other properties—such as size, fill pattern, density—encoded as ASCII for easy transmission. It was designed to display information on TVs, and also used for display on terminals, in BBS software, and on the Prodigy online service. Readers from around the world might be more familiar with Teletext, which is a close relative of Videotex.

Doing pure illustration using a system meant for creating pages of information is exactly the type of software subversion I love to discover!

Barbara Nessim is a name I was already familiar with, as I’d seen her mentioned and interviewed in Verbum magazine, COMPUTE magazine, in various books about illustration, and regarding her groundbreaking interactive art exhibition/installation Random Access Memories (1991/2)—which addressed world issues such as migration and population growth and allowed visitors to operate a Macintosh containing the work, selecting images and printing their own customised booklet of her work with their choice of national flag on the cover. Source 1 and 2

Whilst I had seen other early computer work by Barbara—portraits, nudes, abstract (all of which are worth checking out!)—I had never seen work quite like these images from BYTE.

The chunky scan-line gaps in between the rows of pixels are the result of these images being photographs of the monitor on which they were displayed. Screenshots had existed since the 1960s but in the 1980s getting such an image off a mainframe was not yet easy or universal. Instead images were saved by pointing a camera at the screen, in this case a Polaroid Palette Video Image Recorder, capturing the image on 35mm slide film, and printing them by cibachrome process. Which is really saying something! Of course, I think the photos are much better than screenshots because of the scan-lines, the phosphor glow, the bleeding of colours, and the general analog feel to the whole thing.

Barbara was one of few people to embrace computers for art in the early-1980s, when the rest of the art world considered them at best a “fad” and at worst a threat to their existence. The dismissal was near-total: she couldn’t persuade a single one of her artist friends to come and try the computer with her, and was left wondering whether she was the only one who wanted to. That attitude held for around a decade. It wasn’t until the mid-1990s—when affordable colour arrived and Photoshop went mainstream—that the resistance finally broke and, as Barbara puts it, “that’s when the change happened, and then it was all over”. Before and after the 1980s Barbara carved out a hugely successful career for herself, encompassing many different forms of art, teaching and activism. She continues to create and exhibit her art.

Scans

List of vintage Japanese pixel/dot art software

by Matt Sephton — Sat, 21 Oct 2023 15:56:00 +0000

For a while now I’ve been collecting references to old Japanese pixel/dot art software. My main sources of information are the treasure trove of scanned magazines on Internet Archive, Twitter archives, YouTube videos, Yahoo! Japan Auctions listings, and Google search. I’ve been keeping this list for a while, and the release of 16bit Sensation: Another Layer and its inclusion of Multi Paint System made me realise I should make the list public.

A long term goal would be to find files for each of these so they can be actively used and documented more fully. Most have them can be found in archives of preserved software, with clues in the spreadsheet below, and you can try them using emulation or Virtual Machines.

Selected columns from the big list

The table below is a snapshot of selected columns of a Google Sheet that I’m updating over time. The full spreadsheet contains links to downloads, videos, web pages, magazine mentions, and many other references. So be sure to check, bookmark or subscribe to that link for the very latest information. Since January 2024 I’ve been adding some non-Japanese software that was “big in Japan”.

Regarding the empty cells: software missing a Japanese name was mostly referred to only by an English title. The rest of the missing information is TBC.

ドット絵（ドットえ）作成に使えるビンテージ日本語ソフトの一覧です。

Total entries: 272

Platform	English	Japanese	Year	Developer
FM-7, X1	Art Creator		1984	MDBA
FM-7/8	Graphic Editor		1983	Hiroshi Ichikawa
FM-7/8	Super Graphic Editor	スーパーグラフィックエディター	1983	T&E SOFT
FM-77	FM Graphic Editor	FMグラフィックエディタⅡ V1.0	1986	Fujitsu
FM-R50/60	Z’s STAFF Kid FP		1988	Zeit
FM-R60/70	Z’s STAFF Kid FP		1990	Zeit
FM-Towns	ARTemis		1993	Ryosuke Matsuuchi
FM-Towns	DRAW BOARD2		1993	Souji Yamakawa
FM-Towns	G-Pen32K		1995	rice
FM-Towns	many COLORS		1993	Amorphous
FM-Towns	many COLORS II		1995	Amorphous
FM-Towns	Meta Paint 2	メタペイント2	1992	Oizumi Shigeru
FM-Towns	New Transfer	ニュートランスファー	1992	Hiroshi Toda
FM-Towns	Oops, anime-kun	おっとアニメ君	1989	Nihon Mi-Com Hanbai
FM-Towns	Otome / Towns Paint System	乙女座	1993	Yabara
FM-Towns	Power Paint	パワーペインター	1991	Wave Train
FM-Towns	Towns PAINT		1989	Fujitsu
FM-Towns	TownsFullcolor		1993	Fujitsu
FM-Towns	Z’s STAFF PRO-TOWNS		1991	Zeit
Mac OS X	DotEditerSE		2016	tokyoconsaruai
Mac OS X	DotShot X		2007	Studio Shin
Mac OS X	FireAlpaca		2011	FireAlpaca
Mac OS X	PikoPixel		2013	Twilight Edge Software
Mac OS X	PoCo		2005	KAENRYUU Koutoku
Macintosh	BluePaint		2001	Shungo Onozuka
Macintosh	DotShot		1998	Studio Shin
Macintosh	Leo paint		1997	Reona Takahashi
Macintosh	SketchBook 68K		2000	Shibutaro Kimura
Macintosh	Solid Paint		1996	Masatoshi Utashiro
Macintosh	WishDraw		1998	Motoo Tanaka
MPC-X	MPC-X Lightpen Graphics		1984	Sanyo
MSX	ACE-tools DRAW-SET		1997	Akio Hiramatsu
MSX	Animation editor EDDY	アニメエディタＥＤＤＹ	1984	HAL Laboratory
MSX	ANIMECHA Ver. 2.00		1995	MAR’Z PROJECT
MSX	Art Paper	アートペーパー	1986	Mitsubishi
MSX	CHEESE		1984	NEOS
MSX	CHEESE 2		1985	NEOS
MSX	Computer Painting	描きくけコン	1985	Casio
MSX	Creative Tool	クリエイティブツール	1989	HAL Laboratory
MSX	Da Vinci	ダ・ビンチ	1988	Shinkikakusha Corp
MSX	Dot Designers Club	ＤＤ倶楽部	1989	T&E SOFT
MSX	Dream Block	ドリームブロック	1989	Nikkoh Thinking
MSX	EDDY II	エディー	1984	HAL Laboratory
MSX	Gaban	がばん	1988	Micronet
MSX	Garakuta	画楽多	1988	Southern Create
MSX	Graph Saurus 1	グラフサウルス	1989	Bit²
MSX	Graph Saurus 2	グラフサウルスVer2.0	1991	Bit²
MSX	Graph Saurus 2.1	グラフサウルスVer2.1	1993	Bit²
MSX	Graphic Artist	グラフィックアーティスト	1985	YAMAHA
MSX	Graphic Editor	グラフィックエディター	1984	HAL Laboratory
MSX	Graphic Editor ANGLE	グラフィックエディタアングル	1985	Hiroshi Ichikawa
MSX	Graphic Editor XV	グラフィックエディター	1988	HAL Laboratory?
MSX	Graphic Master Lab	グラフィックマスターラボ	1985	HAL Laboratory
MSX	Graphic Studio Pro	カラー・グラフィック・エディター	1985	HAL Laboratory
MSX	Graphic Tool for screen 12	専用簡易グラフィックツール	1993	KNKKY
MSX	Illustration Word Processor	絵はがき用ワープロ	1985	Hitachi
MSX	Joy Graph	ジョイグラフ	1983	Victor
MSX	Kakikuke kon	かきくけこん	1985	Casio
MSX	Leonard	レオナルド	1987	Omega System
MSX	Leonard Plus Kanji	レオナルドプラス漢字	1987	Omega System
MSX	Lightpen Graphics	ライトペングラフィックス	1984	HAL Laboratory
MSX	MOKO		1986	Toshio Tabeta
MSX	MOKO II Improved Version	改良版 MOKO II	1987	Maeda Mameo
MSX	MSX’s TOOLS		1995	Hitori Circle
MSX	The Painter	ザ・ペインター	1986	YAMAHA
MSX	Tiny Joygraph		1985	Victor
MSX	Pattern Editor Robin	パターンエディターRobin	1985	Hirohumi Ino
MSX	Pixel 2	ピクセル２	1985	T&E SOFT
MSX	Pixel 3	ピクセル３	1988	T&E SOFT
MSX	(Graphic Editor) Sha Ga Raku	写・画・楽	1988	Victor
MSX	UniPaint	ユニペイント	1986	Matsushita
MSX	Video Graphics	ビデオグラフィックス	1986	Matsushita
MSX, WAVY	Light Pen Graphics	ライトペングラフィックス	1984	Sanyo
MZ-2500	G-EDIT2500	グラフィックエディタ2500	1987	Data West
MZ-2500	ILLUST BOX		1987	Rhodes
MZ-2500	Palette	ぱれっと	1987	Dynaware
MZ-2500	Quick MZ Paint		1987	Minoru Morinaka
MZ-2500	Super Paint		1987	S.B.C Software
Newton	HexPaint		1997	HexDump
Newton	NewtPaint		1995	Glen Raphael
OS/2	QueenCy		2000	masami
Palm	CLIE Paint		2001	Sony
Palm	MoePaint		2004	Toshiyuki Hayashi
Palm	PenPenCol		2001	Shigeyuki Seko
Palm	PenPenW		2005	Shigeyuki Seko
Palm	PixMarker		2001	wernyv
Palm	Sphere the PAINTER		2001	Katsunori Sakuragi
Palm	yapp		2000	Ines
PC-100	Airbrush	エアーブラシ	1984	ASCII
PC-6001	Picture Editor	ピクチャーエディタ	1983	ASCII
PC-88	Adventure Maker mk2	アドベンチャーツクールmkII	1987	T.Ueno
PC-88	ART MASTER 88		1985	SystemSoft
PC-88	da Vinci ~Super Graphic Tool~	ダヴィンチ	1985	POPCOM
PC-88	Emi	絵美	1990	MIINA
PC-88	HR-PAINT3		1990
PC-88	Ink Pot M		1987	H.Komatsu
PC-88	LALF ~Hyper Graphic Tool~		1989	Technopolis
PC-88	LUNA		1991	MEW
PC-88	Magic Paint 88 v2.0	マジックペイント88	1988	Atsushi Oshima
PC-88	Magic Paint 88 v3.0	マジックペイント88	1988	Atsushi Oshima
PC-88	Magic Paint 98	マジックペイント98	1990	Atsushi Oshima
PC-88	Magic Paint VA	マジックペイントVA	1988	Atsushi Oshima
PC-88	nedi3.bin		1987	TA(O)
PC-88	Super Artist 256		1989	Seed Software
PC-88	Yukara art	ユーカラart	1987	Tokai Create
PC-88	Z’s STAFF Kid VA		1987	Zeit
PC-88	Z’s STAFF Kid88		1987	Zeit
PC-88, X1	Ink Pot		1985	H.Komatsu
PC-98	256 Color Drawing Tool	256色お絵描きツール	1994
PC-98	6 Coloured Pencils	6色鉛筆	1993	tsutosan
PC-98	Actor98	アクター98	1990	Soft Studio Panther
PC-98	Adventure Maker 98	アドベンチャーツクール98	1992	ASCII/LOGiN
PC-98	Akane	あかね	1992	Miruhi Takahara
PC-98	Art Frontier	アートフロンティア	1991	Bijutech
PC-98	ArtCore (Art/V?)		1992	SystemSoft
PC-98	Assist Art	アシストアート	1991	Assist Co., Ltd.
PC-98	Ayako	彩子	1988	Art Function
PC-98	Camel	キャメル	?	Nazca Corporation
PC-98	CANDY		1984	ASCII
PC-98	CANDY2		1985	ASCII
PC-98	Character Maker 98	キャラクターツクール98	1994	Pegasus Japan
PC-98	Doodle Book / Rakugaki-chō	落書き帳	1993	Toshiya Hayashi
PC-98	DynaPix V	ダイナビックスV	1988	Dynaware
PC-98	ESQUISSE	電子水彩エスキース	1989	SAPIENCE
PC-98	Funny		1984	Zeit
PC-98	Garakuta98	画楽多98	1990	Southern Create
PC-98	GIOTTO		1986	Art Function
PC-98	GRAPHIC HENSHIN	ぐらひっくへんしん	1998	Taro Namae
PC-98	GREEN		1993	Yoshito Takemura
PC-98	GREM		1993	Yoshito Takemura
PC-98	Hyper Ayako	HYPER 彩子	1989	Art Function / Digital Arts
PC-98	JEDAI		1994	D.O. CORP
PC-98	Kureyon-chan	くれよんちゃん	1994	Fusao Saito
PC-98	Maguro/Tuna Paint System	鮪ペイントシステム	1991	Woody_RINN
PC-98	Mapping Paint	写像ペイント	1990	CAST
PC-98	Marupa	まるぱ	1993	Ichikawa Soft Labratory
PC-98	MEDI-98 / nedi3		1990	NOZUMU
PC-98	Monopen	ものぺん	1995	OEAO
PC-98	Multi Paint System / MPS	マルチペイントシステム	1992	C-Lab
PC-98	Paint System Tool / PST	似非キース	1990	hironon
PC-98	Paper	紙	?	Irem
PC-98	Penta-kun	ぺん太くん	1994	NEG
PC-98	Sadayan Paint	さだやんペイント	?	Irem
PC-98	SANDY		1994	Wataru Ishihara
PC-98	Small CANDY		1984	ASCII
PC-98	Super Tableau	スーパータブロー	1987	SAPIENCE
PC-98	Tableau		1987	SAPIENCE
PC-98	Tetsujin	鉄人	?	Irem
PC-98	TrueLine		1996	OEAO
PC-98	Z’s STAFF		1985	Zeit
PC-98	Z’s STAFF Kid		1986	Zeit
PC-98	Z’s STAFF Kid98		1988	Zeit
PC-98	Z’s STAFF Kid98 v3.0		1990	Zeit
PS-55	Z’s STAFF TRAD		1989	Zeit
SMC	Graphic Editor	グラフィックエディター	1984	Sony
TRON-OS	Pelistina		2005	KAENRYUU Koutoku
TRON-OS	Pelistina 2		2005	KAENRYUU Koutoku
TRON-OS	Sketchbook	楽描き帳	2011	Satoshi Sera
TRON-OS	Xbrush for Chokanji	Xbrush for 超漢字	2013	Akira Tasaki
Twin Famicom	Game Maker	ゲームメーカー	1989	HAL Laboratory
Windows 2K	4thPaint	よつばペイント	2007	4th Paint Project
Windows 2K	Let’s Draw F		2007	Oscar Creation
Windows 3.1	Daisy Art	デイジーアート	1995	Ichikawa Soft Labratory
Windows 3.1	Draw Unit		1994	Type-甲
Windows 3.1	GOINDRW		1996	Yasuhiro Nakata
Windows 3.1	ImgFinish		1996	Syouichi Hattori
Windows 3.1	Pattern Editor PE	パターンエディタ PE	1995	Windows 3.1
Windows 3.1	Sailing Draw++		1993	Jun Satomi
Windows 3.1	SUPER KiD		1994	Zeit
Windows 3.1	SUPER KiD v2.0		1995	Zeit
Windows 3.1	Tsuruniha○○mushi	つるニハ○○ムシ	1999	Mr Dad
Windows 7	EDGE2		2006	TAKABO SOFT
Windows 9x	1bitPaper		2004	shiden
Windows 9x	ArtistX		2001	ARINOKI
Windows 9x	ArtistX Labolt		2005	ARINOKI
Windows 9x	AZPainter		2006	Azel
Windows 9x	AZPainter2		2009	Azel
Windows 9x	Camel2	キャメル2	1995	Nazca Corporation
Windows 9x	D-Pixed		2000	Jun Doi
Windows 9x	DoggyPaint		2000	HKR.Jon
Windows 9x	Dot Art Kakiko	ドット絵カキコ	2000	YUUKI
Windows 9x	Dot Art Vacation	ドット絵バケーション	2002	Arue
Windows 9x	Dot Editor Ver 4.0	ドットエディタVer4.0	2000	PSIKYO
Windows 9x	Dot Pictureditor	ドット絵でぃた	2000	shishido
Windows 9x	DotPainterALFAR		2003	Herohero
Windows 9x	Easy Paint Tool SAI	ペイントツールSAI	2004	TANE/KOJI
Windows 9x	eco paint	エコペイント	2006	tyty
Windows 9x	EDGE		2000	TAKABO SOFT
Windows 9x	FARLUX	ファーラックス	1997	Studio BullTerrier
Windows 9x	FudeBoard		1998	matumoto
Windows 9x	Gpen96		1999	Hiroshi Igami
Windows 9x	GraphicsGale		2004	HUMANBALANCE
Windows 9x	HappyPaint32R		1997	Isao Maruoka
Windows 9x	Hyper KiD		2000	Fanfare
Windows 9x	Hyper-Paint		2004	kiriman
Windows 9x	iDraw		1996	hawk
Windows 9x	ILLUSTMAKER		2000	matumoto
Windows 9x	Janus		2007	Rigeru
Windows 9x	Kakukakuoji	かくかくおうじ	2000	1BITMANIA
Windows 9x	L-Paint		2001	via
Windows 9x	Let’s Draw		1996	Oscar Creation
Windows 9x	Let’s Draw Z		2003	Oscar Creation
Windows 9x	Light Painter		2000	Yoshi
Windows 9x	LitePaint		2000	Rigeru
Windows 9x	Matilda		2001	ViikiSoft
Windows 9x	mdiapp		2007	nattou
Windows 9x	Mpaint		2001	ura00
Windows 9x	Neko no Mori Graphic Editor	猫の森グラフィックエディタ	2009	Neko no Mori Soft
Windows 9x	PAL Paint 2		2005	Togura
Windows 9x	PictBear		2000	Yasuyuki Kashiwagi
Windows 9x	PictBear 2		2009	Yasuyuki Kashiwagi
Windows 9x	piroPaint		2011	piroyan
Windows 9x	Pixia		1998	Isao Maruoka
Windows 9x	Pointillist Feng Chu 3	点画師鳳雛３	2005	Maya Takimoto
Windows 9x	PRETTY ART		2000	dmms_21
Windows 9x	SPED4		2001	TwinkleSoft
Windows 9x	SUPER KiD 95		1996	Zeit
Windows 9x	SUPER KiD FE		1997	Zeit
Windows 9x	The Graphics		2002	Fanfare
Windows 9x	Ultra KiD	ウルトラキッド	1997	Fanfare
Windows 9x	Ultra KiD v2.0	ウルトラキッド	1998	Fanfare
Windows 9x	Yumeiro no Enogu	ゆめいろのえのぐ	2008	Kengo Watanabe
Windows CE	EDGE Pocket 2		2009	TAKABO SOFT
Windows CE	JINZO Paint 16		1999	Tomohiro Ueno
Windows CE	JINZO Paint 4		1999	Tomohiro Ueno
Windows CE	JINZO Paint full-colour		1999	Tomohiro Ueno
Windows CE	mdiapp mobile		2008	nattou
Windows CE	Pocket Artist		2001	Conduits
X-Windows	Gedo / Graphic EDitor OMNI		1999	Yasuhito Sugiura
X-Windows	Xbrush		2001	Akira Tasaki
X-Windows	xpx		1994	yav
X-Windows	XShodou		1998	Hiroaki Sakai
X1	turbo Z’s STAFF		1985	Zeit
X68000	Art68K		1991	OOYAMA
X68000	Easypaint SX-68K		1991	First Class Technology
X68000	EEL		1994	GORRY
X68000	EX-WIN (EX-System)		1996	Oh! X
X68000	Full Color Paint Tool SAI	フルカラーペイントツール-彩-	1996	TANE/KOJI
X68000	G・TOOL	G・ツール	1990	Zainsoft
X68000	G68KversionII-PRO		1989	OH! Bussiness
X68000	GE		1990	Miki Hoshino
X68000	GLab		1992	Ushi no shizuku
X68000	gm256.x		1993	Kanzu
X68000	Graphics Editor ARTIST		1992	T.Shimanuki/GCC
X68000	Magic Palette	マジックパレット	1990	Musical Plan Ltd
X68000	Matier	マチエール	1992	Meteor Art Tech
X68000	mfged.x		1988	Mamiyu Yuuki
X68000	MONOCRAYON	ＭＯＮＯくれよん	1990	Yasuhiro Sasama
X68000	MONOCRAYON Wide Edition	ワイド版ＭＯＮＯくれよん	1994	Noboru Ishii
X68000	Monotone		1988	GUNchan
X68000	Object Editor	オブジェクトエディタ	1990	Tonbe
X68000	Onazorikun		1990	Muchi
X68000	Prism 68K	プリズム68K	1989	WOLF TEAM
X68000	RG	ＲＧ	1992	RERO2
X68000	RGBP		1994	Tetsuya Kimura
X68000	Usagi	うさぎ	1992	IKUTA
X68000	XGE		1995	KYA!,CHIAKI
X68000	XPST	えせきーすX68	1991	kenna & PUNA
X68000	Z’s STAFF Pro-68K		1987	Zeit
X68000	Z’s STAFF Pro-68K v2.0		1989	Zeit
Zaurus	PetitPaint		2001	TOK
Zaurus	PrismPaint 3		2001	Soga Juroh
Zaurus	PrismPocket		2002	Soga Juroh
Zaurus	Zausuke	ざうすけ	2000	Soga Juroh
Zaurus Linux	CloverPaint		2005	Soga Juroh
Zaurus Linux	PetitPeinture		2004	Sakira
Dedicated	Aniputer	アニピュータ	1982	JVC
Dedicated	Hyper Paint 2		1991	Shima Seiki
Dedicated	Personal LINKS: PFB-2		1991	LINKS Corporation
Dedicated	Pyuta G-GRAPHIC	ぴゅう太 G-GRAPHIC	1982	Tomy
Dedicated	SGI-Pictoris	ピクトリス	1988	LINKS Corporation
Dedicated	SGX-Hyper Paint		1988	Shima Seiki

Kenichi Shinohara’s Pixel Art Ukiyo-e (1987)

by Matt Sephton — Fri, 13 Oct 2023 10:43:00 +0000

From LOGiN Magazine (1987, No 5) comes the story of 篠原賢一 (Kenichi Shinohara), a “cheerful uncle” from Hyogo Prefecture, who at the age of 60 years old began using an NEC PC-98 to draw pixel art reproductions of Ukiyo-e. He also printed them and made folding screens and kites! Just “for something to do”. I like his style! What a guy.

His process involved pasting copies of artwork from books and magazines to his monitor screen and then tracing them using the mouse. After that he would clean up, add colour, and after 4 to 5 days print it out on his NEC NM9900, check and repeat. Each piece would take 1 to 2 weeks of work.

This is pretty much the same process I used to create my 1-bit Woodblocks series, though with a more modern set of tools, and similar to what Susan Kare did for her famous MacPaint artwork.

Happy 100th

Given that this feature was published in 1987, when Kenichi was 64, that would make him 100 this year. Happy Birthday for your centenary, Kenichi, wherever you are! 🎂

The Setup

We can read that he used pixel art software such as Z’s STAFF, FUNNY and CANDY2. The kite goes further and advertises that its image was drawn using Z’s STAFF with Pluskit LEVEL 1, an NEC PC-9801E and printed on an NEC MultiImpact NM-9900 dot matrix printer.

Handily, many of these tools are referenced in a repeated feature about ASCII C.G. Tools Festival which ran from the middle of November 1985 to the end of February 1986. That feature was essentially an advertisement for Zeit software company and was sponsored by them.

We can see that Funny was a pixel art package, CANDY2 was a technical drawing app, Z’s STAFF was a pixel art app (Zeit’s most famous, in fact), Pluskit LEVEL 1 was an “image reader” software add-on. Interestingly, Pluskit LEVEL 2 involved an interface board to allow for direct camera input.

Thanks to Gaming Alexandria for scanning the magazine and making it available at Internet Archive: archive.org/details/login-may-1987/LOGiN%20-%20May%201987/page/n169/mode/2up

陽気なおごさんに教わるグラフィックツールのひミーふな使い方
Learn how to use graphics tools from a jolly old man

Click the images below to see a zoomable, browsable version of the magazine.

OpenSCAD to Sprite Sheet workflow

by Matt Sephton — Wed, 04 Oct 2023 15:19:00 +0000

I just released the “OpenSCAD to Spritesheet” workflow I created for Daily Driver:

github.com/gingerbeardman/openscad-spritesheet

It’s a Frankenstein mish-mash of a Makefile and several shell scripts that evolved over many months/years. Initial rendering is done using OpenSCAD, and post-processing is done using ImageMagick. Model poses and rendering variations are controlled by variables in either the shell script or passed through to the model. The whole process is optimised to do as much in parallel as I could figure. More info at the link above! 🚗💨

Post Processing

After exporting all frames there is some image magick work to process the files as follows:

stitch frames together into a single sprite sheet
split sprite sheet into RGBA channels
process channels to recolour and dither as required
recombine processed channels into new sprite sheet image

You can read about that in a previous blog post.

Benchmarks

A full build of 36 cars is as follows:

3GHz 6-core Intel Mac mini 32GB
- 100% CPU for ~26 minutes
M1 Pro 10-core MacBook Pro 16GB
- 70% CPU for ~9 mins
- about 3x speedup
- approx 16 seconds per car

That’s parallel 3D rendering, PNG writing & compositing & processing, and copying of ~140K files (which takes up ~0.5GB of disk space).

Example Model

Not to scale! Sizes of features are exagerated to allow for them to appear correct when rendered at a very small size.

Example Output

990 frames each for car and shadow, total of 1980 frames per sprite sheet. Each sprite sheet takes up about ~400KB of RAM on Playdate, and only one is loaded at a time.

Daily Driver: Club GTi

by Matt Sephton — Tue, 08 Mar 2022 12:32:00 +0000

My GTi Club: Supermini Festa! obsession has bled into my game Daily Driver… the “Club GTi” car features smaller wheels than the standard size, more roll during turning, and lots of detail and decoration to show off the rendering workflow I spent so many hours on. A good choice for the autotesting/motorkhana/gymkhana stages.

Here’s the 3D model, created in OpenSCAD.

Daily Driver: How big is a sprite sheet?

by Matt Sephton — Sat, 07 Aug 2021 00:00:00 +0000

Since the early days of the project I’ve been generating the car sprites by rotating the 3D model 360 degrees in a sequence of 32 steps. It works well and I hadn’t given it much thought. Until over on the unofficial Playdate Discord server user Jono showed of a hot-dog trick rendered using 64 steps which looked super smooth! This got me thinking about increasing the number of rotation steps used in my workflow for Daily Driver.

Code changes

I had to do a bit of code changing as I had used the value 32, or the angular equivalent of 11.25 (degrees), in a few places throughout my code. Once I’d changed those to refer to a single variable I was set. I can now run the game with sprites of any number of steps.

Rendering changes

Similar changes were also needed in my rendering workflow, moving any hardcoded steps or angle values into a variable. After replacing hard-coded magic numbers with variables, I spent way too long figuring out why angles were being rounded down to the nearest integer. Eventually I realised that in shell scripts the calculation $( 360/64 ) gives an integer result of 5, whereas $( 360.0/64 ) gives the more accurate floating point result of 5.625.

Interestingly, I also needed to increase my filename pattern from %03d to %04d as there are now thousands of images being processed.

How high?

After making the necessary changes to my workflow it is very easy to render a new set of sprites. But what number of steps to use? My immediate thought was to simply double it to 64, which is higher than the frame rate I’m using and the result was definitely smoother.

After this Neven Mrgan asked if I’d explored whether there was a performance limit or upper boundary? I hadn’t but it sounded like a fun thing to explore.

But why go higher? Well, even if we have more frames of animation that than refresh rate, we can still gain in terms of accuracy. The more steps there are the more discrete angles we can show the car pointing. That was good enough reason for me to try it out.

I spent some time exporting a sprite at 32, 64, 90, 128, 180, 256, 360-steps to compare not only the smoothness of the animation but also other related implications.

Selected results

Most modern browsers are well-behaved enough to only play an Animated GIF if it is on the page. So you’ll probably need to force reload the page (hold shift and click reload) to synchronise one or more of the below animations.

Stats

steps #	render time Secs	frames #	width PX	pixels W×H	png KB	pdt KB	ram Bytes	ram MB
32	30s	704	1216	1016576	48	39	147404	0.15
64	59s	1408	2432	2033152	64	78	294807	0.29
90	82s	1980	3420	2859120	111	107	414572	0.41
128	114s	2816	4864	4066304	143	140	589614	0.59
180	159s	3960	6840	5718240	174	188	829145	0.83
256	192s	5632	9728	8132608	209	227	1179228	1.18
360	285s	7920	13680	11436480	240	264	1658290	1.66

Charts

Implications

The increase from 32-steps to 360-steps is echoed by an increase of around a factor of ten across each of rendering time, number of frames and memory usage.

In the above table we can see that related stats increase pretty much linearly, with a slight downward trend for file sizes and a slight upward trend for everything else.

The increased smoothness is great, and very easy to notice. The benefits of the increased smoothness becomes less noticeable with each increase in step count. However, it’s important to remember there are other implications:

Rendering time
File size
Memory usage
Performance in-game

Rendering time

This increases from what I would call a quick 30 seconds per render at 32-steps, to an extremely slow 284 seconds (4m45s) at 360-steps. For a full set of renders it’s not as easy as multiplying that number, there is some overhead that goes with it. This means a real world increase from ~20 minutes to multiple hours, which could be a problem. Cars aren’t generally re-rendered very frequently but when I do render them I do it many times as I make minor tweaks. So, at this point all numbers of steps are on the table but with a preference for those with shorter rendering times.

File size

Playdate’s compiled image format is very similar in file size to an optimised PNG. The file size increases by slightly more than double as the number of steps is doubled. Even the largest size at 360-steps is only 264KB (0.26MB) which seems OK in the grand scheme of things. All numbers of steps are on the table.

Memory usage

As we can see by the table below, memory usage is quite optimised on Playdate. The system is clever enough to trim transparent areas from cells of sprite sheets and store the offset of the image instead of the complete raw bitmap data. For this example sprite memory usage is roughly (W×H÷8)*1.16 rather than the expected (W×H÷8)*2.0. The car sprite is my largest occupier of memory. Only one is loaded at a time and even at 360-steps it fits comfortably in the Playdate’s 16MB RAM. All numbers of steps are on the table.

Performance in-game

I’m targeting a refresh rate of 60fps on the device, so it’s important for me to check that any changes to rendering don’t have an adverse effect on performance. At 32-steps the car sprite was changed roughly every second update, with 64-steps and higher the car sprite will be changed every update. Looking at performance in broad terms, there does seem to be a small hit when using the large numbers of steps. It doesn’t prevent me hitting 60fps, but it does leave me less time to do other things I have planned.

Final choice?

If you’ve read this far you’re probably wanting to know my choice. How many steps did I choose? Well, the jury is out. This is the sort of thing I’ll have to live with for a while before I settle on a choice.

I’ll probably end up going somewhere in the middle with a choice that gives increased smoothness and accuracy, renders fairly quickly and doesn’t affect performance in-game.

Daily Driver: To GIF and Back

by Matt Sephton — Wed, 14 Jul 2021 00:00:00 +0000

When rendering my vehicles I generate a single PNG containing all frames. Playdate SDK calls these image tables, or more specifically matrix image tables. You could also call them sprite-sheets, with the one qualification that every sprite has the same dimensions.

Given that these are plain old images they can be viewed easily. Showing a grid on top of the image makes the layout obvious. You can edit the image as a whole easily enough, but what if you want to adjust the size of every cell? Then we have a problem.

There are a few apps that can load image tables, asking for the cell size during loading. My favourite such app is Piskel which has good options for import, editing, and export.

However there is another type of image that consists of multiple frames of the same dimensions: the Animated GIF. There are far more apps that can deal with this format, such as Acorn or Adobe Photoshop.

Problem

How can we convert a matrix image table to Animated GIF, and back again?

Thinking

We could use Piskel, but its GUI isn’t the most straightforward so using it twice at separate points in the conversion process gets old fast.

So I had the idea of writing a couple of small shell scripts that leverage imagemagick and can be run from my Makefile, the command-line, macOS context menu, or all of the above.

Solution

Below are both scripts, be sure to grab the Gist versions as they have error checking and “help” usage display.

Convert image table to Animated GIF

Convert Animated GIF to image table

Daily Driver: Channelling RGB into 1-bit

by Matt Sephton — Sat, 05 Jun 2021 00:00:00 +0000

After successfully splitting out dark and light elements of the sprites and rendering them in a HDR style, I figured: why stop there? Maybe I could squeeze another colour into the render - some specific shade of grey - that I could treat in a different way to introduce dithered areas to the sprite.

This came together very quickly but it resulted in my Makefile, yet again, becoming too complicated. So I decided to rethink my approach.

If only there was a way to encode information about three different colours in a single bitmap image. Hang on a minute, there already is: RGB!

Channels

So my new idea was to use red, green and blue as the colours for my render, then split the image into those colour channels and process each individually to get separate light, dark and dithered elements.

Using imagemagick it is easy to separate a single channel from an image:

magick render.png -channel G -separate green.png

From this simple start things quickly become more complex. I always find building imagemagick commands a very time consuming process. Indeed, it took me a long time to arrive at a workflow that was just right. But I think of it as time well-spent as it will result in much quicker and easier iterations when designing vehicles.

Overall, I did a few more tricks:

threshold convert the channels to 1-bit colour
apply a dither pattern to the green channel
composite select layers back together as the final image

And the process worked a treat!

The resulting workflow takes half as long to execute as my previous workflow, with all vehicles rendering in ~8 minutes compared to ~16 minutes before that.

Here are some example hi-res images showing the journey from initial render to final composite:

Elsewhere

2021-06-06—Hacker News

Daily Driver: Pseudo-HDR

by Matt Sephton — Fri, 21 May 2021 00:00:00 +0000

I love OpenSCAD “the programmer’s solid 3D CAD modeller”, despite its idiosyncrasies. One of the quirks that causes me most pain is the lack of controls for scene lighting in the Preview render. Unfortunately, I use that very Preview render as my main output!

This lighting issue manifests as shadows cast on the model. As I rotate the car some white “highlight” elements become darker. At this point the model is made up of many more shades of grey than I’d like.

The problem escalates when I take the Preview renders and convert them to 1-bit (black and white) ready for display on Playdate. I use a simple threshold conversion where any pixels darker than the threshold value become black, and any lighter become white. The highlight elements that have been cast in shadow are now grey and in many cases after the threshold conversion they end up as black pixels when they should be white. The net visual result is a loss of detail as well as flashing elements as they disappearing on certain frames.

My first attempt at solving this problem was to set model-specific threshold levels. This worked to a degree but there were still elements that would flash on and off as the car rotated, with headlights being the most noticeable. Whilst I lived with the issue for a long time it always bothered me as it did make the sprite feel buggy. Deep down I knew that the results could be better. However, looking at the OpenSCAD development roadmap made it clear that any improvements would have to come from me.

One day, out of the blue, I realised that if black pixels are more reliably rendered then why don’t I take advantage of that and render the model in opposite colours so that the highlights are now black. After rendering I could simply negate the colours in the resulting image and the highlights would become white again. I tried a quick test and the results were good!

Of course this means an additional render stage is added to my workflow, but that’s of little consequence since the Makefile is doing all the hard work. I also had to make some changes to my render scripts so that the normal and negative images are composited together into the final image. The resulting sprites have no flashing elements, maintain more fine detail, and appear a lot more solid as a result. Excellent!

Afterwards it struck me that this process is similar to HDR photography where multiple photographs are combined to increase the dynamic range in the final image. So, just for kicks, I’m referring to this technique as HDR 1-bit rendering.

Daily Driver: Makefile

by Matt Sephton — Wed, 19 May 2021 00:00:00 +0000

During the shadow rendering changes I was generating new sprites quite frequently, and I quickly realised that my mess of shell scripts just wasn’t a good enough system to be used in anger. I would have to call my scripts manually, with a variety of parameters, and remember a bunch of stuff unique to each script.

So I spent a day converting the script system into a Makefile, with rules for:

rendering
stitching
post-processing
copying
cleaning

I also improved the scripts to make them touch all their output files with the last-modified timestamp of the original 3D model, meaning the scripts could become self-aware and know which output files are up-to-date and which need re-rendering.

With this system I can generate a full set of renders of all vehicles in ~minutes, or render just a single car in ~seconds. This is such a huge time saver and has enabled me to iterate on car designs more quickly and easily than ever before. I’m already seeing the gains in much better sprites.

Believe it or not this was the first Makefile I’ve ever needed to write from scratch. I knew enough about them to know that they would be a good fit for this task, and it was fun to learn more about something I only knew in passing.

Daily Driver: Pre-rendering Ranger

by Matt Sephton — Tue, 18 May 2021 00:00:00 +0000

Since very early on shadows in Daily Driver have just been simple rectangles: one size fits all, rendered from a single 3D model, and post-processed to add dithering. MVP, you know? Over time I decided to do multiple shadows, one each for short cars and long cars.

Sometime later I threw caution to the wind and decided to render per-car shadows. However, the OpenSCAD projection() command that I was using was so slow! In fact it zapped my desire to finish implementing the feature. Instead, I let it sit for many months.

Recently, I picked things up again to get the a new trailer and demo out. And then it hit me, that if I flatten a car on the z-axis—as if Looney Tunes dropped a heavy weight on it—then that flat thing will be a close enough equivalent of a shadow for my use. So I did just that and the results were great, and more importantly very quick to render!

So I went all in and decided to not only render one shadow per-car but to render shadows for each individual frame. So now the direction of the front wheels and details of the body shape are reflected in the shadow. It might sound like a small thing but it really makes a big difference. You can see old vs new shadows in the image carousel below.

It’s in situations like these that I’m really proud I put a ton of early effort into the tooling and build process that generates my sprites.

Result!

Macintosh drawing software compared

by Matt Sephton — Sat, 24 Apr 2021 00:00:00 +0000

Below is a list of various drawing applications that are available to use with System 7 (68K).

I’m mostly interested in apps that can do both pixel and vector, and that support layers and transparency. The table below might be useful for at-a-glance comparisons. Apps run in both mono or colour, unless stated otherwise.

Deneba artWORKS can do both pixel and vector, has layers and partial transparency. The bottom layer is opaque and all layers on top are transparent. Collections of pixels are managed as a special object, and there’s a limit of 8 layers. The user interface is brilliant.

SuperPaint has two layers: pixel and vector with transparency in all but the base layer. Though it allows cut/copy and paste from the pixel layer to the vector layer at which point those collections of pixels are managed as SuperBits objects and can be edited in isolation.ref

Freehand is king of the vector apps. It really was so much better than Illustrator. Such a shame that it’s no longer around. To use it on iPad is quite something!

Also interesting is how many early versions of successful apps didn’t support layers (Photoshop, Freehand) or full transparency (Photoshop).

Almost every app has only a single level undo, with only Expression and Freehand offering multi-level undo. This is probably why everybody was using Freehand when I started work in graphic design in the mid-late 1990s.

One small disappointment: Macromedia Fireworks requires the PPC architecture so won’t run on my iPad System 7 setup. Sad face. (But we can use infinitemac.org)

APP	PIXEL	VECTOR	LAYERS	TRANSP.	UNDO	NOTES
artWORKS	●	●	●	○		Many layers, many objects
BluePaint	●			○		PPC-only
Canvas	●	●	●	○		Many layers, many objects
ClarisDraw	●	●	●			Pixel drawing within specific objects
Cricket Draw		●
Draw It Again Sam		●	●
Drawing Table		●
Expression		●	●		●	Colour required
Freehand 1.0–2.0		●	○		●	Layers not managed visually
Freehand 3.1–5.5		●	●		●
Illustrator 88–3.0		●
ImageStudio 0.6	●					Custom brushes
LightningPaint	●					Polite palettes
MacDraw Pro		●	●
MacPaint	●
MacroPaint	●			○		Transparent patterns
Photoshop 1.0–2.5	●
Photoshop 3.0	●		●	●		Full alpha channel transparency
PixelPaint	●					Special brush effects
ShareDraw		●	●
Studio/1	●					Animation, 1-bit
Studio/8	●					Animation, 8-bit
SuperPaint	●	●	●	○		Two layers, many objects
UltraPaint	●	●	●	○		Eight layers, many objects
Zeus	●					Animation

Key: ● full support, ○ partial support

Daily Driver: Happy New Year!

by Matt Sephton — Sat, 09 Jan 2021 00:00:00 +0000

I hope you’re safe and well and wish you a great 2021. I’m back at it, and am confident this year will be the year of Daily Driver and more besides!

Recent work on the game includes improvements to the physics of in-game objects and creation of yet more vehicles and levels.

“The car’s the star”, as they say, so I have sunk untold hours into both the physics and graphics of many different cars to ensure that the depth of control and animation is enough to hold a players interest for the time I hope they will spend with my game. There’s no final vehicle line-up, as often some cars don’t look unique enough after the first rough model is tested in the game. But these two are keepers!

Interestingly, both these vehicles show off one aspect of the game that I’ve not really talked about so far: reference and nods to classic games. Here we can see an RC car (whose antenna wobbles!) that is a nod to games like Re-volt, RC Revenge, Smash Cars, RC de Go!, Excite Truck, RC Pro-Am etc. And the forklift is a nod to Shenmue and the infamous New Yokosuka Harbor District.

デイリードライバー

by Matt Sephton — Mon, 14 Dec 2020 00:00:00 +0000

The last couple of months have been tough going for a couple of reasons.

Firstly, a new version of the Playdate SDK broke my game in a couple of important ways: my method of targeting 60fps stopped working, and more seriously the controls stopped working. The workaround for both of these issues was long and drawn out, but here’s a quick summary:

Until this point I was waiting for the next frame update using the SDK wait() function: one line of code that waits for a required amount of time. A change in how this works meant I was stuck. My workaround was do it in a more naïve way - just constantly checking the system timestamp to see if the allowed time for the current frame has passed. Keep it simple, I guess.

The overhead of idling the CPU—the time it takes for it to wind down, do the wait, and then wind back up—is actually quite substantial when it takes a few milliseconds and you only have sixteen of them for each update!

The end result is that the game is now running… better than ever. Even after these issues were resolved at a higher level by the Playdate SDK team, I have kept using my workarounds as the game runs faster. So, silver linings and all that!

Secondly, an important issue that remains unresolved is exactly how—and when—Daily Driver will be released. I’m hopeful that will be as part of a Playdate Season, where games are delivered to the device on a schedule and you don’t know what game you’ll be playing until you see the light flash and you pick up and wake up your device. That’s the magic I want my players to have a piece of. That might turn out to be later rather than sooner, so we’ll have to be patient.

Anyway, other news: I’ve been trying to decide how to render the name of the game in Japanese. The English title uses Futura Bold Oblique which is a style that does not translate directly into non-Roman typefaces. I had found some bold Japanese fonts, with a little bit of character, but they seemed too cute and not geometric enough. After much investigation and many mockups I opted to draw the necessary katakana characters by hand, on a grid, and it’s turned out rather well. I’d love to expand this into a full typeface, but that’s a project for another time.

Doing this sort of graphics work, or car design/rendering, are my goto procrastination tasks when I don’t have enough mojo to dive into the code and tackle the remaining work. So I’m sort of treading water on the final push of work needed to get the game over the line.

Daily Driver: Automation Improvements

by Matt Sephton — Fri, 09 Oct 2020 00:00:00 +0000

The recent automation was really just help with organisation. As soon as I started looking at running OpenSCAD from the shell/command-line it became obvious that I could do the rendering and organisation in one step without having to use external apps like Hazel.

So, that’s now done. I render all the frames, with more sensible filenames, to a single folder.

If I run all the renders one after the other, maxing out a single CPU core (99% CPU usage), time taken:

~17 seconds 🐢

But, using the & directive and wait command, I can run the renders in parallel (well, technically it’s one process each; and batches of 32 works best) using all 6 CPU cores (~485% CPU usage), time taken:

~10 seconds 🐇

…the beauty of the command line!

Note to self: don’t publish a post about an automation breakthrough until the dust has settled.

Daily Driver: Automation

by Matt Sephton — Wed, 07 Oct 2020 00:00:00 +0000

In preparation for regenerating my many cars with x3 the number of sprites, I thought I’d try to sort the rendered frames automatically into named folders because this is fiddly manual work I really don’t enjoy, and a bit of a bottleneck in my asset generation. For each pose I have to render the frames then group the new image files into a folder that describes that pose, as these multiple folders are later be used for batch processing.

I could use macOS Folder Actions for this, but I’ve been using an app called Hazel for many years to do this sort of thing, so that was my first choice.

The hard work is done with a shell script, as I’m quite comfortable writing those.

Flow

get most recently saved .scad file
parse filename to capture car name
parse file contents for left/right/forward/backward tilt values
concatenate all this information as our new folder name
create new folder
move matching file into new folder

This means that the folder name will change based on the render settings in the file—perfect!

I still have to make 9 small sets of manual text changes to render each car pose, so that’s the next thing I’ll try to automate by running OpenSCAD from the command line.

Daily Driver: Post-processing workflow

by Matt Sephton — Mon, 10 Aug 2020 00:00:00 +0000

My post-processing to 1-bit is fairly simple. I use a bespoke tool that allows me to have “live” (realtime) manual control over a bunch of image filters so I can see the results immediately.

But essentially it’s:

convert to greyscale, using one of many algorithms
reduce colours to 1-bit, decide on dithering or threshold level on case-by-case basis

The grey shades that I applied to my model in OpenSCAD give an element of control during this conversion process. Greys can be pushed either way, towards black or white, depending on my need with the specific model I am working on.

In this instance I desaturated the greys which blows them out to nearer white. And then I chose to threshold to reduce to b/w.

I also have the wheels as a separate finished image so I don’t have to worry if their detail is lost during this phase, I can just paste over the accurate/finished wheels.

Final result, unedited:

I would later touch up the sprite by hand to reinforce any details I think have been lost. I use Piskel for edited sprites because it has really nice sprite sheet support, drag and drop loading, and quick and versatile exporting.

Aside: 32 is a number that is a leftover from a different prototype and it’s stuck. I guess it should really be 36? or 24? or 18?. But it’s too late now! Actually it would be relatively easy to change but I have bigger fish to fry.

The animations alone could run at 99fps—it’s anything that causes more drawing which slow things down. Collisions, not because they are computationally heavy, but because they cause a lot of sprite updates - which means drawing moving things - to happen. I’m working hard to maintain 60fps on device (50fps in simulator for… reasons) and am excited I’ve managed to get here.

Daily Driver: OpenSCAD workflow

by Matt Sephton — Sat, 08 Aug 2020 00:00:00 +0000

I took the plunge and upgraded to a Mac mini and 4K display so had to migrate my setup and then figure out why my workflow was broken (spoiler: retina!) compared to my old rMBP with non-retina display.

So, my workflow uses the following apps:

OpenSCAD “The Programmers Solid 3D CAD Modeller”
Retrobatch “a unique application for automating actions on multiple images at the same time”
post-processing “greyscale and dithering tool” (I use my own realtime tool, but any image editor would do it to a degree, see this other thread)

This is so I can re-run a workflow at any point (maybe in a make file) which I often do during development. These become executable assets, of sorts, in my project.

OpenSCAD

define 3D models (I get a feeling like coding CSS in a strange way)
animate the model spinning through one 360-degree rotation
dump frames out as PNG files

Here’s the model definition to try out:

I love building 3D this way, it’s kind of like LEGO. I use basic geometric building blocks (cube, sphere, cylinder, polygon, etc) and some boolean operations (difference, intersection, union). There are some other cool things (hull, minkowski). I have the commands in Dash.appalongside the Playdate SDK docs.

In the image 2 you can see what the model looks like with all the blocks I have used to make it visible at once.

My particular approach is subtractive— kind of like sculpting—I start with large blocks and cut away at them using other shapes and the difference function. When finding the exact placement for a block I use the # precedent which makes the blocks show up as semi-opaque red blocks. See main image.

I colour each block in a one or two shades of grey, black and white. This is to help with the conversion to 1-bit later on. It’s not so obvious here as the lighting makes the colours look many different shades - for example the wheels are black with white centre but look grey here. See image 3.

Using some simple programming constructs and variables I can add booleans to trigger different states, I use this for angled front wheels and tilted car body. See image 4.

And also to set the distance and rotation of the camera relative to the model when in animation mode. In this mode I enter a speed (doesn’t matter but higher the better) number of frames = 32, and the tick the box to dump the images. The tick disappears when the images are all done. See image 5.

I also rendered the skid marks, car shadow, and some other elements.

There is a lot that is annoying about this app

not retina-optimised (so I run it in Low Resolution, set using Get Info on the app)
runs maxed out on a single core
doesn’t have configurable lighting (I’d prefer uniform or no lighting)
Qt Framework app, so not really macOS-native
etc

…but I still use it! I am not aware of anything else quite like it.

Daily Driver: Chequered Flag

by Matt Sephton — Wed, 24 Jun 2020 00:00:00 +0000

Bit of fun at lunch today.

Hanafuda by ZAT SOFT

by Matt Sephton — Mon, 02 Dec 2019 00:00:00 +0000

These beautiful cards were created in 1983 using only characters, without bitmap graphics. This was because the Sharp MZ-700, like many home computers of its era, couldn’t do bitmap graphics.

Here is a download of the Playscii art files for the above cards: Sharp MZ-700 Hanafuda.zip

Also included are a set of blank cards so you can try creating something yourself.

I encourage you to at least try as you’ll encounter some of the genius design decisions made by the original creator!

Verbum “The Journal of Personal Computer-Aesthetics”

by Matt Sephton — Wed, 10 Jul 2019 00:00:00 +0000

Verbum “The Journal of Personal Computer-Aesthetics” (1986–1991) was an early computer lifestyle magazine focusing on interactive art and computer graphics.

All issues (well, except issue 4.3): archive.org/details/verbummagazine?&sort=date
Table of contents for all issues: en.wikipedia.org/wiki/Verbum_(magazine)
Podcast interview with its creator Michael Gosney: www.drfutureshow.com/drfutureblog/interview-media-pioneer-michael-gosney-on-the-renaissance-of.html

Cease & Desist: The Designers Republic

by Matt Sephton — Tue, 17 Jun 1997 00:00:00 +0000

A letter I received from The Designers Republic after creating a font inspired by their work. They chose to order a cease and desist, rather than fostering creativity.

Matt Sephton created an original font called Block Out–a techno font that can still be found here. He had used Fontographer. It was, as he put it, influenced by the tDR font in the Wipeout series of games. He placed a free truetype font on his web site, but was confronted with a threatening letter from tDR and was forced to take down the free .ttf font from his site. They claimed their font 6x6 (even though Matt’s is based on a 7x7 grid) was what he was trying to sell. Another instance of corporate bullying. —Luc Devroye, from luc.devroye.org/fonts-72415.html

My font was drawn completely from scratch using Fontographer 4.1, so I find it perplexing that glyphs I had created straight from my own imagination were the same as those in the apparently identical font. I offered my font as a free download on my website, under the concept of Shareware which encouraged others to also share the font for free, and if anybody felt like sending a donation they could do. As you might expect, this is a bit of a hippy thing to do and nobody ever donated anything! And I never did hear from the Head of the Department of Computer Science.

An archived copy of the font can be found on this CD-ROM from 2007.

Get Info: #graphics

Shibuya Pixel Art Contest 2024

PICO-8

Rorschach for Playdate

Deneba artWORKS for Classic Macintosh

Bonus!

Extras Bonus!

Emigre typography and graphic design magazine (1984–2005)

Tell me about it

Online archives

Digital versions

Related reading

Emoji history: the missing years

1994

1990

A word about word processors

A note about beepers

What makes it emoji?

1988

How old is an emoji?

1986

1984

1979

1965

1959

Comparing Emoji

A word about the word

Conclusion

Terms of use

Printed citations

Barbara Nessim at The Ginza Art Space (1986)

Made in Japan

What software?

JINZO Paint: vintage mobile drawing app

Zen and the Art of Software Design

For my next trick I will run it on a Dictionary

A problem with file selection

Multiple solutions

Keyboard controls

Repo

Further reading

Easter egg emoji: converting pixels into particles

Pixels as code

Pixels as points

Pseudo-random?

Playdate particles

Further reading

YOYOZO (or, how I made a Playdate game in 39KB)

Playdate?

But…why?

Reasons

Breakdown

Abandoned and removed features

Manual/Guide

Timeline

Credits

Further reading

Elsewhere

Early computer art by Barbara Nessim (1984)

Further reading (chronological)

Scans

List of vintage Japanese pixel/dot art software

Selected columns from the big list

Kenichi Shinohara’s Pixel Art Ukiyo-e (1987)

Happy 100th

The Setup

LOGiN 1987 No 5

OpenSCAD to Sprite Sheet workflow

Post Processing

Benchmarks

Example Model

Example Output

Daily Driver: Club GTi

Daily Driver: How big is a sprite sheet?

Code changes

Rendering changes

How high?

Selected results

Stats

Charts