Free Animation for Your NES Project

Hello!

I've been doing a lot of animation lately, and for fun and practice, I want to offer to do an animation for somebody's NES project.

The first person to post a sprite of their character in this thread will get the animation. I don't want to design a character though, so you have to have at least one sprite.

Specify what you'd like me to animate the character doing, how many frames, and tile limitations if any.

You'll get full rights to the animation; you don't even have to credit me. The only caveat is that I want to post it here for feedback, since I'm doing this for practice.

Do you want to do 1 or more bosses for Vigilante Ninja 2?

I'd love to take you up on that offer, but I don't have a project at that exact stage of development as of today, unfortunately. But maybe in a couple months, I'll have designed characters for a short film that I'm writing. Here's the screenplay for what it's worth.

Sure!
For right now though I plan to just do one animation, so it would be like, a walk cycle, or an attack, or something of that nature.

I usually do about 8 frames for an animation on my characters. If you want something 4 frames, then I'll do two.

As said in the first post, post a sprite and you've got it.


Is this an education program for feature recognition, object permanence, and awareness of what information a person would be able to perceive?

There were a couple things that seemed a little confusing and I don't know if it's just me. Why does Bidge say, "I guess you can keep it for a while", giving Mel permission to have her own ball back?

Also, am I understanding this incorrectly or does it rewind to an alternate timeline in which Bidge is aware that Mel had kicked the ball into the toy box? Is it just me or would this be confusing for children?

Same here. In all cases I'd be more interested in being teached how to do great animations, rather than them being done for me.

I really wish someone would offer "free enemy/boss AI" instead, because that's the part of my project that has been preventing me to complete it for years. I know I want enemies to attack the player, I just don't know how.

The offer's still open for the free animation. I'd be happy to do one for Vigilante Ninja or any project if I get a frame to start with. I figure it's probably about an hour per frame, so an eight frame animation should be around eight hours work. I'll revise it too if people have suggestions.



I have been suggested by a member on here that this book: http://www.amazon.com/The-Animators-Survival-Richard-Williams/dp/0571202284 is the resource for learning how to do great animations.


Are there any good threads on this? I'd be surprised if it hasn't been discussed at length.

I haven't got to the point of programming serious AI yet, but for what you're describing, I was thinking of basically having the enemy object test the conditions of it's attack vs. your player data. Specifically position, but you could use things like player velocity as well to make the enemy smarter. If the enemy finds that it could launch an attack that could land, issue that command.

What kind of game are you making?

Here, do something with this...

The boss of level 3 will be a bat.
I need 4-5 flapping wing animations.
Max tiles for any animation is 20, but I prefer closer to 12 (4x3 -ish).

I haven't designed the level, but the background is going to be very dark, black dithered with one of the 0x colors.

darryl.revok : One thing that could be interesting was that I was trying to code a small demo / proof of concept, of a NES fighting game with two oponents, one sprite and one BG.

The demo I have coded so far is extremely ugly, minimalistic and lack animation, so maybe you'd be interested to work on some animation for that. It's not typical NES graphics however, since those would be of large, probably 5x10 tiles (40x80 pixels) ,etasprites. They will have restrictions similar to BG when it comes to usage of coulours (every 16x16 block will have to use 1 palette, no tile overlapping (or maybe a little overlap just for the face)). It would also require more animation frames than a typical 2-3 animation frame on the NES, although this is not a requirement.

Don't expect a full game to come out with that anytime soon though, so if you are interested you can just tell me, but if you don't I fully understand.

Okay, here's the first draft of a flapping wing animation. This hardly took any time at all, so I plan to do a couple more, maybe a diagonal swooping attack? I can revise this too but I'm not sure if there's really anything I can add that would improve it.




I did a three frame ping-pong cycle and I don't know if it needs anymore.

Since the actual animation time for this one was so quick, I was planning to spend a little more time revising it to minimize the number of tiles used. If the bat was symmetrical then that would halve the number of tiles used but could potentially look generic. I'm thinking if I reuse the tiles that are mirrored, and allow some of them to overlap, I can bring this down to a very small number of tiles.


