Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Arne
Pages: [1] 2 3

General Discussion / ROBOCITY
« on: January 26, 2015, 12:41:00 pm »
I saw a WB icon for a demo called RoboCity and got interested because, well, robots! It appears to be an early tech demo for the Amiga 1000 (which heralded the A500). Because it was made so early in the Amiga's life (the very beginning of, 85-86) I suspected that they might not have bothered packing the data, so I decided to write a little program allowing me to have a peek inside. I suppose I could've used GFXrip but I don't have it on my machines atm.

Two palettes, 0-15 for BGs and 16-31 for figures. Some strange color choices, and some colors are not used.

The backgrounds are actually identical, and are used in some kind of double buffer setup. Could be used for nice light strobe effects and color mixing. Would be fun to see static characters in the background to blend things together.

The blank space at the edge of the characters is due to how bitplanes are stored/drawn with 16bit alignment. I tried adding a little bird flying over the dog, so the area can be certainly be used. I'm unsure where the hotspot of the characters lie but it can probably be seen in the youtube video.

Most of the file is image data, as you can tell from my colors in the data block.

Anyways, if I can figure out how the palette can be accessed (Edit:done!) then we could have a little activity, mayhaps? My program can write images into the data using the palette strips for indexing, so I could release it or run the conversion for you. Grandfather A1000 would be pleased to see the ROBO CITY bustle once more.

Program is done and seems to be working. I've located the palettes and cleaned up my code a little. The two BG screens might have different palettes but atm. I'm cloning, like in the original data.

Had to write a special program to spot the palette entries, but in hindsight it was pretty obvious how they were stored. I messed up because my emulator doesn't seem to have a palette extraction function so I had to make up some entries and I guess I forgot about it and ended up trying to search for them.

I think I'll go play around with the gfx and palettes now.

Unsure about the heavy full black, and the details are just happening. Skipped the cartoony eyeball on the dame and did regular shiny eyes which is what I thought it was supposed to be first time I saw her.

Post merging?

Pixel Art / Workbench icons
« on: January 22, 2015, 11:01:25 am »
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~

Pixel Art / Generic 16+16 color palette
« on: September 25, 2013, 07:38:41 pm »
People have been asking me for a 32 color palette, but I figured I'd make it easier for me by just expanding on the old 16 color palette (not allowing myself to change those). That palette was focused on RGBO and several darks. It was missing CMY hues, a skin tone (sacrificed it for the yellow), some greys and more strong graphical mid-tones usable for text and such. The first step was to just fill in those gaps, so I did that and then started nudging the colors around, but it's hard to tell at this point if the colors are usable.

Two grays at the either side of the old one. Note that the darker gray is a bit colder to meet up with the other dark colds. Unsure what this does to its role as a bridge color. I haven't really checked how these gray values ramp into other colors.

A wine red / dried blood red which I figure could be useful. Different from the old-poop brown, but perhaps the dark-pink later gets a bit too close for comfort.

A more bold orange for explosions. Fits into the brown yellow ramp.

My favorite yellow! Maybe even my favorite color.

Now, the requested purples. And three of them! I'm quite unsure about the values for these, but would like them to play well with ramps and maybe even fit into a skintone ramp (or as saturation points to spice up skin tones). Also, I felt that the old palette was very focused on darks and brights so I wanted some mid-tone colors. I'm thinking, Kirby-type creature light and shadow, or something like that. It's sort of hard to tell how well these work without doing some mockups or manual indexing of existing game screens (black BG games will work differently from say, sky BG games like Mario). I'm worried that the dark-pink is too close to the red. I added a colder version too, simply because it was missing.

The promised skin-tone returns! I want this expansion to be Eroge-certified! Unsure how it will handle darker tans though. Or tan lines! I suppose the lighter pink could be put a value notch above the skin-tone rather than below because tan lines are often colder in tone, but... it seems to be more useful as it is.

Cold green to fill in the green ramp. Could be colder.

Two teals. Just added them to fill in the blank slots, unsure about their use.

A purple dark blue, just because the old one was so green (meant to be used for water).

A regular blue to plop into the blue ramp. Could be a tad more saturated perhaps.

Two muddy yellows that I hate, but they fill in a missing part. Maybe usable for burnt grass and such. Maybe the dark one should have a Metal Slug hue?

--- That's it. The tricky part about multipurpose palettes like this is that it's tempting to change a color because it works better on a single test (or because it looks "new" and you forget the use/justification of the old version). I think I'll do some tests manually re-indexing some game screens (Photoshop is kinda crap at indexing). If you want to fiddle around with it, feel free. I don't know which role a lot of these new colors could play, but my hope is that they make non-black BG games more feasible.

Pixel Art / Mighty
« on: September 03, 2013, 07:14:27 pm »
I wrote a little on my blog about Mighty No 9. Some of you might know that Inafune is kickstarting a new "Not"-Megaman character. I ended up making my own version (in the idea stage so far) and wanted to make sure that I could downscale it to sprite size. I think I like it more than other people do, but I can feel it's close to something but still not there.

