GreenDayRlz Posted December 7, 2010 Share Posted December 7, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
AtariLeaf Posted December 7, 2010 Share Posted December 7, 2010 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? Quote Link to comment Share on other sites More sharing options...
+save2600 Posted December 7, 2010 Share Posted December 7, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
GreenDayRlz Posted December 7, 2010 Author Share Posted December 7, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+save2600 Posted December 7, 2010 Share Posted December 7, 2010 Sounds awesome! Quote Link to comment Share on other sites More sharing options...
GreenDayRlz Posted December 8, 2010 Author Share Posted December 8, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
BigO Posted December 8, 2010 Share Posted December 8, 2010 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). Quote Link to comment Share on other sites More sharing options...
GreenDayRlz Posted December 8, 2010 Author Share Posted December 8, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
GreenDayRlz Posted December 8, 2010 Author Share Posted December 8, 2010 (edited) Double post somehow. Sorry! Edited December 8, 2010 by GreenDayRlz Quote Link to comment Share on other sites More sharing options...
yuppicide Posted December 8, 2010 Share Posted December 8, 2010 Why would it need to go that fast? Because you need to make a Nintendo World Champion edition. Quote Link to comment Share on other sites More sharing options...
GreenDayRlz Posted December 8, 2010 Author Share Posted December 8, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Crazy Climber Posted December 8, 2010 Share Posted December 8, 2010 Okay, I thought this would be lame but I'll admit it looks pretty cool! Quote Link to comment Share on other sites More sharing options...
BigO Posted December 8, 2010 Share Posted December 8, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
GreenDayRlz Posted December 8, 2010 Author Share Posted December 8, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
BigO Posted December 8, 2010 Share Posted December 8, 2010 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? Quote Link to comment Share on other sites More sharing options...
GreenDayRlz Posted December 8, 2010 Author Share Posted December 8, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
BigO Posted December 9, 2010 Share Posted December 9, 2010 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. Quote Link to comment Share on other sites More sharing options...
Rev Posted December 9, 2010 Share Posted December 9, 2010 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. Quote Link to comment Share on other sites More sharing options...
GreenDayRlz Posted December 9, 2010 Author Share Posted December 9, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
BigO Posted December 9, 2010 Share Posted December 9, 2010 I never meant to imply that you were wrong. Apologies if it appeared otherwise. Best of luck with the development. Quote Link to comment Share on other sites More sharing options...
potatohead Posted December 9, 2010 Share Posted December 9, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
GreenDayRlz Posted December 9, 2010 Author Share Posted December 9, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
potatohead Posted December 9, 2010 Share Posted December 9, 2010 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. Quote Link to comment Share on other sites More sharing options...
GreenDayRlz Posted December 9, 2010 Author Share Posted December 9, 2010 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. Quote Link to comment Share on other sites More sharing options...
tokumaru Posted December 10, 2010 Share Posted December 10, 2010 Tokumaru on NESDev And here! =) I somehow missed the updates... Looks like this will be a cool port! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.