Learning NES Pixel Art with restrictions

First off, I want to say, "Hi" to everyone being that I am new here

So what am I doing here? For the past years I've been working on nothing but High Res Pixel art for MUGEN. Ignoring the hell out of Low Res sprites, but the pass recent months (while helping two of my friends) I started to work on Low Res sprites. The Lowest of them all with super limitations... NES SPRITING! Ha-ha I would be lying if I didn't want to smash my keyboard for how limited your space and colors are

So for doing things like this:



To NES Graphics, its stabbing my brain out I give nothing but respect and praise to though who can workout the limitations the right way. So here I am trying to do the same thing. Lets just hope it goes the right way.

Now, since I've been helping those two, I went back to continue writing my story that I had stopped the process a few years back... Well more than a few and decided to make an RPG out of it for none other than the NES! Mind you though, I have very little knowledge on what can and can not be done on the NES and I didn't want to bother the other two with my 101 questions. I am a pixel artist, not a coder. But I want to design with the mind set of a coder because I think it is very important for a pixel artist and a coder to be on the same page.

Right now I just want to get the graphic design part down and worry about the rest later but I would still like to know if certain things can be done. I was hesitant to show the first opening world/stage that I've been working on for the past week... or was it two? Ha-ha

I had to update and tweak things a few times before getting it right and have no palette issues >< I felt like exploding after words >< Everything here was done from scratch other than researching tiles and what not to do and things to avoid. All I have every sprited was characters. This is my first time doing environments/stages.

<Training 1 by myself FJF>

One of my questions I had was, is it possible for the NES have a time cycle? Or should it just be triggered in an event?

<Environment Time Cycles>

As I am designing I always ask myself if certain things can be done but not being a coder or fully understanding the limitations and no one to turn to this is where you guys come in I don't want to post up progress after progress, but I will when I have certain ideas that I am not sure if the NES can handle it. I just dont want to design stuff and then having to scrap it. Its a waste of time lol

In Mugen all you do is sprite/animate and the rest is up to the coder. As a spriter you dont need to worry about much other than keeping your animations together with the palette and not worry about much of any limitations.

Thank you for taking the time on reading this post and I hope you guys and gals like what you see. Thoughts and comments are welcome as always.

Definitely. Friday the 13th has a day/night time cycle, as does Simon's Quest, although the latter tends to catch a lot of flak for stopping the game to perform the palette change.

I'm guessing you're pretty aware of the palette and size limitations. Also, keep in mind that you only have access to 256 8x8 background tiles at one time.

Looking like a good start so far! Good luck with NES development. If you need help, don't hesitate to ask. The beginning is always going to be the toughest part.

That's a funny question for an artist to ask, since it has nothing to do with art! Anyway, any computer that can do games can simulate the passage of time. It's just a matter of incrementing a counter at a fixed interval. Then, when the counter reaches specific values it can trigger events, like palette changes/animations or anything else, really. What you can't do is have time pass while the console is off. For that you'd need a clock (and a battery to keep it running) in the cartridge that could be read by the program. Some Pokemon games on the GBC had that. It's possible to create a cartridge like that for the NES, but AFAIK, it hasn't been done yet.

BTW, the sprites are looking good so far.

@ darryl.revok:



Wow, I have completely forgot about FT13 and I never got to play Simon's quest, but that's good to know.



Yes. A friend of mine took his time to explain it to me. It took me a little to understand all of it. You basically have 4 palette groups. Pal(1) - Pal(2) - Pal(3) - Pal(4) That's 16 colors with transparency included. So you only have three colors in each palette. One of my palettes is strictly for my Hub the other 3 is for my environments. The character sprites aren't included.

Reason why I asked was because one, its your classic random battle so there wont be any visual monsters running around (still a thought) but I did wanted to include certain mobs that you can see at specific times in the game.



Hmmm... yes the gif you saw was 256x240 if that's what you meant. I just enlarged the gif so you guys can see it clearly.



Thank's will do. Love your pixel art animations too. I looked at some of your work a few days ago while doing my research



Oh how I know this very darn well. Took me 10+ years to craft my spriting. Hell I am still learning. There's no end.

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

@ tokumaru:



I can't help it! That's how I stress myself out to the fullest. Every time I work on an animation I think to myself is it possible or is it going to cause issues. Well not every time but you get what I mean.



Great! I was worry of two things. (1) that if a person is camping for a mob in a stage that you couldn't make the cycle go through unless you zoned out and came back. (2) If only way to cycle was that the nes would had to do like a loading screen and thought that would mess you up while in a random battle where it kicked you out of the fight or something like that haha. See what I mean? I over think things.



Oh don't temp me! I am known to take on challenges haha



Thank you. The char sprites are just place holders at the moment until I crank out a sprite style. Kinda hard with such limited space >< but I have to over come them.

Re:256 tiles. I think you're misunderstanding. The background is constructed from arranging tiles. The PPU has access to 256 unique ones for background and 256 unique ones for sprites, at any given time.

Technically, you could have more than 256 on screen...by swapping ROM banks mid-frame, but very few NES games do this.

The same for Sprite colors, technically you can layer sprites on top of each other, so you could have a sprite that uses 6 colors (2 sprites on top of each other). But, the NES is very limited with sprites, so use this only sparingly. It is more common to have a character constructed out of sprites that use different palettes...like head one palette, shirt one palette, pants a third palette.

So, for the boy walking that you posted...
1st palette pink, orange, brown...most things
2nd palette yellow, white, black...face/hair
3rd palette 2 blues, white...pants and socks

This is a thing I wrote a while ago for pixel artists about NES stuff: http://wayofthepixel.net/index.php?topi ... #msg115062 (I've been meaning to update it to make it easier to read. Also, wow, broken image will try to find the original.)

That post links to this post, which may be a little easier to digest: http://wayofthepixel.net/index.php?topi ... #msg144531

Here's another somewhat similar topic: viewtopic.php?f=21&t=10808

NES is somewhat complicated in that different cartridges can make the limitations different.

Your NES art seems to be falling into the trap of making the grid very obvious. While yes, NES graphics are tiled, it doesn't necessarily need to look quite like that.

Check out some of surt's work: http://pixeljoint.com/pixelart/96743.htm
Or ptoing's: http://pixeljoint.com/pixelart/80652.htm (Sorta breaks some rules, but still good reference.)
And then there's this for a darker, late game style: http://imgur.com/a/kUrra

I only mention this because your non NES art is good, and your NES art is very, very basic. People starting out with tiled graphics tend to draw inside the grid. Instead, try drawing stuff regularly (with color limitation in mind) and edit it to fit the grid later for a more organic look.