But! I'm curious if any of you have attempted to make pixel art of the original design (see Kickstarter page). It'd have to be pretty large I think, or subject to tons of detail reduction. Post stuff if you have it! I'm quite curious.

With my internet down the whole day, I actually got some work done on my pixel art tutorial! In one segment I talk about common "doesn't look so good"s, and then tried to include some of the more blatant ones in one image.

  ( @1x)

I've made my own "fixed" version of this and written about the process in detailed steps, but before I post that I think it would be interesting to see what other people would do to it (should be a quick edit since it's just a few tiles and a character). I'd like to feature the "guest edits" people do just to give this particular segment of the tutorial a bit more... range. So, if you have the time, I'd like to see your edit and perhaps a few (<5) sentences (nothing too lengthy) about some choice that you made which is of particular interest.

The original shows some kind of 16px front+top-down RPG with no particular color or tile count restriction. Do keep the dimensions for comparison's sake. I left the grass field 2x2 to demonstrate simple grass tiling. We have the typical cliffs/mountains and trees/forest and a lake/ocean. The character is a bit taller than a tile, and there's some sort of gem drop/treasure (feel free to nudge). The assumption here is that the author just wants his pixel graphics to look "good" but whatever edit that you make will be fine and probably ponderworthy to the reader.

& Minidump

Unrelated random Garius ZOID

Something from the line art thread. Wasn't quite happy with it so I didn't want to bump. Probably needs minor... enhancing saturation points.

I started editing Megaman (girl?), but felt that it became too noisy.

Pixel Art / Workbench 3.1 icons
« on: July 02, 2013, 01:42:33 am »
I'm trying to rescue my old Amiga floppies (with images, code and art on), so I put a new HDD into my old Amiga 1200 (+Blizzard 1220/4). My original HDD was dead unfortunately. Actually, I got an IDE-USB adapter for a laptop size HDD and connected that to WinUAE, and partitioned, formatted and installed WB 3.1 and other things from there. Then I propped it into the Amiga and it miraculously worked. Since I can also mount folders into WinUAE I have a way of transferring files to PC now (I was using CrossDOS and 720K floppies before). I think Ubuntu can read the HDD as it is, but I haven't tried yet.

HELLO 1991!

Anyways, all my files seem to lack extensions. I'm thinking maybe I can write a thingamajib which applies extensions and icons and associated openers. Maybe I can even write a thing in AMOS which loads an IFF and generates an icon for the file. The .info format is well documented.

While pondering that, I decided to do some regular OS icons since I never liked the original ones much. Really not a fan of the WB 2.0+ look either. The icons all have panels/borders and the beveled window borders/gadgets/widgets are a bit dull. I prefer the flat look of 1.3 (and 1.4 with the darker desktop). Tangent: Started on a GTK+ theme.

I decided to stay pretty flat in case I swap some colors around later. The icons are stored in 3 bit planes so they have no color data (just index). A thing I tried to consider is truncation to 2 bit planes (the user might go into 4 color mode sometimes) . The placement I chose for the color values (2 groups of 4) should solve this. Works down to 1bp too.

That blue was almost unused, so maybe Windows 95 teal? Here are the icons I've transferred and converted to .info so far. They might look very blurry on the real deal because of video out limitations (I use a composite yellow RCA). 16x16 icons and single width pixel fonts for file names aren't readable unless you use a proper monitor.

I set the highlight color to light-blue in an attempt to tone down the beveling, but I can't do much about the icon borders/BG plates and GUI stuff without third party hacks. I'm not sure how alpha/masks are done for the icons (if at all).

It seems PS CS5's .iff files often doesn't load in DP5. When I finally got a version to load it was pretty simply to copy-paste from DP into the Icon Editor (which apparently does color matching in case the palette is different between the clipboard image and OS... made a mess of things a few times).

The disk icons just go into the root of the disk/partition. Ram disk is different since it's cleared on reboot, so I had to copy its (icon) from hdd into ram: via startup-sequence (boot script). Files with no .info file companion count as hidden. They use a shared default icon when shown (which one depends on type) and the Icon Editor can also quicksave the the default icon dir (somewhere in ENV:).

Pixel Art / SMB2 stuffs
« on: May 22, 2013, 11:02:23 pm »
I started looking at SMB2.

Interesting stuff:

Animation (dangling fruits, tufts of grass, flying vulture, POW, potion etc) is done by changing tile tables. The ending scene is about 8 full tile tables of Mario sleeping.

There are a few one bitplane sprites overlaying each other.

The eye-whites are a separate sprite.

Massive amounts of unused tile table space. Maybe because it was a conversion of Doki Doki Panic and stuff was erased, or they just felt they could afford the space.