This is pretty interesting. The game I'm developing is a bit of a hybrid fighter/platformer, with smaller characters.

I've considered the possibility before of using background tiles for characters and didn't think of a good way to make it worthwhile. Are you going to use CHR-RAM?

After I do a few graphics for Vigilante Ninja I might try coming up with some basic graphics for placeholders for you if that helps. The problem is that seems like a really big project, and I've probably got a couple thousand hours on animations I want to make for my game. I definitely couldn't do a major animation role on a project lke that.

With that being said though it sounds cool and I'd like to help, if doing a few frames helps. I haven't done anything that size yet, so I'm just guessing being over four times the size of my game characters, a frame could take four times as long. Might be good practice though to do something more detailed than what I'm used to.

No. As long as the demo/proof of concept is simple enough so that a character fills a page (256 tiles or 4kb) it doesn't really matter, and I just use plain NROM right now. If this should one day turn into a fully playable fighting game then I'll most likely need more than one 4kb page for one character, and the only way to switch quickly from one page to another is CHR-ROM. Doing it Battletoads style is unthinkable with large characters. We could use multiple buffers (Prince of Persia style), but then it would limit the rapidity of animations, for example changing from one animation to the next might take a minimum of 5 frames. I believe this would be way too limiting for a fighting game, but I might be wrong.

So yeah, CHR-ROM is really the only option here. (Assuming I do not want fancy mappers mixing CHR-ROM and CHR-RAM, or bank switching CHR-RAM).


It really isn't even a project, just a tech demo that is low on my priority list. Just a single fighting character performing a punch, a kick a crouch and a jump animation would be more than enough. Also an advantage of very large sprite is that there needs less to be attention to detail, if a single pixel is wrong it won't make all the difference anymore.

If I'd want to turn this into a full-sized game one day, I could always inspire myself from your animations for the first character if you did them. Maybe even re-use tiles. There was even a discussion about making a collaborative fighting game, using various characters from all our projects. The project was given up but it might resurface who knowns.

I am still unsure about what size the fighting characters should be. My current tech demo has a 4x8 tiles (32x64 pixels) metasprites (so about twice as large as your typical NES sprite), but supports 8x10 tiles. I believe using all that space is a bit overdoing it, and we have to keep in mind some backgrounds should be also present above and below the fighters, and cannot overlap with them. This is actually the most limiting factor, combined by the aspect ratio of those characters, obviously.

So I believe a size of 5x10 tiles (40x80 pixels) would be the upper limit on a still standing fighter's area. I could easily expand my current sprite to become a bit larger, and it respect the very standard 1:2 aspect ratio. Some fighters could be smaller than others, to be more realistic, however that would seriously limit the re-usability of thier respective graphics.

I doubt that drawing large characters is necessary orders of magnitude time consuming than drawing small ones. If you get the overall body shape right, then I believe it is quick to make a convincing animation frame, since there is no such need to look at small details. However, I have still trouble doing that right.

So yeah, it's really as you want. I don't want to steal an opportunity for someone else, as this is really a low-priority side-side project of mine. But if you're bored and skilled with animations, and are interested to do something very different, then why not? Who knowns maybe your animation will be so awesome it'll inspire a whole game from my side (of from yet someone else on this board).


Interesting! I don't know how I could get this book in real life, because I don't use amazon. And your bat animation looks very great, by the way!

Thanks.

Maybe, make 1 more frame where the wings are a little lower, and starting to curl forward. Let's see how that looks.

Here's a mo better bat.



That was a good suggestion about adding another wing flap frame. I also took out one of the frames on the downflap to give it more lively timing.


Yeah, I know what you mean. CHR-RAM is neat for a lot of things but big detailed animations need bankswapping. I definitely need to be able to bank swap for my game engine.

On the other hand, on the quest to find a way to get more than 256KB CHR I came across the Coolboy, with 256KB bankswappable CHR-RAM registers. While I don't know if the Coolboy itself is ideal for production of a final game, I do tend to think bankswappable RAM will be the way of the future of the past of mappers if there are customers interested in high-end mappers.



That shouldn't be too hard. I'll let you know when I have time to do it.

