It is currently Wed Oct 18, 2017 5:12 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 82 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
 Post subject:
PostPosted: Sat Feb 06, 2010 3:51 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19097
Location: NE Indiana, USA (NTSC)
thefox wrote:
My point EXACTLY was to get rid of all those steps and to combine it all to a single, easy to use tool.

As long as the steps are command-line, they can be automated into a batch file that runs steps 2, 3 and 4 in sequence. The steps visible to the user become
  1. Draw.
  2. Save.
  3. Colorize.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 06, 2010 4:18 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
Bregalad wrote:
The NES can't do something like FLI, Memblers tried doing something similar called FAU, but I think it didn't work (at leat not well).

Yeah, I ended up losing I think 64 pixels on right border of the screen due to the forced hblank. These were some extreme measures just to write one byte to VRAM, heheh.

It also made an interesting comb pattern artifact on the border that didn't show up on any emulators when I checked (not even Nintendulator). It only timed properly on certain resets, though I bet that defect could be worked around. Since then, didn't blargg come up with a way to normalize the timing between resets? I hadn't tried it, and don't remember what it did exactly.

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?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 06, 2010 4:36 pm 
Offline

Joined: Sat Nov 17, 2007 8:44 pm
Posts: 385
tepples wrote:
thefox wrote:
My point EXACTLY was to get rid of all those steps and to combine it all to a single, easy to use tool.

As long as the steps are command-line, they can be automated into a batch file that runs steps 2, 3 and 4 in sequence. The steps visible to the user become
  1. Draw.
  2. Save.
  3. Colorize.

It's not the same thing. You have to think of it outside of a programmer's perspective: for artists, colorizing is an important part of the draw step. They need to be able to do it all at once in an MSPaint-like program, where they can view and edit attributes and tiles in the same window. To have to make it in greyscale and use conversion tools is unintuitive and a detriment to the creative process.

It doesn't really matter if this seems like an unreasonable requirement - it's what's necessary to achieve the stated goal of getting artists outside of nesdev interested in making NES art.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 06, 2010 4:58 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19097
Location: NE Indiana, USA (NTSC)
UncleSporky wrote:
Also I mean no offense but your character doesn't look much like the art to me. This is what I see:

It's hard to make a 16x16 pixel character without making it super-deformed. Look at a Pokemon trainer on a map, then look at the same character in the battle scene. Characters with more pixels tend to have more realistic proportions, although characters seen only in SD style might retain SD style even on graphical updates: for example, Mario or Earthbound characters or Animal Crossing characters.

UncleSporky wrote:
They need to be able to do it all at once in an MSPaint-like program, where they can view and edit attributes and tiles in the same window.

I'd never want to work in Microsoft Paint; I'm more of a GIMP fan. GIMP fans might never want to work in Photoshop, and Photoshop fans might never want to work in GIMP. If the hardware dictates separate layers for pixels and colors, do we want the best tool for painting and the best tool for colorizing, or do we want to limit the painting side to the capabilities of Microsoft Paint?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 06, 2010 5:10 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10054
Location: Rio de Janeiro - Brazil
tepples wrote:
It's hard to make a 16x16 pixel character without making it super-deformed.

The problem I see in this particular case is the mouth. If a person keeps smiling like that they appear to have mental problems. It would be OK if the girl smiled for a few frames on certain occasions, but smiling forever looks very weird.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 06, 2010 5:18 pm 
Offline

Joined: Sat Nov 17, 2007 8:44 pm
Posts: 385
tepples wrote:
UncleSporky wrote:
Also I mean no offense but your character doesn't look much like the art to me. This is what I see:

It's hard to make a 16x16 pixel character without making it super-deformed. Look at a Pokemon trainer on a map, then look at the same character in the battle scene. Characters with more pixels tend to have more realistic proportions, although characters seen only in SD style might retain SD style even on graphical updates: for example, Mario or Earthbound characters or Animal Crossing characters.


It was a joke. I wanted to draw him some silly fanart, I was not trying to be critical.

Quote:
UncleSporky wrote:
They need to be able to do it all at once in an MSPaint-like program, where they can view and edit attributes and tiles in the same window.

