nesdev.com

Hello all!

I have been a Nintendo lover, well, the majority of my life, and creating NES games was the second idea that I had for what I would like to do for a job, right after fighter pilot.

Anyway, I started experimenting with programming at a young age, primarily with BASIC, as that was what was available to me. My interests in designing games waned as game technology shifted away from 2D graphics, and I found myself involved with other interests. Sadly, as a child in the early 90s, I didn't have access to wonderful resources such as this site on 6502 assembly or even knowledge of what was actually entailed to program an NES game. Had I known, I would never have started with BASIC and would have jumped straight into 6502.

Now, as an adult, I find myself very fond of the games from my childhood and assembled a pretty nice NES and SNES collection. But playing these games once again stirred the desire to make my own contribution to the gaming library of my favorite consoles. Luckily, this time, I'm armed with the internet and thirty years of information dissemination on programming for them.

So, I've started on the trek of learning the code, and I've began reading and rereading tutorials and familiarizing myself with the syntax. It's a lot, yes, but the simple fact alone that the information necessary to create functioning programs for an NES console is available, is thrilling to me, and would have blown the mind of my childhood self. One can actually commit themselves to learning to create an NES game, as many have. That concept is very exciting and that excitement has brought me here. I've been reading through the wiki and forums for a while now and I would like to be a part of the community.

So, what has brought me here for my first post are some sprite graphics that I did yesterday. This is about the better part of a day's work here, but it was my first one and there was a lot of redoing. By the time I got familiar with the constrictions of designing in 16 x 32 with 3 colors, I did the last ones much faster.

So, the first ones that I designed were the attack animations 1 - 4. I was having troubling visualizing how to portray my character with so few pixels, so I actually started with 64 x 64, then reduced the size by half. That honestly, looked like crap, BUT, it helped me figure out where the few pixels I have to work with should go, then I reworked those, and from then on started designing in 16 x 32.

For the walk cycle, I adapted frames from Moon Crystal. This is a beautifully animated game with a not too dissimilar character style from mine, so after some adjustments I feel like it looks pretty decent. I found the Moon Crystal sprites on Spriter's Resource, and it appears that they were ripped by a fellow named Domobot, so thank you for that.

Now, I realize that having so many animations is going to eat up my CHR space pretty quickly, so I started considering how to design things most efficiently. I went through my frames and tried to identify any that were very similar, and if possible without hurting the animation, I modifying some of these to be the same. So, I believe there are 15 duplicate 8x8 tiles in the 8 frame walk cycle. Am I correct in assuming that I could reuse the other tiles to save space?

When I placed the images in a 32 x 16 space, I aligned the feet to the bottom, and basically, the head moves one pixel counter-clockwise each frame. So it goes up, then left, then down, then right. The tiles that I reused are the ones where her head is in the same position. Her arms and legs are in different spots, but sometimes I could reuse the bottom of her feet too. I'm wondering though, since her head mostly stays the same and just moves a pixel, if this is more efficiently done by drawing a new tile, as I did, or by shifting some existing tile. I'm not even sure if this would work, as it seems there would be a gap, but basically I'm just trying to consider if I am doing things as most efficiently as possible.

I'm hoping that after I draw a couple more animations, I'll have tiles for most of the body positions, so hopefully I can give her a lot of varied moves without using too many tiles. I don't know how many moves I'm going to give her, but essentially as many as is practical. Any thoughts on a common amount of tiles to use for the main character in a 1-player NES game? I'll probably exceed common, but I don't want to go so far that all of my enemies and locations feel generic.

Now, I know that the colors are not NES colors. I just kind of picked what looked decent to help me design. I can always change them easily later when I find out exactly what colors I have. But then again, the color information won't really be stored the same as in a graphics file so I'm not sure if that really matters for this step, other than for art direction.

This is my first draft but I hope to get any feedback that I can early so that I can start on good habits. The idea for the animations is that when she walks, her sword is sheathed, but after she attacks and her sword is out, I'd like to give her different combo attacks where she could move from one attack to another. So the uppercut attack animation is meant to follow the normal attack. If there are any suggestions that anyone has for making these work more efficiently, look better, or just anything at all, I'd love to hear it. Thank you very much for looking!

Looking good so far.


