Learning NES Pixel Art with restrictions

[Fjamesfernandez]

Yeah I can see he did a lot himself but still had help haha. And besides once you involve 3D anything, spriting and animating becomes so damn easy. UNLESS you are SNK and decide to put 20 color shading like KOF13 lol which at first testing took them 5 years just to make one character.

I still say that the dude knew already how to code. so he doesnt count!

[Drew Sebastino]

And besides once you involve 3D anything, spriting and animating becomes so damn easy.

You know what? I'm surprised that not many people have just had 3D models, posed them, and then drawn over them instead of just taking a picture of them. You'd get the basic shading and details from the 3D model, but it would still retain the 2D look. Why don't many people do this? I guess it's because they don't want to bother with 3D models or in the case of the NES, it wouldn't help much more than just drawing sprites normally, while with 4bpp graphics, it could greatly help. This is probably what I'd do if I'd make a fighting game.

Also, I think the difficulty involved in programming is a bit overrated. I'd say the hardest part of programing isn't necessarily programming, but just figuring out how to accomplish something with the limited recourses a system has. It's like me and trying to figure out how to effectively use vram for sprites on the SNES. Once I thought of dynamically allocating 16x16 and 32x32 sized sprites, it wasn't that hard to do. However, I'm dumb and keep adding features to make it better but more complicated and running into even greater versions of the original problem. Luckily, on the NES, you shouldn't have this problem.

I'm pretty sure some people, including myself to a degree, could help you learn how to program on the NES and provide you something to start with.

[psycopathicteen]

Have you actually got your dynamic animation engine working?

[Drew Sebastino]

Nope. School sucks. Instead of just making something crappy and improving it along the way, I'm trying to do everything the first time.

[Rahsennor]

Instead of just making something crappy and improving it along the way, I'm trying to do everything the first time.

I used to think that way, and I have to say it didn't work. After 14 years with nothing to show, I decided "heck with it, I'm going to do the simplest thing that could possibly work" and wrote a Mario clone from scratch in two weeks. The faster you get feedback, the more motivated you are to keep working, and the sooner you actually get things done. That's what works for me anyway.

...it's not helping me learn to draw any better though. I just don't seem to have the right brain for this. Much respect to artists like Fjamesfernandez - I find your work here very impressive.

[Drew Sebastino]

I always wondered, Fjamesfernandez, did you actually draw your profile picture? It looks like something straight out of a CPS2 game!

[tokumaru]

Instead of just making something crappy and improving it along the way, I'm trying to do everything the first time.

I used to think that way, and I have to say it didn't work.

And I have to say I agree with you. trying to make everything perfect from the start never got me anywhere. All the times in my life that I actually got something done only happened because I heavily cut back on the amount of planning, and focused on getting things working, and refining them later when necessary. You shouldn't rush it too much though, because you can end up with something unmaintainable that may prevent you from going forward.

[tepples]

Or to put it short: "Do the simplest thing that could possibly work." --Ward Cunningham

[Fjamesfernandez]

I always wondered, Fjamesfernandez, did you actually draw your profile picture? It looks like something straight out of a CPS2 game!

Nah, My pixel artist team mate Sol Blazer did that for our Character that will be released in Mugen soon. He studied the SF2 portraits and mimic the style. I've done the same fusing styles to make it my own.

[Fjamesfernandez]

So the idea was this. There's a part in the story were the main character is poisoned and knocked unconscious and someone is using a technique to bring him back. Upon doing so that person is lunged into Alex's sub conscious and that person is trying to keep Alex alive and bring him back.

In the story (RPG) I don't tell this part. The Person just saves Alex and the story continue. So this will be like a side quest. Hense this being a spin off to the RPG to make something short and not so crazy at the moment.

So think of it as a Hoard Mode. You will be timed in each stage. To complete the stage you need to find those post that looks like a brain and destroy them. Those post will spawn enemies that will try to stop and kill you. Destroying them will stop the enemy spawn in that location. Destroy them all and a portal will suck you in and throw you into the next area with the same concept but with different enemies.

The radius of the stage will be the same four panel 128x128 (x 4). This will give it a little side scrolling side to side and up and down, but not too big. These stages are meant to be like chambers with in your body where your soul may lay dormant before dying.