I'd never want to work in Microsoft Paint; I'm more of a GIMP fan. GIMP fans might never want to work in Photoshop, and Photoshop fans might never want to work in GIMP. If the hardware dictates separate layers for pixels and colors, do we want the best tool for painting and the best tool for colorizing, or do we want to limit the painting side to the capabilities of Microsoft Paint?

I use a combination of MSPaint, GraphicsGALE and Photoshop. MSPaint because it is on every computer I use and allows for exact percentage resizing without artifacts, GraphicsGALE because it is a nice pixel editor with powerful palette tools. I might be able to do everything I need in Photoshop but I haven't bothered to take the time to set it up and still risk it changing my HSV without my permission.

But for the specialized task of making art compatible with the NES, including precise modes like Memblers laid out above, we don't want separate programs for different functions and we also don't want the exact same capabilities of MSPaint - we need MSPaint with an attribute pane and tile panes. YY-CHR is partway there.

I envision a program that would fill in available tiles as you draw, disallowing further drawing when all PPU tiles are filled. It would also remove tiles as duplicate spaces are created or copy/pasted, and attributes would change in real time depending on which colors you use in a given space. For example, if you draw green in a red/yellow/blue attribute, the space automatically changes to the palette containing green. There would be a secondary drawing mode for applying details with up to 64 sprites (no more than 8 per horizontal).

