Art showcase

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Gradualore wrote:Are we talking about different tasks here?
One task is allowing people who know how NES graphics work to edit NES graphics in a specialized MS Paint clone. Another task is dealing with complaints from people who don't understand how the program works because they don't understand how NES graphics work. A third task is dealing with a large library of images that can't be hand-pixeled in the first place, such as photos from a camera or CG renderings.
It seems like what you (tepples/tokumaru) are talking about is importing any arbitrary bitmap or photo and achieving reasonable results on the NES? That sounds like a big challenge!
It's been solved before, although on a much bigger color space (16 palettes of BG + 15 colors, 8x8 pixel attribute areas). See Quither. And in fact, the gbadev.org thread that led to the creation of Quither came from a similar suggestion of computing an attribute area's mean color.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Gradualore wrote:I forgot to mention, when importing, it asks the user to choose the background color, it does not bother trying to find it.
Although looking for the colors that appear in every palette that has 4 colors wouldn't be that hard (if there are more than one, you could just pick any of them to be color 0 or ask the user to select which one).
Are we talking about different tasks here?
I guess so.
It seems like what you (tepples/tokumaru) are talking about is importing any arbitrary bitmap or photo and achieving reasonable results on the NES? That sounds like a big challenge!
Yeah, and the result will never be as good as converting each image by hand. A human can always reshape things and change the brightness of certain areas so that it all fits better within the attribute boundaries.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Gradualore wrote:I felt it was a reasonable constraint to assume that the input graphics abide by NES graphics constraints, and report errors when those constraints are violated.
That's kinda how my level map converter works. You give it an image with all the metatiles and an image with the level, then it matches the blocks and encodes everything in the format the game uses. If a block isn't found, it aborts and reports the error.
UncleSporky
Posts: 388
Joined: Sat Nov 17, 2007 8:44 pm

Post by UncleSporky »

Tokumaru, I would really like to see some examples of the output of your program, it sounds very interesting.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

UncleSporky wrote:Tokumaru, I would really like to see some examples of the output of your program, it sounds very interesting.
The resulting files probably wouldn't be of much use to other people because my level format is *very* specific.

My level format uses various sizes of blocks based on the 16x16-pixel ones: 4 of them make 32x32-pixel blocks, 4 of these make 64x64-pixel blocks, which make 128x128-pixel blocks, which make 256x256-pixel blocks, which are placed in the level map. This would be impossible to make by hand, so I coded the converter that creates all these blocks for me (and reports back how many blocks were used).

It's just a command line application that takes a 256x256-pixel image containing images of the 256 16x16-pixel blocks that can be used, and one level map image (with dimensions multiples of 256) for each level that is supposed to share the same blocks. The program will then output a binary files with all the blocks (32x32, 64x64, 128x128 and 256x256) and a file for each level map (which are basically references to the 256x256 blocks). It can also do the opposite, and generate images of the levels based on the binary data (useful, because I don't have to keep the huge level images).

It has it's limitations though. For example, I didn't want to mess with any libraries or anything so it only works with PCX images, because they are easy to work with, and have RLE compression (level image can be pretty large, so a bit of compression helps). Also, it doesn't have very strong error handling, so it may crash if you do something wrong.

Is there really a demand for such an application? I figured that something like this would be much easier to code than a full-featured level editor with an user interface, and I could use good image editors for drawing the levels (GIMP with grid snapping on works really well). I guess it could be easily changed to output other level formats, but everyone has their own format, there isn't something universal we can use.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Post by thefox »

tokumaru wrote:
UncleSporky wrote:Tokumaru, I would really like to see some examples of the output of your program, it sounds very interesting.
The resulting files probably wouldn't be of much use to other people because my level format is *very* specific.
I think he was talking about your "photo converter". And I second his request. :)
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
UncleSporky
Posts: 388
Joined: Sat Nov 17, 2007 8:44 pm

Post by UncleSporky »

tokumaru wrote:It has it's limitations though. For example, I didn't want to mess with any libraries or anything so it only works with PCX images, because they are easy to work with, and have RLE compression (level image can be pretty large, so a bit of compression helps).
Hm, none of the programs I commonly use other than Photoshop can do PCX. Speaking for myself, TGA seems like a good choice, as it can do color-mapped images with RLE compression, and GraphicsGale supports it.

Anyway I was initially talking about your photo-converting program but I think your level creator sounds great too. To be able to assemble a level from a picture would be very useful, I could probably put it to use, quirks and all. :)
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