Completing an X amount of stages will toss you into a boss. Defeating the boss will take you to the next level and grant you a power up. that you can choose in and out of via menu OR maybe toggling throw it by pressing select but I may need to add another icon so you can tell which is what power up for your weapon.

Red bar is your health, blue bar is your magic to summon your sword, and the green bar is your enemy or boss health. I may just make it the boss health and when you arent fighting the boss the number score will take over.

Should be able to make it two players without over kill. Question is if those brain things spawn enemies I would want the to be BG and not sprites but youll be able to still hit it. But I wonder how we would go about that. I would had wanted to make it flash but if its apart of the BG I am not sure how that would work.

[Drew Sebastino]

I would want the to be BG and not sprites but youll be able to still hit it.

That shouldn't be any more difficult than checking collisions with a sprite vs. another sprite. If it's a really complex shape and won't work with just a hitbox, you could probably treat it like BG collision then where it sort of checks tile per tile.

I would had wanted to make it flash but if its apart of the BG I am not sure how that would work.

It wouldn't be any different that a regular sprite. What kind of flashing do you mean anyway? Like full white, or invisible? Since the BG can really only be by itself, if you want it to flash invisible, you could just change all the colors in it to be the same as color 0. However, if you want sprites to be behind this and have it flash invisible, you would actually need to make it to where all the pixels of every tile of boss is using color 0, by changing the tilemap, changing the tiles, moving it offscreen, or probably the easiest/best way, turning of the BG midscreen. Or, wait, is this boss supposed to move or be stationary? If it doesn't move, than you should probably use the BG for the scenery also. If you want to make it flash invisible, then either change the tilemap to tiles that looks like the ground underneath it, or actually just change the tiles.

Also, how in the world do you plan on accomplishing that translucent bumble bee thing? If the BG where 3 colors underneath it, you could actually fake transparency by having the sprite above it an exact copy of the BG, just colored brighter or darker or whatever. However, it couldn't move, unless you redraw the sprite to look exactly like what's underneath it using CHR RAM or something.

Also, just a word of advice, I'd personally make the sword/staff thing part of the character's sprite and use the same palette.

[Fjamesfernandez]

That shouldn't be any more difficult than checking collisions with a sprite vs. another sprite. If it's a really complex shape and won't work with just a hitbox, you could probably treat it like BG collision then where it sort of checks tile per tile.

Its just the Brain area.

It wouldn't be any different that a regular sprite. What kind of flashing do you mean anyway? Like full white,

Yes full white to make it look like its flashing in and out of white. No sprites will go behind that object.

is this boss supposed to move or be stationary?

For the most part the bosses are stationary. First boss I am designing will stay one place but his hands will be doing the work. when he changes in and out of a certain form his face will appear to do the damage but he will be able to do a new attack when this happens.

Also, how in the world do you plan on accomplishing that translucent bumble bee thing?

I just did that for sure. if through code you can fade things in and out im guessing this will be okay. if not then you can flicker it to show that its spawning and solid when you can start attacking it.

Also, just a word of advice, I'd personally make the sword/staff thing part of the character's sprite and use the same palette.

Hmm not sure about that yet. He wont have the sword as default. You are only able to use it when you have a full magic (sprite) bar which will deplete when you have it out.

[darryl.revok]

We get it. You like Irem and don't like Metal Slug.

Wait a minute... I thought he liked Metal Slug? Now I'm confused. After seeing so many pictures of Metal Slug animations, I thought that was to say, "Metal Slug is awesome!" Although I'll say honestly that I remember playing those games and enjoying them quite a bit and I don't remember the frame rate particularly bothering me. Super R-Type and Gradius III I remember the slowdown being bad.

Pressing Save All (Ctrl+S) then Build and Run (Ctrl+R) is pretty instant for me

I agree, although I've taken to Ctrl+Shift+S to save all, after spending too much time looking for a bug due to not all of my includes being saved.

This is surely different for everybody, but I actually feel more rewarded doing the coding. I was dreading it in the beginning but it's really fun. For me, I think it's the satisfaction of achieving the result that I want. With programming, even if the code isn't perfect and still needs a lot of refining, you can get it functioning to output the results you want. With coding, I write a rough version to get it to work, without thinking much about optimizing, and then a rewrite phase to optimize it the best I can. With pixels, your result is what you did. There's nothing under the hood.

