I've been working on some Workbench icons. I'm using 3.1 so I can have 8 and 16 color icons, perhaps more - can you imagine?

Because color 0 & 1 is hardcoded to BG and text and it's useful to keep few colors variable for OS styling, I decided to use only 12 static colors for icons and leave the first 4 for a 3.1 or 1.3 scheme or one of my own.



Installing icons is a bit of a pain. There are helper programs (PD) but none of them do quite what need them to, and some don't work due to dependencies and bloat. I'll probably have to finish the file scanner that I started working on.

Icons are stored in separate *.info files where * is the name of the file, e.g. Banana.IFF. The image is stored in bitplanes, 4 in the case of 16 colors. They have 2 frames and can be any size, but keeping the width at or below a multiple of 16 is a good idea because (afaik) the bitplanes are stored in 16-bit/pixel format. A 33px wide icon would waste 15 bits per bitplane * height * 2 frames or so, and would probably draw/blit slower. The .info files also store what-happens-when-I'm-clicked arguments, position in window, etc.

Unfortunately there's no alpha mask, and in 2.0+ the icons have boxes around them. It can be patched though. Setting the 8+ colors is a bit of a pain too I guess (need visualprefs or something). It would've been neat if the icons stored their palette color values and not just pixel data so they could be adapted to foreign palettes, but icons are loaded off floppy often and can lag the system if they have too much data.

I'm blarging. Hmm. About the design of these, I did put some thought into some. Icons are tricky because sometimes you need to illustrate a very strange concept, like "Any file printed goes into a file instead". I just put a printer cable cord onto a floppy for that one.

Library files: I turned this into a book with a brain-tree on it (knowledge tree, and books are made out of wood).
Datatype: Used by programs to recognize new file formats, so Tron recognizer.
Iff file: Combined the DP pyramid with the default iff landscape icon, and random volcano of presumably paint.
Folder: I like the 1.3 look with the white drawers, but folders are nice to so I made an weird Drawlder.
Say: Removed in later WBs but any sound Amigian would copy it over from 1.3 and make it say WUBDUBWUBkRAAkRAAkRAAboobibibbiwowo. I wnated to antho up my WB and here I chose to use the Z head and Maria. Z always felt like it could've been an Amiga game had C= not messed up.
Commodities: turned into robo-creatures for no reason other than antho theme.
Binary/Data files: Used punchcards as reference for these.
Preferences: Took a cue from the lovely System 7 (mac) with the sliders, and combined with a WB style "?". Some of these use the first 4 colors as I'm showing how the editor windows look. Did the same with the calculator.
Tool: Turned it into a cog (was hammer). Used as default icon for programs without icons.

Pixel-technically, I tried to keep AA and dither at a minimum and avoided perspectives resulting in angles. The colors are bitplane collapsible so the icons would look okay in 4 color mode, and this limited which colors I could chose, but not too much. I'm using primaries and a gray ramp ending in warm with option for cool sky blue mid-shade. I did these in 8 colors first and expanded to 12 later so I'm not always uing the palette to its fullest on the older icons.

That's it for now. Toot~toot~

Didn't a lot of older paint programs (e.g. DP) use poly lines for drawing? They worked by drawing a line between old mouse pos and new mouse pos. I did a 2 minute test program and discovered that you can actually get "fat" turns if you draw slow enough with such a tool:



...but I think this can be remedied by keeping an eye at the velocity of the line (mouse delta) or by remembering 3 time points which must be separated by a certain distance, then doing a spline line or whatever. Should give very smooth lines. The three points suggest the intent of the line to some degree, something which is a bit harder to know if analyzing the pixels after they have been rasterized and you're doing image analysis. Also, no line crossing problems.

As someone who mainly does tiny sprites this is of little use to me however. Seems like it would be more useful for Fighter sprites and pixel art drawings.

Same primitive program as before but with much more delay between sample points:



Really fast lines becomes zigzaggy of course, but as mentioned above, this could be fixed.

With the pencil tool, Photoshop single-plots really rapidly it seems. Unsure if you can set it to drawing lines instead.

BlitzMax Sauce (added some comments):
Strict

AppTitle="Single buffer polyline"
SetGraphicsDriver GLMax2DDriver(), 0 ' Need GL for single buffer apparently.
Graphics 640, 480, 0, , 0 ' Main screen turn on.
SetClsColor 225,220,200 Cls

Global mx, my, myold, mxold, mbold

Repeat
mxold = mx
myold = my
mx = MouseX()
my = MouseY()
If MouseDown(1)
' If the line is not continuation of old one (click is fresh) then...
If mbold = False Then mxold = mx myold = my mbold = True ' ...lazily set old coords to new.
' Now draw a line using some kind of DDA I don't know the name of.
SetColor 20,40,40
DrawLine mxold,myold, mx,my
Else mbold = False EndIf ' No line.

If MouseDown(2) ' Eraser
SetColor 225,220,200
DrawOval mx-3,my-3,6,6
EndIf

glFlush ' Go GL pipes! (Draw.)
Delay 50 ' ...in millisecs, adjust to suit pleasant drawing tempo.

Until KeyHit(KEY_ESCAPE) Or AppTerminate()
' The
End

Another drawing. Obvious accuracy/tablet sensitivity problems drawing without zoom of course. (Flood fill in PS because I'm not writing a flood fill).

The whole cluster approach reminds me of the Photoshop filter Noise>Median which blobbifies an image. I sometimes use it in my analog'ish digital art to get rid of unwanted noise. The effect smells a lot like filter though, so I don't like using it. Similarly,  I think a pixel art image which has been heavily clustered/noise reduced (and posterized) can be... rather boring to look at. All the interest points and subtle little scuffs, knobs and trinkets have been washed away. There are no depths to explore once you've taken in the immediate surface.

Also, I think clustering is more effective at a low color count (great difference in color) where haphazard noise really shouts for attention and you need to be graphically clear about everything (detail and subtle stuff can be quite unaffordable). In the case of the lady face which has so many colors, I think orphan elimination isn't as important. In the case of the castle image, I think some of the peninsula erosion is detrimental as it truncates the range of expression (makes things a little blobby).

rikfuzz> More pastels and grays? I was thinking of taking that route because it makes cross-ramping easier. Is this the palette used for your avatar?

DawnBringer> Interesting, I used ot make programs which plotted palettes like this. Unsure if value gap near darks is a problem when I'm using such saturated colors. if I'm to bridge that gap, I probably need to add a low sat color there. Also unsure if a gap in the purples is a problem...

Been trying out the palette a little and made some minor changes:
-Gave the orange more power (too close to red before as noted by DawnBringer)
-Lightened the pinks and skin-tone a tiny tad (skintone was really close to my new yellow which I saturated a bit more). I feel like the new Kirby pink ramps better with my old more desaturated skin-tone purple shade.
-Dark green is colder. It felt a touch too warm before.
-Tried out the teals for beaches (and saturated one a little to space it from lblue), More blue in plain blue, -Stole some Metal Slug dirty yellows as they seem more usable as they can work with the grays. Unsure if they should be so close in value though. It would be nice if one for them could be used for wet sand. I don't have a good sand color though (desat light yellow). And nothing to make skeletons with (like rikfuzz's light yellow green bone colors).


If I were to sacrifice a color, I'd merge the two darker purples, perhaps. Or maybe dark green and dark teal.