It is currently Wed Oct 18, 2017 6:57 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 132 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 9  Next
Author Message
PostPosted: Fri Jul 31, 2015 5:23 pm 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
Espozo wrote:
How the heck can you animate so fast?


I felt like this was taking a while.

I dunno if my techniques are the best way but these are some of the things I've been doing:

Keeping each frame of a my project as an individual layer in a single file, so I can always flip between my frames and see the previous frame or the next frame.

Keep a layer that's green (you can use blue if there's a lot of green in your images) and have it set to low opacity. I put it underneath of the frame on which I'm working, and put the frame I'm looking at for reference under the green one. That way I can see my last frame and still draw over it at the same time. This is a common animation technique from the cel-drawing days but I don't know what the sheet was called.

After I drew her head in several positions I haven't had to redraw that completely for a while. I'll copy the head usually.

I've taken to drawing her body, head, and legs first, with no arms or sword. It's way easier this way, rather than trying to figure out how to make the shapes you want in a mismatch of pixels overlapping one another.

If you have a longer animation, draw your key frames first, and then do your in-between frames after. It's easier a lot of times if you know, okay, "I have to get this pixel over here within two frames"

If you're doing an animation that occurs while your character is moving across the screen, it seems to help for me sometimes to actually shift the image that many pixels per frame while drawing. Then you can know exactly where her feet should be. I did this while drawing the scoot animation, and that one equals one pixel of movement per frame of a four-frame animation.

Hope any of this helps!


Top
 Profile  
 
PostPosted: Fri Jul 31, 2015 5:27 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
I'm being given the impression that the GIFs are misleading since most likely they aren't animating at the intended speed (I bet those attacks are meant to be much faster, but look awful at the speed shown here).


Top
 Profile  
 
PostPosted: Fri Jul 31, 2015 5:33 pm 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
dougeff wrote:
It kinda looks like she's not wearing anything below the waist but thong underwear


She has boots. Those are below the waist. :)

dougeff wrote:
and after she pulls the sword out, she's not so much walking, but shimmying and shaking her butt. Just saying'.


That's kind of the idea. If her sword is sheathed, she can walk but would attack slower. If she draws, she can attack quicker but her mobility is lowered. It's not so much of a walk as a scoot, and slightly over exaggerated for cartoon purposes. I did a few different tries on that one, and in reality, she wouldn't have to kneel down like that to move in that way, but with her short little cartoon legs she kind of does, plus the up and down really added a lot of movement to the character so I left it in.


Top
 Profile  
 
PostPosted: Fri Jul 31, 2015 5:47 pm 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
Sik wrote:
I'm being given the impression that the GIFs are misleading since most likely they aren't animating at the intended speed (I bet those attacks are meant to be much faster, but look awful at the speed shown here).

Any browsers that's I've seen them on seem to play the intended speed, 1/10th of a second per frame. What don't you like about them?


Top
 Profile  
 
PostPosted: Fri Jul 31, 2015 6:07 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1772
Location: DIGDUG
The speed looks fine on my browser.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Fri Jul 31, 2015 6:58 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
darryl.revok wrote:
Sik wrote:
I'm being given the impression that the GIFs are misleading since most likely they aren't animating at the intended speed (I bet those attacks are meant to be much faster, but look awful at the speed shown here).

Any browsers that's I've seen them on seem to play the intended speed, 1/10th of a second per frame. What don't you like about them?

Huh, that'd be 6 frames for every sprite... that looks like it'd be quite slow for the attack animations (at least when her weapon is moving, not all sprites necessarily have to appear the same amount of frames).


Top
 Profile  
 
PostPosted: Sat Aug 01, 2015 10:51 am 
Offline

Joined: Mon Apr 01, 2013 11:17 pm
Posts: 437
darryl.revok wrote:
I'm drawing at 6 fps which to me looks pretty fluid for NES. That should be 10 NES frames per animation frame.

The sword slashing animations feel pretty slow at 6 FPS, but maybe that's just me.

You don't have to stick to exactly 6 FPS; you can always make some frames faster or slower than others. Of course, you're still limited by bandwidth, but you might be able to relax that limitation somewhat by delaying other tasks that require bandwidth.


Top
 Profile  
 
PostPosted: Sat Aug 01, 2015 11:12 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3071
Location: Nacogdoches, Texas
Joe wrote:
The sword slashing animations feel pretty slow at 6 FPS, but maybe that's just me.

I was thinking the same thing.

Joe wrote:
You don't have to stick to exactly 6 FPS; you can always make some frames faster or slower than others. Of course, you're still limited by bandwidth, but you might be able to relax that limitation somewhat by delaying other tasks that require bandwidth.

Aren't you only concerned about that if you're using chr ram? I thought he would have been using a special mapper that allows you to access more tiles in chr rom.


Top
 Profile  
 
PostPosted: Sun Aug 02, 2015 5:58 am 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
I'll definitely try tweaking the attack speeds. On the stronger attacks, I actually want them to be slower. It's the trade-off of using a more powerful attack. Kind of like the smash moves in smash bros.