I'm curious, is the background character going to move via scanline splits? Otherwise it would be difficult not to have them move in a grid. The downside to the scanline splits is that you end up with a blank background behind them.

I'm sure you've thought about all of this stuff. I'd like to know what your thoughts are. Feel free to PM me if you want to keep some stuff non-public for now.



This is really interesting. Do you know where the thread is? I'd like to contribute if this ever resurfaces.



I guess this answers my earlier question.


Have you ever tried drafting your frames first with just the shapes of body parts to get the animation timing right? That's what I do.


Thank you. I tend to think it needs a little extra flavour. It does look a little better now though. Any critiques would be appreciated.

Thanks. Looks better. I might edit it slightly...when I get to that point in my game (maybe a month?)

Yes. At least horizontally for sure, but vertically too probably, unless characters aren't alowed to jump, but that would reduce the fun of fighting. So very likely it'll be scanline split in both axises, with a limited range for vertical scrolling.

Another viable option would be split scroll horizontally only, and make the character jump only through different animation frames that would make it effectively look like going up and down. This would then allow an arena consisting of horizontal lines instead of a plain colour but honnestly... I don't think it's worth the bother, especially considering those horizontal lines would share the BG character's palette.

The screen layout would be like that :


Although I am not even sure if I'll include "arena bottom" at all, maybe just simulate it with a few sprites and/or horizontal lines, in order to free CPU times and stop the scrll split between "arena top" and "fighters".


Personally my philosophy is to always use the simplest mapper possible. If I'd go for a high end mapper, then I'd rather go all-out and do 3D rendered game with many co-processors, so the project is still a technical challenge.


Yes. I usually draw by hand before I draw on the computer, and also I keep an armless body available as a basis for other animation frames.

Making the character jump isn't going to be any trouble. The only real problem is that you've then got a solid color behind most of the playing field. You can do a scanline split above the character for a sky, and a ground texture below. There will be a pretty big amount of empty space in the middle though.


I wouldn't sweat the extra scroll split at all. Once you get far enough to have one, making another isn't any trouble. Are you using MMC3?

I have a scrolling engine that can do all of this stuff. It's for MMC3. I'd use horizontal mirroring, then you only have to draw columns to scroll left and right. Your playing field will be a little less than two vertical screens due to overlap from your character BG scroll split. I've also been able to swap as many as two CHR banks as well as a horizontal/vertical scroll split in one IRQ without glitching. If you wanted to use 1KB CHR banks and swap all four it would take two IRQs, however just two 2KB banks can provide infinite tiles onscreen.


Honestly I'm a little surprised how many people say they're sticking with NROM. I mean, I'm not surprised that people use it at a restriction, to say, I'm going to make the best game I can with NROM to push my skills and give the project a feasible scope, I'm surprised that I feel like most people have this perspective.

Personally, I want to use the simplest possible mapper that will make a game the quality I want. For the animations I want I need 1KB CHR bankswapping and I can't really get around that. A chainable IRQ timer and above all big CHR. 256KB is even a little small for me but I think I can make a program small enough, so that if I use CHR-RAM and compress, I'll leave enough space to fit more than 256KB CHR, with my game, in 512KB. I'm HOPING. That would leave needing larger CHR-RAM than was used during NES's life for bankswapping as the only requirement. That doesn't seem too far for me. It's not putting new hardware in a game to make it work, just a little more of the same stuff that was originally used.

What about Membler's GTROM...

It's no major problem, but it increases the complexity of scroll split (needs to scroll bidirectionally instead of single-directionally), and removes the possibility of using horizontal lines background instead of plain colour. I was planing to go with plain colour anyway so it does not matter.