UncleSporky wrote:Speaking for myself, TGA seems like a good choice, as it can do color-mapped images with RLE compression, and GraphicsGale supports it.
Windows BMP also supports RLE compression in 4-bit and 8-bit modes.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

thefox wrote:I think he was talking about your "photo converter". And I second his request. :)
UncleSporky wrote:Anyway I was initially talking about your photo-converting program
Oh, sorry about that. The thing is that it isn't a program! I follow that "algorithm" manually, using Photoshop. =)

Here's an example though, using that image from the Wikipedia article that talks about palettes:

Image Image
This didn't work out so well IMO. All the green is gone.
UncleSporky wrote:Hm, none of the programs I commonly use other than Photoshop can do PCX.
Yeah, not many programs work with PCX anymore. This was mainly for me though, and I found GIMP to be the perfect tool to edit the levels, so the fact that it supported the format was enough for me.
Speaking for myself, TGA seems like a good choice, as it can do color-mapped images with RLE compression
tepples wrote:Windows BMP also supports RLE compression in 4-bit and 8-bit modes.
Initially I was gonna use BMP, but found some complications (don't remember which), so I switched to PCX. But out of curiosity, I saved the same level map image using the 3 formats (PCX, BMP and TGA), and PCX seriously outperformed the other two. So it's not only simpler to code, but it also compresses better.

The reason for this is that the RLE implementations of the other 2 formats encode the lengths of uncompressable runs too (and there are many of those in the tiny NES tiles), which causes expansion of the uncompressable data. PCX however uses the higher codes (192 and up) to indicate compressed runs, and since the images never have that many colors, uncompressable data does not expand, because they use codes < 192.

EDIT: I may have screwed up with that image, as some areas appear to have 5 colors. Whatever, it doesn't look good anyway.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Here's an example of my "algorithm" that appears to have the correct amount of colors:

Image Image
This uses a lot of dithering, but the red still managed to disappear. Some of the green remained, but the only strong color is the blue of the sky.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

It did a good job recognizing the sky's border, but hand-tweaking of each image's palette is still likely to be necessary. What happens when you freeze the blue palette and add a palette including $26?


At this point, I almost smell split.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

tepples wrote:What happens when you freeze the blue palette and add a palette including $26?
Photoshop didn't like me replacing a gray with red, several parts of the house became pink.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Post by thefox »

tokumaru wrote:
thefox wrote:I think he was talking about your "photo converter". And I second his request. :)
UncleSporky wrote:Anyway I was initially talking about your photo-converting program
Oh, sorry about that. The thing is that it isn't a program! I follow that "algorithm" manually, using Photoshop. =)
Is it possible to tell Photoshop to reduce to 4 colors and to choose the colors from NES palette only? If I "force" the NES palette it doesn't let me specify the number of colors as 4. Or do you just reduce to any 4 and modify the palette by hand to match NES?

EDIT: or do you manually select the 4 color palette beforehand and reduce to it?

Anyways, I think the results are pretty good considering the limitations.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

thefox wrote:Or do you just reduce to any 4 and modify the palette by hand to match NES?
That is one option, but I found out that it works better to first convert to the complete NES palette (using dithering) and then convert back to 24-bit and reduce again using the selective algorithm without dithering, so that you end up with 4 colors that belong to the NES palette. The only color I force during this second color reduction is the background color (color 0).
Anyways, I think the results are pretty good considering the limitations.
I guess we are used to some of the introduced artifacts. In video coding, color bleeding is not so uncommon. I believe that when seen on a TV these images could look like low-resolution digital video from the early 90's.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

Memblers wrote: I think a 4-screen VRAM mode would work well for a background image. You would have the same nametable data in all screens, but you could set the attributes individually and have 16x4 pixel attribute size. All you have to do then is write to $2000 every hblank, that's easy. 4-screen mode is a good option if you're using CHR-RAM. That could work for some types of games, if the background updating is slow enough where the workload can be safely doubled to provide a 16x8 attribute size. This would be like simulating H or V mirroring in software, but being allowed to use an extra attribute table, see what I mean?
I'm afraid $2000.1 writes wouldn't take effect mid-frame.
Also, modifying a noramal CHR-RAM board to get 4-screen mirroring sounds like doable - you'd have to replace the 8k CHR-RAM by a 32k one, force it to be always enabled, and force the internal CIRAM to be always disabled. That's even less rewiring than on the PRG side.
Useless, lumbering half-wits don't scare us.
Post Reply