Author here. I made explicitly certain to credit her in the image caption from the start; that wasn't added later, it was there from the very moment I posted. I also mention her again, and note the relationship to the Tut image, in a quote later from Dan Silva.
There is something captivating in these old pictures that elevates them to pieces of art rather than just computer graphics. The sheer amount of work that went into crafting them makes each one special.
The author notes that circles don't draw well due to mouse polling, but I wonder if this isn't a limit of the emulator running on Windows. I remember Deluxe Paint III on the Amiga drawing freehand circles very well, whereas MS Paint on Windows 95, quickly drawn circles ended up looking like polyhedrons due to infrequent polling.
There's a neat modern DPaint clone called PyDPainter (https://github.com/mriale/PyDPainter). It has various advantages, such as support for modern graphics formats like PNG.
Author here. I did not say circles don't draw well. I said that "swiftly-drawn curves are flattened" and likened it to a "large wash." By that I mean long, swift, edge-to-edge brush strokes. Perhaps the use of the word "curves" confused that point, but the natural arcs of human hand/wrist motion are what I wanted to evoke. I also noted a "fat brush in symmetry mode" exhibits the same effect. I can attest to two points about that from firsthand experience:
1. That was also true on original hardware (when I owned the system in my younger days). I distinctly remember having to slow down certain movements to let the system keep pace, depending on speed and complexity of motion.
2. The effect is drastically improved (and I note so in the article) by choosing a faster virtual CPU.
It runs in DOSBox, making it a bit easier (imo) to get running on most computers (and Android devices) than old Amiga software (even if I have FS-UAE and Amiga Forever installed as well on my desktop computer).
Why would the mouse polling speed mess up the circle drawing itself? You record the start position point (center) and then get the new mouse position and calculate the delta to the start position to get the radius, then draw the circle with the values. Same algorithm.
Great post! Pretty much all that is said about the user interface also applies to the ~contemporary Autodesk Animator for DOS (open source here: https://github.com/AnimatorPro). It has the advantage of running in DOSBox.
Not having layers is frustrating, but also in some way fun. I have not used Deluxe Paint much, but in Animator there is a second Clip screen, it is possible to save and load the clipboard (i.e. "CELs") as well as the current image using keyboard short-cuts, and then there are some other nifty features like "copy everything that changed in this frame since I came here"... The more I play with it the more workarounds I find for things that otherwise would have been easy to do if there were layers.
Also have that set up on my phone, with a lot of on-screen buttons configured in DOSBox. Works well and doesn't come with any of the annoying in-app-purchases and/or ads that all the app painting programs seem to be full of. I even bought a stylus to use with Animator on my phone.
I am sure it is possible to find the Pro version somewhere, but I have not seen a build yet based on the published source code. Pro supported SVGA graphics and had a built-in scripting language, so should be more useful in practice, especially with access to the source code for modifying it (if/when someone figures out how to build it). There have been some attempts to port it to modern platforms, but not sure how that went.
Author here. It's very kind of OP to post this on my behalf. I'm happy it is resonating with people. Maybe I should have self-promoted here sooner, but I thought I should put a little more meat on the blog's bones before posting it here. Maybe I was wrong!
"Maybe this would be the day I finally saw an Atari 1450XLD in the wild! I was obsessed with the futuristic stylings of that line; they looked powerful."
I'm a Commodore guy, always was, but god were these Ataris beautiful.
When he manually measured the columns, then manually quantized the colours, and then manually re-created the image I was metaphorically shouting at the screen "talk to a developer!".
I get that the point of the exercise was to re-create the process by hand using original(esque) tools rather than by using power tools. Another, valid, aim would be to attempt to re-create the image as closely as possible.
DPIV user (A500/512+512k) as a kid/teen in the 90s, been testing things out in pixels again recently.
For a more modern substitute with layer support, GrafX2 is often mentioned. It's a pretty damn good indexed color pixel tool, sort of a child of DP and Brilliance.
Still has the brush and foreground/background color essentials and other things.
- By default, it shares a lot of keyboard shortcuts with DP, with a few key ones being replaced by more modern conventions (you can change them all, apparently).
- It'll open HAM and half-brite images, but will just essentially consider all of the colors as independent (ie instead of automatically deriving the last 32 from the first in H-B), so beware when doing some back and forth.
- It has layers / can handle animations as a result. If you save an image as a gif, all layers become independent frames when the gif is opened somewhere else. Conversely, give it an LBM animation, and it'll load it in the layers, and you can play it back.
- You can start it with a commandline argument to limit its bit depth, so `/rgb 16` will get you to the Amiga's 4096 colors. Apparently dpaint.js can reduce to Amiga colors, but I haven't found where it is and have had colors display wrong in Amigaland in my tests (one doesn't simply reduce to a few colors!). I might have to ask the author about that.
Back then I filled most of my floppies with Star Wars spaceship animations made by combining the perspective and animation tools (as explained in the very thorough manual) - until I ran out of memory and couldn't finish a lot of shapes. People have posted legacy VHS video tutorials, basic and advanced, for both DP3 and DP4, up on YouTube. A lot of what's in there is in the OG manuals, but it's quite a different perspective seeing it in motion, explained by a real person.
Anyway - In DP4 at least, an animation would be saved into a single file, which I found out in some recent exploration gets tricky if you never stuck to a naming convention as a kid :)
DP4 doesn't care about the extensions and will happily load an animation as a still image (and just show you the first frame), although it might complain in some other directions (image as anim, brush as image...).
Thankfully, GrafX2 can tell the difference! You open the file regardless of it being a picture, brush or animation and it does the rest.
As for doing stuff in emulation, for sure turn up the emulated hardware specs, good call from the author there. Don't even really have to step away from cycle-exact, just going up to a 030+FPU or 040 is already a big relief. Mounting part of the real filesystem is great too ; and since you're emulating a faster machine, I'd just upgrade from 1.3 to 3.1 too for a bit more creature comforts (3.1 is rough enough as it is, but it at least allows you to list files without icons in the GUI...). On that front, I would also suggest maybe using noicons in DP - spamming the host filesystem with .info files (icons - also IFF/ILBM and viewable in Grafx2!) gets old fast IMHO.
Used my Wacom tablet a bit as a dumb pencil mouse through the emulator, and even without pressure sensitivity, it was already so much better ; although the "right click to paint in background color" thing is really awkward there. I had to make sure windows pen input was disabled, and that was it. It's possible to get pen pressure in the amiga with DP5 but... that's quite the can of worms, and I wouldn't even try this on emulation.
As for alternatives on Amiga, I also tried PersonalPaint (got the actual licence in my AmigaForever package some years ago), but besides color reduction, error-diffusion dithering and other effects, I couldn't jive with it.
Newtek Digipaint was interesting to play with ; you always work in HAM there and have interesting brush expression parameters. It really makes it obvious that you have to plan your piece and pick your base 16 "real" colors before you start doing anything.
Haven't found a copy of (True)Brilliance to play with.
To give credit where it's due, the 32 colour King Tut image that Deluxe Paint's mascot was drawn by Avril Harrison. More of her graphics: https://www.amiga.lychesis.net/artists/AvrilHarrison.html
(I see the article now credits her on the image subscript?)
Also, the article mentions the colour-cycling animations of Mark Ferrari, but you might also like a big collection of specifically Amiga colour-cycling animations: https://www.amiga.lychesis.net/specials/ColorCycling.html
Author here. I made explicitly certain to credit her in the image caption from the start; that wasn't added later, it was there from the very moment I posted. I also mention her again, and note the relationship to the Tut image, in a quote later from Dan Silva.
There is something captivating in these old pictures that elevates them to pieces of art rather than just computer graphics. The sheer amount of work that went into crafting them makes each one special.
It's nice to finally learn the creator of that picture.
Some may be interested in this demo of the animation features added to DPaint3 (demoed by Dan Silva, the main author):
https://www.youtube.com/watch?v=WjIQO1MjV2w
Also, looks like the source code for DPaint1 has been made available:
https://computerhistory.org/blog/electronic-arts-deluxepaint...
https://github.com/historicalsource/DeluxePaint
Written in C!
I always thought it was written in ASM.
The author notes that circles don't draw well due to mouse polling, but I wonder if this isn't a limit of the emulator running on Windows. I remember Deluxe Paint III on the Amiga drawing freehand circles very well, whereas MS Paint on Windows 95, quickly drawn circles ended up looking like polyhedrons due to infrequent polling.
There's a neat modern DPaint clone called PyDPainter (https://github.com/mriale/PyDPainter). It has various advantages, such as support for modern graphics formats like PNG.
Author here. I did not say circles don't draw well. I said that "swiftly-drawn curves are flattened" and likened it to a "large wash." By that I mean long, swift, edge-to-edge brush strokes. Perhaps the use of the word "curves" confused that point, but the natural arcs of human hand/wrist motion are what I wanted to evoke. I also noted a "fat brush in symmetry mode" exhibits the same effect. I can attest to two points about that from firsthand experience:
1. That was also true on original hardware (when I owned the system in my younger days). I distinctly remember having to slow down certain movements to let the system keep pace, depending on speed and complexity of motion. 2. The effect is drastically improved (and I note so in the article) by choosing a faster virtual CPU.
Also this older clone: VGA Paint 386 (https://www.bttr-software.de/products/vp386/)
It runs in DOSBox, making it a bit easier (imo) to get running on most computers (and Android devices) than old Amiga software (even if I have FS-UAE and Amiga Forever installed as well on my desktop computer).
Why would the mouse polling speed mess up the circle drawing itself? You record the start position point (center) and then get the new mouse position and calculate the delta to the start position to get the radius, then draw the circle with the values. Same algorithm.
They did not mean a circle drawn by a circle tool, but instead freehand drawing curved shapes.
Correct. I did not say anything about the circle tool being slow.
There is also a DPaint inspired app which can run in the browser.
https://www.stef.be/dpaint/
edit: you can even "Preview in DPaint" which has an embedded emulator!
Stone Tools author here. I did mention that web app twice in the story, though I didn't catch that "Preview" function!
Well that shows how much I was paying attention whilst reading!
Great post! Pretty much all that is said about the user interface also applies to the ~contemporary Autodesk Animator for DOS (open source here: https://github.com/AnimatorPro). It has the advantage of running in DOSBox.
Not having layers is frustrating, but also in some way fun. I have not used Deluxe Paint much, but in Animator there is a second Clip screen, it is possible to save and load the clipboard (i.e. "CELs") as well as the current image using keyboard short-cuts, and then there are some other nifty features like "copy everything that changed in this frame since I came here"... The more I play with it the more workarounds I find for things that otherwise would have been easy to do if there were layers.
Also have that set up on my phone, with a lot of on-screen buttons configured in DOSBox. Works well and doesn't come with any of the annoying in-app-purchases and/or ads that all the app painting programs seem to be full of. I even bought a stylus to use with Animator on my phone.
Author here. Thanks for reading, and I'm happy you enjoyed it! I've never touched Animator, but I'm intrigued now.
There is a binary of the original 1989 Animator (but compiled around 2010 from BSD-licensed source code I think) here if you want to try it:
https://github.com/AnimatorPro/Animator-Pro/tree/f5ed3/bin/d...
I am sure it is possible to find the Pro version somewhere, but I have not seen a build yet based on the published source code. Pro supported SVGA graphics and had a built-in scripting language, so should be more useful in practice, especially with access to the source code for modifying it (if/when someone figures out how to build it). There have been some attempts to port it to modern platforms, but not sure how that went.
Author here. It's very kind of OP to post this on my behalf. I'm happy it is resonating with people. Maybe I should have self-promoted here sooner, but I thought I should put a little more meat on the blog's bones before posting it here. Maybe I was wrong!
Gosh! So many fond memories!
Deluxe Paint IV on my Amiga 500 was fantastic. I had so much fun making dumb animations with my friends.
I think I still have the diskettes, I just need to fire up Greasweazle to dump those.
"Maybe this would be the day I finally saw an Atari 1450XLD in the wild! I was obsessed with the futuristic stylings of that line; they looked powerful."
I'm a Commodore guy, always was, but god were these Ataris beautiful.
https://www.youtube.com/watch?v=i4EFkspO5p4
Reminded me of this: deep dive into an early artwork done in Deluxe Paint
When he manually measured the columns, then manually quantized the colours, and then manually re-created the image I was metaphorically shouting at the screen "talk to a developer!".
I get that the point of the exercise was to re-create the process by hand using original(esque) tools rather than by using power tools. Another, valid, aim would be to attempt to re-create the image as closely as possible.
Still, impressive result!
I'm pretty sure that artwork predated Deluxe Paint. It was probably done using Graphicraft.
I had a very similar experience growing up, except the Amiga was a 500, replacing a Mattel Aquarius, and Deluxe Paint III just came out.
DPIV user (A500/512+512k) as a kid/teen in the 90s, been testing things out in pixels again recently.
For a more modern substitute with layer support, GrafX2 is often mentioned. It's a pretty damn good indexed color pixel tool, sort of a child of DP and Brilliance. Still has the brush and foreground/background color essentials and other things.
- By default, it shares a lot of keyboard shortcuts with DP, with a few key ones being replaced by more modern conventions (you can change them all, apparently).
- It'll open HAM and half-brite images, but will just essentially consider all of the colors as independent (ie instead of automatically deriving the last 32 from the first in H-B), so beware when doing some back and forth.
- It has layers / can handle animations as a result. If you save an image as a gif, all layers become independent frames when the gif is opened somewhere else. Conversely, give it an LBM animation, and it'll load it in the layers, and you can play it back.
- You can start it with a commandline argument to limit its bit depth, so `/rgb 16` will get you to the Amiga's 4096 colors. Apparently dpaint.js can reduce to Amiga colors, but I haven't found where it is and have had colors display wrong in Amigaland in my tests (one doesn't simply reduce to a few colors!). I might have to ask the author about that.
Back then I filled most of my floppies with Star Wars spaceship animations made by combining the perspective and animation tools (as explained in the very thorough manual) - until I ran out of memory and couldn't finish a lot of shapes. People have posted legacy VHS video tutorials, basic and advanced, for both DP3 and DP4, up on YouTube. A lot of what's in there is in the OG manuals, but it's quite a different perspective seeing it in motion, explained by a real person.
- DP3 video guide with insights from Dan Silva - https://www.youtube.com/watch?v=4qTv8qnTzYU
- DP4 basic video guide - https://www.youtube.com/watch?v=973fiFaSXqw
- DP4 advanced video guide - https://www.youtube.com/watch?v=KybIkyilCQI
Anyway - In DP4 at least, an animation would be saved into a single file, which I found out in some recent exploration gets tricky if you never stuck to a naming convention as a kid :) DP4 doesn't care about the extensions and will happily load an animation as a still image (and just show you the first frame), although it might complain in some other directions (image as anim, brush as image...). Thankfully, GrafX2 can tell the difference! You open the file regardless of it being a picture, brush or animation and it does the rest.
As for doing stuff in emulation, for sure turn up the emulated hardware specs, good call from the author there. Don't even really have to step away from cycle-exact, just going up to a 030+FPU or 040 is already a big relief. Mounting part of the real filesystem is great too ; and since you're emulating a faster machine, I'd just upgrade from 1.3 to 3.1 too for a bit more creature comforts (3.1 is rough enough as it is, but it at least allows you to list files without icons in the GUI...). On that front, I would also suggest maybe using noicons in DP - spamming the host filesystem with .info files (icons - also IFF/ILBM and viewable in Grafx2!) gets old fast IMHO.
Used my Wacom tablet a bit as a dumb pencil mouse through the emulator, and even without pressure sensitivity, it was already so much better ; although the "right click to paint in background color" thing is really awkward there. I had to make sure windows pen input was disabled, and that was it. It's possible to get pen pressure in the amiga with DP5 but... that's quite the can of worms, and I wouldn't even try this on emulation.
As for alternatives on Amiga, I also tried PersonalPaint (got the actual licence in my AmigaForever package some years ago), but besides color reduction, error-diffusion dithering and other effects, I couldn't jive with it. Newtek Digipaint was interesting to play with ; you always work in HAM there and have interesting brush expression parameters. It really makes it obvious that you have to plan your piece and pick your base 16 "real" colors before you start doing anything. Haven't found a copy of (True)Brilliance to play with.
>I must reiterate that Kickstart and Workbench are owned by Amiga Forever. Minimum cost for Kickstart/Workbench 1.3 is US $20.
It's not so simple[0].
0. https://sites.google.com/site/amigadocuments/