Some of the sprites seem to have been rushed together. Look at shrunken forms, especially Toad. (Screenshot from my NES tile arrangement tool, the tiles are not ordered like this in the actual game data, but as far as I can tell my tile order corresponds to that of the game.)

Looks like they squandered the space for two complete head frames for running. The vulture probably isn't used, and I think the noise is the potion puff which could be optimized in size (if even used).

Anyways, fiddled some on my own versions. Haven't really tested the 2 frame animation yet. Tried to keep the legs a little ambiguous in Z-order.

Also some SMB1 fun. 4 colors is too tight. 5-6 is enough for almost anything, retro-look-wise.

I found an old dump that I made of the SML sprites and couldn't resist fiddling with the sprites. The originals use a lot of black lines. Maybe it shows up better on the LCD screen, or it was just the style of the artist. I quite like some of the original sprites, like the Shellcreeper/Koopa and the spear fly (look at that death frame... so sad, like it's philosophizing, empty-eyed, over its own wingless demise). Its huffing and puffing is very cute.

The live fish needs a bit of work. Perhaps it can be turned into a chibi-blooper (edit: meant cheep-cheep) instead of the rigid thing it is now.

I think the koopa turned out OK-ish. Some jumpy black pixels to clean up, but it's overall more readable than I expected despite not being a flat black silhouette anymore. However, it would be interesting to make it bipedal, like the SMW ones. Might yield another pixel of horizontal space!

My Moai heads are dull. Needs some sort of design gimmick. The 2 designs are more consistent now though. I made it look like it runs using the wings.

Some death frames are air-to-ground drops so I curved the bodies a tad so they look OK in free fall, hopefully. Pionpi now looks a bit more like the artwork, but I randomly gave it a skull on the death frame.

The ball is a bullet fired by Tatanga which splits three-ways. Tried doing a glob. The rock was... strange so I tried to make a character of it. The crushing hand felt silly so I did a falling... spiky block thing instead.

Looking at it now, I spot a few supposedly moving masses with stuck static pixels. I'll fix it next iteration. I have a few enemies left, like bosses, plants, spiders. Spiders will be tricky due to leg count and stripes.

2x version for Chrome users

Pixel Art / Phantasy Star 1 Gfx edits
« on: January 02, 2013, 02:38:35 am »
It was time for some fun with old pixels, so I played around with the notion of injecting some graphical changes of mine into Phantasy Star 1 (1987) for the Sega Master System. My Alis is supposed to look more like the character design, but it might be a little gritty, many minor details fighting for pixel space. As usual, I'm in favor of partially coloring or omitting outlines, especially around the bases/feet to ground the masses, and at the top to suggest light... bloom? I added some color noise and hues here and there to liven things up, but I'm not sure if it just makes things dirty instead. I'm unsure about keeping the snot-green field so large on the trees. I wanted to be faithful to the originals.

I might be wrong, but the starting town might be on a platform (the EXIT could be an elevator), so some atmospheric perspective over the edge would be nice. There appears to be a palette entry for it, but it's a warm green similar to the regular grass. has some nice ref. material.

This is the first time I've worked with SMS hardware restrictions, so I wrote a program to help me fiddle around with the game data. I might have messed up the endianess on the patterns/sprites, because they're flipped. Pixels can have 16 colors (from 16 color BG or FG palette) so they are 4 bit planes (8 rows of 4 bytes each for an 8*8 tile). I guess a global palette makes it more difficult to change enemy colors (e.g red/blue Octorok). In Phantasy Star you only encounter one graphical enemy at a time, and the building are all different graphically. I'm thinking the palette, or part of, is changed by the program during encounters with NPCs or enemies.

Hunting these palettes tables down is somewhat difficult as they seem to be scattered about (as are the pattern tables). A color is defined by a byte, or rather, 6 bits, like 00bbggrr, meaning, only a 2 bit resolution per slider, meaning, a 4*4*4 = 64 colors to choose from. Unfortunately, this results in several too similar colors and also too large value gaps / missing colors (such as grays, or a yellow skin tone).

Solution: Go to the Edit menu, then down to Color Settings and Check "Ask When Pasting" (and maybe the others too).

I just installed Photoshop CS5 (on a Mac). It seems the default setting for the Color Settings (/Color Management Policies) throws a stick in the wheel for us pixel artists. If the image (the one in the clipboard) has a color profile different from PS's preferred one, it seems PS will dither the image to produce a "match". To make matters worse, PS isn't competent enough to collapse extremely similar colors with the "Image/Mode/Indexed Color..." conversion, so 255,64,255 and 255,63,255 won't be merged even though the other colors are extreme greens, yellows, etc. I just had an 8 color image (BBC micro palette) turn into 15 colors and Indexed Color refused to turn it back into 8.

When doing pixel art critique and paintovers, this can be a nuisance. I'm just putting this here so the world knows.

Pages: [1] 2 3