I remember Amiga games looked pretty great back in the day. Some still do, if seen on real hardware. Pixel artists adapted their art for an environment with specific video out signal processing, CRT scanlines, gamma and ghosting. Using an emulator, certain scroll text movements, copper gradients, or frame flicker tricks will look harsh and skippy. The gamma might be way off, judging by the peculiar black-points I'm seeing coming out of a lot of emulated old hardware, in particular MAME.
Of course, some games looked terrible both then and now. There wasn't really any convenient way for pixel artists to communicate, rip/dump game graphics or download reference for analysis. TVs didn't exactly show you what was going on with 1:1 pixels either (and pausing required special hardware). Some of the best looking games were those by Bitmap Brothers and Psygnosis. The artists behind those were probably some kind of wizards.
Looking at the raw pixels now, I'm finally able to understand how things were done, and I quite enjoy poking and prodding the pixels to learn. Here follows some Amiga game related pixel art that I've been doing lately.
For organic, large subjects with many colors, I like to paint big, then downscale and index. It's faster to sketch and blend like that, I feel. Pixel optimizations can be done later, though I don't always bother as I can be more interested in the concept aspect of the character/creature design.
Photoshop is not that great at indexing an image (choosing a nice palette) so I prefer to handpick some spots on my 24-bit image, then make a palette on a separate canvas, index that, then apply that palette to 24-bit image. Even so, I often change the palette around a bit to add some hues and life to it.
Here I'm fooling around with a Shadow of the Beast sprite, from the Megadrive version I believe. The SotB sprites varied a bit between ports. Using around 8-12-16 colors per character feels pretty right for this style of rendering with painted volumes and sick hues. This particular guy is pretty monotone though, and can get away with a smaller palette.
I like to put a sky color into one of my ramps to bind the scene together. I had the luxury of affording the special eye color as well and I think small accents can be worth their cost.
A gnarly tree from the Shadow of the Beast title scroll. I gave it more colors, hues, and modified the branches to give it a little more flow (negative spaces). To many colors for an old Amiga doing dual playfield stuff I think, but these are just for fun and practice. Using cold and warms in a mix is often effective. Gives the surfaces a certain dimension which you can't get with flat colors of the same hue.
A ramp with 12-ish colors of the same hue is meaningless for a detailed subject like this. Whenever my figure is looking blurry and lifelessly monotone, I go in and hue shift a few colors. Those colors are much more valuable as hues. Antialiasing/smoothing is a giant trap, I feel. The teal on this tree was initially a highlight brown but changing it to the flat teal made the dead tree feel more... alive.
This awkward sliding boss thing is so strange I had to do something with it. Gave it some legs to explain the sliding movement.
A not finished pixel version (too many noisy and unnecessary pixel groups and orphans). I gave it a few more colors than 12 because it's so big.
Cutting this into parts would make it easier to animate, but it's still too much work for my taste.
From left to right: Original sprite (Shadow of the Beast, Megadrive), then my
24-bit paint-over at center. I use a pixel brush on 50 percent opacity to blend, but it makes the details and colors really muddy, so the color reduction and pixel grouping cleanup work of the final version is welcome.
Took some liberties and gave it an armoured top.
More SotB. I turned the strange shapes of this gargoyle design into limbs which can be used for locomotion or hugging.
Nechithon. I started on this project for a Ludumdare (2016). Programming a simpler form of SotB is not that difficult on modern hardware, but I wanted to fiddle with graphics at my own pace so I never got to the programming bit.
The mockup below is 15 global colors, plus a copper background (for letterbox & sky). Nopan ecchi marathon.
Yolanda terrain, Barbarian II warrior, SotB worm thing. Dropshadows under platforms add a lot of depth. It's one of the reasons why I'm against parallax scrolling in games. Barbarian II could've been very interesting but was not. All of my pixel women have oily highlights. I'd almost expect to see that SotB worm in a vore game.
Yolanda could perhaps fit right in with the difficult-platform-games of today, such as I wanna be the guy. If I understand the mechanics correctly, the player is playing several randomly chosen levels rather than progressing linearly. I think this is a fun level progression mechanic which can be developed further. There could be 12 worlds with 4 levels each. The player is progressing through a small randomly chosen set of these and completing a world unlocks a random new one out of the 12. Since dying immediately spawns the player in a different world, the player can't get stuck as easily and the game stays fresh.
Original screenshot here, partially painted over, mostly original.
I rescued some 40 megabytes of images off my old floppies (and some of the hard drive many years ago). A lot of the images are just a few kb each so there are a lot of them. Most were done in the early 90's (some perhaps in the late 80's) and I was still a teen then of course. Many of the images were sprites for games, but I only managed to save the source code for a few. I've been amusing myself with pixeling over my old stuff using DP or Photoshop.
I made many sets of shmup graphics. This one was for a space invaders game and I have vague memories of writing an engine for it. Idea for engine: draw invaders in a matrix and scroll using the screen pointer rather than moving all of the individual invaders. Set up a copper sky gradient. Make player ship and bullets sprites or bobs so they won't scroll with screen. Use a second screen at bottom for a static ground/planet and maybe score/life counter.
CHEESE, a game I made in the early 90's, and managed to mostly rescue off a decaying floppy. It played a bit like DALEK+Pacman iirc. Puzzle Action. Good thing about uncompiled AMOS is that source remains. Sound banks which are embedded in source were a bit damaged but still plays.
In case you wonder what AMOS is, it's a BASIC language for the Amiga. Here's my IDE setup (it's highly customisable). I'm working on a game called GOSUB ATTACK, a remake of a game I did in 1994. I'm only using Gosubs... The code here gets around some problems with blitting masks.
I found the AMOS source code for this game I had written in AMOS The Creator. Must have been before late 92 as I remember getting AMOS Pro early.
It is a mess of Goto statements and long If lists (without using Else of course). I may have been around 14-15. I don't think AMOS has switches (but Goto can seemingly be used as a switch). Anyways, the game was inspired by the castle exploration board game Drakborgen (the english port is known as Dungeonquest). I had implemented 4 creatures, dice combat (15 sided :O ), permanent corpses, locational damage... a Nose killed me here. The game is playable, but highly unfinished.
Pixel-over from early 2017. GUI is deliberately chaotic.
Zep'91 title screen WIP running at 50FPS on emulated A1200 (unfortunately quite slow on A500 due to my sloppy copper code). Using copper effects as well as recycled sprites and palette shifting a'la Defender of the Crown. 16 colors + copper + sprites. Made in 2017. Here's a potato video of an older version.
Zep was one of my early game projects, likely started in around '91. It's based on an older pseudo-exploration game I have fond, hazy memories of - Zeppelin for the C64. My original graphics were 8 colors, but I upped it to 16, adopting a GODS type palette with dual chrome ramps. There's a subtle copper effect on the rocks (similar to Lionheart's), and I'm strobing/flashing the yellow to make it more vibrant. Began writing a scrolling routine, but might actually go for a Cybernoid flip-screen solution instead as it's less taxing on me and machine. Actually, I'm doing full X,Y scrolling as I just made that work at a decent 25 FPS (Gods was apparently 17 FPS).
A demo type logo in the same dither style, apparently made in '93. We had Amiga... pizza boxes at school for video editing so the Amiga guys would use those for showing off .mod and .iff work. No internet/www or PC network stuff at schools then. Kids a few years after I graduated got to play networked Quake 1 during the breaks...
This is a re-do of Scorched Tanks for the Amiga (similar to Scorched Earth for PC). I initially used my 32 color "CPC BOY" palette but it has poor coverage of earth tones (and too many greens), so I'll have to modify it. Also seen in mockup is Lemmings for "Dark Crusade" project.
I'd do this in a software render mode, using various planes for material checks, textures and parallax, similar to Cortex Command I guess. For the excavated texture layer I'd highlight the top rim, and use hollow sphere decals for explosions to make things look nice. Tempted to go for 400x300 to lessen the claustrophobia.
Amiga Workbench icons in 16, or rather, four plus twelve colours. The first four colours are mostly used for the OS GUI and can be safely changed without affecting the icons. However, the icon select state uses the OS's orange highlight colour, which the user can customize. Some icons might use the colours for transparency/reflection/ambience effects so they mesh with the OS.
The colour values here are bit-plane collapsible, meaning, reducing down to eight or four colour mode does not garble up the icons.
I know there's something called deficons, but I think a better solution would've been if .info files had entries for:
These references could be four characters (like AMOS). When a program installs (or maybe just runs), it could put some icons in ENVARC (is that in RAM?). Unique icon images are really only useful for unique programs such as utilities, games and homebrew. Embedding icons in the .info file slows down directory loading but also makes it hard to change icon sets. Is it possible to have a .info file without an icon, or would that ruin backwards/sharing compatibility by making the files invisible? Worst case, I suppose one could make a small 16*8 two or four colour icon which keeps the .info file sizes down.
Flavours (like system 7's colored folders) would be interesting to support as well, in particular for drawers and coloured diskettes. It could also be used for versions, like Amos 1.3 vs Pro files which afaik use the same extension (.AMOS). The reference system could be used here... I don't think there would need to be a flavour entry.
Iconize. Another useful feature would be automatic icon assignment (for anonymous looking or .info-less files) via a Workbench menu. Iconize: file, folder, subfolders (ask for each, don't do existing icons). It's often fairly easy to guess what a file is by scanning the first dozen bytes or so. Unfortunately it would generate tons of .info files so it's not really a good solution, but:
Extensionize. An alternative could be to Extensionize, also based on file scans. I guess some of my projects would break if the file names were changed, but it's not really a huge hassle to fix compared to having tons of mystery files.
Thumbnailize. Certain file type like DP's .IFF images could benefit from having a thumbnail representing the image content. I (half)wrote a program for this.
Related, I wonder if storing the palette name in the icon file could be useful when moving icons between systems. A PD disk might come with icons made using some foreign palette. Actually, if the icons are mostly in ENVARC, local icons will be used to begin with.
Summary: If there's no .info file (and Show All Files), check for extension and use associated icon in ENVARC. (If there's no extension, use some generic file icon.)
If there is a .info file, look for references to icons in ENVARC. If that doesn't exist, look for fallback reference. If that fails, try displaying the embedded icon. If that is bad, use generic icon. If that is bad, draw a "missing texture" box (red checkers?).
A later version with some palette & icon changes. WB1.3's Freemem looked like a fishtank, and could perhaps make a nice task manager/mem inspector. I put the Rock Lobster in it. WB1.3 is quite wonky in retrospect, but had some really nice programs like the Font-EDitor "Fed". If only the icon editor had been that good. Amiga BASIC's Sprite&Bob editor was no fun either. Say was excluded later because it was licensed iirc.
An even later version with tweaks to some icons and the palette, testing out the first four "theme" colours.
I think my vision for an update to WB3.1 would be to (philosophically) target an upgraded A500 instead of the A1200. A kickstart upgrade + new OS disks. I don't care about 24-bit hirez desktops and playing videos. Thinking about it, I didn't really use my A1200's graphical capabilities much. What I like about it is the speed, extra RAM, and HDD support. It's hard for me to imagine a modern Amiga. It'd just be a shitty PC. I'd rather have a more polished (but relatively simple) back-then-experience because it's somewhat of an unoccupied niche.
This is just a screenshot of Workbench 1.3 with Kickstart 3.0 running in FS-UAE under Linux. I don't like the look of this window manager much. Interesting bits:
16+240 color palette, i.e. 256 colors. Version 3. I've opted for shorter ramps in order to fit more hue variation. There are two sets with different saturation, and some blocks of special colors. Unsure how competent this palette is. There are different ways to index an image. I've noticed that RGB proximity can give worse results than HSV proximity (which can be weighted to focus on hue, saturation or value). For v4 I'm tempted to shorten the ramps further to fit even more hues. I think I'd rather be able to select the right hue of a slightly wrong value. Value relations can be nudged up and down but a missing/bad hue is harder to make up for. This palette hasn't really been use-tested and might be quite suboptimal, though probably not worse than most existing system palettes out there.
I wrote a 256 color mode "emulator" in Blitzmax, using pixmaps and memory manipulation. This screen only uses the first four color indices though. The gradient bars are done by altering a color index on the scanline front porch (beginning of every y increment).
Older version. I started with 8 colors but later expanded to 16 colors (this icon editor only shows 8 though). I like how the Amiga icons can be variable size, and have a special active frame. Whilst WB3.1's editor is better than 1.3's, it's best to just copy-paste icons from a DP work sheet.
My files are a mess - no extensions and obscure names, so I wrote a file tree traverser, scanner, icon-applier and iff thumbnailer in AMOS. It looks at the header/start of a file and somewhat reliably identifies file type. The appropriate .info file can then be copied into the directory and named after the file (thus creating the icon). The thumbnailer loads the iff and creates a downscaled, lightly antialiased thumbnail, using the WB colors, converted from the image colors using the HSV as cathetus for the 3D hypothenuse, doing a occasional/thresholded dithering using the first and second best color match. The correct method would be to make a table of all possible dither pairs and their corresponding average color, then do a second color match search if the regular solid colors are not close enough.
I'm using the active frame to show some fun info about the image. The thumbnail is can be peeked right off the bitplaned screen memory into the .info file as the format is the same. In turn, WB probably blits that data straight onto the screen memory. Program isn't finished yet. I've yet to reverse engineer the rest of the icon format.
Every Amiga nerd has perhaps fantasised about saving the Amiga through means of time-travel shenanigans. For the thought experiment to be fair, only nudges can be made to certain decisions. Everyone would probably go about this differently, but here's my approach:
When a system has a keyboard and mouse like the Amiga, the need for tons of buttons somewhat diminishes. Still, double D-pad would be nice for Robotron 2084 and similar shooters. Games like Exile requires quite many buttons to play. Centipede/Millipede benefit greatly from a trackball or trimpot device I hear. Actually, the Amiga joystick kind of supported a D-pad, analog X,Y, and Fire. I talk about that more here.
Super floppies (4-16mb or something) never took off, but perhaps they survived in an the Mirror Universe? We should build a portal, because this place is starting to suck.
Been trying to draw an X68K variant for some time, but the concept didn't take off. Salvage design by applying stickers generously? Stole A3000 FDD.
Attempt to HitBit-ify the Amiga case.
IV: Maybe my favourite of the bunch, despite superfluous bumpers. Accidentally looks German, but C= stuff was huge there. A computer with special hardware should be identifiably unique in its case design too.
V: Lowered keys. I sort of like the half-height keys on my Logitech K120. After having typed on a flat iMac keyboard for many years, I can't quite cope with the travel and look of normal, full height keys.
Mac-Amiga : Mamiga.
Apparently a Raspberry Pi can emulate an Amiga and interface with a disk drive using the GPIO pins. I remember that PC drives couldn't read Amiga floppies but apparently this gets around it. Designed a case for it.
I just wanted to draw a (not so) floppy disk with a grab-friendly top. It would be stored away laying on the side with the thick labeled edge up, and the metal guard way from the dusty bottom of the disk-box. I think the Zip-drive inserted the drive head into the disk from the bottom or something (a solution I used here for the sake of label space). These disks would be engineered for data retention (30+ years) rather than data density.
If I had a bazillion dollars to selfishly spend on making a new Amiga, a fair amount of that budget would go to launch-day software. My dream lineup would be paraphrases/hybrids of the following games (I've got concepts for a few):
Space expl.: Starflight Platform expl.: Turrican + Metroid Top shooter: Paradroid + Alien Breed + Dogs of War Ship Shooter: Psygnosis Blood Money + Fantasy Zone Physics flying: Wings of Fury / Biplane 3D: Elite 2 Frontier (+Arc Elite) "3D" Adventure: Space Quest Strategy: Master of Orion Building: Utopia + Sim City + Tower defence + Dune II Tactics: Laser Squad + XCOM Platforming: Psygnosis SotB + Ork + KGS + Gods Sword'em-up: Barbarian + IK+ Destructible: Lemmings + Alien Fish Finger + Worms + Scorched Tanks AbstractPuzzle: Puyo Puyo Driving: Super Cars + Combat Cars Sports: Sensible Soccer + Speed Ball RPG: Pokémon Relax: Farm sim
AROS mascot girl. I might install AROS on an old EeePC (as the WinXP support has ended). Maybe the AROS logo can be made to look checker'y. Also played around with making the Amiga checker ball into some kind of logotype. Watched Desert Dream and drew a watermelon ship. Thought about how Amiga gaming was hampered by the lack of joystick buttons. I think that was a factor anyways. There are 9 pins, 2 for ground and power, and seven remain for controls. Four are used for directions and three for buttons, but one is not connected for some reason and IIRC the Tac-2 only had one button, mirrored for lefties. It might be possible to have three buttons, and two more which trigger up+down and left+right which are impossible directions. This would no doubt make some games behave funny though... well, if the programmer does not account for it. I'm thinking the buttons could be Pause and Menu, i.e. buttons which you don't use while steering.
As a side note, there are no good Mario games on the Amiga. All of the platformers are kind of... stale and "walky". Some games did support 2 buttons (not sure about 3) but most people had the TAC-2 for some reason. With more buttons, you can sponsor a more diverse set of actions. that said, modern joypads confuse me. The Amiga had a keyboard so any rare / slow actions could go there, like menu, pause, typing.
I tried to do a sort of Pokémon'y Rock Lobster but it didn't work out... so I did a Rockman Lobster. Pharaoh girl is Denise. Sprite wings, arrow weapon. Guru meditation is a Kappa-like turtle...bunny?
If a design works as a sprite I think it's on the right track. Not sure about this one. At sprite/pixel level, you're forced into simplicity. One example might be Mario's famous mustache, which doubles as a nose shadow and mouth detail.
Amiga logo sketches. I think I like the hands on hip eye robot girl the best.
Attempts, to draw the Turrican suit...s. I thought I'd turn the cover version into a heavier Varia/Barrier suit, but failed as I do not like the design and... strayed in the wrong direction over and over. Turned ingame title version into zero-suit.
Giana Sisters + Hard 'n' Heavy pixel-over work... in progress. Some of the original graphics visible (and no changes to the difficult but workable 16 color Amiga palette). I never much liked Giana Sisters, though I did play it back then and feel perhaps some nostalgia for it. Mostly it highlights just how polished SMB is, with the details like character design, block bumping, shell bouncing, and general physics/movements. Difficult to best that title scroll tune in Giana though...
Hard 'n' Heavy borrows several sprites from Metroid and Kid Icarus, but is a sort of linear thingy. Its main appeals are the metal look, robots, flamethrower, and title screen. Might be cool to combine their aesthetics and fly off in some wild direction with the gameplay. Collecting coins, rings, crystals for score and extra-lives feels vapid. I prefer getting useful things like ingredients, or currency for shops. I'm thinking houses with that pig NPC from Dragon's Trap. Zenny crystals like in MML. Buying upgrades. Maps designed for explorations and obscure secrets rather than jumping puzzles. Simon's Quest, except good? Going on "digs" to find Zenny, upgrades and adventure? I liked that part of the Hard 'n' heavy plot by the way. The robots were supposed to go to Mars as labor, but decide to go on their own adventure instead!
I'm amusing myself with the idea of the player starting in a village with clear orders to mine 28.000 lithium ore thingies from a rock. A simple task but obviously a real grind. However, nothing stops the player from just wandering off, exploring. The player knows s/he's being naughty and this allows the design to take that into consideration. It's not a puzzle world for the player, but a place the player invades.
MOS or MOE? Older design, should match 'em with mascots better.
More fictional Amiga floppy fun, practicing fonts.
Muscle-fem Zoolus Megaran.
If I understand things correctly, Commodore wanted to compete with the budget Sinclair/Mattel/TI machines, so they worked on an entry level computer(s) (C16) meant for... it's hard to say. They had designed this custom "TED" chip focused on text graphics (not game graphics and sound), so maybe small home businesses. Supposedly they had some nice designs, but marketing made a poopoo and things got really confused. Commodore fragmented their own market a bit too much I think (with multiple C16 models even). And when Tramiel left, they had the Atari ST to deal with. C= also sold IBM-PC compatibles (though at the time the C64 sales were massive in comparison).
Anyways, the contradiction with a machine like this (price-point-wise) is that, in mid 80's, expensive peripherals (drives, printers, networks) were needed for saving business records and such. Hmm. I guess with an OK keyboard, but low memory, it could've worked as a terminal for schools and such still (not much to tamper with). The Plus/4 had programs in ROM: BASIC, Debugger, Word processor, Spreadsheet, Graphing. Seems like a good idea but the programs have to be quite good and the C16 machines came out too late, too expensive.
Thinking about my own simplified TED chip:
I made a 16 colour/hue palette with 4 luminosity/brightness values, here generated by Photoshop but actual hardware would likely produce different results. It's based on the TED one that had 16 colours/hues and 8 values (121 colours as 8 were all black). Mine has 64 colours, which is 4+2 bits. This means it's not possible to use 4 bits each for background and foreground colour in 1-bit mode. This would be a simpler system so with bottlenecks and limited memory maybe the video modes have to be a bit peculiar:
- It's a Sony. Remember when they bought Commodore back in 1988...what? You don't remember? ...which timeline is this? You've tampered with the temporal vortex! President Danny DeVito will hear about this!
Made up some specs: 664... 6x64kB banks? So... an MMU... with Supervisor perhaps. Banks: - ROM/BASIC/Utilities - OS/Supervisor/Process RAM - User RAM x2 - Video RAM x2 - Cartridge space x2 (unpopulated). Bitmap & Tilemap GPU, 80 column text mode. Dual SID. 8502 CPU with turbo mode. Built in 3.5" MF2DD.
In some ads, the C64 utility cartridges were shown as spaceships, so I wanted to take that further.
What's this Atari contaminant doing here?!
Apparently GEM, the graphics environment manager on the Atari ST etc. (on top of TOS) was made more for square-ish pixels, unlike Amiga WB. Icons are kinda System 1-7 on Mac... and indeed they got sued. Kinda silly now as everyone uses this type of presentation and Apple got it from Xerox or whatever anyways. Strange mix of 2 and 4 colours. I redid most things here except the top main menu list font. Oh, Gary Kildall's Intergalactic Digital Research were actually responsible for GEM (it could run on top of various OSes).