The second problem with jumping is that it greatly increase the height of the plain colour band, and as such, greatly reduce the heigth of arena graphics (no matter if they're top or bottom). Let's say if a fighter is 10 tiles heigh and don't jump, and the status bar is 4 tiles high, and that we can't use the top/bottom 2 tiles because of overscan.

Then the amount of tiles for arena is : 30 - 2 - 4 - 10 = 14 tiles

But now if we have the character jump it's own heigth, then 20 tiles should be reserved for the character alone.

The arena's heigth becomes : 30 - 2 - 4 - 20 = 4 tiles.

Obviously that's a major problem. Basically the screen will be a narrow status bar, a narrow arena, and a huge blank area. Not very good looking.

The only real solution is limit the height of the jump to much less than a character's own height. Or have smaller characters. Or a mix of both.


I'm using NROM right now, but if this turns into a game it of course will use a more complex mapper capable of CHR-banking. I don't know if MMC3 will be necessary, if it is, then having a bottom area for arena graphics is doable, except for the screen space problem I mentioned above.

Since screen space will be so limited anyway, I thought I could just as well get rid of the bottom arena part, and have a few sprites doing the job of filling the very bottom of the screen. Especially considering the sprite fighter character will take only about 25 of the 64 available sprites (using 8x16 sprites).

If I remember correctly, the GTROM wouldn't work because it didn't have fine grain CHR banking for sprites.

Since my characters have around 16kb animation, they're pretty much restricted to needing their own CHR bank.

Although, I really like the direction that Memblers is taking with his boards.



You could scroll the screen vertically a little when people jump to get a bit more at the top and bottom but that's still not going to solve the issue of most of the visible screen being a solid color.

Have you given any thought to making a fighting game with sprites? I know it's going to limit the size of the character but I feel like the overall game might be limited less. Let's say you use all 64 sprites on the characters and somebody throws a haduken. Well, you could just render the haduken every other frame. Being that it's translucent, the flicker won't even look bad. Then you could set it up so that just the low priority sprites of the fighters flicker out, leaving the ones to define the shape. The characters would probably have to end up being smaller than a traditional fighter, but it's a trade-off.

Something else that I feel is worth considering is the two button limitation. This is just my opinion, but I don't think anybody's ever going to be able to, for example, recreate the experience of Street Fighter II on the NES. If nothing else, the lack of buttons is really going to hinder that. So, just to throw it out there, I feel like an NES fighter needs something unique in the gameplay department. I'm not saying something complex, quite the opposite. A unique gameplay mechanic that is simplified enough to be really fun on the NES. Something that makes playing this fighting game different from any other for reasons other than just being on a lower powered system.

In other words: clone Smash Bros. instead of Street Fighter.

To be honest I haven't because I tought this was probably already done. It would limit the technical challenge, and such, loose my personal interest for such a project.

This would basically limit sprites to 4 tiles horizontally for the typical, not much smaller to what I have proposed.

However the worst case has to be considered, and that is the case where both fighters lie on the ground, so their whole body lies horizontally. We could design the game so that's impossible, so only one fighter can be knocked out simultaneously. Then, we can imagine that the standing fighter is 3 tiles wide and 6 tiles high, while the knocked-out fighter is 6 tiles wide and 3 tiles high. There would be a little flickering, and the characters would be only 6x3 tiles.

With my sprite/BG scheme, the lying character on the ground can take all 8 sprites for himself, and such the heigth limit is 8 tiles (so all what I said before about a heigth of 10 tiles is completely wrong, as I had forgotten that detail).

In order to keep the traditional 1:2 ratio, thet would make the characters 4x8 tiles when standing, and it's probably why I only used this size in the demo, even though it supports more.

Annother approach would be to store the tiles for the knocked out character twice in the ROM (for both directions), and alternate the BG/sprite character on the fly, so that whether a character is knocked out, he becomes rendered by BG, and the standing one is rendered by a sprite. This also forbid a situation where both fighters are knocked out simultaneously, unless flickering becomes acceptable in this rare case. Anyway, this is required only if larger characters are desirable, and because of the vertical screen space problem we don't know if they are.


As much as I love this move, it would be an obvious copyright infringement, so I wouldn't use anything like that in any game I'd ever program.


I agree. I don't know how a game could be so unique though, fighter games are in general only interesting because of their characters, and still...

I guess having such large "sprites" on the NES would be unique by itself, but if you forget the "on the NES" part then you get a very bland, generic and uninteresting game that is less fun than Street Fighter, and that lacks hadokens as well as any interesting moves. If jumps aren't allowed then it becomes even flatter/blander.

EDIT : Yet another solution to the "knocked out" problem would be to completely change the approach: Instead of having the character knocked out lying horizontally like you'd traditionally except, we could make he lying vertically, so that he would be positioned along the Z axis. It would look strange, but maybe if the art is good this could work great, and get rid of all the issues I mentioned about rendering knocked out characters. Or, even simpler, make a fighting game where characters aren't knocked out during the fight, and are only "dizzy" no matter what happen.

You can bend the legs in various ways when the character's are lying down so that the sprites don't have to be as wide as they're tall when standing up.

I'm also not against the idea of rotating the fighters so that their feet are facing the camera when they're down, if this rotation is visible in the animation. It would actually look pretty cool if they spun in the air before falling to the ground.

In context, I read it as a generic projectile move. (Kaa... meeee... haaaaaa... meeeeeeee.... HADOKEN!) If that's protectable, then Capcom should sue Nintendo over Luigi's neutral B and Ness's forward B in Melee and Brawl. But Capcom won't waste lawyer money on that because it lost last time it tried that (Capcom v. Data East).

Make a "Heineken". (source 1 | source 2)

The Hadouken is the most generic energy attack ever (at least in the game, where there's no characteristic build-up like in the Street Fighter II Victory anime series), so you definitely shouldn't worry about fighters shooting energy balls.

Surely that's not the only way we can find to challenge ourselves. Granted, with a two player fighter not requiring map-based collision and limited scrolling, I bet it would be way under the amount of processing available.

What's the main goal? Is it a tech demo? A fun game? I'm all behind the idea of making a community project of it. Is there anyone who's particularly good with planning and coordination? Perhaps we should start with an outline of the idea.

This is a silly idea I had but one that could be fun. What if we let every active member who wants to be involved have a character? Some sort of nesdev community brawl. Just a thought.


To me this seems like the best solution as the one that imposes the least restrictions on the overall design of the game.

I'd see doing things like moving sprites into BG more along the lines of "stretch goals" personally.

I'm most behind the idea that gets people excited about getting the game going. So if people here are more behind doing a system with BG character then I would be too. In any case I think it would be cool to see the basis of a game get formed. Even if it's on a rough engine. Maybe people will see the project coming and say, "Ahhh let me fix this part here!"


I don't really agree that that's the ONLY reason they're interesting. A huge part of it, sure, but bad play mechanics ruin a fighter completely. Mediocre mechanics with good characters get forgotten easily.

Honestly this was a little more what I was thinking. I think utilizing X-Y movement and some platforming might play to the strengths of the options we have available. It's just one way to consider it.

That's exactly what I meant. Of course we shouldn't use any intellectual property that we don't own. I'm sure our characters will shoot some sort of projectiles though.

Great joke, I'll certainly want to wear a tshirt like this!


Cool, it's good to know I can still have great ideas sometimes, even with my advanced age.



This attack is what break the monopoly of punches and kick, and is why I'd sooner play Street Fighter rather than anything else. I do not manage to pull more advanced combos, other than by pure luck. However it seems it was heavily inspired by the Dragon Ball universe.


To be honnest my main goals were a tech demo about a figthing game, which could possibly be later turned into a game. I'm pretty sure fighting games with sprites only have already been done over and over, and such are as interesting as their content - doing a fighting game isn't interesting per se. But if one character is BG, then this is an interesting use of the NES hardware.

It goes completely oposite of the philosophy "make games - not engines" and definitely have low chances to end in a full sized game, I rekon.

I just had an idea, what do you think of this:

It kind of goes along with the thought of shifting some parts of the sprites into the background.

What if the characters were sprites, and then instead of flickering sprites when a scanline holds more than eight, actively combine the sprites with the background tiles and update to CHR-RAM.

If that engine could be devised, I think that might be the ultimate option. Then you could have as detailed of a background as you want and not have to store left and right facing tiles of your characters. CHR would end up becoming the limiting factor on making a game from this engine.

Just brainstorming, the idea may be a little challenging but I think it's doable. If we don't scroll and essentially do nothing else but play music in NMI, we could even blank out a little on the top and have plenty of time to upload tiles. Like I said before, I bet calculating the collisions and damage stats will leave enough headroom to potentially prepare the tile updates.

Drawing a tile, the program would need to analyze the sprite and replace any pixel which is color zero with the color of the BG tile underneath. The characters would most likely have to be stored in CHR to the shape of their animation, so they can be referenced and combined with a BG tile offset by X-Y position.

We'd also have to switch CHR banks in NMI. That's quick.

I'd say go with vertical mirroring so we can have a two screen width without having to write to nametables. Then we could slightly expand the vertical screen when characters jump by vertically spreading BG layers on scanline IRQs.

What do you think of any of these ideas?

That do not sound feasible, as it have the same problem I already mentionned with using CHR-RAM for animation : The CPU to VRAM bandwith is too low. It could be feasible only if the animations are seriously slowed down, and for a fighting game I belive this is unacceptable.

The Game Boy version of Street Fighter 2 does exactly what you describe, but I personally think this version suck.

But what if you only wrote the ones to CHR-RAM that needed to "flicker" out?

Also, if you needed more time, make the game in 16:9 to fit modern TVs and you'd have a ton of time outside of rendering.

Then it'd require a mapper that has both CHR-ROM and CHR-RAM, such as TQROM. And even then I'm not sure it'd be feasible, in the case of 5x10 tiles sized characters, we'd have to rewrite aprox. 3 columns and maybe 6 or 7 tiles height for both characters, so 48 tiles, definitely not doable at 60 FPS. Even if we limit to 2 colums (that would work, but not allow any other sprites, as each character would use 4 tiles) we'd have to rewrite at least 24 tiles, and that's still too much.

I didn't even approach the huge problem it's going to be with palettes, but it seem like a poor idea overall. Either using only sprites or using one character sprite + one character BG are the most sensible solutions.

You're right. The palettes alone make that not possible.

Although my idea would have been to only write maybe around 20 tiles max, the excess ones. That much would be possible with some extra blanking time.

The most tiles updated per frame in any NTSC NES game is the Snake Pit level in Battletoads. 16 tiles for Rash, 16 tiles for Zitz, and 24 tiles for the snake animations, diagonal scrolling, and a top status bar that begins 31 scanlines into the screen. The patterns for the snakes are simple, so multiple consecutive values can be stored without reloading anything.

I still think the tile update portion of that idea is possible but as Bregalad mentioned, the palette aspects make it more graphically limiting than other options. Every character and background would have to share the same palette, per level.

Also, I don't think it would take both CHR-ROM and CHR-RAM. I believe I mistakenly said something about drawing to CHR-RAM from CHR-ROM but I meant PRG-ROM. I'm sure the program itself wouldn't have to be too big. Graphics on the other hand, think of how many KB of tiles per character you want. BG characters will have to be stored both ways, unless you reverse in CHR-RAM. I was thinking like a bank-swappable MMC3 with CHR-ROM replaced with large CHR-RAM.

Anyway, you're right though that the idea I had would be too limiting to work. What do you need help with, just graphics? I've done some work with scanline splits but I'm sure it's not as good as what you'd program.

Edit: Just a couple typos

For fighting games on the NES, I'm a fan of the idea of having one character use the background and the other use sprites. If they're always facing each other, like is common in fighting games, you don't even have to store flipped versions of the graphics, you can simply switch which character uses sprites and which uses the background as necessary.

The biggest drawback of this method is that the background has to be blank anywhere the fighters can go. You could maybe decorate that flat area a bit with sprites so it doesn't look so dull, being careful to never use more than 1 or 2 sprites per scanline, as any more than that would cancel the advantages of having one of the fighters use the background.

One thing I was thinking about is that all projectile attacks will have to be sprites, since they can't move horizontally at a different speed than the BG character. That might make it tough to have sprites left over to decorate the backgrounds.

Multiple projectile attacks on the screen will have to flicker a little, but i don't think that's bad for projectiles, and we can leave the ones that define the hitbox so that a player never loses track of that with their eyes.

I would personally treat the background character as an object, so collision testing would be the same with the sprite object. Then offset the scroll of his background strip based on his object's X/Y position.

Actually there's an awfully common situation in fighting games where both players can be facing the same way: when one player jumps above the other, and the latter is still performing a move when the first one lands (players don't turn around until they're done performing their moves). Until the second player is done with that move, both players will end up facing the same way.

No, it's not about your typo. You'll admit that your idea required CHR-RAM to scroll a (or both) fighter(s) while having a background there. However it also might need CHR-ROM in order to get new animations in fastly for the sprite part of the fighters. Anyways this is overly complicated and a bad idea in general.



Yes, the problem is that since this technical feature is the only reason we're interested in the project at all, we'll loose interest as soon as the game "engine" is done, and will never get a fully functional game. Once again. That's why I was more aiming at a tech-demo anyway, leaving the possibility to get a full game open.


That seemed obvious from the very start to me.


Well yeah, *just* graphics. I am not a very skilled artist, and designing/animating 4x8 or 5x10 tiles sprites is harder than the usual 4x2 we're more used to. I mentionned that project because it's the only project where I needed animation done. I'm sorry for completely highjacking your thread.


Oh no! I guess you're right. We'd have to somehow get around this.

Hum... I hadn't considered this case when both characters are briefly facing the same way. If this is an original game you have the freedom to cut any ongoing moves short and have the character immediately turn if the other one jumps over their head.

Wouldn't that feel odd when playing, though?

Maybe just duplicate all of CHR-ROM, with the second half having every tile flipped. Then when somebody complains that it'd have been unfeasible, just say that back in the day it wouldn't have been duplicated and the MSB of the address was used to flip the tiles instead

I don't think it'd feel odd... Odd would be someone in real life continuing to perform an attack on nothing after realizing the opponent jumped over their head.

Once you're in the follow-through of an attack, though, it's hard to pull out of it.

You're doing all this to avoid doubling the needed CHR-ROM space for flipped background version. As an alternative you could: half the number of characters, half the required frames of animation, or half the character size (or any partial combination of these things).

If you used bankswitched CHR-RAM big enough to hold all needed tiles for a fight, you could at least save on ROM space by flipping in software on load.

You could also build a mapper that knows how to swizzle CHR data lines. Punch Out got a custom mapper for its specific large-character needs; how about your game?

It's really a question of which of these options seems best for your situation. There's no actual situation being discussed here AFAIK, so I'm tempted to use one of these ¯\_(ツ)_/¯ but maybe you enjoy the debate, so don't mind me.

But then it's doubled again in comparison to the new requirements, so we're back at complaining about the same thing. Unless there's some reference CHR-ROM size to compare against, that kind of suggestions don't really work.


...and screw that turns out that you could just argue Nintendo did it.

Who even cares about if it's what they would have done then? If I ever get around to really making an SNES game, memory is going to be my last concern, because memory is cheap now. If many developers just added more memory to their cartridges, we would have seen much more accurate ports on these older systems, and I thought that it's cool to show off what these systems are capable of without the unnecessary constraints like that.

The entire situation is hypothetical, so if you want to argue what "really" works I'm just going to...

¯\_(tsu)_/¯

Congrats. You just missed the whole point of retro game development.


Definitely, but I also think it's impossible in real life to jump over someone else... unless you start from the top of a wall or something. Without any running up, you could barely jump to a heigh of 50 cm, 1/3 of a very small person's heigth.

Okay, so this is super rough, but I wanted to post something productive on this topic. I'm on hold on doing anything for Vigilante Ninja so I'll work some on the animations for this project in hope it gets to going.

I wanted to start with a template for a character. This is what I came up with:



Then I wanted to attempt a punch animation, and my very first step for animation is usually to make some super rough outlines to make sure I get the motion I want. That's the point that I'm at right now and here's a super rough punch animation:



So, I'm hoping to get some feedback before I go further. Any feedback or edits would be appreciated. If there's stuff we want to change about the first frame of the template, better to do that before fleshing out the others.

Also, is it worthwhile to have a template or will every character have a unique stance?



I love it how rainwarrior's post reads like a TL:DR for the whole discussion.

The first problem I see here is the legs, they're really not convincing. They are also proportionally too short.

Yeah, the legs are really weird, and especially so in the animation. He's bending forward and moving his butt back, nobody punches like that. Generally you move your whole body forward a little bit, and step forward with one foot to keep the balance after throwing your arm forward.

What if he is supposed to be a little teenage?

Proportions don't necessarily mean much in videogames, where a wide range of deformities are considered normal and even cute.

Maybe the whole reason you want to do it, but not me. I wanted to prove how powerful these old systems are without the things that constrained developers from back in the day, like cartridge size. I mean, I'm not going to be a jackass with it and make really bloated code, but if I had to choose between processing power vs. memory, I'd choose memory. That's why I'm probably not even going to deal with compression, because the CPU will be busy with handling objects, and I like shooters and games like this were the only limit to the amount of objects is CPU time or PPU bandwidth.

Basically, I want to see how well the SNES would look if it got the Neo Geo treatment. I don't think that's "missing the whole point of retro game development."

A literal "Neo Geo treatment" would make Mario Paint, Jurassic Park, Wolfenstein 3D, and Qix impossible. While all existing MVS/AES cart boards use CHR ROM for sprites and fix layer tiles, these four games render to CHR RAM in real time based on user input. The moving objects in JP and Wolf3D could be drawn with sprite shrinking, but not the walls. But they'd work on Neo Geo CD, which uses CHR RAM, or on a custom MVS or AES board that links the PRG and CHR boards with a ribbon cable and a bus arbitrator that connects CHR RAM to PRG address space during downtime (e.g. vblank).

And the Super NES is known for playing music through ADPCM channels. How would that work on the Neo Geo, most of whose ADPCM channels are fixed to 18 kHz? A Mellotron-style setup where each pitch gets its own sample? Perhaps music would still have to sound like Genesis music. Or would you just do it MSU1-style and make the whole soundtrack a single 18k sample?

Ha, ha, ha...



What you've said is correct, but I don't see why so many people say it's "impossible". Star Fox on the SNES is possible, but 1080p video isn't. That's the way I see "possible". When it's "impossible" is when you actually have to change electrical components inside the system.

CHR RAM on Neo Geo MVS/AES is "possible" in the same way that a grainy approximation of GameCube graphics on an NES is "possible" through a TV tuner that outputs CHR data. It's possible in theory but probably too expensive to bother.

Well, it would be cool as a test. I imagine Neo Geo carts are already expensive though.

I'm derailing this even further, but I've always wanted to know, are you the only one who's been making the "240 pixel suite" programs? I just wonder because they're on so many different systems, and I wonder how you did it on things like the GameCube.

Most of the 240p test suite ports are by Artemio Urbina and his friends at shmups.system11.org. Mine was a complete rewrite from scratch, optimized for space (48K vs. about 512K for the SNES version).

Definitely, and a fightin game doesn't have to preserve the typical 1/3/4 proportions (where the head is 1/8th, the body 3/8th and the legs 4/8th).

Typically the head is much bigger, for the simple reason is where we need to show detial, but I believe the body/legs ratio of 3/4 should be preserved, even in SD graphics. Here it's clearly not the case, the legs are smaller than the body. Or maybe I just say something wrong, I don't know, but something looks wrong about the legs, I cannot say what exactly.

I could send you the model I used for my fighting game, but only if you're interested.


Why not, but that feels like having a sport car with tractor tires, that is, two things not adapted to eachother.

I'm pretty sure the body of Manny Garcia from Disney's Handy Manny is longer than three-fourths of the legs. The legs are also a bit shorter in anthropomorphic "funny animal" characters, as humans tend to have some of the longest legs (relative to body) in the mammal class.

I definitely don't mind to make the legs longer. Let's try to get a first frame for a first character that we like.


Please do. I was going to use some more realistic images for reference before the next edit.

Edit: Also, I'm curious whether or not it's worthwhile to even make a template. It might be common that there are a couple very similar fighters (eg. Ryu and Ken) but for the most part, fighters tend to have very different stances and movement. I wonder if it would be more fitting to start with designing a character.