Learning NES Pixel Art with restrictions

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

Moderator: Moderators

Post Reply
User avatar
Fjamesfernandez
Posts: 57
Joined: Thu Oct 01, 2015 5:34 pm
Location: NYC

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by Fjamesfernandez »

darryl.revok wrote:As I was saying, you have to fill in 960 puzzle pieces with 256 tiles.
Got it.
darryl.revok wrote:focus on doing what you do best, the art. If you want to design for a mapper that gives you access to the features of the NES you're most familiar with, and can be produced, I'd go with the MMC3.
Understood. It's what one of my friends (E.B.) said and yeah, soon I have to go back to recreating the first scene to make everything within those grouping palette limits.
darryl.revok wrote:I think, for an example, Link in LTTP can move diagonally without a diagonal sprite.
Yup, they all did... except BOF(1) pisses me off by not adding that >< been playing that when I have free time and their movement erks me.
darryl.revok wrote:The animations look really nice. The biggest thing that I'd say though is that the one on the right definitely looks to me like an angled walk. Not horizontal
I noticed that after I finished going through hell with the walking up animation and therefore I ended up editing it after I did the walk up animation. Working on these reminded me why I hate working with low-res so much, but I need to break out of that. I've been too spoiled with HR sprites.

So far the Walking up gave me the most trouble. I either made him move his upper body too much from side to said (and when I sad to much I mean one pixel is like 5 pixels in low res movement :D) or I mistakenly made his ass move too much >< had to redo his arms because it made him look like he was running the first time around. now the upper part seems fine but what still gets to me a little is the legs. no matter how i made them it looked funky to me. At times it look like he was jumping out of excitement from side to side or his leg would go too far out or in. this is close to perfect to me without doing what every darn RPG does. using just two frames. Yeah it works but I rather keep editing until i get it before resulting to doing the same thing as others.

I might have to push the legs back one pixel on the side walking.
Attachments
Early-Dev-Alex.gif
Early-Dev-Alex.gif (7.92 KiB) Viewed 8612 times
Alex-Mugen-Nes4.gif
Alex-Mugen-Nes4.gif (1.81 KiB) Viewed 8612 times
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by lidnariq »

darryl.revok wrote:With a skilled developer, you could do the trick we mentioned that lets you get more than 256 tiles on screen, as in Smash TV. It's an option, and I wouldn't say that you need to know much more about the tech side of that other than just to use it sparingly. It'll take a lot of graphics.
In fact, I'd even argue that for cut scenes, the NES's CPU isn't doing anything but displaying graphics and playing music, so expecting to use all 960 tiles to be more impressive is both feasible and a nice touch.

