This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Feasibility of DDR for NES

Feasibility of DDR for NES
by on (#67523)
@Dusty

Are you trying to make a DDR Dance off? :D

That'd be 8).

If four power pads would work I take it 4 zappers would work?

by on (#67525)
So you want to make this:

Image

Four player DDR would have a problem: Too many sprites.

Image

by on (#67526)
tepples wrote:
Four player DDR would have a problem: Too many sprites.

Considering that the background is just a plain color, it should be possible to draw the arrows using the name tables. You'd need to have all vertical positions of an arrow pre-rendered twice: 1 set for when the red arrows are on the blank background and another for when they're over the gray arrows. In fact, if they all move in sync you could even get away with just the red-over-gray set, and move everything below the gray arrows by splitting the screen.

Sprites could be used for effects and such. The text in front of the arrows would either have to be relocated so that they don't overlap or be drawn with sprites and use the flickering as an "effect".

by on (#67527)
tokumaru wrote:
tepples wrote:
Four player DDR would have a problem: Too many sprites.

Considering that the background is just a plain color, it should be possible to draw the arrows using the name tables. You'd need to have all vertical positions of an arrow pre-rendered twice: 1 set for when the red arrows are on the blank background and another for when they're over the gray arrows.

Arrows come in four colors:
  • Red at quarter notes (16n pixels down)
  • Blue at eighth notes (16n + 8 pixels)
  • Yellow at sixteenth notes (16n + 4 and 16n + 12 pixels)
  • Green at any other offset, usually used for triplets (16n + 5 and 16n + 11 pixels)
These arrows start overlapping in harder songs (e.g. Paranoia KCET and .59). Any song with gallops (e.g. So Deep) or certain syncopated patterns will have yellow arrows overlapping red or blue arrows.

Scroll speed can change in the middle of the song. The legend of Max, neoMAX, and Energizer have a slow overlap-fest between two fast parts.

Quote:
In fact, if they all move in sync

Before the round starts, each player can choose between moving them at 1x, 1.5x, 2x, 3x, or 4x speed. If the player chooses a faster speed, the arrows are spaced more widely so that they end up at the receptors at the same time. For this reason, experts tend to find speeds faster than 1x easier to read in a song with a lot of overlaps such as bag. Different players can choose different speed mods, as seen here (left 4x, right 3x).

Each judgment is shown for roughly 30 frames after the step is graded, and yes, it overlaps the arrows. A 50% duty flicker can be handwaved as an "effect", but a 25% duty flicker (as would be seen with four PERFECT! judgments) is more like Pac-Man 2600 ghosts.

by on (#67552)
DDR on the NES would be kind of pointless anyways since the frame rates would be too unstable to have any sort of accurate playing. Even on the ps1 where the frame rates were 30 fps veterans complained about the home experience being terrible compared to the arcade. Wasn't until the ps2 came along that a good port was made, since all of the ps2 titles run at 60fps (with some slowdown on the crappier ports).

by on (#67553)
DDR on the NES would probably run at a solid 60FPS if it's just scrolling the arrows upward.

by on (#67555)
nothingnew wrote:
DDR on the NES would be kind of pointless anyways since the frame rates would be too unstable to have any sort of accurate playing.

I don't know where you are getting this from. The logic behind DDR games is so simple that even an Atari 2600 could do it at 60fps. Moving arrows up and checking if buttons are pressed at the correct times is way simpler than scrolling a level map while moving lots of creatures that interact with each other in a world with simulated physics, and the NES had a lot of games doing the latter running at 60fps.

The only thing that could be slowing the game down in the ports you mentioned are the background visuals, but if this is the case it's pretty safe to say that it's not the console's fault, it's the developers of said ports who did a pretty bad job (either by not designing the visuals according to the system's capabilities or by not making proper use of them).

by on (#67559)
The DDR 5th Mix engine ran at 60 fps. But it was Japan-exclusive because Konami of America wanted "solo" (6 panels on one pad) play, which was in the 4th Mix engine (used for Konamix) but not the 5th Mix engine.

Back to the NES: To use the background plane for arrows, all players would have to use the same speed mod and no "boost" style mods, and the CHR would have to represent all possible combinations of overlapping arrows. Want to see a mock-up of what step charts with overlapping arrows would look like? And I still don't see how CHR with the arrows near the receptors would be organized.

by on (#67560)
I don't see why you can't just avoid everything that causes a problem. It's not meant to be a perfect port, it's meant to be DDR, which at its minimum is four arrows at the top and at least one arrow moving up the screen.

Different colored arrows using up too many colors? Use dithering patterns instead.

Overlapping arrows an issue? Don't include them. Don't put any songs in the game that would need them, or force all players to play at a faster speed so they aren't required. This is a good idea anyway because you could go with the sprite option again, if less arrows need to be shown onscreen.

by on (#67562)
UncleSporky wrote:
I don't see why you can't just avoid everything that causes a problem.

The point of a discussion is to determine what necessarily causes a problem and what avoidances would be rejected as a Porting Disaster by regular DDR players. For example, Donkey Kong for NES leaves out the "cement pie factory" stage, but that didn't elicit cries of "ruined forever". I had to leave hold and multiple previews out of a previous puzzle game project due to control and palette issues, but I solved that by setting up the randomizer and scoring so that hold isn't needed to make a phat combo. This made it a good game in its own right. But leaving out preview entirely wasn't worth it, and neither was introducing unreasonable delays in line clearing (due to VRAM bandwidth issues) or making one player's piece flicker all the time (due to the OAM DRAM refresh glitch).

Quote:
force all players to play at a faster speed so they aren't required.

The ends of both Afronova heavy and Max 300 heavy have double-taps 2/3 of a beat apart, which need 1.5x for no overlap. This results in 300 BPM for Afronova or 450 BPM for Max 300.

Other songs have eighth-note double-taps. These include all Paranoias at all difficulties and the end of Maxx Unlimited standard. Avoiding overlap for eighth-note double-taps needs 2x, which is 360-400 BPM for the Paranoias or 600 BPM for Maxx Unlimited. Good luck expecting Player 3 who has chosen the Beginner or Light step chart to be able to read at that speed.

Quote:
This is a good idea anyway because you could go with the sprite option again, if less arrows need to be shown onscreen.

A single jump for four players is 16 sprites (2 sprites per arrow * 2 arrows per player * 4 players).

But you can't hook up four Power Pads or four Super NES controllers to an NES anyway. No arcade DDR game has had four pads, and the only console DDR games supporting that are DDR Ultramix series on Xbox. So the solution I'd probably adopt involves cutting down to 2 players, drawing arrows as sprites, and using the following sprite cycling scheme to handle the occasional tight overlap in step-jump combos and 16th note runs: Draw left halves of arrows in front in even frames and right halves in front in odd frames.

by on (#67564)
It's already not going to be anywhere near what a real DDR game is like, though. As you say, it can only support two players at once, so we make that concession. It can only do 5 channel chip music, so we make that concession. Why then can't we make concessions for less colors and less available sprites?

And again, thought experiments about songs like Afronova and Max 300 doesn't seem worth it to me, because they don't have to be included. There's a huge range of songs to choose from. If a certain level of play is going to be too fast for the engine, then I guess they'll have to be left out and those hardcore players aren't going to be challenged by the game. But that's niche enough that I doubt it would be a problem.

To me the most important thing is considering the audience. DDR on the NES would be a novelty - you're not going to be able to capture the exact same experience as the full game and few people are going to play it, so I don't see a point in exerting yourself to make it work. The few people who see it will be thrilled that you got DDR on the NES, period.

You tend to list things that are problems in porting gameplay over to the NES, but you don't always offer potential solutions. And you're a smart person too, so I would guess that if you don't offer a solution, you consider the problem insurmountable, so I offer workarounds that I think would make sense.

by on (#67565)
UncleSporky wrote:
It's already not going to be anywhere near what a real DDR game is like, though. As you say, it can only support two players at once, so we make that concession. It can only do 5 channel chip music, so we make that concession. Why then can't we make concessions for less colors and less available sprites?

Two players is a concession for fewer available sprites. Use of DDR-style steps and jumps instead of ITG-style handplants and mines is a concession for fewer available sprites.

Quote:
And again, thought experiments about songs like Afronova and Max 300 doesn't seem worth it to me, because they don't have to be included. There's a huge range of songs to choose from.

Even comparatively easy songs like Cowgirl heavy and 5.1.1. heavy have gallops, or red arrows that overlap a yellow arrow 12 pixels down in the same column. The one song concession I'd make in a 2-player DDR clone for NES is no Bag. Bag is the only song I know of that routinely has six arrows in one beat.

Quote:
If a certain level of play is going to be too fast for the engine, then I guess they'll have to be left out and those hardcore players aren't going to be challenged by the game.

I guess I was just spoiled by the development process of LJ65, where I was able to make it fun for casual players yet still challenging for the hardcore players who frequent HardDrop.com and TetrisConcept.net.

Quote:
DDR on the NES would be a novelty - you're not going to be able to capture the exact same experience as the full game and few people are going to play it

Yet Konami earnestly tried to market DDR for Game Boy Color.

Quote:
Quote:
the solution I'd probably adopt involves cutting down to 2 players, drawing arrows as sprites, and using the following sprite cycling scheme to handle the occasional tight overlap in step-jump combos and 16th note runs: Draw left halves of arrows in front in even frames and right halves in front in odd frames.

You tend to list things that are problems in porting gameplay over to the NES, but you don't always offer potential solutions.

I thought I already did: limit to two players, with a sprite cycling method to handle pathological cases. As long as no more than four steps are in one beat, the worst cases (spurts of 16th notes and runs of 8th note jumps at 1x) would end up flicker-free in 1-player and still readable in 2-player. Besides, even hardcore players aren't guaranteed to run into flicker so quickly. By the time the player is tackling 9-footers like Matsuri Japan and Rhythm and Police, the player will be used to fast scrolling in the light and standard charts of songs like Drop Out, The least 100 seconds, and Across the Nightmare, and thus is likely to pick 1.5x for songs in the 180-200 BPM range.

But living in software patent country and dealing with a company that has shown itself to be willing to take infringers to court, I can't really work more on this until 2018.

by on (#67574)
tepples wrote:
And I still don't see how CHR with the arrows near the receptors would be organized.

First you'd have to reduce the color count so that both the moving arrows and the receptors can be represented with a single palette. I imagine your CHR would have to look something like this:

Image

by on (#67576)
Oh, so that's how an engine with charts on the background would work. It'd use vertical mirroring, with the chart on the first nametable and the receptors and fields on the second. That would need two splits, one below the receptors and one below the scrolling area, so it'd need either a scanline-counting mapper or no sampled drums, but I managed to produce passable covers of Butterfly and Maxx Unlimited without sampled drums.

But you've used 144 tiles for the left arrow alone. Where would the tiles for down, up, and right fit?

by on (#67577)
How about making the letters wave up and down to prevent being too many sprites on the same scanlines.

by on (#67578)
tepples wrote:
But you've used 144 tiles for the left arrow alone. Where would the tiles for down, up, and right fit?

Yeah, tile count will be a problem. If you can afford the palettes, you could make the gray arrow "transparent" (i.e. the same color as the background) for the middle section. You could also try to move the arrows 2 pixels pixels at a time instead of one. Depending on how fast the arrows move that won't look bad. Another possibility is to leave the foreground arrows in one pattern table and the receptors in the other and switch between them as necessary. I'm sure that a combination of the above ideas would make this possible.

EDIT: I also screwed up with that image. There are more repeated tiles in there I didn't get rid of.

EDIT: If all arrows move at the same time, you could just use CHR-RAM or CHR bankswitching and save a lot of pattern table space.

by on (#67579)
Don't forget that even rows and odd rows can alternate pattern tables, otherwise I couldn't make Chu Chu Rocket.

by on (#67580)
How about bankswitching between a top-of-grey-arrow tiles and the bottom-of-grey-arrow tiles?

by on (#67590)
How about editing the CHR-RAM and have 16K of RAM, Use one for the screen, edit the other and just edit the full page and just swap them ever 2 frames or something. Would that be an idea for making it possible? Using the background for the arrows, I don't know if you guys have shunned it yet but still, it's an idea. It would take a while to move the screen up one pixel though, thats alot of bytes.


EDIT:

How about 8K in the WRAM area and 8K to the grpahics, same idea, nearly the same image, just edits it there. It will edit the WRAM one so you don't have to go through the PPU to edit the CHR-RAM. I have never used CHR-RAM but I assume you go through the PPU which is alot harder and wasteful of cycles so it would seem better to do the 8K WRAM editing.

Is there any game that swaps out 8K of RAM from CHR to WRAM and vice versa?

by on (#67596)
65024U wrote:
I have never used CHR-RAM but I assume you go through the PPU which is alot harder and wasteful of cycles

Not necessarily. If your goal is to read-modify-write pattern table data, then yeah, accessing it through the VRAM registers is slower, but if you are just copying sequential bytes to it, the automatic address increment feature of the PPU actually makes things faster (because pointer/index manipulation for the output isn't necessary).

Quote:
Is there any game that swaps out 8K of RAM from CHR to WRAM and vice versa?

I don't think so. You'd need a new mapper for that.

Rewriting huge portions of the pattern tables during gameplay is not an option. Rewriting the whole 8KB would take 10 frames or so, and that's with the fastest possible code and several scanlines of forced blanking.

by on (#67602)
As I said earlier, two players is possible with sprites, just not four.