None of my graphics are yet exactly where I want them to be, so while I feel rewarded to get close, I feel like I end up getting frustrated because there are things I want to improve and I don't know how to do so. With the code, everything probably still needs a little tweaking, or will need to be adjusted when I add more features, but there are still parts that do exactly what I want them to do, from the perspective of the player.

There's also the fact that I've wanted to make an NES game almost as long as I can remember, so I couldn't possibly hide my excitement from seeing my work running on the console.

Nope, though you can copy and paste what you are doing here for others to analyze it then you have to worry about someone saying you used his code without telling him/her. I'm only saying that because ive seen that said at Mugen Fighting Guide. People be bitching about stealing codes but never complain about using resources for sprites or frankenspriting.

I'm curious if anything along these lines has ever happened around here. As far as I can tell, everybody's pretty cool about helping one another out, posting code snippets, and respecting one anothers' work. It's a pretty small group, and as far as I can tell, everybody who's active here is pretty passionate about making their own contributions. Sometimes that contribution is sharing a technique for others to understand and use in their project, and sometimes that contribution is a unique game. It seems like a lot of the members here are also pretty adamant about making their own game completely by themselves.

Instead of just making something crappy and improving it along the way, I'm trying to do everything the first time.

I used to think that way, and I have to say it didn't work.

Chock me up as another one who agrees with this.

Hense this being a spin off to the RPG to make something short and not so crazy at the moment.

This does seem like a project which could be done much quicker, and would get you some attention for the eventual RPG if you do it.

The radius of the stage will be the same four panel 128x128 (x 4)

I think you may still be confused on this, or I'm misreading.
Screen size is 256x240, so if you're saying that your game area is two screens wide and two tall, the total resolution would be 512 x 480

I'm personally a fan of SMB3 style scrolling for a situation like this. Basically, SMB3 (in a 4 way scrolling level for ex. Lvl 1-1) draws 2 screens vertically all of the time. This lets the screen scroll up and down without even having to load any tiles. Tiles are only loaded when the screen scrolls horizontally.

The standard approach to 4-way scrolling is to draw both rows and columns around the screen area. This has the benefit of allowing for as much scrolling in any direction as you want. It's definitely more flexible, but there are more things to worry about when it comes to corner tiles and things of that nature, and it's probably going to be a bit more processor intensive.

Basically, I'm just saying that if a game or a level only scrolls two screens high, I'm a fan of using the simplified method of scrolling they used in SMB3. Kind of like tepples said, "Do the simplest thing that could possibly work." If you ever feel like opening SMB3 in an emulator, and going to view the nametable, you can see exactly what I'm talking about.

Should be able to make it two players without over kill.

It can surely be done, but adding two simultaneous players adds a lot of concerns.

One thing I would think about, have you ever played Contra on a vertically scrolling stage with two players? If so, then I'm sure you're familiar with the phenomenon my friends and I have termed as "scrollf*cking". In this game, if a player touches the bottom of the screen, they're dead. If the player on the top jumps to dodge a bullet, bottom player dies. It is by far the most annoying part of these games.

I was randomly thinking about this the other day, even though my game isn't going to be two players. I was thinking about how I might address this issue, and I had an idea. What if, when the players were too far apart vertically, the screen split? That way, nobody dies and nobody has to go off screen. If the screen is only scrolling vertically, it would be easy to separate the screen halves and rejoin them when close enough. If the screen scrolls in two directions and one player could leave from the bottom and rejoin on the side, it would make it a little weirder but I'm sure there's a decent solution.

If it's a really complex shape and won't work with just a hitbox, you could probably treat it like BG collision then where it sort of checks tile per tile.

Minor issue but I think it would be better to put a hitbox object on top of it. Here's why:
Sword object would have no reason to check against background collisions otherwise. So not having this as a BG object could eliminate the need to do that check in the first place.
BG collisions are generally a bit more intensive than object collisions. This is because BG collisions require finding position on the map, calculating metatiles to read, unpacking collision data, checking multiple tiles, etc. With object collisions, you have the data that you need for the computations available in RAM.
Since collision data is typically tied to metatile data, that means that in most games the smallest unit of collision for BG is 16x16. With an object hitbox, this can easily be changed. It would be easier to make complex shapes out of hitboxes than BG tiles.

For the most part the bosses are stationary.