That's the proper resolution but that's not what I was talking about. You've got 32 x 30 tiles on your background, so that's a total of 960 background tiles that are displayed on the screen at one time. (I suppose to be pedantic you could say it's possible to have more than that showing if some are half scrolled in.)

What I was saying is that the background tiles that are being drawn all have to come from a maximum table of 256 tiles. You may already know this, and I don't think your images have a problem with this, I'm just pointing it out in case you didn't know.

The NES will be able to access a total of 512 8pixel x 8pixel graphic tiles at one time. (These can be switched in and out with mappers, but there will still always be a total of 512 at a time) Half of the tiles are for sprites and half are for backgrounds, hence 256 tiles for backgrounds. So, that makes it difficult to do something like a full image for the background without repeating. It CAN be done (like in Smash TV) but it's advanced.


Thank you! The ones you saw on here are most likely older ones that I've replaced. I just started with this a couple months ago and I'm still learning. It's been several years since I've drawn much to be honest. I used to do screen printing.

I looked down through your Mugen animations. Your stuff is really good. I like the girl with the suit and Katana. You shouldn't have much trouble getting into this. One thing I do is make little rules for my drawings to keep things for consistent. Like, I never draw an outline pixel on a corner, except for special exceptions when I'm trying to define an object that's not thick enough to have color. Or like, I never have my arms progress in a diagonal line without an adjacent horizontal or vertical pixel. I don't know if that made sense, but the point is that I find it helps a lot to have my own set of rules to make design consistent. There's a lot less to work with with lower pixel resolution as I'm sure you've noticed.

And if you're drawing a curve, always be mindful of the length of your "steps". Like, don't have a step that's three pixels and then one that's two and then one that's three. You probably won't have any problem with this. Your drawing skills are a bit above mine.


I'm not sure if I understand this. Obviously the NES has limits, but you have a lot of freedom to program your time to cycle however you want it. I haven't heard anything about how you'd want this to happen that would be impossible for the NES.


Games like Simon's Quest tend to make people think this is true, but it's not the case. AVGN even pointed out that it wasn't necessary to do so in Simon's Quest because FT13 didn't.

What has to happen is that you have to go into an NMI. This happens once every 60th of a second, I believe. So, it's not hard to make this happen in real time. You just can't make it happen at the point in your logic that the program realizes this needs to happen. Let me try to explain that better. You get to a point in your game logic where your time counter triggers a palette change. Since you're not in NMI at that very millisecond, you set a flag that you program can check in NMI to know to do the palette change at the proper time.

These exceptions have to be taken into consideration by the programmer and dealt with in a way that doesn't cause trouble. The system itself will not impose any limitations regarding these things. Every behavior is possible, it just has to be explicitly programmed into the game.

If the game is in a state where certain actions shouldn't be triggered, a simple solution would be to not check the time at all when in that state. Then, when going back to the state that is supposed to handle those actions, just check if the time is more than the time when the actions should have been triggered, and handle everything retroactively.

Anyway, these are just the rules of the game, and the programmer is free to implement practically any rules they want.


Well, it would certainly be interesting to see an NES game with a real-time clock...

Umm, that's when I get lost >_> I am not going to lie (Uncomfortable laugh) that just sounds to me as 256 unique sprited tiles that are broken up to make one puzzle (canvas). which to me if I were to count each tile on the stage, it would be around 900 tiles. So in other words that stage would be cropped ingame... Brain exploding >< But I guess this is what you mean. If so, would it be something that you can have the camera to scroll with the player rather than loading each zone?





That I know. Rule is you cant have more than 8 sprites on the same horizon (Scan line) any more than that will cause the "Flicker effect". I thought about just one layer on top but thats it. See around the world it would work fine. but will cause issues when heading in places that may have NPCs around the area unless I put the NPCs in a way that wont cross each other to make the flicker, but still.

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



Nice to know so that I don't have to worry about things so much and just enjoy the art part lol



Well said.



We'll see. I never like to waste a programmers time waiting on artwork and animations to be done. What cant take a spriter years to do. A darn programmer comes in and puts in all in a matter of days or weeks ><

Maybe you could build a cart with a clock in it...that updates the SRAM with time information.

Did you see my explanation of this?

You have 960 tiles on the screen, but those 960 tiles must draw from a pool of 256 tiles. So you will have to use some tiles multiple times. It appears that you did this.


Technically, you have to program the game to make sprites flicker. Their default behavior is to disappear.


The programmer who builds an NES RPG in weeks must be the best NES programmer of all time.

Although they're quite expensive, you can get special battery-backed RAMs that include a physical real-time clock.

That's exactly what it means. You can only have 256 UNIQUE 8x8 pixel areas in your level.

This may help. These 256 tiles:

are used to draw this map (Ignore the Mega Man sprite.):

The tiles are colored by a palette, and then placed in the map. (simplified)
Your map can be as large as you like, as long as it doesn't have more than 256 unique 8x8 pixel areas. (There are exceptions, but forget about those until you understand the concept better.) When a new area is loaded, this new area can use a different set of 256 unique tiles. This is how different stages of Mega Man have different looks.


A bit pedantic, but having more than 8 sprites per scanline doesn't cause flicker. It causes additional sprites to simply not be drawn. Flickering is the programmer's response to this, so that different sprites end up not being drawn. If the programmer did nothing, one object might end up entirely hidden, instead of it only being hidden on certain frames. The hardware does not flicker sprites automatically.

Yeah got it, though that would drive me crazy. Just an animation I did that the cape had to be in another layer made the animation longer to do haha.



Thanks for the links. I will study them. The reason why I got so stuck on grids was because I was trying to avoid using too many colors on things. I have a habit of over detailing things and I was trying to force myself to think in smaller space. I will work on this definitely. Thanks for pointing that out.



Yup I did. Sorry about that. Didn't notice the post at first while I was replying to the other stuff haha. but yeah things are really getting cleared up now. Thanks



Cool. Well I am not worried about the cost atm. Right now just focused on getting the art done along with the story and other stuff before we get to the money part haha.



Got it! so even if you a do a little camera scroll (IE Zelda) you can only use those 256 loaded tiles for that screen area until you zone out to the next area where it will load another set.

If you'd like to learn about NES backgrounds in a hands-on way, I'd recommend trying Shiru's NES screen tool: https://shiru.untergrund.net/files/nesst.zip

Anything you can make with this tool is a valid NES background.

It also has a sprite editor, so you can assemble and test sprites with it as well.

Yeah I have that though I haven't messed around with it much. I don't like drawing anything outside of photoshop unless theres a ."file" I can save and use it from photoshop to nesst.

_______________________________________________________

Okay I figured it out how to convert it from photoshop. What I need to know how to do now is putting the palette together in photoshop to port it over.

NES Screen Tool supports importing/exporting .bmp files. But you might be better off to also get a Tile Editor program like YY-CHR or Tile Layer Pro. It goes something like this...
-create image in Photoshop
-change Image/Mode/ to Indexed...and "custom"/"custom" and reduce the palette to 4 colors.
-Ctrl+A, Ctrl+C
-open YY-CHR (or Tile Layer Pro)
-Ctrl+V
-edit the tiles in the Tile Editor
-save as .chr file
-open in NES Screen Tool
-Patterns/Open CHR

Shiru's tool is not a good art program. It's pretty good for assembling tiles and building things that are easy to put into an NES ROM, but it's not good for drawing or making art. I suggested it as a tool to learn the rules of what the NES is capable of, since it does exactly that.

My own NES art workflow is usually to create stuff in GIMP or Aseprite, then pack a bunch of tiles into a BMP or some other intermediate thing to import into some NES related tool like this one.

3 colors? Am saving tile by tile? And yeah I downloaded them. they are meh thanks though



Yeah. I used that program and I got it to show up but color palette wasnt matching. I just can't stand programs without shortcuts. I cant be clicking all over the place when drawing.

______________________________________________________________

With that said since posting here I have had a lot of clarity on what I was confused on when a friend of mine was trying to explain certain things to me. So now I can be more mindful on setting things up.

Question though, can you actually have certain things in the BG animated? I remember seeing one RPG that had water animated and one that had rain. is that really in the BG or is that a sprite? But it cant be a sprite for sure. Just wanted to know if I wanted to add extra elements.

If I recall, Shiru's BMP import will take the first 4 colours found (i.e. scanning left to right, top to bottom) and treat those as color 0,1,2,3 in the imported tile. I think I worked around this by placing 4 dots in the corner just to keep it from re-ordering the colours on me.

Backgrounds can be animated.

The simplest most familiar example is the waterfalls in SMB2, which animates by using extra hardware in the cartridge to replace the tiles at a regular time interval.

Hmm, I might have to make a custom palette for the image to see if I can make it work.



I swear! How is it that I keep forgetting about those games >< I have way too many things in my mind at once . thanks for reminding me.

I am sure to have all of that together all tiles from the BG, HUB, and animated BGs would have to be under the same space >_>

While any given frame has a 256 tile limit*, you can have more than just 256 tiles across all frames of your animation.

For example, here's an animated gif of what SMB2 is doing:

You can see the cherries, plant greens, POW blocks, waterfall, &c are all grouped together here and running at the same rate.

* Well, ok, you can do various tricks to get more than that, but to a first approximation, it's 256. Many games with a status bar actually use one of these tricks to use a separate library of tiles for the HUD.

Oh cool! Nice to see everything together like that. Im a visual person lol

See palette issues haha



I feel stupid now. You are suppose to import>BMP file as nametable and it carries over the palette. ><

By the way, you can take a visual look at how the tiles and backgrounds work for any NES game with FCEUX.

Tiles: Debug > PPU Viewer
Backgrounds: Debug > Name table Viewer

In the PPU viewer you can right click on the tiles to change the displayed palette.

For games that do mid-screen timing effects, you can change the "display on scanline" value to a different line of the screen. These debug views show the current state as it appears at that specific time in the frame.

You can pause with the Pause/Break key, and advance single frames with the backslash key, if you want to look closely at animation.

Ill give it a try without my brain popping out my head

Dont know whats going on here. Could had sworn I made sure each tile was in three colors unless I missed up some where.

The NES is weird (to me anyway. I'm more of a "16 bit era" guy) in that every 2x2 tiles (4 tiles total, in a square formation, like the blocks in SMB) must use the same palette. Notice the difference in the lines of the grid? The dotted lines are for each tile, while the solid ones are for each palette.

However, there is hardware that is found in the cartridge that can (somehow) overcome this limitation, called the MMC5. But don't use it for something this small. From what I've heard, it's a bit of a beast, and only a handful of games used it, so if you where going to want to release this in a real cartridge, you'd have to destroy one of the few games that have it to use the MMC5. Just make the pond 2x2 tiles, and shift the whole area over or something like that.

That just blew my mind... I had no idea that the palette was in every 4 tiles. I thought that the palette was for every tile >< talk about redesigning everything ha!

And yeah the plan is to make my first release on NES then work my way up.

Are you going to program it? Or just do the artwork?

Hell no, I am no programmer haha. I just don't ask anything from a coder until all artwork is done other than can this or can it not be done or is it too much of a hassle to do. I dont like programmers to be waiting around.

If you prefer to use GIMP or Photoshop, and you're willing to install Python (see Windows instructions) and use a command prompt, you could try the savtool program that I included with my graphics editor that runs directly on the NES. Give it a 256x240 pixel BMP/PNG and an NES palette specified as a hex string, and it converts the image to a .sav file containing the pattern table, nametable, and palette. You can then edit it further in the editor on the NES or just convert it back to a PNG to see where you broke the rules.

That won't work for me even if I tried I am still on Windows XP and running a 10 year old computer. so yeah... At least now I know the rules (I hope) and will be more thoughtful of designing my world.

_________________________________________________________________________________

So the design is more of a place holder. I already now know that this is too big and doesnt follow the 2x2 (16x16) rule that I've learned today because of this wonderful forum >_> on like where my other project is at. hover over the pic to see my notes.



The idea here was the top right side where it says pos will tell you the city/town/shop (etc) Name. The X and Y was to give you the coordinates one the grid. The plan for the X and Y is to play with the day/night cycle for bounties. Would that be a problem? as far as X and Y? Im sure the name thing is fine and basic

The bottom right where it says RR I wanted the player to switch his party on the fly on the HUD but considering that this isnt the space I worked in. I will have to see what space I have in the actual restriction space so this may not work and I would have to make it for another tab "Party".

Other than that I am sure there is just too much information on one screen and I would have to break it down into tabs.

Will the icon pictures be sprite or BG?

In this case, both. There are too many colors in a given tile, so one'd probably make the whites of the eyes sprites ... and maybe the shadows on the face. Or the red box, one or the other.

The Red, White, and Blue are already part of the BG color and the transparency is black so you don't have to count that, but spriting shades in sounds good.

Redesigning the HUD I seem to be stuck. Looking through references how is it that the NES FF7 remake breaks the 128x128 tiling? Because designing it on that size the text pretty much takes up a lot of the space. Unless its using that whole thing about increasing the size as long as all the tiles are the same. Then what size can I actually make the HUD?

Be these are the things that are so damn confusing.



Edited it to where it falls in the 2x2 palette area.

What? Don't you mean 8x8? I think what you're trying to get at is who Final Fantasy uses proportional font vs. monospace, like this:



You see, it may look like the proportional font isn't following the tile grid, but it is:


I'm pretty sure the Final Fantasy games use something called CHR RAM that pretty much allows you to draw your own tiles instead of just looking through pre existing ones, hence RAM vs. ROM. In this picture, the text box is actually unique tiles throughout the whole thing, as in if the text box is 64 x 256 pixels, it's using 128 tiles, because (64/8) x (256/8) = 128. Basically, what's in the textbox is irrelevant. You could draw a picture of a smiley face over all the letters and it wouldn't make a difference. Just think of it as like Mario Paint.

And yes, this can be used for animation, because the text box is actually being animated, if that makes sense. Like I said, it's just like Mario Paint, except that the game is programed to only draw letters and numbers and the like.

When I said 2x2 I meant for the bg palette radius of 16x16 (8,8,8,8). I'll just keep designing and stop worring about crap like that (some what). But with that said (excluding the text) everything is lined up.

Just don't get to tech on me. Speaking about ram, rom, chips and such, I will only follow what you are saying to a certain extent. Though it's not a waste of time because I know you guys are teaching me. Just take it easy haha.

I just want to know if I am doing everything that is needed to be done on the proper canvas size. If you are telling me you have 256 unique tiles that fits in a 128x128 (that's how I see it in Photoshop) where the four color palettes shared in the bg applies to every 4 tile radius... I would stick to that.

And I do understand if you want a small or big scrolling of the area (whether it's over head or side scroll don't remember the number radius for that if there is one) it has to share the same unique tiles that is loaded for the area (screen) until you zone out and load in another set.

So when I see huds bigger than the 128 rule it confuses me at times. Keep in mine this is all new to me I'm a pixel artist, yes but never sprited with so many rules haha.

So I guess one of the questions is if you are going to use the same unique tiles for that loaded area, how big of a radius can the player walk through. Sigh I'm sure I am wording it wrong and I guess it doesn't matter as long as you are designing with the same tiles for that area.

I'm asking so that I can have the idea on how the player would move around in a decent size are and not move block, load, block, load etc there should be a balance between the two. Knowing that I will be able to design the scenery better. I hope I'm making since.

Any way so yeah don't get too tech on me. That's how my other friend lost me while explaining things. So far you guys have been awesome and I want to let you know that I appreciate all the knowledge you guys/gals have been taking the time on giving me.

Well, I know you said you don't really want to know about technical stuff yet, but just keep this one simple thing in mind: With rom, you can only load information from it, but with ram, you can not only load information from it, but you can store information in it during runtime.

I now know what you mean by 128 though. You're saying that all 256 8x8 tiles will fit in a 128x128 box, because (128/8) x (128/8) = 256
The screen is 256x240 pixels large, so change tiles that often. Something called overscan can actually clip 8 pixels off the top and bottom of the screen for 256x224 pixels, so you might even be able to change tiles that often. Anyway, I'm going to work with 256x240 here.

I mean, look at this picture:


Imagine the "1" tile takes the same spot as the "2" tile in the 128x128 are you're talking about. (it's the tile that's being changed.) Because the screen is 240 pixels tall, you want to have a 248 pixel space where none of them are being used. (the extra 8 pixels is because of scrolling.) Horizontally, it would be 256 + 8 = 264 pixels. The blue area is where it's safe to have the "1" tile, and the red are is where it's safe to have the "2" tile. When the screen is perfectly positioned in the purple area, that's when you switch the tiles. (they're completely out of sight. Going up will change it to "1", going down will change it to "2".) Of course, this means you gradually changing the tiles, not all of them all at once.

Yeah its like the side scrolling games. While going side to side the far end "right" and far end "left" gets clipped to load in the design (I think i said that right) Its like making a triangle cutout on a cardboard paper then putting it over a passage on a book. as you are going left to right letters get clipped while from the left and loading new letters from the right and vise verse.

See its easier to visualize it on side scrollers games while I see things like zelda who uses over head but is always loading per box. That per box thing can get annoying at times, reason I said it should be a mix of scrolling bigger areas and loading block to block depending on the feel of the creator.

I know "Mother" (Mother's Map)does this with the over world. though its more over head scrolling and the only time it loads is when you go in a building or cave but how do you determine the size of something like that?

so back to the image (i know I have to make my edits ) if I wanted this large area for the player to walk through without moving block to block just to get your scenery all cut out (yuck)



and have the player move freely like this without loading until he goes into the cave or the bottom area to the new zone, but also keeping it where you fall under the BG palette groups.



How do you know when too big is too big? I just may be overly thinking things. I must be annoying by now so I just want to apologize on my noobness .


_____________________________________________

Soon to be redone and fixed so it doesnt look so "tile-ish". I have to rethink this whole thing now with the whole grouping area for a darn palette(s).





How so? I put the transparent - 3colors, transparent - 3colors, transparent - 3colors, transparent - 3colors,
but for some palette 0, 1, and 3 works. I tested 2 but its not changing anything.

Hope its okay to double post. Sorry for all the questions I didnt meant to drive people away Ill get it in time.





Though it was nice to have those colors, i dont see that working well down the line with 3 layers of color. That I am sure is going to cause issues if I decide to have his party members follow him or even during battle. He is one of the main characters. Took me a while to get my own style into it after researching and looking over many nes/snes RPG styled characters.

Looks good. Double post all you want...it's your thread.

I think this is closer to the original sprite, but it kind of looks like he's not wearing pants...

Cool. I know know most forums don't like people doing that



Yeah... Trust me i put that color before and thought the same thing. You did however created the pants. Forgot to put those two pixels on them >_> The all blue doesnt bother me too much. I can always change the original artwork to make it fit the sprite.

But yeah, those colors are so tempting but not worth the stress its all about sacrifices in the NES world. So im mixed between all blue or let him look like he isnt wearing pants First sprites always takes the longest for me to make. after that animating it would easy.

Oh quick question. while in the battle screen (turn base battle screen) is it possible to have a quick animation like in Ninja gaidens Cut scenes? and would that have to still share the unique tiles or some how make it load in? Nothing too lengthy may be like a few seconds.

I think what people don't like is "bumping". That is, posting for the sake of keeping their topic at the top of the active topic list.

If you have something new to say, relevant to the topic, especially a new question, then I think it's ok. If people don't like it, they will just ignore you.

Anything that an actual NES game did, is by definition possible to do in an NES game. Is it easy? No. Can you do it with 256 tiles? Yes, if you use flat anime style animation... Or keep the animation restricted to a 128x128 box in the middle of the screen.

Or, more cinematic... 256x64 with subtitles below.

The plan is to have each char have their own "Mega Move" (I'll call it something esle). Nothing to crazy and maybe up to 5 frames that will be restricted by the numbers you wrote. Most important are the key frames. You wont see the enemy just your char doing the move.

I just need to think it though on how it would look. Batman did a good job on it from what I saw. Now if it can load its own tiles in with a mapper that was capable of bank switching from a different pattern table.

Do you want to animate attacks as cutscenes? Yes, that's be perfectly doable. You just have to mind the total tile count for the entire game, since cutscenes can be quite tile-hungry. Most mappers that use ROM for graphics can only address 256KB worth of tiles (16384 tiles). A rare exception is the MMC5, the NES super mapper, which supports up to 1MB (65536 tiles).

If there's a clean cut between the battle screen and the cutscene, there's no need to share the same unique tiles. Depending on the type of memory you use for the tiles (ROM or RAM), you can switch in an entire new set of tiles automatically or in a couple of blank frames, which should look nearly instantaneous to the player. If the animation is supposed to happen while some of the battle screen remains visible, then you'll most likely have to share the pattern table, reloading only part of it with cutscene tiles, and restoring them when the animation is over, or maybe switch banks mid-screen if the animation is supposed to occupy only the middle portion of the screen.

BTW, I think most of us are avoiding to get too technical with the answers, but we can't simply go "yes" or "no" when you ask if something is possible, because sometimes even though things are possible, they're not necessarily trivial to implement, so it's important that we let you know of the implications of doing certain things. Otherwise you might end up drawing a lot of things that would be hard to implement and the programmer would have a tough time later on.

For example, the MMC5, a mapper that was already mentioned a couple of times, greatly increases the capabilities of the NES: it can increase the palette resolution to 8x8 pixels, allow access to 16384 unique tiles instead of 256, 512 unique tiles for sprites instead of 256, it has a scanline counter for raster effects, completely versatile tilemap arrangement, not to mention the 3 extra audio channels and the number multiplier. It's the most complex mapper ever made for the NES, but it was only (under)used in a couple of games, so it's not easy to come by. Nobody who manufactures new NES cartridges has replicated this mapper yet, and the existing Flash cartridges can't physically replicate all of its features. So even though it can "fix" a lot of the issues artists have with the NES, we don't encourage its use.

Nah you guys are doing excellent honestly. I shouldn't had said not to get so tech on me because through all of this I am learning. Its like you said, "you might end up drawing a lot of things that would be hard to implement and the programmer would have a tough time later on." When I do projects I end up being over ambitious so what ever it takes with what is available to us I am up for it. so please go back to being technical.

I need to learn one way or other. Just be patient with me



Yes. Think of it as their super in a fighting game or this pictures they show slightly animated in Disgaea, but nothing to frame crazy. I have my way of showing things without using so many frames.



Nah, battle screen doesnt have to remain visible. so Mega move pops on for you to use, click on it, Animation goes through taking you away from the battle screen, and then goes back to the battle screen and your damage shows up on your target.

I need to read up on this. I know "RAM" only through memory for the PC not the cartridge. this is all new to me.

______________________________________________

Just read between RAM and ROM... It looks like RAM is the way to go. Id have to keep reading it to get a better understanding between the two.

That's cool.


No worries then. Since it's basically a different screen, you can reload the tiles entirely if you need to. Even if you have to do it manually (byte by byte to RAM), it still takes only a couple of frames, and what are a couple of frames in a console running at 60fps? The player will not notice any lag.


I think Espozo mentioned it a few posts back, when talking about proportional fonts. Basically, on the NES, tiles can be stored in RAM or ROM. ROM, as the name implies, is read-only, so you have to program the game with all the tiles you can possibly use in their final state. RAM, however, can be modified in real time, so you can modify or create them on the fly (as you would for displaying proportional fonts).

RAM is cool because you can manipulate the tiles however you want, create and modify them on the fly, freely combine tiles from different tile sets, and so on, as the program runs. The only problem is that changing RAM is slow. Each tile is 16 bytes, and the fastest you can typically write a new byte to the PPU is 8 CPU cycles. Each frame, you have about 2270 cycles for sending data to the PPU, so in the best possible case (without hardcore tricks) you're looking at updating about 16 tiles per frame, if you're not making any other kind of video updates (no sprites moving, no background changing, no palette updates, nothing). So, modifying tiles in CHR-RAM is not something you'll be able to do at blazing fast speeds, specially during gameplay, when there are other types of video updates happening.

Changing ROM tiles, on the other hand, is fast. Nearly instantaneous, in fact. The same 8 cycles that change only one byte of CHR-RAM, could change all 512 tiles (8192 bytes) if they were in CHR-ROM. This is because in this case there's no data being copied byte by byte, the mapper simply manipulates how the CHR chip is wired to the PPU to make different tiles visible to the NES. It's like if you had a piece of paper with a small square hole in the middle, and behind it there was a long strip of paper with different graphics along its length. You can only see a small portion of the strip at a time through the hole, but you can quickly slide the strip left and right to see different parts of it. If this was RAM, there'd be no strip of paper, the graphics would be somewhere else, like in a book, or anywhere else you could look them up, and instead of a hole in the paper you'd have a pencil and an eraser at your disposal. You'd be responsible for looking up the drawings and reproducing them using the pencil. You could always erase a drawing to make another one, but that takes significantly longer than just sliding the strip with pre-made drawings.

The disadvantage of ROM is that you no longer have complete freedom to arrange the tiles however you'd like. You're limited by the mapper, and how small the holes in the sheet of paper are, how many holes there are, and how long the strips containing graphics can be.

Well, if somebody could make a mapper that could access 340,282,370,000,000,000,808,640,304,032,688,192,896 tiles, then we wouldn't need CHR RAM.

5,444,517,899,999,999,976,416,792,344,456,648,656,624 bytes of data... Yeah, this is beyond completely ludicrous even with modern technology.

Jokes aside, I usually don't like the "it's possible to create a mapper that does XYZ" talk, because we're developing for mappers that exist now. We can't be hostages to hypothetical hardware, so unless this is someone who can do both software and hardware, the most sensible approach is to pick something that already exists and is well supported (in emulators and flash carts) and reasonably available (if you plan on making carts).

So lets see if I can water down the difference between Ram and Rom. With Ram create, modify, and freely combine tiles from different tile sets, but The only problem is that the RAM is slow. Rom makes changes to tiles fast and nearly instantaneous. but you are no longer able to switch "tiling" around. So I guess that means is what you drew on the canvas stays.

_______________________________________________________________

Okay so I put this together on how I envision what I want to develop thus far. Just keep in mind these are just place holders I do need to consider rules and other things.

Movement



This should be able to be done if you are able to do side scrolling and have it load the path for that stage. When the character is loaded in as usual your view is in the 128 space. move left and the 128 box follows you. when you go up you'll reach a certain X/Y (middle) point before the view box has to follow you. with that said as past post mention youll just have to use the existing tiles that are loaded for that area only until you zone out to a new area.

ingame day/night Cycle and time



As your normal classic RPGs there will be no enemies on screen therefore it will generate random battles. but when taking on bounties, finding out the location and pos will trigger a monster to pop on screen who youll run into to trigger the battle.

CS for Mega Move(s)



As seen in here when the Mega Move is activated and used, the CS will take over. You wont see the battle screen. a very short CS will play to show the mega move and goes back to the battle screen and the damage will show.

Also a friend of mine mention that it looks like I may have to use MMC-3 too but seeing what I am trying to do what do you guys suggest.

______________________________________________________________________

With that said I'm all about using what exist now, but I would want to use all that it has to offer. Not just do something in a way because its easier. I had the same issue when I was working on my Mugen character. Had one main playable char and an on screen helper who without him you cant do your air combos and etc. People telling me its too much, just make on char etc etc. I like breaking boundaries as much as I can and it took a brave coder (in mugen) to take up the project which is almost done. the orange shirt kid you saw in the first post.

_______________________________________________________

Im all about making organic non-tile feel looking environments but I can see that this will drain all the tiles and not leave space for anything else.

You can change which puzzle pieces go where...any time. But, with ROM, you can't make new puzzle pieces.

I like your sample a lot! Final fantasy style. Good choice. The enemy, however, may be slightly too large. You would have to have a ROM bank dedicated to each enemy, which would limit the total number of enemies, unless a lot of them are different color versions of the same enemy.

What's the 128 box? You know you can have 256 x 240 px on screen at a time, right? 32 x 30 tiles.

Some games like this load a new screen when you reach the edge and some will do two-axis scrolling. From a design perspective, I don't know if you need to make so much of a distinction for that part because a coder could use your graphics either way.



From what I'm seeing, I don't think you necessarily need the MMC3 but you will need a mapper for the quantity of graphics you're doing and MMC3 is probably the most versatile readily available one. If you wanted, you could design cutscenes with split screens that scroll in different directions. That's a cool thing that mappers make easy. The split has to be horizontal though. No vertical splitting, except with MMC5.

I'm guessing that your cutscenes are largely going to be composed of background tiles, with some sprites over top for certain effects. I would say that this makes CHR ROM the better choice, but I guess there's still some gray area. For my game, I'll have objects loading a bunch of sprites in a single frame in game, and this has to happen right away. For a cut scene scenario though, without player control at the time, you may lose say, 3-4 NES frames to load a cut screen graphic, which would equate to roughly 3-4/60ths of a second. That would seem almost instantaneous in an instance where you're just watching.

I've also heard mention of MMC3 carts that have CHR ROM as well as RAM but I'm not entirely sure how that's implemented.

You might want to restrict your enemies to about 64x64 pixels. And only have a final boss of this size (it looks about 100x140). In your example, the enemy would be rendered as background, so to avoid sprite flickering.

Remember the example of SMB2? That's CHR-ROM animation.

The library of 256 tiles.

On some level, the hardware implementation doesn't matter. The CHR-RAM portion still has the CHR-RAM constraints, even if it can be switched out for CHR-ROM portions. (However, wiki).

You can even use CHR-ROM bankswitching animation with CHR-RAM. It's just that no commercial games ever used more than 8 KiB of CHR-RAM, and that's a very small space to fit animation into.

Thanks. Didn't want to do FP like Mother and some of Persona games that you only see the enemies. Though you'll have more detail space to work with for the enemies it feels kinda empty IMO nor did I wanted to do BOF style where you never see the front of you character and doing vise verse just kills the detail. So FF view is the best way to go.



Oh! Yeah that won't be the size. I just did that for a sample only thing there that is true to size is Alex's sprites. I don't mine going old school which its the same enemy sprites with different color and their names are change. A lot of RPGs have done that. But I would like some of the boss battles and Bounties Monsters to very in sizes.



I don't mind the horizontal. The CS in battle for the MM doesn't have to be over complicated. Just load animation and load back to the battle and done.



Yeah think of some of the summons in FF7 and all the few summons on FF10. The main character disappears while the summon is in. It would be the same here but the whole battle screen goes to load in the cut scene for the MMs and after its done the battle scene is restored to the viewer and carries on the fight, but it will be short enough where the player doesn't lost momentum of the game play like AKA "Knights Of The Round" >< and yeah I read a little about the whole Ram and Rom being together.



Haha yeah the biggest I can go for normal enemies IS 64/64 Again just did that just to show my ideas Reason why I didnt want to make the heroes with multi layers to make better colors on them.

Anything like a "limit break" in Final Fantasy series?

With CHR RAM, you can plan on modifying up to 8 tiles per frame easily. That can be done while gameplay is happening; I've done exactly that in two NES games (RHDE: Furniture Fight and a forthcoming game published by Two Coins Entertainment). It's not quite blazing fast, as the game has to alternate among background tile updates, sprite tile updates, and nametable updates, but it's enough to present a seamless menu or platforming experience.


Except perhaps Videomation, the two Oeka Kids games (Japan only), and RacerMate Challenge 2 (unlicensed).

Yeah, I was idly contemplating whether using the Oeka Kids games hardware might actually be useful here. On the down side, tiles can only be reused in any given 64x8 tile region, but on the plus side, you have enough tiles (1024) to fill a screen all the time with no duplicates ... including a bunch of spares in the bottom quarter.

Except perhaps Videomation, the two Oeka Kids games (Japan only)[/quote]
But the way it's implemented in these games only benefits drawing programs, since the purpose was to allow for an entire screen to have unique dynamic tiles. If you can't bankswitch this RAM in small chunks, it's pretty much useless for background and character animation.


Never heard of this, but from the little I could find about it, it looks stupid. I couldn't find any gameplay videos though, so I don't know how the extra RAM was used.

Tangent: the Racermate "games" were software for use with an stationary exercise bicycle, so they've got more in common with the silly LED graphs on a treadmill than, say, Duck Hunt.

Yeah. Limit Break (FF), Mega Move (SNES DBZ), Desperate Move and so forth I know with the characters on screen itself is very limited though to the fact that you need to share space between party members, mobs, and other things and I wont be able to get a fluent animation with them. so, going the CS rout for special moves would work great I think. A cs like I did (ROUGH SKETCH THOUGH) was simple enough. I can do a lot with that so as long there is enough space to do so with everything else being implemented.

What would b e the CS size any ways? that's the only thing that confuses me at times. I dont want to work on a canvas and it ended being too big or small and I had to resprite it again. Reason I am hesitant to work on sample title screen. like this might be too big.



Not something I would use for a title screen. Too much going on. Less is more at times.

________________________________________

On that note I've been working on the animations for ALEX atm. Front, Back, Side. I may consider diagonal animation being that i would want it to move freely. Not all like a chess piece, but there's ways around that without having to make animations for it. well except for when you are going diagonally up.

________________________________________

All this time ive been going to photobucket when I could had been using the attachments here haha.

So, I guess this is why we're talking about it, but just to be clear; if you have 16 KB of CHR-RAM, could you switch out the active portion of CHR-RAM and write to the other half outside of NMI? If so, this would seem like the ultimate solution.

I'd even think for a low production run it could be cheaper. 16 KB of RAM is nothing these days, and a production run of a mask ROM would require high quantity and custom tooling.

Not without an incredibly expensive circuit to swap which chip is connected to each line of the CPU or PPU bus.

Okay, I'm going to start with the super simple answer first because I think we may have confused you earlier (or perhaps just confused me)

256 x 240. This is always your screen size.

You are filling in a puzzle that's 256 x 240. You have 256 unique puzzle pieces that you can use to fill it out, and you have an unlimited number of each piece. You can fill out the puzzle with 960 of the same piece, or any other combination. But you're always filling in 256 x 240.

So take something like Ninja Gaiden. The tops and bottoms are black, but that's because of other reasons. Namely, the number of graphics to load for the middle section is still a lot. They still filled out the 256 x 240 puzzle. It just so happens that they used the same piece for a lot of the top and a lot of the bottom, and that piece is solid black.

Does that make more sense?


I also realized after posting that you'd still need the mask ROM from which to pull graphics.

Hmmmm...

You can get 5 bits of "bus-exchange switch" for around 42c/ @100; you'd need 24 bits per 8 KiB SRAM. At 10 ICs that'd be ... pretty goofy, but not unaffordable.

Well if things go into the right direction and I have more work to show, I am planning to put together a Kickstarter for this. It's the reason why I said for now that I am not too worried about the money to make the carts for it and such.

I am in the mix of rewriting/editing the story and getting all the character concept art I did a very long time ago together and updating it. Because I've stopped writing the story a long time ago I need to revise it so that it doesn't sound like something that has already been done. That's a bit hard in a way because everyone gets inspired by something regardless. its all about how you put it together in your own perspective.

I still am working with my spriter team mate whom is a great animator as well. I have someone who I can pass my concept art over to at deviant art but that as you know cost money though my sprite mate can draw as well as I can.

So lets see what happens. I know that answered the question if I was thinking of making a physical cart. I also spoke to my mugen coder if he can look up how to code for NES but he hasn't given me a solid answer so thats pretty much open. Only reason why I wish he would is because he wouldnt be afraid to take on challenges not saying that no one else can though

Oh here is a very old video of the project I am working on. I mean really old because the art work doesnt look like that any more for those who did look through my photobucket.

Mugen: Mel Masters

Theres still things I need to fix in the bottom animations. but its just trail an error. Been so use to animating in HR haha.



Yeah... I get it.....

Danger! Danger! Hypothetical mapper alert!

Hey, I like analyzing the possibilities for new hardware improvements as much as the next guy, but, unfortunately, almost always this never amounts to anything. The existing mappers are what we have (and sometimes not even that - we don't have full control over the MMC5), so we should be designing our games around those, right?

Heh, I guess I'm very incoherent sometimes... Just the other day I was interested in crazy mapper capabilities, but listen to me now. It's not just this... recently (and not so recently) I've changed my mind about a lot of NES development stuff... Now I'm favoring generic NMI handlers instead of one for each program mode, CHR-RAM instead of ROM, simple discrete mappers instead of more advanced ones... Go figure.

To me, the only place ram has for graphics is in 3D games and painting games. Other than that, its worse than rom because it's too slow. (On the NES and the SNES anyway. I wouldn't mind it on the GBA...) I'd pick rom over ram on the SNES any day if I could. My code would be a hell of a lot simpler and faster if the SNES had something like MMC5 chr rom capabilities. I bet about half of the time for processing is spent on vram related things, like finding empty slots or objects that use the same sprites.

Eh, there's a huge difference at all points on the spectrum between:
* Specifying the programmer's interface.
* Checking economic feasibility of a design
* Putting the full design in an EDA program
* Actually putting some parts on a PCB
* Writing some verilog/VHDL for the powerpak

Where you cut the line is a matter of taste; I personally put it right after the first line ... mainly because to me the middle three are so close to each other.

But really, the skill set for writing a game is different enough from the skill set for designing hardware that it's not really the same thing. Dual-ported RAM would be nice. This is a goofier way to do it, but extremely simple, and not that expensive.

But defining the limitations to be only those things supported by emulators ... that's stupid. We could trivially graft 32 KiB or 128 KiB of CHR RAM into almost any CHR-ROM based mapper, but emulators mostly don't support that.

Reading is the same speed. If you have enough RAM to cover your bankswitching needs, fill it up once at some appropriate transition, and switching is just as fast as with ROM.

Writing is bandwidth-limited, but if you're comparing to ROM's write speed, it's infinitely faster. It's only "slow" if you're comparing non-bankswitched RAM writes to ROM bankswitching.

The problem here is more with the iNES format than anything else. Now that RAM is as cheap as it is, it's pretty viable to build a board with bankswitching RAM. Emulator support requires iNES 2 headers, though, which is still poorly adopted.

So would a game in the Chinese language or in Japanese with kanji be a "painting game"? Would a game with text in a proportional font (on a video chip not powerful enough for one sprite per glyph) be a "painting game"? Qix is a painting game, but is Hatris likewise? And into which category does a game with arbitrary juxtaposition of more than three smoothly animated enemy types fall?


What I did for the Action 53 mapper was the first two steps. I specified the programmer's interface, counted the number of bits of state (which is a lower bound for the number of macrocells it'll take in a CPLD), and wrote a comprehensive test ROM. Then I contacted specialists for the rest: kevtris wrote Verilog for the Kevtendo and thefox adapted it to the PowerPak, and infiniteneslives put it on a PCB.


Then someone should write some test ROMs for 32K CHR RAM. I might have included that in my multi-mapper test ROM, which has the NES 2.0 header, but I can't test on PowerPak because current PowerPak firmware ignores NES 2.0.


I think Espozo is comparing exactly that, coming from an arcade environment where you have longer tile number registers for sprites and often a tilemap that can be written during active picture, again with longer tile numbers. The Neo Geo, for instance, has 20 bits for 16x16 pixel sprite tile numbers, to address the equivalent of a 16384x16384 pixel tile sheet. Even its "fix" layer (a single, non-scrollable, high-priority 8x8 tile layer intended for scoreboards) has 12 bits of tile number for each of the 38x28 usable spaces.

My PowerMappers have a partial NES 2.0 support (only CHR-RAM size). There might be some mapper-specific limitations (that I can't remember right now), but it should work as expected in most cases.

Also the latest versions of Nintendulator (and NDX) have support for large CHR-RAMs. One test ROM (a fullscreen image) here: http://thefox.aspekt.fi/ines2-chr-ram-test.zip

Yeah, combining a mapper that does 1 or 2 KB CHR switching with CHR-RAM would be really useful. It's a shame emulators don't support that, even though it's simple to accomplish on hardware (just swap the ROM for RAM - the only real problem is when the board doesn't have the pin for the VRAM write signal).

Now that you're cleared up about the screen size, I think you'll understand when I say that the trouble that you'll usually have in creating an image like this on screen is going to be the number of unique tiles in the image. As I was saying, you have to fill in 960 puzzle pieces with 256 tiles. This is going to be a a lot of the reason that something like Ninja Gaiden has the cutscenes only in the center of the screen. There may be other reasons, but that's going to be your main one. If you could build an MMC5 game, then it won't be an issue, but you feasibly can't have MMC5 carts produced. I would say, in my opinion, not to worry about the theoretical discussion of what could be done with a mapper, and 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.

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.



I think, for an example, Link in LTTP can move diagonally without a diagonal sprite. I think Chrono Trigger was also like this. Even though a lot of RPGs tend to, you don't have to restrict your character's movement to tiles. Chrono Trigger is a good example of this with a turn-based RPG. On NES, the first thing that comes to mind is Crystalis, but that plays more like a Zelda game.


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, if that was the intention. The other thing I see is that his chest appears bigger in the right one. The one on the right looks to me like he's got some pretty big armor. Looking at it though, I don't know if his chest is the trouble exactly. Maybe his waist is too big? It's hard to tell. It's still a lot of trial and error for me as well. What I feel has been working the best for me so far is to make rough frames for the entire animation, and then watch the animation over and over, go through each frame, each pixel that goes against the flow of motion or conveys the wrong shape. Those finicky little pixels. Just one or two can change and image this small drastically.

Got it.



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.



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.



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

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:

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

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

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.

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.

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.

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.

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.



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



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.



Understood. Might need someone to calculate that >< I'd be lost on that part.



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.



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.



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.

If that makes any sense to ya'll 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.

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.


Naïve coverage


Staggered grid coverage


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


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

Cool. I will look into it and thank you for making it more visual. That's the way I learn 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.



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.

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)

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.

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

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

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?

Nah I didn't take it lightly at all and no never programmed in my life editing scripts for FFXI Macros spellcast doesn't count. I just like focusing on one thing, and that's the artwork. To do both would be a pain in my ass. Though the person who made Axion Verge did it all himself but it helped that he already worked for a company and he didn't have to code in assembly programming language. Though I am a fast learner when I have hands on but even so.

If I do try to learn it would be off the spin off to start something small then work my way up on projects being that spriting isn't really a problem for me.

Evidence that many people can't handle both drawing artwork and programing: https://www.youtube.com/watch?v=lw8yq1ubQG0 or https://www.youtube.com/watch?v=LUH32GRqqHI

Can't or CAN? Just remember that everyone learn differently. a Programmer turn pixel artist would be a lot easier than a pixel artist trying to be a programmer I think. It all depends on the person. I know my limitations. I won't say that I wouldn't try.

Can't. Did you go more than a minute into Metal Slug 2? The game already runs at 30fps, so whenever it slows down (which it constantly does) it runs at 15fps, which is about the framerate of Starfox.

The second example (I think) isn't quite as bad. The programming is good in that there isn't any slowdown anywhere (not even a hint, unlike R-Type III, although it isn't very noticeable there) but the artwork, which is CG, isn't that great. The effects are nice in that there are many parallax layers and sprites and whatnot, but that doesn't necessarily have that much to do with the artwork. Many people will say that CG graphics never look as good as hand drawn graphics in 2D games, but all the DKC games look very attractive, aside for some weird artifacts around sprites as a result of the reduced color depth and resolution that could have been avoided by editing over them a bit, like what was done in Doom and Mortal Kombat with the digitized graphics.

Maybe someone with programming skill would be willing to trade you code for art.

Well let see what happens. Talking won't solve anything. Doing does My ass won't sit here waiting for people to be interested. I'll keep doing what I've been doing. Trading art for code sounds cool because all in all. If i don't get paid for my artwork why should you get paid for your coding? Its a lot of work on both sides.

like someone said before. "We work to get paid not paid to do work"

Even if it doesnt make it to NES at first like Shovel Knight.

This is foolish conjecture. We get it. You like Irem and don't like Metal Slug.

Kinda funny because I dont see what those two got to do with anything I said about Spriting and coding at the same time A one man team. Only person I give props to like that is who I mention. Tom Happ for developing Axion Verge by himself.

I totally understand where you're coming from, Fjamesfernandez. I know how to sprite, compose and write, but learning how to program has been a huge hurdle for me. It's very difficult because you have to be good at abstract thinking. Unlike art or music, you don't get immediate feedback while you're working on a program. You have to work on it for a while, compile it, then hope everything works at runtime. It takes talent and it's just not something that comes naturally to most people.

So don't worry, I've heard your situation is pretty common. In game development, project leads are usually the artists/designers or composer/designers or writer/designers, right?

I'm not sure what you mean by no immediate feedback. Pressing Save All (Ctrl+S) then Build and Run (Ctrl+R) is pretty instant for me, even on this dinky little single core Atom laptop running Xfce and FCEUX.

Somewhat of a joke, but okay.


I'm pretty sure you also realize that the first 3 Metal Slug games where made by Nazca that branched off of Irem when it went out of business. I have no reason to hate Metal Slug, because it's not like SNK bought out Irem or something. In fact, SNK had little to do with the original Metal Slug. I just feel like running a 2D game at 30fps and having it constantly slow down to 15 is a bit of a problem. Gunforce 2 (which I think was better, although it may not be as "professionally made") slows down to 30fps, but at least it's more justified and does it less. I think I've also shared my opinion about Super R-Type.


Well, Rendering Ranger R2 was pretty much made by one man.

In that case, perhaps Rendering Ranger makes all of us look bad if one man can finish a project of that scale by himself.

Pretty much. I think it took him about 4 years to make it though, but that's kind of expected. Just so you know, like the game proudly says, it was made by Manfred Trenz, a German game developer. I'm just stating that because he originally wanted the game to be released world wide but there was some sort of financial thing or something that prevented it and the game was only released on the SFC on 5,000 copies. It was supposed to use more traditional graphics, but he and the company he was working under felt pressured by the success of DKC.

With that much effort put into that game, I would have been more than upset to realize that my game would only have a very limited run in only Japan...

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.



Yup, normally a programmer itself don't have does things. They just know how to implement them



Yup thats a good kick in the face.



Hmm even so you did mention that he was working under a company. So I am sure he got some kind of help. Also its pretty easy as hell if you took the time to make 3D renders and just sprite over them. you dont have to worry about reference or anything being that its all laid there and again, I am sure he know already how to program. Take someone that never programmed in their life. you have a better chance to learn how to do pixel art than what you can do programming.

Well, actually I'm stupid. He didn't necessarily make the game by himself, but it's still impressive, although it kind of invalidates my statement...

Anyway, here are the credits: https://www.youtube.com/watch?v=LUH32GRqqHI&t=1h13m43s (The worst part is, I've beaten this game before...)

In other words, Made by Manfred Trenz... And a bunch of other people.

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!

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.

Have you actually got your dynamic animation engine working?

Nope. School sucks. 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.

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

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.

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

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.

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.

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.


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.

Its just the Brain area.



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



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.



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.



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.

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.

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.

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.

Chock me up as another one who agrees with this.

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.

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.

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.

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.

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.

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.

Clearly we don't get it.


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.

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)



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



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.



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.



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.



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



Yeah.

Fading is completely different from translucency. Fading is accomplished by darkening/brightening the colors, and while this may look like transparency revealing the black color underneath, this is not actually the case. Alpha transparency is a very complex concept, that even the SNES and Genesis struggle with, and there's certainly nothing like that on the NES.

Well, it's a hardware feature on the SNES, even if it is relatively limited. It's generally better suited for BGs than sprites, and I can think of plenty major commercial games that use it, most notably the DKC games. However, I can't think of many games that use alpha channel sprites. One kind of cool, although limited, effect is found in Firepower 2000 which always has transparency for sprites on is that whenever an explosion happens, it is at first opaque, but then uses the transparent palette for when it is fading away. palettes 4-7 are exactly the same as 0-3 to allow effects like this. However, I've never understood the Genesis's shadow and highlight modes. I think I remember hearing something about how it either halves the color values of something or doubles them. Also, does this only work for sprites, because I remember messing with the Sonic 3 and Knuckles debug mode and moving around a transparent waterfall slap sprite.

But yeah, the NES doesn't have anything like this in hardware. In fact, I'm pretty sure that even most "16 bit" arcade machines didn't. If the Neo Geo had SNES alpha transparency capabilities for sprites, it would be totally useless, because it would clip through everything.

I'm not sure what you mean by this, but you can use a different palette for every 16x16 area on the background.

You can use a different palette for every 8x8 sprite.


You don't have to actually have an associated sprite to make it an object hitbox instead of a background collision. You could have the spawner in the background and just have a hitbox above it that the player won't see. Just an invisible box over where the spawner is in order to test for collisions.

It can. As I said, a 16x16 area is the smallest background area that can have a color defined.

Whether an object is drawn with sprites or background tiles is just a detail of its graphical representation. The object should be spawned regardless of how it's drawn. It can have a hitbox and its own behaviour even if doesn't use any sprites.

As for making a background object flash, there are several ways that can be done. The most obvious is to redraw the tiles at the same rate of the flicker. If the object is small enough and you're not using much of the vblank time for other things, this should be easy. Another option would be to make sure that the colors used by the object itself are not used anywhere else in the background, and then you could simply change the palette to make the object flash white, or whatever color you want. Yet another option is to overlay white sprites with the same shape as the object over it, only when necessary, so you only affect the sprite count temporarily.

Gotcha, was trying to see if i can trick this



So in all honesty flickering it in for a spawn animation would do best.



This is what i meant. each square is the coloring radius for the BG. refer to the attachment I may be overly complicating things on this.



Yeah I was running that through my head of the things youve mention. If it was BG it would had shared that palette because of how I made the BG itself. so making it a sprite would be the best thing to do. its kinda crazy how its easy for me to make an over head BG but when it comes to side scrolling BG for some reason i get stuck. that makes no sense to me lol

The only problem with outright making them sprites is that there's one on each side, and if the player and the bees happen to be up there as well, there will definitely be significant flickering. If you don't mind that, it's OK.

yeah dont worry it was just a mock up. it wont be like that. I was just trying to get my ideas out on paper or should i say photoshop

Setting things up on the first stage. Im trying my best to plan things out so that it doesnt go crazy with the palettes. Stupid question but will that door be easy to operate for a BG? the colors arent final i know that ladder will cause issues if thats a BG tile. im just using any color then change it later.

Not necessarily easy, but it could be done. I imagine you'd have to keep track of where those tiles lay in the nametable and update them each frame. You'll have to store tiles for every position in which the door will be. So you'd need a tile for each pixel movement. It doesn't look like a door that would move quickly.

The moving collision detection would take a little work. One method would be to put a moving object over top of the door. I haven't personally done ejections from objects though, so I'm not sure how that works. Ejection from tiles is usually done by determining the distance to the next multiple of 16 pixel location. I suppose you could use the width of both hitboxes to determine a suitable ejection location for x axis and likewise with hitbox heights and y axis.

I've never done this personally so I wonder if anyone has any other suggestions. I don't think it would be too hard.

Yes. I suppose you could make the very bottom of the door a sprite (a few sprites). That would smooth the door's movements, and you could calculate collision based on the sprite. But, now that I look at your door, that wouldn't look right...only if it was a plainer looking door. For your door, it will probably have to be a background object.

I believe that's how they draw the beams in Quick Man's stage.

The spikes on the side of the door make this one a bit different though. It wouldn't really work quite like that.

I was thinking more like the sides of Battletoads lvl 2 or kind of the way Metal Storm does parallax.

Is a 2-tile wide door really worth the trouble? Is there an actual reason to make it part of the background?

Nope would move slowly.



Those aren't spikes on the door so you dont need to make any hit colisons there. Its only the bottom that has the spikes, but i can take the two spikes off from the bottom.



I can make it one tile wide. I just made it two so that I can add more details like the bolts in the middle and I would think making it BG and not a sprite would be better so we can add more stuff sprite wise. but things can change. everything isnt set in stone im just planning it out atm.

And just incase people are wondering, NO the BG wont be black its just a transparent color im working with right now. all of that will be filled. I am putting all the obstacle stuff out there first.

I wouldn't take them off. The ones on the bottom aren't really an issue either way.



I don't think you need to reduce the size of it to make it a sprite object. I think was Tokumaru was saying is that it would very easy to move on the screen if it was a sprite object. It can still be two tiles wide.

Moving an object inside of the background is a relative pain vs. moving an object, and to move a background object smoothly requires a lot of graphics.

Two tiles isn't that bad for the 8 scanline limit. That's probably going to be the width of most enemies and the player. A little bit of flickering is almost inevitable for most action games.

I guess if you got done with the game and had plenty more room for graphics and enough time to work on little tweaks, you could move it to a background object to reduce flickering, but I would push it to the back of the goals.



If you want to find some inspiration for organic style backgrounds, two examples that come to mind are R-Type and Lifeforce

Gotcha, I did resize it and took off the bottom spikes but I always have the original design in a seperate layer any ways in cause I got back to that.



Yeah its a bit tricky but worth to try both and see what happens instead of ruling it out.



Cool Ill check those out. Been a while since ive seen R-type

ignore that pink outline. thats just a note for me to where the Door needs to stop. If you see when opening the door it blocks you from the chest but keeping it closed after you go through you wont be able to make that jump. Though there will be some power-ups throughout the stage to help you in situations where you need to fill in that gap.

After drawing countless weird shapes over and over on the train to my son, I manage to pull this off. Of course what was on paper and whats on this image is totally different but paper is always the start. Don't let that art disappear ^^

Of course after seeing a ton of weird organic stages from different games including Life Force. it was a nice exercise to inspire me to make that BG.

I had to rearrange the objects and make the column door back to its original size because it didnt match to the platform on top. If i would had left it one size down it would had messed with the platform's palette when I increased its width. the column door will be a sprite to ease things. I think it would be a pain to try and figure how to replace tiles though I wouldnt mind giving it a try. not like it has to move but one pixel. can move by each 8px square.

The spawner will have to be a sprite as well. With this type of BG it would blend too much in where you wont be able to see it clear enough. besides with it flashing when taking damage it would be a mess and im not up to making little black holes around it so it can stand out. The whole point is search and destroy.

Added the door down below because this will be the first area you will go through after the game begins in that room.

Added walls and edited the platforms. Of course I wont know how well it is until the character is in and his jumping value is implemented.

What do you guys think about grabbing the edges of platforms?

I think this is something you should discuss with your programmer.

True. with that said working on another area of the map. Theres some adjustments I need to do but im just putting down what i planed out on paper. The boxes stick out too much so i may have to re color those. Boxes on the left are BG and the box on the right will be movable and will be a sprite as well. I have to work on that little light source. its a bit boxy and of course the light itself. May have to make that into a sprite as well.

HAHA just noticed the mistakes i made. gonna have to make those platforms thicker so there wont be no palette issues.

Sorry about the slow progress. I am working on two other things so this is some what on the bottom of my list. Here is a sample on how things would look connected. I still have a long way to go for the first stage but gives you an outlook of it for now. The character will be able to push and maybe pull objects as you can see. I also recolored the spawner and the box. Spawner blended too much and the boxes were to bright.

Looking good! Always exciting to see your progress.

A quick thought would be, how about creating multiple layers to the background? Say, if the background is a tissue of some sort, what if there were sections where that was pulled away, and you could see something else behind it? You could use some other colors as well to spruce up the larger background sections.

Perhaps a better description would be to have some accent tiles for the main background. Also, the squareness of the tile repetition stands out to me. I'd try to come up with a repetition that's offset in a way which is a little less apparent.

I like where this is headed.

I have to be honest, this is looking pretty bland and blocky. It's not bad, but the only thing that really stands out is the background, which has an interesting organic look.

The metal door for example, is so bland that it almost looks like a button from Windows 3.1. It's too flat and the shading is too simple. If you added scratches, dents, rust, or any sort of imperfection, I'm sure it'd look more interesting. The same goes for the metal walls, obviously.

Another problem is that the floors are too repetitive. The pink floor pattern (which appears to be made of little Geisha dolls, something I can't unsee now!) repeats after only 8 pixels, without anything ever breaking the monotony. The metal platforms are even worse, repeating after only 4 pixels! If you're gonna use patterns this short, at least add some variety every now and then, with broken/cracked segments, or some ornaments that appear every several pixels, things like that.

The shading on the crates looks confusing to me, and doesn't give them any volume. The color change was also weird, because they appear to be made of metal now, but the structure is still that of a wooden crate. If you want to see some great looking crates on the NES, check out Batman - Return of the joker. Just look at the texture and volume in those crates. And the game even has wood and metal variations.

Yeah that's some what the plan. I didn't want to put too much stuff until I see the space we have for the tiles because we would need a decent size for the char, objects, enemies, and tiles which you already know.

The squareness I already know. If its standing out to you its been punching me in the eye so how do you think I feel Right now I am trying to get a feel for it while keeping the stupid palette thing in mind. If it wasn't for that radius BS this would be easy or if this was an easy forest or cave, anyone can easily put it together.

So yeah once i know the following I can add more curves and everything else to this. These are just all place holders and to get my idea down.



as explained above. All of this are just blue prints (place holders) to get the bone structures of what goes where. I refuse to over detail stuff just to have it be put together and then realizing that something needed to be taken out or because of the palette radius takes over and I have to redo everything. So yes its bland and repetitive. once everything is put into place and I see what works I would be more than happy to super over detail everything with that NES has to offer.

I am more of a character designer not a BG designer. Normally you'll have just one person for BG. I know there are some people that does everything with no problem, but I am not on that level yet though I am forcing myself to go beyond those limits. But I appreciate the references and opinions to make this stand out more. It'll get there. I just refuse to do what everyone else does with environments. Forest, caves, forest, caves, forest, caves, castles meh

Yeah, I think tokumaru made some good points for when you get to detailing. Batman: Return of the Joker looks great, although it drove me crazy that Batman's weapon is a gun that shoots sparkles. That didn't seem particularly Batman to me.

One thing I wonder is whether or not it's common to have different eject points within metatiles. This could potentially help some with the blockiness. The way I see it, one byte could define 16 positions for height, 16 positions for width, and then two bits within the collision data could determine if the solid portion is on the top/bottom or left/right.

I agree with you about the level deal. I liked how AVGN made the point that every game has to have a cave where you fight snakes and spiders.

Fixed the boxes and finally got a darker enough color to work with the stage. Door was edited though honestly with the platform on top even with that metal column fully raised, I don't think there was suppose to be that much lighting going in there. still tweaking the shading but wont be fixing the "repetitive" stuff until later. With that said I will add a few more texture layers to the BG to do different combinations.

The boxes are much better!

I don't know if this has been pointed out already, but you have to be careful when using dithering patterns. Due to the way that the NES generates composite video, dithered patterns often generate weird diagonal lines and/or artifact colors. You can see this effect in games by using an emulator that includes blargg's NTSC filter, which accurately simulates the way the NES generates images. If you want to preview your art without having to program a ROM, you can use this.

Man, Its been such a long time since I have been on here... Almost two years as it seems. A lot has happened and my pixel art for 8 but has gotten much better over the years... well more recently lol with more understanding now of the NES (though there are still things I need to learn) things have been a lot easier and organized. Finally I came to a decision to make an NES game.

I am still working on the player's template. Because of the limitations and the lack of coding I had to really make it as easy and thought out as I could. There is still much I have to do... I am wondering now if I need a shadow tile for when the player jumps.... Here we go again lol