That can pose a problem with NROM. It's not quite as much of a problem with bigger cartridges such as UNROM/MMC1 class or MMC3/FME-7 class. With UNROM or SGROM/SNROM, you can stream tiles from the ROM into video memory as they're needed. And with MMC3 or FME-7, you can break the 256-tile sprite area into four 64-tile windows that you can switch individually, one for the heroine and one for each of three enemies on the screen.


Yes, you can reuse them. Some engines prefer to reuse 8x16 tiles for various reasons. You can even reuse tiles if they're not at the same relative position within a 16x32 pixel bounding box because each 8x8 or 8x16 pixel piece can be placed individually.


Nowadays, with memory being so cheap, you can have almost as many tiles as you want, so long as you don't go through them faster than about 12 fps.



This is why you'll never see a 50 Shades of Grey game for NES

_________________
Pin Eight | Twitter | GitHub | Patreon

05-11-36 would be the closest, right? (actually not 36 since in the original it's white but let's liven up the colors a bit =P)

EDIT: actually maybe 37 is better. We'll see.

EDIT 2: there, added the graphics with the palettes I mentioned. Yeah, 37 looks better indeed. OK honestly it's just subjective. Also I just realized I forgot to remove a line... whoops >.<

Looks really nice!

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

It looks absolutely awesome for a first design.

Really, the only criticism I can come up with is that the boots appear to shrink in some of the slashing frames vs. the walking ones, but other than that, it looks really good. (Also, on one of the slashing frames, the outline on the legs disappear.)

Thanks everyone!

I've done some more. I'm constantly going back and revising the old frames, so I'm going to hold up on putting them up frame by frame until I hit a wall, just in case someone was to do an edit and I already edited mine.

For the colors, I picked 6-37-21. 36 looked a little too pinky to me. My original palette was really dull and bland, so of the NES colors I tried, I preferred those to ones which were closer to my original colors.

Yeah, I agree with the boots. That's something that I just now noticed but I haven't tweaked it yet. I think I'm about done for the day. The walk and jump frames I adapted from moon crystal where his boots were much bigger, but the problem I'm having with the shoes is making them both A) define her foot position and create a sense of movement, and B) fit the anime SD chibi style of the drawing which has extremely small feet. I'm not sure exactly how to tackle them on the walk, and I think that issue is even more obvious on the jump. Another thing that was bothering me was the sheath. On my jump animation it was changing size, which I believe I just fixed, but it doesn't seem rigid in all of the animations, especially jump. It looks floppy. I'll fix that shortly. I noticed some of the outline issues yesterday and fixed most of them. Sometimes I find more though, especially when I realized that I had drawn in a layer other than the one at which I was looking. Originally I didn't have an online on my first drawings. The outline was throwing me off at first but now I feel it really helps define the shapes in a limited number of pixel.



So, I'm still fuzzy about my limitations, but I suppose I'll worry about that when I get to the game engine and just worry about making good animations while I'm doing that. Even if I had 64 tiles per character, my walk cycle alone is 64 minus duplicate frames, so there may be some issues loading up the next animation. However, these kind of things have been accomplished with the NES on numerous games so I'm sure it's possible.

Here's an animation of her jump cycle, then jump attack, landing with her sword back, then going between standing and crouching with her sword back, then a crouch attack from behind. That may sound a little confusing but I'm sure it will make since when you see it.

I've made a flowchart of all of the moves I want to give her and what she would be able to do from each position. I'll post the animations up as I get them done.

I guess it depends on the intended ethnicity.


An SD-proportioned character can swing a weapon, but she'll need feet big enough to put some power behind it.


Michael "Dark Ness" [Fisher-Price Little People]


Charlie "The Bat-Man" [Peanuts]


"Swing for the Fences" [Precious Moments]


With an MMC3-class CHR ROM board, you can use multiple 64-tile banks because you can switch to another bank at any time, even in the middle of one animation.


I've had success with the Battletoads technique. With a CHR RAM board, you can load in tiles continuously and switch to the next frame once it's loaded. An 8-tile walk cycle can be loaded in one frame; the sword swing frames with 12-16 tiles would take two frames to load. With Disney-quality 12 fps animation, you get 5 NES frames per animation frame. So this is fine so long as you don't try to go excessively fluid on the enemies too.


Looking great so far.

_________________
Pin Eight | Twitter | GitHub | Patreon

This is the old palette (it was the only picture that was the right size, and it can be easily changed) but the frame without the outlines was fixed (some of the others where actually missing in some random spots)


