Hey all, glad to have found these forums.
I'm an established NES collector looking to delve a little deeper into my hobby and begin programming. I have thorough experience with higher-level languages and some assembly experience.
That said, some questions before I dive in head-first.
1. I know at some point chatter about this project existed, but I can't get the search here to work, and any pointers to the thread (if it exists) would be appreciated.
2. Are there copyright issues with homebrewing using existing licensed-release sprites / music from NES games? Specifically, if I produce and release a homebrew with stolen material, will I get my arse sued. This one alone would be enough to put a damper on the whole project....
3. Does anyone care!
thanks -Dan
DDR for NES...
Moderator: Moderators
1. At least one of them is here.
2. Yeah, every problem imaginable, depending on the material. Copyright, trademark, and possibly derivative work. If it's a free release there might not be anything to sue for, but working paranoidly (is that a word?) in the shadows doesn't sound like as much fun. I'm sure you could find an artist (actually, having a demo working with any kind of sprites would be a big encouragement), and I'm absolutely certain you could find many musicians.
3. If you mean about a DDR-type NES game, then yes.
2. Yeah, every problem imaginable, depending on the material. Copyright, trademark, and possibly derivative work. If it's a free release there might not be anything to sue for, but working paranoidly (is that a word?) in the shadows doesn't sound like as much fun. I'm sure you could find an artist (actually, having a demo working with any kind of sprites would be a big encouragement), and I'm absolutely certain you could find many musicians.
3. If you mean about a DDR-type NES game, then yes.
testing
The good part is that there's not a whole lot of testing that needs to be done for this game. Forget about collisions and such...it's the simplest possible thing to program. Most of the problems will probably result from making it interesting...just having arrows up on a screen with music isn't very spectacular. And since the backgrounds would be computer controlled...no real worries.
That said, my idea which may complicate things...or make them simpler and nicer...was to use the "arrows" as a scrolling background, and have them move vertically up past a static background page that would draw first. This should make things smoother, allow for other sprites to move about the screen and minimize slowdown. You could even make the "glow" with palette swaps so they don't need to be animated at all.
Syncing the scrolling rate with the music playback rate should not be too much of a problem, doesn't most NES music follow the same meter? Even if it doesn't isn't it just a variation on a hexidecimal scale? Even through trial-and-error and assuming no slow-down you could just plug in numbers and come across the right synch rate for each song.
And I guess my concept is out of the question...I wanted to make my first one entirely Mega Man music...you'd select the game (MM2, MM6, etc), then select the boss you'd like to "fight" and it would play the music from the level, while you danced to it. How well you did would govern how well your sprite was beating up on let's say Bubble Man, and if you passed the song you'd conceptually beat the boss.
But of course this is a selfish idea since there are so many talented NES composers that should be on the first NES DDR game...even before the legal considerations obviate themselves.
Thanks for your responses thusfar -Dan
That said, my idea which may complicate things...or make them simpler and nicer...was to use the "arrows" as a scrolling background, and have them move vertically up past a static background page that would draw first. This should make things smoother, allow for other sprites to move about the screen and minimize slowdown. You could even make the "glow" with palette swaps so they don't need to be animated at all.
Syncing the scrolling rate with the music playback rate should not be too much of a problem, doesn't most NES music follow the same meter? Even if it doesn't isn't it just a variation on a hexidecimal scale? Even through trial-and-error and assuming no slow-down you could just plug in numbers and come across the right synch rate for each song.
And I guess my concept is out of the question...I wanted to make my first one entirely Mega Man music...you'd select the game (MM2, MM6, etc), then select the boss you'd like to "fight" and it would play the music from the level, while you danced to it. How well you did would govern how well your sprite was beating up on let's say Bubble Man, and if you passed the song you'd conceptually beat the boss.
But of course this is a selfish idea since there are so many talented NES composers that should be on the first NES DDR game...even before the legal considerations obviate themselves.
Thanks for your responses thusfar -Dan
Re: testing
That would complicate things. When you have eighth note taps (seen on all three difficulties of "PARANOiA"), arrows can overlap. Would you use backgrounds for all quarter notes and sprites for everything else?dangevin wrote:That said, my idea which may complicate things...or make them simpler and nicer...was to use the "arrows" as a scrolling background, and have them move vertically up past a static background page that would draw first.
You'll still need to swap the four frames of the animation for the white segments inside the arrow that light up in the order 3, 0, 1, 2, changing every sixteenth note. But MMC3 CHR swapping can handle that easily.You could even make the "glow" with palette swaps so they don't need to be animated at all.
Most NES games use three, four, six, or eight tracker "rows" per quarter note.Syncing the scrolling rate with the music playback rate should not be too much of a problem, doesn't most NES music follow the same meter?
Re: testing
I can't see any way to make sprites work as the arrows. There's the possibility with quarter notes' top halves or bottom halves being on the same line as half-notes...and if it's a jump (two arrows simultaneously) moving into a jump with the opposite arrows there's the potential for up to 16 sprites on the same line, won't fly. Even with a mix of bkgd tiles and sprites, you've got potential slow-down on a song with lots of steps, they're all on the screen being repositioned every draw, NG. With bkgd tiles though, for the quarter notes I could just make more variations of tiles...some would have like the top-half of one for quarter-steps, then the bottom half of the same quarter step at the top of another tile right below to give the illusion. Better yet, I can make big arrows if I just use 4 tiles (2x2) to make up each arrow...and this will eliminate the problem entirely. The other advantage being...then they're BIG. And at that size I could still fit 7 full arrows end-to-end on screen from bottom to top, that definitely gives enough time for the dancer to "read ahead."tepples wrote: That would complicate things. When you have eighth note taps (seen on all three difficulties of "PARANOiA"), arrows can overlap. Would you use backgrounds for all quarter notes and sprites for everything else?
This doesn't sound too bad. Kinda like question-mark blocks in SMB?You'll still need to swap the four frames of the animation for the white segments inside the arrow that light up in the order 3, 0, 1, 2, changing every sixteenth note. But MMC3 CHR swapping can handle that easily.
Although I don't anticipate a big headache from synching the tunes to the scrolling, it IS the most important part of the programming aspect so I figured I'd ask. It's digitally precise so what, me worry?Most NES games use three, four, six, or eight tracker "rows" per quarter note.
I will be reading everything I can get my hands on for the next week or so, it's been almost a full decade since I've coded anything. BUT it's like falling off a bike, you never really forget how
Thanks for your help.
I designed Squeedo for music, so it has those 4 extra sound channels. Now that could make a huge difference in a game like this. Currently only my hacked version of the MCK driver supports it though.
With the PIC being the expensive part on there though, it could add $10 - $20 to the final selling price (compared to something simple like UNROM). That's without the comms adapter/cable and probably no WRAM.
Since the PIC has that expansion port (normally used for the comms adapter), it possibly could take a PSX controller there. If 4 I/Os + 5VDC/GND is enough. Interesting idea.
With the PIC being the expensive part on there though, it could add $10 - $20 to the final selling price (compared to something simple like UNROM). That's without the comms adapter/cable and probably no WRAM.
Since the PIC has that expansion port (normally used for the comms adapter), it possibly could take a PSX controller there. If 4 I/Os + 5VDC/GND is enough. Interesting idea.
Oops, I didn't know quite how Squeedo's audio expansion worked, so I was thinking about the IRQ system. Any further comments?
How essential is the PSX controller port? I can see why a PS1 dance pad might be useful given the limited availability of Power Pads, but how much sub-frame timing will be used in the scoring system?
Oh, and might dmc_saw be useful anywhere in this quasi-project?
How essential is the PSX controller port? I can see why a PS1 dance pad might be useful given the limited availability of Power Pads, but how much sub-frame timing will be used in the scoring system?
Oh, and might dmc_saw be useful anywhere in this quasi-project?
Warning: I am not a serious developer (yet), but CS and EE really interest me.
I was -_pentium5.1_- until I screwed up. This is why I screwed up. ^_^
I was -_pentium5.1_- until I screwed up. This is why I screwed up. ^_^
The rumored "Hellraiser cart" (which in fact was supposed to be for a game other than Hellraiser) had a separate CPU and PPU and fed just the controls, audio, and pixel stream through the cart interface. But Nintendo itself has done this at least four times:blargg wrote:especially if we make a new cartridge that has its own CPU and graphics processor, merely using the NES for its power switch.
- Wide Boy (prototype Game Boy on Famicom)
- Super Game Boy (commercialized version of Wide Boy for Super Famicom/NES)
- Wide Boy 64 (prototype Game Boy Color on N64)
- Game Boy Player (commercialized GBA on GameCube)
Huh? I don't see any relevant evidence on this page:tepples wrote:The rumored "Hellraiser cart" ... was supposed to be for a game other than Hellraiser ...
http://www.planetnintendo.com/thewarpzo ... aiser.html (The only other game it mentions being made for the Supercart was for testing purposes. I intentionally linked to the old version of The Warp Zone since the new version has broken images.)
Also, tepples, are you suggesting that Wii's Virtual Console feature might eventually be supplemented by special hardware for certain special purposes...?
Last edited by 85cocoa on Wed Oct 04, 2006 12:12 am, edited 1 time in total.
Warning: I am not a serious developer (yet), but CS and EE really interest me.
I was -_pentium5.1_- until I screwed up. This is why I screwed up. ^_^
I was -_pentium5.1_- until I screwed up. This is why I screwed up. ^_^