Boom! NES Game interest check, check first post if wanting to buy!

[GreenDayRlz]

Gameplay video, even missing some features from the latest version like high score:

 

http://www.youtube.com/watch?v=mz6UkX45FH0

 

Hey guys, as for an update, I'm now trying to gauge how many carts I'll sell for parts needed and to get everything together. Please head over to NA on the link below and post if you would like to get a cart of this! More info there. Thanks a lot!

 

http://www.nintendoa...&threadid=66786

Edited March 24, 2012 by GreenDayRlz

[AtariLeaf]

Looks good. The vaus controller would probably work great for this but they're hard to come by. Will this work well with a standard NES pad? How are you addressing the control issue?

[+save2600]

Not to mention the speed, redraw and flicker issue. Good candidate for the Arkanoid controller too. Be interesting to see how this stacks up against the frantic speed of the VCS.

Edited December 7, 2010 by save2600

[GreenDayRlz]

Well, the demo with the old 8x8 sprites mode was doing 48 on-screen bombs INSIDE VBLANK without any sort of problem at all, so I am not concerned about speed. If need be, I can make it run 1-frame slow. This could kill the VCS in speed, but why would it need to go THAT fast?

 

 

I am going to use the Vaus controller, and I don't even have one to test, but I am pretty sure my code works. I know it's a limiting factor, but I mean, Kaboom! without a paddle-like controller isn't kaboom. Period. But I am considering a 2-player mode (And probably 2 player alternating) that one person could control the bomber with a d-pad and the player would do the buckets with a controller, too, and then to change the speed, just pressing the button will be just kinda slow. If A is pressed, it will go a little fast. B will also make it go even faster, and then A+B would make it go very fast. I think that'd be a good way for the game mode to work without the Vaus. Although, I could do the player 1 mode like that, but I'm not sure. I might add it, maybe not, but we'll see as I get into development.

 

 

 

Here's a mockup I did inside FCEUXD. I added the bomb sprites and the water jumping to make it look like it's working, but it's just the core engine running like normal. I am hoping to getting the bomb add, bomb move, and bomb delete programs working again, when I updated the graphics, I broke them beyond repair. Haha.

 

 

Well, here's the emulator screenie. Also, the way it will be set up, there should be no flicker at all. None. Period. End of story.

 

 

EDIT:

 

Also, he is going to be on a brick wall, too. Maybe some other changes, but thats the only one planned so far.

Edited December 7, 2010 by GreenDayRlz

[+save2600]

Sounds awesome!

[GreenDayRlz]

Got the bomb movement added, combined Delete Bomb and Bomb Movement into one. Not much else to say. For the doubters of the speed, first file is slow, second is fast. Tell me what you think!

 

 

-removed because roms were old and taking too much space on my webs-

 

 

To see movement, use Paddle Controller, port one. And also, hit detection is coming next. Should be added by tomorrow. But who knows what school will throw in the way?

 

 

Thanks!

 

 

-Aaron (3GenGames)

Edited January 28, 2011 by GreenDayRlz

[BigO]

 

I wonder if there's a DIY way to build one of those controllers.

 

I imagine it's just sending a serial data stream that's interpreted by the software as position instead of as just various button presses. The standard NES controller is based on a parallel in (8 bit), serial out shift register. It probably wouldn't be hard to create an Arkanoid style controller if somebody could analyze the datastream that one puts out (or is willing to do a whole lot of experimenting to reverse engineer it the hard way).

[GreenDayRlz]

Here ya go!

 

 

 

http://wiki.nesdev.c...noid_controller

 

 

 

8-bit shift out connection to a 8-bit ADC $0D-$AD plus the 2nd pot inside the knob I guess. (I don't have a controller either, actually, but I'd trust that info.) I know my game also relies on the value being $54-F4, or near there, since thats what they did too. But I cut off the unnecesary numbers to cut it down to only a $80 range and adjust that by multiplying by two for the controller X position in pixels, with two pixels per step. If it reads position $FF, it means no controller is plugged in, so it sets paddle position to 0 on the screen, for some reason when that doesn't happen....the buckets gets split up. lol.

 

 

Also, just tested on cart, this demo works on a NES. (NROM-128 cart with EPROMS)

 

 

Hit detection being added tomorrow! Woooo! >.< Thats going to be fun. :3

Edited December 8, 2010 by GreenDayRlz

[GreenDayRlz]

Double post somehow. Sorry!

Edited December 8, 2010 by GreenDayRlz

[yuppicide]

Why would it need to go that fast? Because you need to make a Nintendo World Champion edition.

[GreenDayRlz]

Why would it need to go that fast? Because you need to make a Nintendo World Champion edition.

 

 

 

"Homebrew World Championship" has a great ring to it! I love that idea.... But it'd be up to Bunnyboy on RetroUSB.

 

 

And also, It can go faster then that, I just wanted them to still be see-able. >.<

Edited December 8, 2010 by GreenDayRlz

[Crazy Climber]

