Ideally you draw with the palette restrictions in mind, rather than drawing an image, and then trying to constrain it to palettes.

tokumaru wrote:

It's much better to let artists choose their own limitations during the creation process, and just create the final product by exporting/converting.

So which suggestion should I take?

These advices are not mutually exclusive. You definitely should draw with the restrictions in mind. Using unrestricted software doesn't mean drawing photorealistic images expecting them to convert well to NES specs. One thing you can do, for example, is enable a 16x16 pixel grid in Photoshop (or whatever software) when drawing backgrounds, so you can easily tell if you're respecting the attribute limitations, but you'll still have layers (for keeping trees, bushes, etc. separate in case you need to move them later), transparency (for onion skinning of background animations, for example), and whatever other features you find useful as an artist. In photoshop you can also use smart objects for tiles, metatiles, or repeated elements in general, meaning that changing 1 instance will automatically affect all others. When you're done, you can export the final image for conversion, but still keep the editable (layered) version for future tweaks that might be needed.

What route you'll take will depend on how you like to work as an artist. Most artists already have an established workflow, and they'll definitely be more productive if they can maintain that workflow. If they're targeting an specific console, they should definitely keep the limitations in mind, knowing that the final result should strictly conform to them, or deal with any degradation introduced by automated conversion. If you're new to this, doesn't have a workflow, and just want to plot pixels, then by all means, draw all your graphics in YY-CHR or something, where you'll be constrained to tiles and palettes all the way.

Quote:

Let's find out how did they make those complex backgrounds.

I'm pretty sure that the artist is more important than the tools. A good artist will make do with the crappiest of tools, but not even the best software in the world will improve the work of a bad artist. Hunting down the obsolete computer and floppy disk with the software they used to make the Nekketsu games will NOT instantly allow you to draw the same kind of graphics (just like using the same assembler used for SMB3 will not instantly allow you to create an engine as good as that game's), but if you study the graphics well and really understand what makes them any good, you'll probably be able to create similar art no matter the software. Most artists will prefer to use their tools of choice though, in order to achieve the best possible result in the smallest amount of time.

I'm pretty sure that the artist is more important than the tools. A good artist will make do with the crappiest of tools, but not even the best software in the world will improve the work of a bad artist.

I agree with you, but those who follow Nerdy Nights nes programming tutorials (including I myself) are not professional graphic designers, and for making a hobby nes game they will not hire professional graphic designers. A customized graphic software for NES games can help these kind of people to make their own simple graphic without struggling to use heavy graphic softwares.

The main thing that makes those nekketsu screens so nice is the shared palette entries, which help to hide the attribute grid. That's not a technical feature, it is a creatively made decision about use of color. Having better graphics editors won't help someone the way you're looking for.

Knowing NES graphics restrictions, studying some basics of color theory, illustration and design--and being able to analyze how professional game graphics are successful or could be more successful in those areas will help more. For example, gesture drawing exercises can help greatly in sprite work when it comes time to represent bodily motions at such a low resolution and in so few frames. Also, being willing to separate one's self from local color is a common growth art students usually go through and can greatly help when working with such limited palettes, and when one gets to 16-bit color, knowing how to use saturation (and in particular the lack of it) to your advantage can help tremendously.

The image editing software is irrelevant. I use Photoshop, yy-chr, graph paper, and NESst. Once you learn the restrictions, self-imposing them is no problem. I think everyone has a different workflow (and comparing them in a thread may be enlightening. I've compared my own to a few others, notably Alp and Grimlock via email conversations.)

Tools that automate features are the most helpful, NESst's importing for example. I'd like a tool that analyzes similar tiles by similarity and frequency, and it looks like one's in the works in the thread currently below.

The image editing software is irrelevant. ... Once you learn the restrictions, self-imposing them is no problem.

I agree with this.

NES Screen Tool is great for learning how NES backgrounds work, but it's not a very good editor. Loading backgrounds from NES games you want to learn from in it, like FARID is doing there, is also a really good way to learn.

Mostly I work with GIMP. I don't use indexed colours when working, because I like to use transparent layers to guide things or draw on top of reference, etc. Instead of indexed colours, I just have an NES palette open in the colour selector, and more of then than that I just use the eyedropper tool to grab colours from nearby in the image instead (really quick and easy to switch tools with the keyboard once you know the shortcuts). The most important tool is just a 16x16 grid, which generally makes it very easy to see what colours I can put where.

After I'm done working there, I'll migrate the stuff over to an NES specific tool like NES Screen Tool or something else to actually assemble the data. Maybe I'd make some minor tweaks from there, but in general I want to do any major work in a proper art program like GIMP or Aseprite, etc.

I don't use indexed colours when working, because I like to use transparent layers to guide things or draw on top of reference, etc.

That's exactly what I mean. While drawing, there are many reasons not to abide by the restrictions of the target platform. I for example like to work on a huge canvas with "snapshots" of the progress of each sprite I draw, and that'd be impossible with only 256 tiles. Another thing I often use is layered sprites, which AFAIK isn't possible in dedicated editors. Layers and transparency are great for drawing pixels over reference images (say, a higher resolution pencil drawing you scanned), or for animating (looking at past and future frames to draw inbetweens). Layers can also help with "rigged" characters, for which you can create different animation frames simply by moving the independent body parts (each one being a different layer). The possibilities are endless as long as the tools are there.

Quote:

Instead of indexed colours, I just have an NES palette open in the colour selector, and more of then than that I just use the eyedropper tool to grab colours from nearby in the image instead

Same here.

Quote:

The most important tool is just a 16x16 grid, which generally makes it very easy to see what colours I can put where.

Yes. Most programs will allow you to freely customize the grid, some even allowing subdivisions, so you could have a 16x16 grid with 8x8s inside them, allowing you to always see the boundaries of tiles and attributes. It should also be possible to use non-square grids, such as 8x16 for tall sprites.

You definitely should be familiar with the limitations of the platform you're making graphics for, but having your tools enforce those limitations all the way is too restricting, and far from ideal for experienced artists.

I never got around to posting about it because I had kind of assumed user error on my part as well, but I've had this same thing happen before. I can't recall all the details off the top of my head, sadly.

Does the attribute error show up when you load the nametable file back into NES Screen Tool? If not, then the file can't be faulty. If yes, then NST obviously has a bug.

When I load the nametable in NES Screen Tool 2.04, it looks fine. When I load the nametable created with NST in a rom, it is when the error appears.

Anyway, that NST looks good, is not guaranteeing us anything, so the test is not worth anything.

I suggest that there is an error in NST when saving the attributes of the nametables.

In fact, as you can see, another user has something like this.

freem wrote:

I never got around to posting about it because I had kind of assumed user error on my part as well, but I've had this same thing happen before. I can't recall all the details off the top of my head, sadly.

Anyway, that NST looks good, is not guaranteeing us anything, so the test is not worth anything.

I suggest that there is an error in NST when saving the attributes of the nametables.

It doesn't guarantee anything, but if it's able to save and load the data without corruption, it does show that at least it's able to save (and restore) the information in the file in some form. It should be fairly easy to examine the data in a hex editor to figure out what, if anything, is going wrong (look at the last bytes of the nametable file).

Who is online

Users browsing this forum: No registered users and 3 guests

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