That said, this is probably the right place to note that the NTSC NES's pixels aren't square. (They're slightly wider, 8/7 as wide as they are tall). And only 224-ish vertical pixels fit on screen at a time.

(The PAL NES is even more distorted: there it's ≈7/5 as wide, but all 240 vertical pixels are visible)

Mockups:
Attachments
Title-Screen_pal.png
Title-Screen_pal.png (28.64 KiB) Viewed 8603 times
Title-Screen_ntsc.png
Title-Screen_ntsc.png (24.78 KiB) Viewed 8603 times
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by Myask »

And, on most NTSC TVs, you're going to lose some of the picture. Official design documents back in the day avoided placing anything important in the outermost 16 pixels on each side, but nowadays you're unlikely to lose anywhere that much--my TV, for instance, loses 16 rows (total) of NES output but no columns. (Emulators can, of course, avoid this completely.)
User avatar
Fjamesfernandez
Posts: 57
Joined: Thu Oct 01, 2015 5:34 pm
Location: NYC

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by Fjamesfernandez »

Yeah once I get the right positioning on things it would be easier for me. That title screen picture is just a place holder to learn a way to shade without having to use much colors. That picture would just make things look too cluttered though the RoboCop had a cool title screen. Though Alex is the man protagonist he isn't a spot light hog like other RPGs.

I am sure I didnt need to animate these but I couldn't help it. IF the animations would be too much in the Battle Screen (turn based) then the animations can be used for Bounties being you have to search for the NMs and pop them any ways. NMs are the only mobs that you would see on screen in the environment.

And as you can see, I dont mind using different palettes and just change the names to make it seems like more mobs lol
Attachments
Mc-Fly-FJF-A.gif
Mc-Fly-FJF-A.gif (2.4 KiB) Viewed 8547 times
Mc-Fly-FJF-P.png
Mc-Fly-FJF-P.png (5.06 KiB) Viewed 8547 times
User avatar
Fjamesfernandez
Posts: 57
Joined: Thu Oct 01, 2015 5:34 pm
Location: NYC

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by Fjamesfernandez »

You think these may be too big? These should be find if you take a look at the grid. I know in most RPGs for the nes they dont move nor do a simple drag the sprite over to the heroes to give the illusion of them attackings like BOF1 for the SNES. but that might work here too.

I didnt want to animate Alex only because there will be two others with him and im sure that would take up too much valuable space, but depending on the space I might be able to do one attack with their weapon just for a default attacking animation and something quick for magic and item usage that can be recycled.
Attachments
Batty-FJF-A.gif
Batty-FJF-A.gif (1.71 KiB) Viewed 8547 times
Batty-FJF-P.png
Batty-FJF-P.png (4.75 KiB) Viewed 8547 times
User avatar
darryl.revok
Posts: 520
Joined: Sat Jul 25, 2015 1:22 pm

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by darryl.revok »

Fjamesfernandez wrote:IF the animations would be too much in the Battle Screen (turn based)...
I'm guessing that the main reason that most RPGs don't animate the enemies is due to the amount of graphics for which there are room on the cart. If you put the graphics for the animations in your cart, I'd put them in the battle, because there'd be little reason not to. Cycling a couple frames during a turn-based battle isn't going to be an obstacle. With MMC3 CHR ROM, you have a total of 256 KB of graphics. If you use CHR RAM, then you have to have the graphics in PRG ROM first, and you have a total of 512 KB for PRG ROM.

I wouldn't necessarily give you the tech specs but in this case I think you'll probably want to know what you have to work with.

You could store 256 KB of 2 bpp graphics on a CHR ROM. With RAM, you COULD theoretically store up to 512 KB of 2 bpp graphics (and even compress them) but every graphic is going to limit how much code your program can have. As far as how much space you'll need for code, I have no idea. Perhaps if someone has completed a similar project then they could give you an approximation but I don't think anyone here has completed an RPG. Actually, the Quest Forge game is the only homebrew NES game that I've heard of but I'm a little out of the loop.

A couple of games used CHR ROM and RAM. I just want to throw out that realistically I'm going to guess the game will take about two years to complete. By that time somebody may have a working production run of the MMC5 or something like the bankswitching RAM we were conceptualizing. But none of that is for sure. What I'm doing personally is designing my game for the MMC3. The fact that there's a limited amount of CHR space to me just gives me a point that I know the project will be done. If I had space for unlimited graphics and code then I'd have a tendency to not know when to stop. :)

I remember when I was a kid and I was really into SNES RPGs, my friends and relatives would tend to think that the games didn't have good graphics, but no other genre of which I am aware typically had that QUANTITY of graphics. During SNES era a lot of the games started to be really impressive even in still frames. As far as I know, the biggest SNES carts were always RPGs.

TLDR: Cart space will ultimately be your limiting factor for graphics. After you do a few characters, enemies, cutscenes, etc, it would probably be a good idea to calculate how much content you're going to have in your game and aim for about 256 KB of 2bpp graphics.
User avatar
darryl.revok
Posts: 520
Joined: Sat Jul 25, 2015 1:22 pm

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by darryl.revok »

Fjamesfernandez wrote:I didnt want to animate Alex only because there will be two others with him and im sure that would take up too much valuable space
If I was going to animate either the characters or the enemies, I'd animate the characters, because you'll be seeing them all of the time. Even FF1 had slightly animated characters. How valuable the space is depends on how long the game is. Do you want to prioritize quantity of graphics or quality of animations? These are the game design choices you have to make.
I might be able to do one attack with their weapon just for a default attacking animation and something quick for magic and item usage that can be recycled.
You may be able to creatively arrange the sprite tiles so that the characters could share graphics for arms and weapons, if that's the way your game works. In a lot of the RPGs, characters rarely have the same weapon types, so they don't have a need to share the graphics.

Your tiles also don't have to be aligned to a grid. Take a look at how my main character is stored in CHR. Notice the split on the legs. The game engine lines the sprites up properly.
Attachments
tilesplit.png
tilesplit.png (1.17 KiB) Viewed 8499 times
User avatar
Fjamesfernandez
Posts: 57
Joined: Thu Oct 01, 2015 5:34 pm
Location: NYC

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by Fjamesfernandez »

darryl.revok wrote:I'm guessing that the main reason that most RPGs don't animate the enemies is due to the amount of graphics for which there are room on the cart. If you put the graphics for the animations in your cart, I'd put them in the battle, because there'd be little reason not to.
Well, Yeah as I said. No enemies will be on the field unless its one NM Bounty that you pop do to day/time/item conditions. Only those would be animated outside of battle. However inside the battles is where they will be animated if there will be enough space to do so.
darryl.revok wrote: Perhaps if someone has completed a similar project then they could give you an approximation but I don't think anyone here has completed an RPG. Actually, the Quest Forge game is the only homebrew NES game that I've heard of but I'm a little out of the loop.
Yeah, its because side scrolls games are much easier and less time consuming to produce, but not the rout I want to go. May be for a spin off but I am not interested in that at this time :D and yes, MMC3 and Rom with what ever mock up you can put together seems the way to go but I can't set anything in stone just yet.
darryl.revok wrote:I remember when I was a kid and I was really into SNES RPGs, my friends and relatives would tend to think that the games didn't have good graphics
Funny how people say that. 8-bit 16-bit etc, you can go back to them 50 years from now and they still look appealing to the eye. Try to go back and play games for the ps1 like FF8, RE1 and so forth and they look so damn horrible.
darryl.revok wrote:Cart space will ultimately be your limiting factor for graphics. After you do a few characters, enemies, cutscenes, etc, it would probably be a good idea to calculate how much content you're going to have in your game and aim for about 256 KB of 2bpp graphics.
Understood. Might need someone to calculate that >< I'd be lost on that part.
If I was going to animate either the characters or the enemies, I'd animate the characters, because you'll be seeing them all of the time. Even FF1 had slightly animated characters. How valuable the space is depends on how long the game is. Do you want to prioritize quantity of graphics or quality of animations? These are the game design choices you have to make.
It would be the characters of course. Quantity of Graphics is aways on top for something like the NES animations you can get away with things just the same as Mario. NIntendo didnt even do a full walking animations. so as far as animations goes you can always trick the eye with the right frames.

And how big would the game be? That I think depends on the player. It would be big enough to last a good chunk of time and slightly fast if they dont want to do any of the extra content. They'll just have harder battles without doing so. Some where around that line. Either way, you always needed to devote time for RPGs especially if they are going to buy a physical copy. Who here loves buying a $65 dollar game to be beaten in a few hours? I sure don't but that's just my own opinion.
darryl.revok wrote:You may be able to creatively arrange the sprite tiles so that the characters could share graphics for arms and weapons, if that's the way your game works. In a lot of the RPGs, characters rarely have the same weapon types, so they don't have a need to share the graphics.
Yeah no they have their own. Already as it is I can't detail the weapons how I want them to be. That's where those Cut Scenes come in.
darryl.revok wrote:Your tiles also don't have to be aligned to a grid. Take a look at how my main character is stored in CHR. Notice the split on the legs. The game engine lines the sprites up properly.
It's a force of habit. Reason why I do it that way at first is because I don't want a tile that has only a few pixels on it. That to me is just a waste of byte/space. Im pretty sure the sword would be on a different layer in the battle, but things will get adjusted accordingly.


With that said I would animate everything just to have it on file. Whether they all will be used or not all depends on the space. So at least I have things to choose from to keep or add in rather than not having enough work to mess around with.
Attachments
Cave-Fatty-Fly-FJF-A.gif
Cave-Fatty-Fly-FJF-A.gif (1.77 KiB) Viewed 8495 times
Cave-Fatty-Fly-FJF-P.png
Cave-Fatty-Fly-FJF-P.png (5.17 KiB) Viewed 8495 times
User avatar
Fjamesfernandez
Posts: 57
Joined: Thu Oct 01, 2015 5:34 pm
Location: NYC

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by Fjamesfernandez »

If that makes any sense to ya'll :D better over than under. I am sure certain things may need to be cut down the line but I also know that none will go to waste.
Attachments
Cave-Gnats-FJF-A.gif
Cave-Gnats-FJF-A.gif (1014 Bytes) Viewed 8495 times
Cave-Gnats-FJF-P.png
Cave-Gnats-FJF-P.png (3.62 KiB) Viewed 8495 times
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by tepples »

Myask wrote:And, on most NTSC TVs, you're going to lose some of the picture. Official design documents back in the day avoided placing anything important in the outermost 16 pixels on each side, but nowadays you're unlikely to lose anywhere that much--my TV, for instance, loses 16 rows (total) of NES output but no columns. (Emulators can, of course, avoid this completely.)
Except for PocketNES on Game Boy Advance, which cuts 16 pixels off the top, 11 off the bottom, and 8 off the left and right. That size also seems to approximate what I've tended to see on actual 1980s CRT TVs. I guess Nintendo was just trying to be safe, even for 1970s TVs.

Nintendo's background design sheets: 224x192, (16, 24)-(239, 215)
PocketNES and 1980s NTSC TVs: 240x211, (8, 16)-(247, 228)
HDTVs: 256x224, (0, 8)-(255, 231)
HDTVs in zoom mode: 256x168, (0, 36)-(255, 203)

As for that bat, if you're using sprites instead of background, they don't all need to be aligned to the 8x8 grid. You can slide individual rows or columns of sprites to use fewer tiles, which saves on both CHR size and flicker.

Image
Naïve coverage

Image
Staggered grid coverage
darryl.revok wrote:As far as I know, the biggest SNES carts were always RPGs.
Not necessarily. Donkey Kong Country was 32 Mbit, the biggest without a coprocessor. And the biggest Super NES game with a coprocessor was Street Fighter Alpha 2 at 48 Mbit. (Star Ocean used the same coprocessor and was also 48 Mbit, but it was made only for the Super Famicom, not the Super NES.)
After you do a few characters, enemies, cutscenes, etc, it would probably be a good idea to calculate how much content you're going to have in your game and aim for about 256 KB of 2bpp graphics.
Until the artist quadruples the length of your game, causing you to revise your initial 128 KiB (1 Mbit) estimate up to 512 KiB (4 Mbit).
User avatar
Fjamesfernandez
Posts: 57
Joined: Thu Oct 01, 2015 5:34 pm
Location: NYC

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by Fjamesfernandez »

tepples wrote:Nintendo's background design sheets: 224x192, (16, 24)-(239, 215)
As for that bat, if you're using sprites instead of background, they don't all need to be aligned to the 8x8 grid. You can slide individual rows or columns of sprites to use fewer tiles, which saves on both CHR size and flicker.
Cool. I will look into it and thank you for making it more visual. That's the way I learn :D as far as the mobs goes right now I am making them sprites but if needed I can make them into BG. Reason I am making more than I need to just to is so that I can have more options open down the line.
tepples wrote:Star Ocean used the same coprocessor and was also 48 Mbit
Whoa! Can't wait to get my translated repo on that.

----------------------------------------------------

Testing out the frames needed for something like this. Isn't too bad but wont know until they are places on their sprite sheet tile grid.
Attachments
Alex-Default-ATK-FJF-A.gif
Alex-Default-ATK-FJF-A.gif (4.41 KiB) Viewed 8465 times
Alex-Fist-IdleFJF-A.gif
Alex-Fist-IdleFJF-A.gif (980 Bytes) Viewed 8465 times
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by dougeff »

Size questions...

I think you picked a good size, my quick math tells me you could reasonably fit 100-200 unique enemies of this size into a game, depending on how many animation frames per enemy.

(Edited)
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
Fjamesfernandez
Posts: 57
Joined: Thu Oct 01, 2015 5:34 pm
Location: NYC

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by Fjamesfernandez »

Frame wise for the mobs they are two frames each. Bath was only 3 because I didnt want to flap it like the insects. Unless the med transitions frame is taken out and the frame rate is slowed down. The up and down can be done via code so you dont have to use tiles for that.

For the heroes im trying to make it as less as possible. I could had mad the idle stance two frames but that was too basic so I made it into 4 frames which if I have to I can reduce that as well. The other heroes will not pass the 4 frame limit for their idle.

Dash forward and back was one frame. Coder can do something to it visual if anything. Punch was two frames but I can reduce it to just one which shares most of the tiles from his idle stance. so yeah.

I will sprite the other playable characters soon. I am creating stuff via updating the story. so each part of the story ive been revising, I am working on at the same time.
User avatar
Fjamesfernandez
Posts: 57
Joined: Thu Oct 01, 2015 5:34 pm
Location: NYC

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by Fjamesfernandez »

Hey guys just stopping by to let you know whats going on. I jstill have my Mugen Project going on that I need to finish up and working on a NES BOX ART. After talking to some people including a programmer I am making some decisions on my nes game. Though my ideas are possible but they were very cut about things that for right now it may be to big of an ambitious game. Now where have I heard that before :D

The amount of hours + pay for a game my size may be too much even for a kickstarter with so many games being on it. So right now I have mixed feelings and may (for right now) make a spin off from the story and if I can generate anything from that (making a physical cart) and find a dedicated programmer or team I will go back to original idea.

I just need some time to think things through and plan them out. Ill still post up some art for both main and spin off. I have something in my head... I just need to put it down on photoshop.

Am I disappointed? Of course, but I rather do something short and see it finished than working big and find no one that is good and welling to put in the hours to put it together. I ain't rich, thats for sure :D
User avatar
darryl.revok
Posts: 520
Joined: Sat Jul 25, 2015 1:22 pm

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by darryl.revok »

Well, it would be a shame if it didn't happen. I for one was excited to see what you'd come up with. With that being said though, developing for NES can be a lot of work and it's not a project to undertake lightly. There's usually not as much possibility of monetary return either.

Have you ever thought about doing any of the programming yourself? Have you ever programmed before?
Post Reply