Okay, I thought this would be lame but I'll admit it looks pretty cool!

[BigO]

http://wiki.nesdev.c...noid_controller

 

 

 

8-bit shift out connection to a 8-bit ADC $0D-$AD plus the 2nd pot inside the knob I guess. (I don't have a controller either, actually, but I'd trust that info.) I know my game also relies on the value being $54-F4, or near there, since thats what they did too. But I cut off the unnecesary numbers to cut it down to only a $80 range and adjust that by multiplying by two for the controller X position in pixels, with two pixels per step. If it reads position $FF, it means no controller is plugged in, so it sets paddle position to 0 on the screen[...]

If I'm understanding this correctly, it wouldn't be a major feat to build such a controller. So, the button bit is in the middle of the paddle position data?

 

Should be easy enough to test my understanding with a standard NES controller, some jumper wires, soldering equipment and an Arkanoid cartridge.

 

An Atari 2600 paddle controller seems an ideal housing for a homebrew controller. If I ever stumble onto an Arkanoid cartridge at a yard sale, I might tinker with this.

Edited December 8, 2010 by BigO

[GreenDayRlz]

Nope, actually the controller is tied to +5 or ground, not sure which, just being a push button on it's own data line. The 8 bit shift register for the paddle is the value for the pot only. The button is on a different data line. It's easier then you think. ^_^

 

 

I am not sure about it, but a Atari 2600->NES adapter might be possible. I am not sure, though. I am not farmiliar with the 2600 controller hardware.

 

 

 

And yeah, it was lame at first. Here's a screenshot with my graphics before Tokamaru on NESDev showed me some better ones I used from him:

 

 

 

 

 

Thanks so much to him. He has no idea what these new graphics have done for my moral. Even though I had to re-write the whole game for them, it was worth it. On the version with those graphics, I had hit detection and score added in so maybe I can knock them both down really soon. Maybe even tomorrow.

 

 

We'll see. Wish me luck. ^_^

 

 

EDIT:

 

You'll probably find 10 Arkanoid games before the controller. I am a NES collector, too, and have like 3 copys and have NEVER seen a vaus controller. They're pretty hard to find, but it's neat. Too bad it wasn't it's own controller with it's own support in games. :/

Edited December 8, 2010 by GreenDayRlz

[BigO]

Not an adapter. That gets ugly in a hurry given the way the Atari pots are wired. I meant the physical controller mechanism could be easily repurposed. It would be easier to adapt one axis of a PC joystick.

 

How many bits are in the actual serial data stream coming from the pot? I think the example you gave is referring to an internal register that you access in software. The regular controller only latches and transmits 8 bits of data (using a clock sent by the console) and sends all data out one serial line.

 

With a quick search, I can't find any place that references a second data line or other bits coming from the controller. Do you have any more specifics on the hardware to support that? Is it using pins 5 and/or 6 which are defined as NC for the standard controller?

[GreenDayRlz]

It's exactly like a controller, instead of hooking to buttons, it hooks the the data bits of the ADC inside the controller. It's the same thing I am pretty sure. It reads off 8 bits. The button is on another data line not in any way connected with the value of the controller knob.

 

 

Does that make more sense? ^_^

 

 

EDIT:

 

 

Here's a new screenie. Yay! Like the new background? Probably going to make the cracks more uniformed later, but whatever.

Edited December 8, 2010 by GreenDayRlz

[BigO]

It's exactly like a controller, instead of hooking to buttons, it hooks the the data bits of the ADC inside the controller. It's the same thing I am pretty sure. It reads off 8 bits. The button is on another data line not in any way connected with the value of the controller knob.

 

 

Does that make more sense? ^_^

 

 

EDIT:

 

 

Here's a new screenie. Yay! Like the new background? Probably going to make the cracks more uniformed later, but whatever.

 

It probably does make sense, but not to me at the moment. I can't find any documentation of "another data line" supported by the console. And there are only 8 bits of data in the data stream. If they stick with the 8 bits of data, then it would most likely allocate 7 bits of resolution on the pot and use one bit to represent the button state. That would be pretty simple to implement. I can see how it would be possible to have any number of bits but I'm guessing that since you've referenced an 8 bit register that they're just using 8 bits.

 

Bear in mind that I'm basing my statements on speculation and nearly total ignorance.

[Rev]

how about some king of new level or gameplay idea instead of just prettier graffixx?

 

...just a thought.

 

but i like it so far. i always liked kaboom on the 2600.

[GreenDayRlz]

Well when you think about it, what else is there to add?

 

 

 

Here's a diagram of the controller port pins:

 

http://wiki.nesdev.c...ler_port_pinout / http://www.hardwareb...Controller_port

 

How they work:

 

http://wiki.nesdev.c..._port_registers

 

 

With each read, the shift register connected to the data pin it has to send data out will shift off the analog data. You read this first since it doesn't matter when you read the button because you don't have to reset the shift register for the button because it doesn't have one and is directly connected one of the other registers. I don't say which ones because I don't want to say for sure since I'm not sure what they hook to, but thats exactly how it works. The 8 reads will output the serial data from the pot inside the controller with the hardware inside, and the button can be read anytime since it doesn't hook to any registers and it right on the controller port.

 

 