I may actually redo a lot of the animations. When I did some of the first ones, especially the attacks, I wasn't putting too much thought into her movements. I feel like I've become more conscious of it during the project.

Right now I'm plugging some of these animations into my first NES software project, so we'll see how that goes.

I was actually wrong about the 6 fps. They're all at 10 fps, expect for some of the frames I held out to 1/2 second for animations sake. That's pretty fast. I don't know if I'll be able to go much faster with two or three enemies on the screen simultaneously.

From what I understand, the 64 displayable sprites are DMAed from system memory to the PPU every frame, so that won't be a bottleneck.

If there is a bottleneck it would either be in transferring images from CHR to RAM, or in bank-switching, but I'll have to see.

I need to reread earlier responses to this post now that I believe I have a better understanding of the technical advice.


Top
 Profile  
 
PostPosted: Sun Aug 02, 2015 6:41 am 
Offline

Joined: Mon Apr 01, 2013 11:17 pm
Posts: 437
darryl.revok wrote:
If there is a bottleneck it would either be in transferring images from CHR to RAM, or in bank-switching, but I'll have to see.

Bank switching is instantaneous (except for a few cycles spent to switch banks), so there's no bottleneck if you use CHR-ROM. There are other limitations, but none that would force you to reduce animation speed.

Uploading tiles to CHR-RAM does take time, and this is where your animation speed might be limited.

It's possible to have both CHR-ROM and CHR-RAM on the same cartridge. I'm not sure why you would need that, but it's an option.


Top
 Profile  
 
PostPosted: Sun Aug 02, 2015 7:01 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19098
Location: NE Indiana, USA (NTSC)
Joe wrote:
darryl.revok wrote:
If there is a bottleneck it would either be in transferring images from CHR to RAM, or in bank-switching, but I'll have to see.

Bank switching is instantaneous (except for a few cycles spent to switch banks), so there's no bottleneck if you use CHR-ROM. There are other limitations, but none that would force you to reduce animation speed.

Say you do like SMB2 and SMB3, both of which use the MMC3 with CHR ROM, and bankswitch the player's tiles at PPU $1000-$13FF. You can do one of three things, one of which does reduce enemies' animation speed:
  1. Bankswitch each of three enemies' tiles into $1400-$17FF, $1800-$1BFF, and $1C00-$1FFF. This will limit you to three simultaneous enemies. This can be perfectly fine for a one-on-one fighting game, a Final Fight-style beat-em-up, or a platformer with DKC-sized enemies.
  2. Bankswitch an entire enemy set's tiles into $1400-$1FFF. This will limit the fluidity of the enemy animations that can be stored in a 192-tile enemy set.
  3. Pay big bucks to design a mapper with finer-grained CHR ROM bankswitching.

Quote:
It's possible to have both CHR-ROM and CHR-RAM on the same cartridge.

Outside of China, only two games did this: Pinbot and High Speed. They were on the TQROM board. It's more common on Chinese MMC3 clones because the Chinese language uses far too many characters to fit in a single CHR ROM bank.


Top
 Profile  
 
PostPosted: Sun Aug 02, 2015 9:44 am 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
tepples wrote:
Say you do like SMB2 and SMB3, both of which use the MMC3 with CHR ROM, and bankswitch the player's tiles at PPU $1000-$13FF. You can do one of three things, one of which does reduce enemies' animation speed:
Bankswitch each of three enemies' tiles into $1400-$17FF, $1800-$1BFF, and $1C00-$1FFF. This will limit you to three simultaneous enemies. This can be perfectly fine for a one-on-one fighting game, a Final Fight-style beat-em-up, or a platformer with DKC-sized enemies.
Bankswitch an entire enemy set's tiles into $1400-$1FFF. This will limit the fluidity of the enemy animations that can be stored in a 192-tile enemy set.
Pay big bucks to design a mapper with finer-grained CHR ROM bankswitching.


I'm liking the idea of having 4 switchable banks. That way I don't have to be limited with my enemy design and placement. I'll only be able to have one animation cycle per bank, and in some cases I may even have to split up bigger animations into two banks, but that should still be okay. I always have time to switch a bank between a frame if I'm expecting it. I feel like the tricky part will be interrupting animations, such as if a player got hit or decided to move. I want to see if I can possibly fit the first frame of all or most animation paths a player could take from an animation cycle into the 64 tile bank. So, for example, every bank would need to have the first frame to getting hit, and the taking damage bank should have the first frame of whatever the player might decide to do after given control back.

My first question about this is exactly how many switchable 64 tile banks I can have.

My second question is concerning the fact that this is dubbed the "Battletoads" technique, and I'm wondering if anyone else has seen a high rate of bugginess with Battletoad carts. They seem to do okay if the carts cleaned up, but I feel like almost every time I've seen this game in the wild, it's ended up glitching a lot by the end of level one and level two is where it usually goes to hell. Now that I think about the way it works, it seems like the glitching that I often see could result from loading the improper banks, as tiles start to glitch out wildly. Has anyone else seen much of this? Did many other games use this technique?