Using scroll splits, you can move a BG object as well. Think of it like this:
You can only create a horizontal line that splits the scroll. No vertical splits.
If, for example, you had the boss on the top portion on the screen and the ground on the bottom, you can set the scroll for the top portion of the screen independently from the bottom, and move your boss.
Basically, you can take your background and slide it around to move your object.

A one man team. Only person I give props to like that is who I mention. Tom Happ for developing Axion Verge by himself.

It's a different sort of thing, but I definitely give props to those who went before, discovered the information about developing for the NES and posted it for the internet. I know I definitely wouldn't be making NES games if people hadn't spent years refining the knowledge base and creating the resources for people to learn how to do so.

[Drew Sebastino]

Wait a minute... I thought he liked Metal Slug?

Clearly we don't get it.

Although I'll say honestly that I remember playing those games and enjoying them quite a bit and I don't remember the frame rate particularly bothering me. Super R-Type and Gradius III I remember the slowdown being bad.

Well, I had found out that all the games run at 30fps, something that bothers me, even if I couldn't really notice it beforehand. I'm weird like that.

However, Metal Slug 2 constantly slows down, and it already targets 30fps, so not only is it slow, it's also choppy. They made Metal Slug X which is like Metal Slug 2 except it (tries to) eliminate the slowdown, but they changed enemy placement and did things that I like less. If you can play an overclocked Metal Slug 2, that's the way to go.

However, I'm not way too crazy about the over "cartoonized" characters, especially in a game like this. This is a good comparison for what I'm talking about.

Gunforce 2 vs. Metal Slug.png (2.53 KiB) Viewed 6273 times

[Fjamesfernandez]

I think you may still be confused on this, or I'm misreading.
Screen size is 256x240, so if you're saying that your game area is two screens wide and two tall, the total resolution would be 512 x 480

what I meant when i said 128x128 was the 8x4 box (the color palette radius) so I really mean is the what is it 250x240 players view. So think 250x240(view) x 4(view panels for scrolling)

This does seem like a project which could be done much quicker, and would get you some attention for the eventual RPG if you do it.

Yeah to get the feel out there and maybe generate a fan base, some revenue to work on the full RPG, and anything else that would help a long the line. This still is apart of the RPG but like I said, its a part that I didnt mention in the story itself which youll get here. Its a straight to the point story but it will build up for the RPG and youll see enemies and bosses that you would had seen in the RPG... just not all of them and vise verse

I'm personally a fan of SMB3 style scrolling for a situation like this. Basically, SMB3 (in a 4 way scrolling level for ex. Lvl 1-1) draws 2 screens vertically all of the time. This lets the screen scroll up and down without even having to load any tiles. Tiles are only loaded when the screen scrolls horizontally.

Yeah though I wouldn't make the stage that long. Think of battle kid's Screen by Screen loading but instead of loading in one screen at a time you get to scroll through a 4 panel. These are chambers rather than SMB3 full stage that all you pretty much doing is going left to right to finish.

It can surely be done, but adding two simultaneous players adds a lot of concerns.

Yeah I was thinking about all of that. That's one of the things I even hated in Secret of Mana. Damn NPCs would get stuck on a block and prevented you from walking to the next area forcing you to either walk back to the NPC so it can get off the block or you had to switch to that char to fix it ><

So as of right now maybe to focus on one player and slowly work towards a 2 player function. Two player isn't really needed but was just a thought. But the split screen seems nice though I haven't seen it on a NES game that I've played. But then slow downs and scan line limitations may cause issues with that.

Minor issue but I think it would be better to put a hitbox object on top of it. Here's why:
Sword object would have no reason to check against background collisions otherwise. So not having this as a BG object could eliminate the need to do that check in the first place.

Yeah I was trying to avoid having too many sprites on screen, but I guess it will be fine as long as I place the spawners in a way that wont cause scan limitations. It was driving me crazy that it couldnt have its own palette to begin with haha. So making it a sprite would be better.

As far as I can tell, everybody's pretty cool about helping one another out, posting code snippets, and respecting one anothers' work. It's a pretty small group, and as far as I can tell, everybody who's active here is pretty passionate about making their own contributions.

Yeah honestly sometimes smaller groups are better than an all out forum and everyone that has commented here have been very helpful and knowledgeable. So everyone has my thanks including you

I know I definitely wouldn't be making NES games if people hadn't spent years refining the knowledge base and creating the resources for people to learn how to do so.

Yeah.