Not to be rude, but I've explained it like 3 times, and thats how it works. I know what I am saying is true. Maybe there's a diagram somewhere, I'm not sure. :/ Maybe I suck at putting it into contex, too. XD ^_^

Edited December 9, 2010 by GreenDayRlz

[BigO]

I never meant to imply that you were wrong. Apologies if it appeared otherwise.

 

Best of luck with the development.

 

 

 

 

[potatohead]

Why go that fast??

 

Well, KABOOM is at the top of my, "will always play it, until I simply can't" game list. It needs to go that fast so that the human player is taken to the upper limits of their response. Literally, thought becomes action at that state, and it's the most addictive quality in gaming, for me personally, and it is seen boiled down to the very elegant basics in KABOOM.

 

Consider some flicker on the higher level bombs, away from the users attention, before dropping the speed one frame. It's important for this game.

 

And if there is some analog style controller for the NES, consider support for it, because that too is a big part of the game, though some scaling of the D-pad input to the bomb drop speed and spread will make the game possible and playable at the higher levels. Not sure if people will trance out on it, but they might, and it would still be a lot of fun.

 

Great game! Have fun building it.

 

 

 

Well, the demo with the old 8x8 sprites mode was doing 48 on-screen bombs INSIDE VBLANK without any sort of problem at all, so I am not concerned about speed. If need be, I can make it run 1-frame slow. This could kill the VCS in speed, but why would it need to go THAT fast?

 

 

I am going to use the Vaus controller, and I don't even have one to test, but I am pretty sure my code works. I know it's a limiting factor, but I mean, Kaboom! without a paddle-like controller isn't kaboom. Period. But I am considering a 2-player mode (And probably 2 player alternating) that one person could control the bomber with a d-pad and the player would do the buckets with a controller, too, and then to change the speed, just pressing the button will be just kinda slow. If A is pressed, it will go a little fast. B will also make it go even faster, and then A+B would make it go very fast. I think that'd be a good way for the game mode to work without the Vaus. Although, I could do the player 1 mode like that, but I'm not sure. I might add it, maybe not, but we'll see as I get into development.

 

 

 

Here's a mockup I did inside FCEUXD. I added the bomb sprites and the water jumping to make it look like it's working, but it's just the core engine running like normal. I am hoping to getting the bomb add, bomb move, and bomb delete programs working again, when I updated the graphics, I broke them beyond repair. Haha.

 

 

Well, here's the emulator screenie. Also, the way it will be set up, there should be no flicker at all. None. Period. End of story.

 

 

EDIT:

 

Also, he is going to be on a brick wall, too. Maybe some other changes, but thats the only one planned so far.

Edited December 9, 2010 by potatohead

[GreenDayRlz]

So Kaboom! used flickering of bombs not on the screen? Hmmm....I don't think I am going to do that, it just seems like a bad idea. A frame without a bomb and then it being back there would just be really.....eh. Probably not well recieved. Although the bomb flicker of the fuse might make some effect like that with the eyes.

 

 

 

Yes, Arkanoid controller. It's going to use it mainly. Maybe some controller modes to support a more available type, but I really don't want to let the rarity cause this game to be held back from playability with it.

 

 

I mean, I know that Kaboom! is supposed to be be one of those games where you just play and play, but I really want the game to end. Haha. Just so everyone doesn't feel bad about not sometimes being able to beat it. It will still go fast as hell, but I would eventually max it out. Maybe having a mode that doesn't end and just keeps increasing in speed as you play until you just lose. One life, no matter how many buckets, and no resting time. Imagine playing Kaboom! with no breaks inbetween levels for 5 minutes straight. I think I will also consider putting that in. It seems like a good idea, too. But we'll see. I didn't get to add hit detection today. I fell asleep after school. So I'll get that done maybe by sunday. Having friends and then a band performance saturday, so my schedule it hectic from today on. >.>

Edited December 9, 2010 by GreenDayRlz

[potatohead]

No flicker at all on the VCS.

 

I would not flicker anything, if possible. If it's possible to keep the speed up and not flicker, that's the best case scenario. I was suggesting flicker, before losing speed, that's all.

 

Maybe it's better to cut the speed, due to most people on a D-pad. Don't know. Just thought I would share impressions on what makes the game great.

[GreenDayRlz]

Oh, haha. Well the way the game is set up, there will not be any flicker. Ever. At all. No matter if all 32 odd bombs are on the screen at once, there will not be any flicker.

 

 

Like I said, I will make the paddle version as close to the original in game play, but the controller version might be slower, and be more about not getting juked out more then not being able to keep up. I'm not sure, we'll know when I settle on th final code for that mode.

[tokumaru]

Tokumaru on NESDev

And here! =)

 

I somehow missed the updates... Looks like this will be a cool port!