Amiga games looked pretty great back then, and some still do if seen on the real hardware. I think the video out signal processing and TVs do things to gamma and ghosting, and pixel artists adapted their art for this environment. In an emulator certain movements, gradients, frame flicker tricks etc can be harsh and skippy looking. I think the colors are a bit brighter and washed out too, at least on my monitors.
Of course, some games looked terrible both then and now. There wasn't really any way for pixel artists to communicate and ripping game graphics so you could analyze them was difficult. TVs didn't exactly show you what was going on with 1:1 pixels either. Some of the best looking games were those by Bitmap Brothers and Psygnosis but the artists behind those were probably some kind of wizards, at least in the mind of the then me.
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 in a kind of learning experiment. Here follows some Amiga game related pixel art that I've been doing lately.
Painted big, downscaled and indexed. Sometimes I like working big because the work flow feels more organic. Pixel optimizations can be done later, though I rarely bother much as I'm more interested in the concept aspect of 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.
Fooling around with a Shadow of the Beast sprite, from the Megadrive version I believe. Around 12 colors per character feels pretty right for this style of rendering with painted volumes and hues. This 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 it's worth its cost.
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. 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 tree feel much more alive in its deadness.
This awkward sliding boss thing is so strange I had to do something with it. Have it some legs to explain the sliding movement.
A not finished pixel version (too many noisy and unnecessary pixel groups and orphans). 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). Not really Amiga restrictions but I'm posting it here because it's SotB related. 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 expect to see the 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.
Scratch-made Speedball type character which ended up too noise, not chunky enough. Lots of other problems but I'm leaving it here anyways.
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.
I found the AMOS (The Creator) source code for this and it is a mess of Goto statements and long If lists (without using Else of course). I don't think AMOS has switches. 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... the game is playable, but highly unfinished. The hero was a peculiar looking humanoid figure in loincloth and this of course had to be changed...
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 4+12 colors. The first 4 are mostly used for GUI widgets and can be safely changed without affecting the icons. This way the OS can be recolored. The color values here are bit-plane collapsible, meaning, in 8 or 4 color mode the icons are still somewhat legible.
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.
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:
If I were rich like a troll and didn't care about spending it on silly things, I'd make a cheap Amiga. Some kind of compact, cool, silent and underpowered thing, maybe 1997 performance. People could use it to rescue their floppies and shuttle them out via USB or whatever. It'd read super floppies too (4-16mb or something). I like being able to write protect and air-gap my floppies and I miss drawing on floppy disk labels. USB sticks are boring and CD's lead to FMV/Evil. Perhaps the file indexing/search function could be made to work with external units like floppies.
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.
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.
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". Maybe it has something to do with the lack of buttons. Amiga platformers often do like... up to jump, button to attack, and no running.
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.
MOS or MOE? Older design, should match 'em with mascots better.