Well, everything is in the title. I mean to to animate a big BG made fighter. The best would be to have each fighter take a 8x8 gird (64 tiles) and just maze it once at the start of the fight, then you only have to switch between CHRROM bank to animate the guy and have to do nothing else. Unfortunately this waste BIG chunks of CHRROM, and unless you use a mapper with supports 256 KB CHRROM (aka the MMC3), and even here, with 8 different fighters, assumink you still want 32 KB CHRROM for the rest of the graphics, this make 224 remaining KBs. With 1 KB per animation (8x8 tiles) and 8 characters, this would do 28 animations, wich is correct, but would waste a lot of CHRROM and remain very few for the rest of the graphics. If you want the same with only 128 KB of CHRROM (wich the MMC1 supports), this will do 12 animations per character which is barely decent.
So I guess it's forced to have a system that re-writes tiles for the such character. If the character is max. 8x8 large, and if there is no attribute to update, I guess it should be doable if there is only nametable updates. With CHRRAM, this would be pretty limited as each character would only have ~70% of a pattern table for itself. If the chracter is big, that means not so many animations frames.
So I guess both pattern talbe CHRROM switching and nametable updates are necessary. Alternativly, CHRRAM updates (and no nametable updates) could be done, but it would certainly make things harder, as a lot more updates are needed for the same animations.
Am I right ?
I bet someone will say MMC5. I'm not a MMC5 fan myself, but I admit that being able to index that many tiles at a time would make things easier. Wait, did I just suggest the MMC5? O_o
Seriously though, I'd avoid CHR-RAM for this. If you blank a few scanlines it is possible to copy a big deal of attribute table data per frame with (partially) unrolled loops, but since one of the fighters is drawn with background tiles, you already have very little space on the screen with actual background graphics (only above and below the fighting area), and giving up on a few scanlines might make a big difference.
I don't think you can do a decent fighting game with less than 256KB of graphics. If you think about it, 28 frames of animation for each character is not much... unless they don't jump and don't have many special moves... I'd rather reduce the number of fighters for beter animation of the remaining ones. And you also have to account for other tiles, such as the ones used for blood, special effects and energy blasts...
I bet you could do it with the MMC3. Maybe each 2KB bank could contain as many frames of animation of the same character as you can fit there, so that you can switch the appropriate bank depending on what the character is doing. On the side that switches banks of 1KB you just switch 2 banks in. On the side that switches 2KB chunks, the other 2KB could be used for the background tiles and other tiles that are commonly used (life bars, etc). The ramaining 2 1KB banks can be used to hold supporting sprites for the players (one for each player), such as energy balls and blood, and you switch them as needed, to achive very rich animations.
You'd have to update the name tables though, but without having to update CHR-RAM this is easy.
The MMC5 rocks, but who would want to destroy a CV3 cartridge to developp a homebrew game without even being sure to finish it proprely ? Yes, destroy Laser Invasion would be a good idea but it's not released here in europe so I have no chances to find it.
Since the screen would be something like 3/4 background and 1/4 fighters at most, reducting a small part of the 3/4 of background to have a longer VBlank would not hurt at all. At least I think so. And CHR-RAM could allow the tiles to be software flipped (usefull for the BG fighter !), else the BG fighter would always have to watch the same direction (which isn't that much a limitation).
28 frames per characters isn't that much, but it starts to be a little decent I think. However some frames would only have small differences with others, making that a full 1KB bank per frame would be a waste.
So I'd think CHR ROM switch + Name table (and possibly attribute) is the way to go. Since it causes no problem to have the CHRROM bankswitched midframe, each fighter has a full pattern table at disposal.
About blood I wouldn't put any no matter of what anyone says, because I can't stand gore games, and that is especially valuable if this introduce technical complications. And yes, slashes and such things could be done, but there wouldn't be the need for many, and this could be part as the fithter's graphics themselves.
The problem is that if you want to use the same tiles for a fighter regardless if he's BG or sprites, then the background color must most probably be set to another color than black, and the sprite fighter will always be the flipped one by sprites while the BG one is non-flipped. Alternativly CHRRAM could flip sprites by software, and swap the colors for the background. However, if the fighters are, say 8x8 tiles in size even while banking a few scanlines, it would take 4 frames for a complete update, so for both fighters they could only animate each 8 frames each, which is kinda limited (but it still could look okay I think).
Maybe TQROM could help when having once character animated with CHRRAM (the BG one most likely) and the other with CHRROM (the sprite one most likely), so that they could move each 4 frames, which is good enough, and still could be flipped/color swapped (by reading the tiles from CHRROM, editing them and write them back to CHRRAM). This could also allow all the game's graphics exept the fighter to be held by CHRRAM, so that 64 KB may be enough (maybe not, though).
I think 8 fighters is not that much and having even less will make the game seriously too short. 7 maybe, but not much less. I think 128 KB could handle it, as long as you keep the animation tile-optimised and that the rest of the graphics are not terribly varied/detailed.
You could always go the Mortal Kombat/NBA Jam route and make a lot of the characters palette swaps of one another with different heads.
Or you could go the Kung Fu/Shaq Fu/Smash Bros. route and make the characters smaller and arenas bigger.
tepples wrote:
You could always go the Mortal Kombat/NBA Jam route and make a lot of the characters palette swaps of one another with different heads.
Oh, my that is CHEAP ! Unlike the said characters are supposed to be twins or something. Well, with different head that could be decent.
Punch Out is very guilty of reusing bodies and switching heads.
I'm personaly against destroying games for any reason.
Then think for 2 secs how do you make a dev cart huh ?
And PLEASE change your avatar IMEDIATELY or I'll piss on you.
Bregalad wrote:
Then think for 2 secs how do you make a dev cart huh ?
PowerPak?
MMC5 is not supported, MMC1 and MMC3 are but there are no proof they are 100% acurate.
And, the personal main beef is that you need a cash card to order a power pak.
Bregalad wrote:
And, the personal main beef is that you need a cash card to order a power pak.
Or a bank account or a friend with a credit/debit/bank account.
Bregalad wrote:
MMC5 is not supported, MMC1 and MMC3 are but there are no proof they are 100% acurate.
Who cares about accuracy to Nintendo mappers if you'll never be desoldering ROMs or mapper ASICs from cart boards? Tengen didn't care about accuracy vs. Nintendo MMC3 when it upgraded MIMIC-1 into RAMBO-1. If a work runs on an NES, it runs on an NES.
NotTheCommonDose wrote:
I'm personaly against destroying games for any reason.
You can always program the original game to EPROMs/FlashROMs and still play it with the board... Many games are crap and I don't feel bad at all about destroying them.
And please, do not distort whole pages with this terrible avatar.
tepples wrote:
Who cares about accuracy to Nintendo mappers if you'll never be desoldering ROMs or mapper ASICs from cart boards? Tengen didn't care about accuracy vs. Nintendo MMC3 when it upgraded MIMIC-1 into RAMBO-1. If a work runs on an NES, it runs on an NES.
I don't think anyone wants to program a PowerPak-exclusive game.
Some of the fighting games (like the Mortal Kombat ripoffs) use MMC3. It's fully capable of running your average generic NES fighter game.
Normally what they do is use sprites for the fighters, and lots of flickering to get 'em all to fit on the screen at once.
I think they could actually be decent games, but the terrible "music" and crummy gameplay ruin it. The graphics are quite decent for the NES and if the coding was better, it could be really nice.
It seems that there's only really one "fighting game engine" and it was copied/hacked/pirated over and over again. The music certainly is mostly the same in them, and of the same style.
(as an aside, it appears that only company is responsible for alot of these knockoff games, and use the name "hummer" or "hummer team". I see that show up alot in the graphics.)
The pirate Street Fighter III (I said III, all the versions of II are crap) has pretty good graphics, and is better than the average pirate fighting game for the NES. They managed to make nice looking fighters just with sprites, and, as far as I remember, the flickering is not that bad. If you're gonna be inspired by a pirate, this should be the one.
Well graphics are ripped from the SNES Street Fighter 2 and the gameapay is SLOW !
And the pirate versions of most fighting games are pure crap, maybe SF3 (which seems to really be a renamed pirate SF2) is decent, but definitely not good.
Well, the controls are way better than most other SF and MK pirates. And the sprites, although obviously ripped, are composed by pieces that use more than one palette (there seems to be a "shared" skin palette, plus another one for each fighter), which makes them look much better than the common washed out fighting sprites you usually see in these pirate games.
I didn't say this SF3 was a good fighting game, but it sure is the best pirate I've seen. Graphics mostly. It even makes me believe that the NES could have had an official port of SF2.