Also, I'm sure you know this, but if some 8x8 tiles in different frames are exactly the same, they can be reused, like the hair in the walk cycle. Also, depending on how you are planning on making your metasprite code, everything still needs to be made out of 8x8 tiles, but they don't really need to be on a "grid", if that makes sense.

Also, this is just my opinion, but I like the thicker boots better. The other ones are unnaturally small. Also, if you plan on using a blue that light, you might want to consider making the eyes brown because it is hard to see them now because there isn't enough contrast between the face and the eyes. I do think the light blue looks a lot better for the sword slash though.


That name is certainly something...

I was reading about the Battletoads technique last night, and a post you made about predictive loading. It was very interesting.

So let me see if I've got this right. So, 8 tiles per NES frame.

I'm drawing at 6 fps which to me looks pretty fluid for NES. That should be 10 NES frames per animation frame.

So between each drawn frame, I have the potential to load 80 tiles.

When you consider all of the options for the animation that could happen next, say, will the player walk, attack, crouch, get hit, attack upward, the first frame of which is usually at least 8 tiles, and then the enemies, I can see where an idea like the predictive loading could come in handy.

Does that tile load include for the background as well? Am I correct that the PPU can have 256 sprite tiles, and 256 background tiles at once? If that load speed is separate from the background tiles, then it seems a pretty workable limitation.

Thank you so much for all of your help and feedback and for the color palette file!

Hey thanks! I'll compare them to the changes I already made. I've probably fixed a lot of that stuff but you may have had some different ideas about how to do it. It may be helpful to check out.



I definitely agree about the eyes. It was okay when I had it blown up but now I can't see them. I can't make them brown or then they won't be visible against the hair. I think I'm just going to have to find a better blue. As for the feet, I guess I'll have to do some side-by-sides. I tended to prefer the smaller ones but I understand the reasoning why others would prefer the big ones. On one hand though, the larger boots become a little tougher to draw in a small space without making a mush. I had highlights on them in my original design so that might be an option. One of the most important things in animation and platform games is for the character to have a sense of weight, and bigger boots might actually help a little at that. At the same time though, I want her to feel really agile, kind of like Mega Man X, and having small feet she could dance around with might help with that. Sometimes SD anime characters just have like little points for feet and that's what I had drawn first.

Thanks again!

It doesn't matter if the tiles you're loading are for the background or for sprites (the same tile can even be used for both, under certain circumstances), a tile is a tile. If your engine can update 8 tiles per frame, it's up to you to define how many of those are for the background and how many are for sprites.


Yes. Some mappers allow access to more tiles, but generally it's better to work within the limits you mentioned.

Tile and nametable updates goes through the same interface ($2007) and timing (vblank), so it's a shared resource. You can very easily send 64 bytes in one vblank. If you're skilled you can probably manage 128. There are some advanced techniques to get even more.

You'll spend about half your vblank uploading sprite and palette and probably some other upkeep. An efficient routine could push 128 bytes in what's left of the vblank.

For a scrolling background, you might get away with as little as 32 bytes per frame dedicated to it, but 64 might be more convenient. You might have enough left over for 4-6 tiles.

I made the character a bit less wonky looking in my opinion. I think the sword swipes can be improved to look more like the latter ones you made, but I don't feel like doing that right now. You could try to find a color somewhat in between the two, so the eyes and the sword swipe look good.



Well, I'd say if you're not doing too much, try to use the stock NES, but I wouldn't constrain myself if you end up planning on making something really crazy. I'd really like to see something like Metal Slug on the NES in that you have large elaborate backgrounds made of tons of unique tiles and lots of frames of animation for objects.

Most of the time, you'll be changing only the map. An 8-pixel-wide column of map spaces is 30 bytes; a row is 32 bytes. Each of these is 2 tiles of vblank time, plus about another tile's worth of time to upload updated attributes for the new tiles. Actually uploading new tiles for the background most often happens once the camera gets to a new area.


The code I posted in the other thread will manage 128 no sweat.

Do you plan to scroll in 2 directions on each map (like SMB2, Metroid, and Mega Man) or in 4 directions (like SMB3)?

So about the sprite cels: It might be easier to see the boots if you include some non-brown detail on them.


That's why Sonic's red sneakers have a white stripe across them.

DRW would be pleased with the direction of this project.

_________________
Pin Eight | Twitter | GitHub | Patreon