Third question would be whether or not the remaining 4K tile bank for backgrounds is bank switchable.

I guess my fourth question would be what the downsides are to using this technique, because I'm not sure if I really see any to be honest, except for the crashing I mentioned. I can't think of too many games on the NES that had more than three simultaneous enemies on the screen of a different type. I'm thinking about shooters which have a lot of simultaneous enemies, and they're usually a lot of the same thing at any given time. If I can ever think of an example that would, it would be that genre, however, you could still cram multiple small enemy animation sets into 64 tiles. It seems like with using this technique with some experimentation, even in a shmup you could even have more varied enemies, and if you want, cram the three tilesets together at the end of a level for a boss, right?

Thanks so much for your help! I'm having a lot of fun with the code. Still trying to properly cycle multiple animations right now. Is it hard to integrate bank switching into a project?


Top
 Profile  
 
PostPosted: Sun Aug 02, 2015 10:37 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19098
Location: NE Indiana, USA (NTSC)
Quote:
So, for example, every bank would need to have the first frame to getting hit

This won't be needed. With CHR ROM and a 1K bank mapper such as FME-7 or MMC3, you can put each frame of animation in a separate 64-tile bank if you want. You'd queue up the bank numbers in RAM while building the display list and actually perform them right after setting the scroll position.

Quote:
My first question about this is exactly how many switchable 64 tile banks I can have.
[...]
Third question would be whether or not the remaining 4K tile bank for backgrounds is bank switchable.

MMC3 has two modes, each with six CHR windows. In CHR bank mode $00:
  • 128 tile window at $0000
  • 128 tile window at $0800
  • 64 tile window at $1000
  • 64 tile window at $1400
  • 64 tile window at $1800
  • 64 tile window at $1C00

MMC3 CHR bank mode $80 inverts A12 before passing it to the bank switching circuit. Use it when you want to switch backgrounds (at $0000) with finer granularity than sprites (at $1000).
  • 128 tile window at $1000
  • 128 tile window at $1800
  • 64 tile window at $0000
  • 64 tile window at $0400
  • 64 tile window at $0800
  • 64 tile window at $0C00

FME-7 is simpler, with eight 64-tile windows at $0000, $0400, $0800, $0C00, $1000, $1400, $1800, and $1C00. Only one NES game was released on FME-7 in North America, so you'll probably want to forgo donors in favor of new CPLD-based boards if you go that route.


Top
 Profile  
 
PostPosted: Sun Aug 02, 2015 11:04 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10056
Location: Rio de Janeiro - Brazil
darryl.revok wrote:
I feel like the tricky part will be interrupting animations, such as if a player got hit or decided to move. I want to see if I can possibly fit the first frame of all or most animation paths a player could take from an animation cycle into the 64 tile bank.

Bankswitching is nearly instanteneous, just a couple of mapper writes and the new tiles are in. You can literally change all 512 tiles from one frame to the next without problems. This means you can easily start any anymation at any time, and they can be as fast as you want, don't worry about this.

Quote:
My first question about this is exactly how many switchable 64 tile banks I can have.

All mappers I know of that switch 1KB (64 tiles) use 1 byte to index the banks, so they can address a total of 256 banks. That should be enough for most NES sized games.

Quote:
My second question is concerning the fact that this is dubbed the "Battletoads" technique

What? No, the Battletoads technique is all about updating CHR-RAM, it doesn't have anything to do with CHR-ROM bankswitching.

Quote:
Has anyone else seen much of this?

I had never heard about Battletoads having a tendency to glitch graphics, no.

Quote:
Did many other games use this technique?

Not many, because CHR-ROM was really popular with later NES games. Some examples that come to mind are Alfred Chicken, Smurfs and Asterix. Some games using this technique are PAL only, and make use of the extended PAL VBlank to update tiles.

Again, this has nothing to do with CHR-ROM bankswitching. If you want examples of that, you can look at high profile games like SMB3 or Kirby's Adventure, but really, there are countless examples of that. Nearly all MMC3 games using CHR-ROM will use bankswitching to animate the main character.

Quote:
Third question would be whether or not the remaining 4K tile bank for backgrounds is bank switchable.

Why wouldn't it be?

Quote:
I guess my fourth question would be what the downsides are to using this technique

Only that the smallest unit you can switch is 1KB, so you have to arrange your tiles according to that. This will often result in a few unused tiles in some banks, or repeated tiles in others, wasting a little space.

Quote:
however, you could still cram multiple small enemy animation sets into 64 tiles.

Sure. Not all games have huge enemies all requiring several frames of animation.

Quote:
and if you want, cram the three tilesets together at the end of a level for a boss, right?

Definitely.


Top
 Profile  
 
PostPosted: Sun Aug 02, 2015 1:40 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1772
Location: DIGDUG
I've noticed that Mike Tyson's Punch out switches banks every few frames for the opponent (rendered as background) and I believe also switches banks mid-frame because the top of the screen uses a different tile set than the opponent. It uses MMC2, which is also an option.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 132 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 9  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group