nesdev.org

Bregalad wrote: The problem is that this doesn't really help in this case, as if the characters moves by big chunks it will look bad. However, characters don't move that much vertically, so maybe it'll be possible to make some horizontal line to not make a big chuck of one solid color as the background, and when the character jumps, well, I don't know...

Maybe parts of the fighters that jump that go above the fighters' "horizontal line" can be drawn using sprites, but that may not be plausible if the fighters are more than 8 tiles wide.

For a fighting game, I was thinking that to draw a normal background (not blanked at all) along with BG fighters, the game could use MMC5 with ExAttributes. Parts of fighters that cover whole or almost whole tiles would be rendered to the BG, and parts of fighters that take up half or less of a tile would be rendered with sprites. The game would need to turn off some scanlines (maybe a little more than 16?) to update more tiles than usual for updating the fighters. Since there's no level data and very little objects to check collision for, it might be plausible to set up this data to render without slowing the game down.

It doesn't matter if there is the MMC5 or not, as the MMC5 has the ability to show more tiles at once on the screen and to bypass the 2x2 normal color limit to implement a new 1x1 limit, it doesn't allow multiple backgrounds to scroll one on the other, so you'd still have to have the area behind both fighters blank. Unless of course one of the fighters doesn't move, which is just stupid.

The method I was thinking of allows background tiles behind the fighters, although it won't allow multiple scrolling backgrounds behind the fighters' action area as a disadvantage. This could be resolved by using the animating parallax tiles method as mentioned before, but the tiles would likely be repetitive like that. The ExAttributes could help have more fighter tiles rendered to the BG so that the background and fighters' attributes don't collide, and less sprites to fill for missing fighter areas that take up less than half a tile (since only fighter tiles that take up nearly whole tiles are rendered to the BG in my method). Although this method could also be done without ExAttributes, but that would require some more sprites for the fighters' missing areas.

He was suggesting a method to have big fighters while still having a background.

I think he meant that tiles that are fully occupied by the players (both of them) should be drawn to the background, while tiles with transparency would be rendered as sprites, surrounding those other tiles.

I think this is a good idea, but there are some problems. first, motion would not be very smooth, because when drawing stuff to the background you have to respect the 8x8 pixel grid, so it'd probably feel like some fighting games programmed for the Mester System. Also, even if we're just using sprites around solid tiles, there are many frames of animation where there aren't many solid tiles, and almost everything would have to be sprites anyway.

The "blank background" way can provide smooth animation for both players, since only one is drawn to the background and this background can be scrolled freely. I'd probably use 1-screen mirroring for that, with one of the name tables used for the background (with a blank area) and the other name table is exclusive to the other fighter. The screen would have to be split twice during rendering, to insert the background player in the blank area.

I'm still thinking of a good way to "fake" a more complex background while still having one player fully rendered with background tiles.

EDIT: Oops, too late! =)

Well, what you describe is quite insteresting, while it seems not doable.
This would work if both players moves by 8 pixels increments (both vertically and horizontally) AND if the mapper is MMC5 so that each tile get independant banking adressing and color, which is great. Then the game would have to redraw those tiles each times one of the fighters changes it's position or moves 8 pixels ahead, mazing the background back, and re-mazing the player further. I think it could look good if the player are really enormous, but then the graphics won't look too good either if the characters are just too big. Alternativly, you could duplicate each sprites (but decaled of 4 pixels and get 4 pixel increment, which is more decent, and quadruple all sprites (each time decaled of 2 pixels) to get 2 pixel increment, which would look good enough. Then each fighter for each poses has all it's "interior" made of background with 8 different variants (in function of the horizontal position), and both fighters moves horizontally by 2 pixels increment, and vertically by 8 pixels increments (they won't move much vertically anyway exept when they jump and when they fall). Additionally to this, both fighter's palette (assuming they use one) are redundant with the background, leaving 2 palettes for the background. Since the background is selected in function of one of the fighters (typically) this helps a lot. This sounds definitely doable, but only with the MMC5, and with a lot of CHR ROM. It can be done with another mapper, but then everything would have to be the same color (grayscale) and would look terrible, or have to move in 16 pixels increment, which is even more horrible.

I better like the idea of one figher BG and the other sprites, and this can be done easily, but with BG only above and below the fighters, which can definitely look decent. Honnesly, I already see the street background with houses on the top, a road in the middle which is made of solid grey where the guys fights, and a barrier with some people watching the fight below. Or even better, a beach where you have palm tree, etc.. on the top, solid yellow on the middle and the sea on the bottom. Seriously such backgrounds are easy to made. Additionally you can have the bottom scroll more than the top and give the game a 3D look. This would be done with vertical mirroring, and would work very well.

If jumping (or vertical moving) is allowed, this make things more complex, not only for collision detection, but also for animating the player themselves, especially if one is made of backgound. Additionally to this, as long as jumping is featured, the players can jump over the other and face another direction. If jump isn't featured, you can just assume player 1 is watching right and player 2 is watching left.
As for the size of the characters, they can definitely not be higher than 8 tiles : Because when they fall, the sprite player cannot be "longer" than 8 tiles, and it would look bad if he suddently become shorter because it fell. Maybe if he passes from 9 tiles to 8 this won't look too bizzare, but more difference will be noticeable. Of course, the CPU could automatically exchange the sprite and the BG player when needed (so when one fall, it automatically becomes the BG one to be more long), and I guess it would be rare that both player fell at the same time (depending on the game engine). I don't know if this would be doable.

Tokumaru : Are you really sure fighting game are that much easy to code ? Becuase I never trought about it seriously but now... I couldn't think about anything else the whole day ! I might do a fighting game after my current game is out if I get inspired for enough characters (and moves) ! And the advantage is that you can take your characters from other games you already did (you just have to add details to them). Maybe even stole characters from existing games : Imagine a NES fighting game called Capcom vs NESdev !! Wouldn't it rock ?
As for the AI of fighting game, I think having the CPU attempt random moves at regular intervals (and no nothing if the player blocks those moves) might work well enough, and making it so that normal mode have the CPU act slightly faster than easy modes where the CPU only kick and punches once in a while. Hard mode can have the CPU try to avoid and/or block kick and punches from the player more often (additional to quick attack when it get the chance to), but still do it with enough delays betwen actions to give the player a chance.