Learning NES Pixel Art with restrictions

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

Moderator: Moderators

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

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

Post by Fjamesfernandez »

dougeff wrote:
it possible to have a quick animation like in Ninja gaidens Cut scenes?
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.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

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

Post by tokumaru »

Fjamesfernandez wrote: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.
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.
User avatar
Fjamesfernandez
Posts: 57
Joined: Thu Oct 01, 2015 5:34 pm
Location: NYC

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

Post by Fjamesfernandez »

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 :D
tokumaru wrote:Do you want to animate attacks as cutscenes? Yes, that's be perfectly doable
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.
tokumaru wrote: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
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.
(ROM or RAM)
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.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

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

Post by tokumaru »

Fjamesfernandez wrote: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.
That's cool.
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.
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 need to read up on this. I know "RAM" only through memory for the PC not the cartridge. this is all new to me.
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.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

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

Post by Drew Sebastino »

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

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.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

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

Post by tokumaru »

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).
User avatar
Fjamesfernandez
Posts: 57
Joined: Thu Oct 01, 2015 5:34 pm
Location: NYC

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

Post by Fjamesfernandez »

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

Image

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

Image

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)

Image

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.

Image
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

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

Post by dougeff »

no longer able to switch "tiling" around
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.
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
darryl.revok
Posts: 520
Joined: Sat Jul 25, 2015 1:22 pm

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

Post by darryl.revok »

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.
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.
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.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

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

Post by dougeff »

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.
nesdoug.com -- blog/tutorial on programming for the NES
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

Remember the example of SMB2? That's CHR-ROM animation.
darryl.revok wrote:What's the 128 box?
The library of 256 tiles.
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.
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.
User avatar
Fjamesfernandez
Posts: 57
Joined: Thu Oct 01, 2015 5:34 pm
Location: NYC

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

Post by Fjamesfernandez »

dougeff wrote:I like your sample a lot! Final fantasy style. Good choice.
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.
dougeff wrote:The enemy, however, may be slightly too large.
Oh! Yeah that won't be the size. I just did that for a sample :D 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.
darryl.revok wrote: 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 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.
darryl.revok wrote: 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.
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.
dougeff wrote: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.
Haha yeah the biggest I can go for normal enemies IS 64/64 :P Again just did that just to show my ideas :P Reason why I didnt want to make the heroes with multi layers to make better colors on them.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

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

Post by tepples »

Fjamesfernandez wrote: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.
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.
lidnariq wrote:no commercial games ever used more than 8 KiB of CHR-RAM
Except perhaps Videomation, the two Oeka Kids games (Japan only), and RacerMate Challenge 2 (unlicensed).
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

tepples wrote: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.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

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

Post by tokumaru »

[quote="tepples"
lidnariq wrote:no commercial games ever used more than 8 KiB of CHR-RAM
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.
and RacerMate Challenge 2 (unlicensed).
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.
Post Reply