Learning NES Pixel Art with restrictions

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

Moderator: Moderators

Post Reply
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 »

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

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

Post by Fjamesfernandez »

tepples wrote: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.
Yeah. Limit Break (FF), Mega Move (SNES DBZ), Desperate Move and so forth :D 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.

Image

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

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

Not without an incredibly expensive circuit to swap which chip is connected to each line of the CPU or PPU bus.
User avatar
darryl.revok
Posts: 520
Joined: Sat Jul 25, 2015 1:22 pm

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

Post by darryl.revok »

Fjamesfernandez wrote:What would b e the CS size any ways?
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?
tepples wrote:Not without an incredibly expensive circuit...
I also realized after posting that you'd still need the mask ROM from which to pull graphics.
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:Not without an incredibly expensive circuit to swap which chip is connected to each line of the CPU or PPU bus.
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.
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 »

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 :D 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 :D

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.
darryl.revok wrote:Does that make more sense?
Yeah... I get it.....:D
Attachments
Alex-Mugen-Nes.gif
Alex-Mugen-Nes.gif (1.28 KiB) Viewed 5257 times
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 »

lidnariq wrote: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.
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.
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 »

tokumaru wrote:CHR-RAM instead of ROM
:?: 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.
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 »

tokumaru wrote: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.
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.
User avatar
rainwarrior
Posts: 8735
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

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

Post by rainwarrior »

Espozo wrote:...its worse than rom because it's too slow.
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. :P 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.
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 »

Espozo wrote: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.
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?
lidnariq wrote: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
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.
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.
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.
rainwarrior wrote:It's only "slow" if you're comparing non-bankswitched RAM writes to ROM bankswitching.
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.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

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

Post by thefox »

tepples wrote: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.
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
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
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 »

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).
User avatar
darryl.revok
Posts: 520
Joined: Sat Jul 25, 2015 1:22 pm

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

Post by darryl.revok »

Fjamesfernandez wrote:Reason I am hesitant to work on sample title screen. like this might be too big.

Image
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.
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.
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.
Theres still things I need to fix in the bottom animations. but its just trail an error.
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.
Post Reply