Progress Thread -- Super Smash Bros. NES

A place where you can keep others updated about your NES-related projects through screenshots, videos or information in general.

Moderator: Moderators

russellsprouts
Posts: 53
Joined: Sun Jan 31, 2016 9:55 pm

Re: Progress Thread -- Super Smash Bros. NES

Post by russellsprouts »

Here's a ROM that people can try. Warning, there's not really any gameplay implemented. You'll see the layout of the menu screen, but it's not functional yet. Press start on the controller to play as Peach on Final Destination. Ignore the fact that Peach is offset from her correct position. That's because the automatic metasprite generation doesn't yet know the center point of the player sprite. I'm working on a way to define that easily for each frame. The damage and stock indicators simply increment every frame for now. If you fall off, press select to reset.

The shadow on Final Destination is on the background layer. I have some bytes in RAM reserved for the shadow data, and I perform bitwise or operations on them to place shadows. I only needed 12 tiles for all the combinations of possible shadows.
Attachments
game.nes.zip
(21.27 KiB) Downloaded 785 times
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Progress Thread -- Super Smash Bros. NES

Post by tokumaru »

russellsprouts wrote:I also rewrite all of the palettes every frame using self-modifying code. I have a routine in ram which uses load immediate instructions, so all the bytes of the palettes are sent to the PPU in just over 200 cycles.
I think that self-modifying code is a little overkill for palettes, but the fact that you used it shows that you really want to do this as fast as possible, so here are a couple of optimization tips that will make palette updates even faster:

1- The NES doesn't have 32 active colors, only 25. Unless you want to use the trick where you point the VRAM to $3F04, $3F08 and $3F0C when rendering is disabled to show those colors (something I personally can't think of many uses for in an actual game), you can cut the update time down by 14 cycles if you simply don't load those 7 bytes that don't mean anything. Even if you do want to use that trick, you can still get rid of 4 load operations, saving you 8 cycles.

2- Start updating from $3F01 instead of $3F00. Writing color 0 to $3F00 is redundant, since it has a mirror at $3F10, that you will be writing to later. This means you can save 4 more cycles by not writing a byte that will be overwritten later anyway.

Code: Select all

;set the target address (12 cycles)
lda #$3F
sta $2006
lda #$01
sta $2006

;update the first palette (18 cycles)
lda #$XX
sta $2007
lda #$XX
sta $2007
lda #$XX
sta $2007

;load the background color in another register (2 cycles)
ldx #$XX

;update the next 7 palettes (7 x 22 = 154 cycles)
stx $2007
lda #$XX
sta $2007
lda #$XX
sta $2007
lda #$XX
sta $2007
;(...)
That's 186 cycles, which would reduce a bit the impact of doing palette updates every vblank.
russellsprouts
Posts: 53
Joined: Sun Jan 31, 2016 9:55 pm

Re: Progress Thread -- Super Smash Bros. NES

Post by russellsprouts »

Using self-modifying code is definitely overkill, but I might as well do it since it's easy enough. Thanks for the tips -- that's exactly what I do. I start at $3F01, and only perform 3 loads per palette. I said just over 200 cycles because I was counting the cost of the jsr to the code, a bit PPUSTATUS just to be sure the latch is in the right state, and the rts instruction.
User avatar
nintendo2600
Posts: 367
Joined: Mon Mar 30, 2009 4:40 pm

Re: Progress Thread -- Super Smash Bros. NES

Post by nintendo2600 »

Just noticed this thread. Can't wait to watch the progress on this game. Exciting concept to see being taken on for the NES.
Post Reply