Obviously better than this, but it gives an idea (linked so it doesn't break the page).


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 06, 2010 8:17 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19097
Location: NE Indiana, USA (NTSC)
Nice mock-up. Here's how I see that working:
  1. When you draw into a tile, it changes the tile's attribute into the attribute corresponding to the pen color. Watch out for attribute clash, but this time, the blocks are bigger than on Apple II (7x1), MSX (8x1), or even Spectrum (8x8).
  2. When you lift the pencil, it automatically runs bmp2chr and chropt and fills the first pattern table.
I saw selection tools, but I don't see how pasting an image from the clipboard would respect the attributes unless the program either
  1. snaps the edges of selections to the 16x16 pixel attribute grid, or
  2. doesn't modify the attribute layer when pasting, instead trying to remap each pixel into the closest color in the attribute that's already at that position. This resembles my original suggestion of editing in GIMP and colorizing later.

Perhaps there would need to be several different selection modes: attribute-aligned, tile-aligned, and free. Attribute-aligned would paste like a, and the others would paste like b (as would images copied from other programs).

I saw you put two pattern tables in your mock-up. If one is for sprites, then the sprite layer would not need tile limits, as half a pattern table is enough patterns for all 64 sprites at size 8x16 pixels.

If only I knew GTK...


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 10, 2010 1:22 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2962
Location: Tampere, Finland
UncleSporky wrote:
I envision a program that would fill in available tiles as you draw, disallowing further drawing when all PPU tiles are filled. It would also remove tiles as duplicate spaces are created or copy/pasted, and attributes would change in real time depending on which colors you use in a given space. For example, if you draw green in a red/yellow/blue attribute, the space automatically changes to the palette containing green. There would be a secondary drawing mode for applying details with up to 64 sprites (no more than 8 per horizontal).

Obviously better than this, but it gives an idea (linked so it doesn't break the page).

Pretty much what I was thinking about. I might try to implement something like this (probably with C#) once I've finished couple of other projects.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 10, 2010 1:32 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2962
Location: Tampere, Finland
Memblers wrote:
Bregalad wrote:
The NES can't do something like FLI, Memblers tried doing something similar called FAU, but I think it didn't work (at leat not well).

Yeah, I ended up losing I think 64 pixels on right border of the screen due to the forced hblank. These were some extreme measures just to write one byte to VRAM, heheh.

Could you share the demo/sources? It would be interesting to see, because I've been toying with the same idea myself. I found some old links searching for FAU on this forum but they're not working anymore. :)

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 10, 2010 3:20 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
thefox wrote:
Could you share the demo/sources? It would be interesting to see, because I've been toying with the same idea myself. I found some old links searching for FAU on this forum but they're not working anymore. :)


Sure, I re-uploaded it here:
http://www.parodius.com/~memblers/nes/fautest.zip
It's a really weird format, see fau.txt for the description. I still am not sure how a picture would look if it could be converted to that. I'm sure it would make great atari-2600-style sunset scenes at least, heheh.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Feb 11, 2010 11:03 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 983
Location: Pennsylvania, USA
thefox wrote:
UncleSporky wrote:
I envision a program that would fill in available tiles as you draw, disallowing further drawing when all PPU tiles are filled. It would also remove tiles as duplicate spaces are created or copy/pasted, and attributes would change in real time depending on which colors you use in a given space. For example, if you draw green in a red/yellow/blue attribute, the space automatically changes to the palette containing green. There would be a secondary drawing mode for applying details with up to 64 sprites (no more than 8 per horizontal).

Obviously better than this, but it gives an idea (linked so it doesn't break the page).

Pretty much what I was thinking about. I might try to implement something like this (probably with C#) once I've finished couple of other projects.


My own custom graphics editor works like this (it actually looks strangely similar to that mock up, haha!). You can import a 256x240 source bitmap, and it finds an optimal palette (if possible with the input bitmap), generates the pattern table, and attribute and name table if you want it. Or, you can just draw and come up with your own palette. Also, it has a sprite mode and an "attribute workspace" where each attribute is one tile in size, so you can use other parts of the editor for designing meta sprites and animations. It is also written in C#. Looks like several of us may be duplicating work on a possibly valuable tool! Parts of it were hastily written, and could be dramatically improved I think. But for my purposes it works great and has greatly improved my workflow when importing/developing graphics assets.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Feb 11, 2010 11:28 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19097
Location: NE Indiana, USA (NTSC)
Gradualore wrote:
You can import a 256x240 source bitmap, and it finds an optimal palette (if possible with the input bitmap)

The basic problem is as follows: Given 240 sets I of 4 colors, find four sets P of 4 colors (∀p #P[p] = 4) such that one backdrop color B is in all P (∀p∃B B ∈ P[p]), and each I is a subset of some P (∀i∃p I[i] ⊆ P[p]) I was hung up on 1. how to construct P efficiently, and 2. what to do if P does not exist, such as trying to dither a photo down to NES specs.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Feb 11, 2010 11:35 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 983
Location: Pennsylvania, USA
tepples wrote:
Gradualore wrote:
You can import a 256x240 source bitmap, and it finds an optimal palette (if possible with the input bitmap)

The basic problem is as follows: Given 240 sets I of 4 colors, find four sets P of 4 colors such that one color B is an element of all P, and each I is a subset of some P. I was hung up on 1. how to construct P efficiently, and 2. what to do if P does not exist, such as trying to dither a photo down to NES specs.


The importer assumes that the bitmap you are importing is either a screen shot from a real NES game minus sprites (actually, either bg or sprites), or art developed by someone who is aware of NES graphical constraints. If it can be displayed on the NES (assuming no advanced tricks are used), it can import in my editor. The color depth of the bitmap does not matter, the importer counts the colors and finds close matches to the NES's master palette.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Feb 11, 2010 11:45 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10054
Location: Rio de Janeiro - Brazil
The "automatic" way I use to convert photos to the NES is (only experimental, I never actually used them for anything):

1. Scale a copy of the image down so that each pixel = area using the same palette (a 256x240 pixels image becomes 16x15 pixels);

2. Color-reduce the scaled image to 4 colors (different algorithms will give different results - never use dithering though), each color represents a palette;

3. Select each of the 4 areas that correspond to a palette and individually color-reduce them to 4 colors, forcing color 0 to be the same for all palettes. Dithering can be used this time;

I haven't though of a good way to select the best common color (color 0). Maybe looking for the most common color in the image might be a good idea. You can always hardcode it to black, which is a pretty useful color. Or you can ignore color 0 completely and reduce all 4 areas to 3 color.

Anyway, the results are acceptable for photos (it would probably suck for pixel art), it looks like the output of one of those old Windows 3.1 video codecs, such as Microsoft Video 1 or Cinepak, with lots of color bleeding.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Feb 11, 2010 11:59 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 983
Location: Pennsylvania, USA
I forgot to mention, when importing, it asks the user to choose the background color (i.e. click on it on the bitmap to import), it does not bother trying to find it. Are we talking about different tasks here? 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! I only needed to import NES graphics suitable for a game, so 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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 82 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group