Art showcase

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic

Art showcase
by UncleSporky on 2010-01-11 (#55031)

We were talking about the difficulty of finding artists to work on NES games in another thread. It occurred to me that I had never posted my own drawings here as far as I can remember, so I figured I'd make a thread for people to showcase their work.

This isn't like an open call that I will do art for anybody's NES game, although I might depending on what it is. I don't have any delusions of being a totally awesome pro or anything, it's just part of the hobby.

Pixel art:

This is an old background wall I did, I still really like the rocks but the tiny blocks are way too busy and something's off about the giant crystal.

Here are some backgrounds I've been working on specifically for the NES:

Animations in Easytoon:

An animation from Flipnote Studio on the DSi:

And finally some random drawings:

Some dudes and a chicken nugget (linked so it doen't break the page)

by Bregalad on 2010-01-11 (#55048)

Wow you sure is a good artist. I can draw a few things, but it takes me like forever to have something looking decent so I only do it when I really need it for my game.
Not to mention I have trouble coming up with monster, and when they come on paper they are somtimes almost impossible to pixellate.

by Celius on 2010-01-11 (#55049)

Hey, some pretty nice stuff here! I like the detailed animation of the black mage !

I seem to recall the guy in the 7th picture on the right being discussed in the thread about the fighting game, am I correct? It looks really nice, and the shading is really sharp. You could easily scale that down to only 3 colors (I think I see 4 in the skin tone, and some more for the eyes. Perhaps I'm wrong?).

And for the one right below that for the background with the rocks, I agree that the background is way too busy. My recommendation would be to darken it down so it looks more like emptiness with something in the distant background. The way it is now, I have trouble telling if it is side scrolling or top-down (the wall almost looks like a floor). Otherwise, the rock pattern looks pretty nice, and the background wall looks good it just needs color adjustment (in my opinion, at least).

And the stuff below that is pretty cool too. I'm curious, how did you color the last one? Is that photoshop, or was it actually colored on paper?

As for some of my work, here are just some things I've posted in other threads:

Some pretty big portraits for my NES game (actual segment of a screen print of FCEUXD):

Main character:

I think the mouth needs a little work, because with the limited pixel space it makes the player look like he might be making a stupid face... I still think it looks coolish, kinda. The sprites of that character:

It's hard to tell where what ends because the player is actually made with a black outline and black in other spots. It's just against a black background so it's hard to tell...

For the other character, here is the NES portrait and real portrait:

And here's a link to the real pic so it doesn't make you scroll over and crap:

http://the_bott.webs.com/Leah_Scan.jpg

It's not that great of a painting, but I like the nintendoization of it a lot.

That's basically all I have for now. Nothing that special, but decent I think.

by UncleSporky on 2010-01-11 (#55052)

Thanks for the comments.

Celius wrote:
I seem to recall the guy in the 7th picture on the right being discussed in the thread about the fighting game, am I correct? It looks really nice, and the shading is really sharp. You could easily scale that down to only 3 colors (I think I see 4 in the skin tone, and some more for the eyes. Perhaps I'm wrong?).

You're right, that was a long time ago! I color reduced him for that thread, he needs one sprite for eyes:

Quote:
And for the one right below that for the background with the rocks, I agree that the background is way too busy. My recommendation would be to darken it down so it looks more like emptiness with something in the distant background. The way it is now, I have trouble telling if it is side scrolling or top-down (the wall almost looks like a floor). Otherwise, the rock pattern looks pretty nice, and the background wall looks good it just needs color adjustment (in my opinion, at least).

It was supposed to be a background along the lines of a Sonic water level. I just ditched the small blocks and today I've been working on making the rocks usable for solid tiles in a NES game, trying to figure out which style looks best:

(by the way they're not easily usable right now, I screwed up the tiling of the sides/top and have to redraw some stuff)

Quote:
And the stuff below that is pretty cool too. I'm curious, how did you color the last one? Is that photoshop, or was it actually colored on paper?

Just Photoshop.

I like your portraits too, they remind me of NES FF2 portraits. And the sprite looks very much like it would fit in a modern Castlevania.

by Celius on 2010-01-11 (#55057)

Haha! It's funny you say the sprites remind you of modern day castlevania, because they're for my game "ChateauLeVania", which is basically going to play just like modern day castlevanias. The portraits are much bigger than FF2 portraits, however. They're about 64x96 pixels, I believe. That's like 1/3 of the screen tall! There's a lot of sprite layering that happens there too, so it's a pretty complex image to display.

Are you sure you -need- an extra sprite for the eyes of your guy? It seems like you might be able to find a solution with your current palette for the rest of the body. It might really save you to not have to depend on two of the palettes remaining constant.

About your rock tiles, I really think the second one looks best. You've got a nice variety of color going on (or the illusion of variety with dithering), and it doesn't look as cartoony as the last one does. It's very nice shading.

Re: Art showcase
by tokumaru on 2010-01-11 (#55076)

Preety good stuff, UncleSporky!

UncleSporky wrote:
This is an old background wall I did, I still really like the rocks but the tiny blocks are way too busy and something's off about the giant crystal.

I don't think this is the problem (being busy), I just think that there isn't enough contrast between the rocks and the blocks. If the blocks were darker it would probably look much better.

by UncleSporky on 2010-01-11 (#55077)

Well I got the rocks all NES-ready. They lose a lot of the great organic feel from the original pic but I still like them.

by tokumaru on 2010-01-11 (#55078)

Some things from my NES project (some are outdated):

Here are some contributions I made to the Sonic 2 LD project (a hack of Sonic 2 SMS to make it look more like the MD version):

Here are a couple of drawings (both are several years old now!):

And here is some more stuff I've worked on.

by Kasumi on 2010-01-11 (#55083)

Tokumaru: I always wondered why you never posted any art from your Sonic game on this forum. I found a few of those images on a Sonic forum a while ago. Glad to see they're finally here.

Sure, I'll play along with this topic. I'm gonna post some youtube videos (animations and gameplay videos, not films), and deviantart links.

A Face From a Photo

A thirty minute speed paint from a photo.

A Dive Animation

Walk Animation

Warning: A fat creature belly dancing. Weird Thing I'm Not Too Proud Of. I'm better at animation now. I might fix this up, or redo it.

A NES "portrait" of someone. It's This Guy

Last, but not least, a game I abandoned for the PSP. In some ways it was like RPG maker for PSP. It shows some sprites and stuff. (I'm of course, better at animating now.) http://www.youtube.com/watch?v=fAtGmIDEeGI

by UncleSporky on 2010-01-11 (#55095)

Wow, that is some great stuff! Tokumaru, did you draw most of that Sonic stuff yourself, or are they partly rips from the Game Gear/Master System games? Either way they look great, and I hope you do manage to finish it someday. And the drawing with the sword guy looks straight out of a movie!

Too bad you abandoned that project, Kasumi. I can see how an RPG maker would be a lot of work. Nice work on the photo portrait.

by tokumaru on 2010-01-11 (#55105)

UncleSporky wrote:
Tokumaru, did you draw most of that Sonic stuff yourself, or are they partly rips from the Game Gear/Master System games?

I never rip sprites directly, at most I get together a few sprites similar to what I want to achieve and interpret them (sometimes it's hard to tell what pixel artists meant to represent when it comes to small details), then I draw my own version of that interpretation, according to the limits of the target machine. The Sonic 2 LD sprites were based on the MD/GEN ones, but I didn't copy anything directly.

Quote:
Either way they look great, and I hope you do manage to finish it someday. And the drawing with the sword guy looks straight out of a movie!

Thanks! =) Your work is awesome too!

by Bregalad on 2010-01-12 (#55109)

Well Celius your portraits looks very good, espeically the guy, it looks like you improved him a lot since the last time you show it to me. In fact I think his mouth is perfect too.

Tokumaru is sounds like you are actually a lot better at drawing that what I was suspecting. You really shouldn't have anything to worry about art in your games.

As for myself you can see art by me on my very outdated website (will upload it when I'll be done with the exams I guess).

by Dwedit on 2010-01-12 (#55121)

I guess now would be a good time to pull out my TI83 Sprites Page.

by Celius on 2010-02-04 (#56165)

Wow, Dwedit. I somehow skipped over looking at your page, but I have to say I'm impressed with how well you've maintained all those sprites even when scaling them down to ridiculous dimensions. I can't imagine trying to scale Zelda II sprites to be 8x16 pixels! What's even better, I didn't even have to read the text to see what sprites were from what games. That's hard to make someone do with sprites so small. Good job!

by Bregalad on 2010-02-04 (#56167)

Well now I've eventually go trough an update of my website (I eventually fixed terrible misspelling and removed some really outdated info) and take up to date pics of the game I'm developing, with NTSC filter and manually corrected to normal aspect ratio.

http://jonathan.microclub.ch/rainbow/en/drggallery.html

Feel free to use my pictures to do the graphics analysis, altough you'd probably says that there is a lot of repeated patterns, and obviously no backgrounds because it's top-down view.

By the way if anyone known any software that could easily remove that white background on my drawing scans it could be cool

by HJRodrigo on 2010-02-04 (#56169)

Wow, neat stuff. I should post my sprite work here too. I did some sprites for the Kings Quest 3 vga remake, although they accidentally used my WIP ones . I also did some sprites for an N64 to SNES Zelda game, but the project was cancelled. Like tokumaru I do not rip graphics. I looked at the official art and drew sprites based on them.

by Celius on 2010-02-04 (#56175)

Great stuff, Bregalad! I haven't seen that desert level pic before; it looks really cool. Each time I see a screen shot of your game, I really want to play it. It looks like it has a rather unique style of gameplay, so I'm really interested in trying it out. Keep up the good work .

Also, I'd just like to mention that your Nintendoization of Lucia riding the dragon is seriously almost exactly like the picture. I remember you told me you redrew the picture by hand instead of just converting the scan, am I correct? If that's the case, it's incredible how close this looks to the original.

Also, if you want to know how to easily remove white, use Adobe Photoshop. With that, you can use the eyedropper tool to sample a color from the picture, and then you can go into the "Select" menu, and click on "Color Range". Then in the window that pops up, you can select "Sampled Colors", which will basically specify that you want to select all pixels matching whatever color you selected (in your case, it would be white). You can also adjust the sensitivity, so that for scans, it will select more than just one exact color value, but colors similar to what you selected. If you turn the sensitivity too high though, you'll select more than you want to. So just adjust the sensitivity so that it selects all the white in the background, and then hit "OK". If you followed these steps after selecting a white pixel on one of your pictures, all of the white background should be selected, and then you can hit Delete to get rid of it all. However, in this case you would want to have a black layer underneath the picture so that when you delete the white, there is something to appear in its place.

Also something I like to do in the case of "keying" out the background in pictures is do what I said, but after you delete the white, make the background a very odd, vibrant shade of green. There will probably be a few white pixels around the edge of whatever you're trying to isolate on the image, so in that case I go in by hand and make them that very same shade of odd green as the background. Then once that's all done, I can select all of the green with almost no sensitivity for color selection, and delete -exactly- what I want removed.

Sorry if that's confusing; I guess it would make more sense if you saw the process yourself...

by Bregalad on 2010-02-05 (#56198)

Well thank you, yes the desert is new (altough it was planned for a long time). I don't want to reveal TOO much things else nobody is going to be impressed when it will eventually be released.

I drawed and "nintendoized" that dragon some 4 years and a half ago. I think I did a great work tough because I didn't have to retouch it or anything. Yes I didn't use any automated tools to do the "conversion". The reason both are alike is that because it took me a couple of tries to get the real drawing right, so I got the idea how to do it and was able to redo the same on the computer. Altough the aspect ratio is a bit squarer and the wings are a bit shorter, due to that 127 tiles limit (because 128 others were already reserved and I need a blank one).

Same happens with enemy sprites, I almost always draw them on real paper before pixelizing them, altough they don't always ends up alike, but it don't matter if the pixel version looks good. And same happens to music, I usually play in on my real piano before entering it into the computer, even if it sometimes ends up very altered, etc....

About the white borders, I tried removing them in GIMP, but it always ends up looking bad and blacking out some highlighted areas in the drawing itself I don't want to black out (eyes, feet, etc...). I think the only solution is to leave it as-it or do it manually (which would take terribly long).

by miau on 2010-02-05 (#56211)

There isn't a whole lot to show off, but here's some pixel work of mine:

More available here: http://pixeljoint.com/p/3422.htm?pg=1&sec=icons

A screenshot of the game I'm working on (sorry for the numbers, ignore them):

I got myself a graphics tablet recently and have since been working on concept art.. kind of:

Anyway, the tablet was an excellent investment. I actually draw better with it than I would do using pencil and paper, probably because my lines are never quite right and I need to erase a lot (which is easy with a tablet, no holes in my LCD so far!).

by UncleSporky on 2010-02-05 (#56217)

Oh cool, another person who visits PixelJoint! I posted my stuff in the forums there years ago, I still go back to browse sometimes.

I love the Mario with super long moustache and beard.

I also got a tablet semi-recently, that was how I made the first two drawings in my post. They are really great to draw with, even for pixel art.

I just made this, which one is scariest and/or which do you like best?

(defined eyes / pinpoint eyes / teeth visible / eyes close in roar)

EDIT: I made his head rounder and changed the way his spine things lay down:

by HJRodrigo on 2010-02-05 (#56221)

UncleSporky wrote:
I just made this, which one is scariest and/or which do you like best?

Blue is a calming color to me so non of them look scary to me, but the orange ones kinda make me think of fire. I would say the third orange one looks the "scariest". The fourth one looks a bit cute with his eyes closed on the roar. The first two look cute when their mouths close. The teeth being visible with the mouth closed and the eyes still staring while roaring make the 3rd one look the most dangerous/aggressive. Although the pinpoint eyes seem to add a creepy aspect to the second one. I guess my favorite one would also have to be the third one as he seems to have the most detail

by miau on 2010-02-05 (#56229)

UncleSporky wrote:
Oh cool, another person who visits PixelJoint! I posted my stuff in the forums there years ago, I still go back to browse sometimes.

Yeah, same here. Was there at the very beginning after the old Pixelation forums went down, but went into lurking mode after a year or so.

UncleSporky wrote:
which one is scariest and/or which do you like best?

I like your edit most minus the teeth in the first frame which look somewhat out of place to me, especially how they "connect" in the animation. The animation of the spine things looks really good now.

Maybe the transition from frame 1 to frame 3 should be a little faster. Also, add some screen shaking if you want to make the roar even more fearsome. Well, no, that would be a little too much unless it's a boss enemy, but it might be possible to have parts of the body tremble/flicker or something... I guess it would be difficult to pull this effect off on a small sprite like this, though.

A quick just-for-fun edit:

by UncleSporky on 2010-02-05 (#56231)

I hung out at the Pixelation forums too, I almost think I remember seeing you there. Did you post a lot? I mostly lurked.

Also your edit looks awesome which is a good thing because that's exactly what I was planning to do with it in-game. I just wanted to show the basic frames for now.

You don't like how the teeth connect? I don't know what you mean. Which frame shows the problem?

It's tough, I could go either way on the teeth in the standing frame. Without teeth he looks more alien and mysterious, with teeth he looks more brutish. (With teeth showing, they're supposed to be his top fangs, and the "mouth line" is invisible...but they could also look like they're jutting upward from a lower mouth...)

by miau on 2010-02-05 (#56234)

I suck at explaining this, but I'll try anyway: For some reason my brain thinks the teeth in the first frame and those in the second frame aren't the same, but instead it links them to the lower fangs in the third frame.
Also, in the first frame I feel they should have the dark blue color of the mouth around them like in the second and third frames.

Haha, that explanation is still awkward. Let me make another edit instead:

I changed frame 1 and 2.
Anyway, don't mind me too much, I just love nitpicking.

UncleSporky wrote:
...but they (the teeth) could also look like they're jutting upward from a lower mouth...

Oh yeah, that's what I meant. Missed it the first time I read your post.

EDIT:
UncleSporky wrote:
I hung out at the Pixelation forums too, I almost think I remember seeing you there. Did you post a lot? I mostly lurked.

Not a lot, but I was somewhat active for a few months. Under what alias did you post on the forums?

by HJRodrigo on 2010-02-05 (#56235)

miau wrote:
I suck at explaining this, but I'll try anyway: For some reason my brain thinks the teeth in the first frame and those in the second frame aren't the same, but instead it links them to the lower fangs in the third frame.
Also, in the first frame I feel they should have the dark blue color of the mouth around them like in the second and third frames.

Haha, that explanation is still awkward. Let me make another edit instead:

I changed frame 1 and 2.
Anyway, don't mind me too much, I just love nitpicking.

UncleSporky wrote:
...but they (the teeth) could also look like they're jutting upward from a lower mouth...

Oh yeah, that's what I meant. Missed it the first time I read your post.

That edit looks great. He definitely looks looks brutish in it.

by thefox on 2010-02-06 (#56250)

It's unfortunate nobody has made a graphics editor for making full screen graphics for the NES. I'm thinking something similar to the C64 graphics editor called "Project One" would be cool, I uploaded it here so you can take a look: http://thefox.aspekt.fi/Project1_V0.5.zip

Here's a quote from Project One help file:
Quote:
"P1's main goal is to give a tool into the hand of c64 artists that is as easy and fun to use, while boosting productivity."

I feel like giving artists a tool that enforces the NES limitations would encourage more people to take a shot at it.

The editor could have configurable attribute area (16x16 / 16x8 / 16x4 / 8x8 [MMC5]) and tile allocation settings (mid-screen bank switched or limited to 256), support for sprites (8x8 / 8x16), interlacing (changing the displayed picture every frame to simulate higher resolution), export to iNES ROM or data files for use in games/demos. Also an import feature (from hi-res graphics) could be done similar to Project One, although it's pretty hard to get good results thanks to the attribute area restrictions.

Personally I like the UI in Project One so I think taking the best parts out of it would be a good start for a NES editor.

What do you guys think? Any ideas?

by Bregalad on 2010-02-06 (#56254)

I agree that Project One really rocks and I've had fun converting images to it.
However, keep in mind by default it relies on a technique called FLI that changes the attributes each lines, at the price of a crop bar on the left side (if I remember well). But you can change it to do it every 2, 4 or 8 lines. If you do it every 8 lines only then it becomes an image the C64 can display as-it without crazy timed code doing constant registers update (I remember I coded software to display such images, but unfortunately couldn't test it on my C64 )
However you'll notice the quality of the resulting picure is significantly taken down that way.

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).

Another big difference is that the NES has no bitmap mode. If the resulting image exceed the maximum of 256 tiles, you can't display it, I can't think of a way to do a trick that could display it with lower quality (altough there may be one). The closest you can come of it is to use 4 banks of 256 tiles, but then you'll need raster code to display the image anyways.

So yeah I agree it would be great if something was available, but would probably not be that much practical to use in games.

by tepples on 2010-02-06 (#56265)

thefox wrote:
It's unfortunate nobody has made a graphics editor for making full screen graphics for the NES.

You're looking for something called a "nametable editor". They exist. Steps are as follows:
Draw 256x240 pixel image in 4-level grayscale
Use a BMP to CHR converter
Use CHARlie or chropt to combine duplicate tiles and spit out the first 960 bytes of a nametable
Use NSA, 8name, or another nametable editor to add attributes

But I'm not aware of any nametable editor that supports two separate attribute tables for 16x8 attribute spaces, which are the smallest you can reasonably get without MMC5.

by thefox on 2010-02-06 (#56274)

tepples wrote:
thefox wrote:
It's unfortunate nobody has made a graphics editor for making full screen graphics for the NES.

You're looking for something called a "nametable editor". They exist.

That's like saying because hex editors exist and you can do NES games with them assemblers and text editors are useless. My point EXACTLY was to get rid of all those steps and to combine it all to a single, easy to use tool. Let me quote again:
Quote:
"P1's main goal is to give a tool into the hand of c64 artists that is as easy and fun to use, while boosting productivity."

I doubt there would be nearly as much and as high quality music for NES if FamiTracker/NerdTracker didn't exist and everybody would have to learn MML.

Btw, I'm not looking for anything myself. I want to give others a tool that enables them to create good graphics. I want to see what NES is capable of.

by UncleSporky on 2010-02-06 (#56277)

miau wrote:
I suck at explaining this, but I'll try anyway: For some reason my brain thinks the teeth in the first frame and those in the second frame aren't the same, but instead it links them to the lower fangs in the third frame.
Also, in the first frame I feel they should have the dark blue color of the mouth around them like in the second and third frames.

Haha, that explanation is still awkward. Let me make another edit instead:

I changed frame 1 and 2.
Anyway, don't mind me too much, I just love nitpicking.

UncleSporky wrote:
...but they (the teeth) could also look like they're jutting upward from a lower mouth...

Oh yeah, that's what I meant. Missed it the first time I read your post.

I do like it better with the dark blue to show an overbite, but the second frame looks pretty awkward to me outside of an animation. If it has the more defined mouth I could potentially use it outside of the full roar.

And I didn't notice before that you opened his mouth wider! Now I have to use an extra tile, geez...

What do you think of him with various amounts of highlighting? It makes his eyes and teeth stand out less but it becomes a more interesting sprite overall, I think...or should I just not mess with a good thing?

I suppose it's a matter of art style and creature design (does he have scaly skin?), but he's already got a lot of shadowy parts so I may as well highlight where I can as well.

Also I mean no offense but your character doesn't look much like the art to me. This is what I see:

miau wrote:
UncleSporky wrote:
I hung out at the Pixelation forums too, I almost think I remember seeing you there. Did you post a lot? I mostly lurked.

Not a lot, but I was somewhat active for a few months. Under what alias did you post on the forums?

Same name. I just think I remember your cat avatar, if you used it at that time.

thefox wrote:
tepples wrote:
thefox wrote:
It's unfortunate nobody has made a graphics editor for making full screen graphics for the NES.

You're looking for something called a "nametable editor". They exist.

That's like saying because hex editors exist and you can do NES games with them assemblers and text editors are useless. My point EXACTLY was to get rid of all those steps and to combine it all to a single, easy to use tool. Let me quote again:
Quote:
"P1's main goal is to give a tool into the hand of c64 artists that is as easy and fun to use, while boosting productivity."

I doubt there would be nearly as much and as high quality music for NES if FamiTracker/NerdTracker didn't exist and everybody would have to learn MML.

Btw, I'm not looking for anything myself. I want to give others a tool that enables them to create good graphics. I want to see what NES is capable of.

I knew what you meant and I think it's a great idea. It's the sort of thing that pixel artists on forums look for to do retro graphics when they feel inclined. Most people just don't understand the limitations, since the NES is so inclined towards games (repetitive graphics and tiny moving sprites) rather than artwork.

Bregalad wrote:
Well now I've eventually go trough an update of my website (I eventually fixed terrible misspelling and removed some really outdated info) and take up to date pics of the game I'm developing, with NTSC filter and manually corrected to normal aspect ratio.

http://jonathan.microclub.ch/rainbow/en/drggallery.html

I meant to comment on this earlier, I really like your logo and the background graphics look nice, especially the desert one. And you did convert that drawing very well, I wouldn't guess that it was edited at all to fit within 8x8 tiles.

by tepples on 2010-02-06 (#56278)

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
Draw.
Save.
Colorize.

by Memblers on 2010-02-06 (#56280)

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?

by UncleSporky on 2010-02-06 (#56282)

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
Draw.
Save.
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.

by tepples on 2010-02-06 (#56283)

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?

by tokumaru on 2010-02-06 (#56284)

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.

by UncleSporky on 2010-02-06 (#56285)

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).

by tepples on 2010-02-06 (#56288)

Nice mock-up. Here's how I see that working:
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).
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
snaps the edges of selections to the 16x16 pixel attribute grid, or
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...

by thefox on 2010-02-10 (#56419)

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.

by thefox on 2010-02-10 (#56421)

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.

by Memblers on 2010-02-10 (#56425)

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.

by GradualGames on 2010-02-11 (#56450)

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.

by tepples on 2010-02-11 (#56456)

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.

by GradualGames on 2010-02-11 (#56457)

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.

by tokumaru on 2010-02-11 (#56458)

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.

by GradualGames on 2010-02-11 (#56459)

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.

by tepples on 2010-02-11 (#56461)

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.

Quote:
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.

by tokumaru on 2010-02-11 (#56462)

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).

Quote:
Are we talking about different tasks here?

I guess so.

Quote:
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.

by tokumaru on 2010-02-11 (#56463)

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.

by UncleSporky on 2010-02-11 (#56470)

Tokumaru, I would really like to see some examples of the output of your program, it sounds very interesting.

by tokumaru on 2010-02-11 (#56472)

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.

by thefox on 2010-02-12 (#56488)

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.

by UncleSporky on 2010-02-12 (#56489)

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.

by tepples on 2010-02-12 (#56493)

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.

by tokumaru on 2010-02-12 (#56499)

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:

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.

Quote:
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.

by tokumaru on 2010-02-12 (#56508)

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

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.

by tepples on 2010-02-12 (#56509)

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.

by tokumaru on 2010-02-12 (#56510)

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.

by thefox on 2010-02-12 (#56511)

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.

by tokumaru on 2010-02-12 (#56513)

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).

Quote:
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.

by Bregalad on 2010-02-12 (#56548)

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.

by tokumaru on 2010-02-12 (#56555)

Bregalad wrote:
I'm afraid $2000.1 writes wouldn't take effect mid-frame.

I think it works horizontally, right?

Bregalad wrote:
you'd have to replace the 8k CHR-RAM by a 32k one

Why 32KB?

by tepples on 2010-02-12 (#56557)

Horizontally would only give you 16x8 pixel attribute areas, but that might be good enough.

32 KB because you'd need 12 KB, but SRAMs appear to come in sizes that are a power of 4 times 512 bytes: 2 KiB, 8 KiB, 32 KiB.

by tokumaru on 2010-02-12 (#56558)

tepples wrote:
Horizontally would only give you 16x8 pixel attribute areas, but that might be good enough.

Yeah, already better than 16x16, and can be done with regular vertical mirroring.

Quote:
you'd need 12 KB

Yeah, so I expected a 16KB chip to be used...

Quote:
but SRAMs appear to come in sizes that are a power of 4 times 512 bytes: 2 KiB, 8 KiB, 32 KiB.

Weird that they don't make 16KB SRAMs.

by ccovell on 2010-02-13 (#56574)

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

Your "algorithm" looks a lot like my old one:

All done by hand, right?

by tokumaru on 2010-02-13 (#56582)

ccovell wrote:
Your "algorithm" looks a lot like my old one:

Oh yeah, I forgot about that picture! It's pretty old, probably something I saw when I first started studying the NES! =)

Quote:
All done by hand, right?

Yeah, I didn't bother coding a tool because I don't think the results are good enough, and I can't see it being used for actual game projects.

by tepples on 2010-02-18 (#56775)

So I've started to set up a gallery page on the wiki for background tiles and sprite cels useful for tech demos. Who wants to see their art on this page?

by Bregalad on 2010-02-19 (#56788)

Not me I don't want to be plagiarized.

by Jeroen on 2010-07-28 (#64995)

It's not plagirizing if you give permission. What you mean is "I don't want people to use my work with absolutly no compensation at all" (Not saying thats a bad thing...after all you did put work into it. Why shouldn't you be compensated somewhat?)

by blargg on 2010-07-28 (#64996)

Plagiarizing is putting your name on someone else's work, thus falsely claiming that you created it. It'd be like someone posting foobar's NES test ROMs even though they were the ones I wrote. That's totally different from foobar's emulator including unmodified copies of blargg's NES test ROMs along with it.

by jasonflord25 on 2010-08-05 (#65481)

nice drawings you got there tokumaru

by UncleSporky on 2010-08-13 (#65917)

So in this other thread someone linked Thaddeus's CV2 hack, and I figured out how he was doing the forest graphics - using blackness as the trunks of trees and starting/ending the forest graphic at different times and heights. A while ago I added to what I had done with it and made some leafy canopy tiles. Just wanted to share that:

I might use this tile set someday.

by tokumaru on 2010-08-13 (#65928)

The funny thing is that what happens in this background is the exact opposite of what most people would consider normal: the closest trees are darker than the distant ones. Most people would just darken the distant trees and add more detail to the closest ones, but this scene managed to simulate fog pretty well by inverting the shading and not using textures at all. This is the work of a true artist.

by Jedi QuestMaster on 2010-08-21 (#66452)

Yay! My turn:

by cartlemmy on 2010-09-24 (#67803)

First of all, hello I am new to this forum. I recently have become obsessed with learning how to develop NES games and was happy to find a community dedicated to such endeavors.

I didn't realize how incredibly limited the NES palette was until now. I always knew that you could pick 16 of 50 or so (54?) colors, and use only 4 of them per 16x16 square. But I never realized that the first is always transparency and that you can only have 4 palettes for each the BG and sprites.

The cool thing about being so limited is that is forces you to be creative and intuitive. Which is the reason I wanted to try to make an NES game in the first place. Anyhow the below screenshot is something I did in about an hour on GIMP. It may not translate perfectly to NES, but it is just a result of my learning experience.

Now to learn 6502 ASM, yikes!

by tokumaru on 2010-09-25 (#67806)

cartlemmy wrote:

This looks very good, and it's nice that you're considering using slopes in your game... a lot of people are afraid of implementing them, but I think they are worth the trouble and make all the difference.

I don't think you are obeying the palette limitations though. Assuming that you use the color of the sky as the background color, you're gonna need one palette for where the grass meets the sky (sky color + 3 greens) and another for where the grass meets the brown (2 greens + 1 brown). There are only 2 background palettes left, not enough for the green blocks (which use white, so it's not the same palette as the grass), the blue blocks, the red blocks and the gray blocks.

Also, you have to watch out for the 8-sprites-per-scanline limitation. Your character is pretty big (3 sprites wide if I'm not mistaken), and with the fire and smoke effects, plus the ball, you're gonna reach that limit pretty quickly. Try to design your graphics in a way that doesn't line up so many sprites at once, otherwise you'll have a lot of flickering once you add enemies and such.

by cartlemmy on 2010-09-25 (#67816)

Yeah, slopes make collision detection a lot harder. I've already done slopes in x86 ASM before... so hopefully it won't be too much of a stretch

Yeah, I'm going to have to re work a lot of this. I think I am using 5 bg pallets in this screen shot. I'll narrow them down somehow And the 8 sprites per scan line thing should be interesting to work with too. To tell you the truth diving into assembly language again is really scary, but it should be fun (right? lol)

Anyhow, thanks for the welcome and the suggestions. I've read some of your other posts and it sounds like you really know what you're doing.

by shao on 2011-10-12 (#84993)

Hello, I do not program for nes, for I have no knowledge of it, but I try to emulate his style by another programming language, this is a screen of a game I'm doing, I think the color palette beyond but I have to review it. The resolution is 320x240 at the moment that I can not use the native NES.

I'm from Spain I write English with Google Translate.
a greeting!

by Dwedit on 2011-10-12 (#84994)

I've remapped the palette into NES colors. But it still doesn't meet the 4-colors per 16x16 square limitation.

Here is the palette I am using, it's from Nintendulator.

by shao on 2011-10-12 (#84996)

ok, thank you very much for the info, did not know what 4-color 16x16 boxes, a question, where I can get information about the detection of ground in the NES? I mean, like the sprites to detect the floor and walls in the NES?

by tokumaru on 2011-10-12 (#84997)

shao wrote:
ok, thank you very much for the info, did not know what 4-color 16x16 boxes

We recently explained someone about all the graphical limitations of the NES in this topic, and helped him make his game more similar to an actual NES game. I'm sure you'll find helpful tips there.

Quote:
where I can get information about the detection of ground in the NES? I mean, like the sprites to detect the floor and walls in the NES?

Well, this is not specific to the NES, this is a general game programming concept. The same technique used in the NES can be used in any other platform. The basic idea is to check some key points around the sprites, and checking what kind of blocks/tiles are there, and not allow movements that will cause those points to be inside solid blocks/tiles. Search for "collision detection" and you will probably find a lot of posts on this subject.

EDIT: Here are some posts I made about collision detection over the years:

http://nesdev.com/bbs/viewtopi ... =4617#4617
http://nesdev.com/bbs/viewtopi ... 0918#40918
http://nesdev.com/bbs/viewtopi ... 9897#59897
http://nesdev.com/bbs/viewtopi ... 0374#60374

by Dwedit on 2011-10-12 (#84998)

tokumaru wrote:
We recently explained someone about all the graphical limitations of the NES in this topic, and helped him make his game more similar to an actual NES game. I'm sure you'll find helpful tips there.

It was a great thread, but now all the images have been taken down.

by shao on 2011-10-13 (#85005)

ok, a lot of information, the method of the points is what I was using so far, but I thought that was different NES, thank you very much!.