Rabbit 2600 Posted June 8, 2013 Share Posted June 8, 2013 Just a demo I'm working on to test out what I've learned. It's a fighting game alá Double Dragon. Very basic at the moment. You can punch the enemies and walk around a bridge. Updates to come GAME - default.bas.bin SOURCE - default.bas Quote Link to comment Share on other sites More sharing options...
Rabbit 2600 Posted June 8, 2013 Author Share Posted June 8, 2013 (edited) Added a debounce to the punching so now you can't hold the firebutton in. Gonna see if I can remember how to set a counter up so the punch lasts for about 1 second. I tried using this but could not make the counter work, some small silly mistake I made somewhere no doubt. Game - default.bas.bin Source - default.bas rem **************************************************************** rem * rem * Debounce fire button. rem * rem ```````````````````````````````````````````````````````````````` rem ` If fire button not pressed, clear debounce bit and skip. rem ` if !joy0fire then _Bit1_Debounce_Fire{1} = 0 : goto __Skip_Fire rem ```````````````````````````````````````````````````````````````` rem ` If fire button hasn't been released, skip this section. rem ` if _Bit1_Debounce_Fire{1} then goto __Skip_Fire rem ```````````````````````````````````````````````````````````````` rem ` Turn on fire button debounce bit. rem ` _Bit1_Debounce_Fire{1} = 1 rem ```````````````````````````````````````````````````````````````` rem ` Skip Punch. rem ` if joy0fire then a = 120 : g = 10 if a > 0 then a = a - 1 if a = 1 then g = 10 : a = 0 __Skip_Fire Edited June 8, 2013 by Rabbit 2600 Quote Link to comment Share on other sites More sharing options...
bogax Posted June 8, 2013 Share Posted June 8, 2013 (edited) Added a debounce to the punching so now you can't hold the firebutton in. I probably shouldn't confuse you, but that's not actually debounce. It's more edge detection though The term debounce seems to be (mis)used for it a lot. (drives me nuts, heh ) Probably someday you're going to run into someone talking about actual debounce and wonder what they're talking about. For various reasons (one being bouncy contacts in a switch, hence debounce) when going from, say, 0 to 1 a switch might jump back and forth between 0 and 1 before it stays 1. Debounce is getting past that cleanly. Now suppose I decide I wont believe its really a 1 until I've seen three 1s in a row. then it might look something like this (each 0 or 1 is what I read when I read the switch one time): what I read 0001010010110110011101110111111 edge detection 0001010010100100010001000100000 debounce 0000000000000000000111111111111 Edited June 8, 2013 by bogax Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 8, 2013 Share Posted June 8, 2013 I probably shouldn't confuse you,but that's not actually debounce. It's more edge detection though The term debounce seems to be (mis)used for it a lot. (drives me nuts, heh ) So keeping a switch or fire button from activating again until it is released is not called debouncing? I better add a note to Atari's Game Standards and Procedures then: http://www.randomter...starting_a_game The Reset switch should be debounced so it does not start another game until it is first released. What is it supposed to be called? Quote Link to comment Share on other sites More sharing options...
Rabbit 2600 Posted June 8, 2013 Author Share Posted June 8, 2013 Ahh, I did not know that, I learned that it was called debouncing when you can't hold a button in. Thank you for explaining it =) Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 8, 2013 Share Posted June 8, 2013 Ahh, I did not know that, I learned that it was called debouncing when you can't hold a button in. Thank you for explaining it =) He might have been talking about you wanting to add a counter. I think this might still be considered debouncing: http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#debounce_fire Quote Link to comment Share on other sites More sharing options...
Rabbit 2600 Posted June 8, 2013 Author Share Posted June 8, 2013 Mhm, okay =) Quote Link to comment Share on other sites More sharing options...
bogax Posted June 8, 2013 Share Posted June 8, 2013 What is it supposed to be called? I'd call it edge detection. Not sure it matters. My impression is that, when talking about writing games debounce is more often used to mean edge detection than actual debounce (but not always) You might note that it's not actually debounce but that that is the term that's used and leave it at that. And/or you might add a bit on actual debouncing since that's generaly considered a good idea even though I don't see it done here much. (probably more likely to see it when talking asm) Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 8, 2013 Share Posted June 8, 2013 Do you have any links to pages that define the terms? Here's one thing I found when Gooling: (Debouncing) A keyswitch, when pressed, may send several rapid electrical signals in succession. This could be interpreted by a computer as numerous independent keystrokes rather than just one. A debouncing circuit is a timer or similar system to eliminate spurious responses caused by key bounce. This code keeps the fire button from bouncing or having a rapid-fire effect: http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#debounce_fire rem **************************************************************** rem * rem * Debounce Fire Button rem * rem * Example program by Duane Alan Hahn (Random Terrain) using rem * hints, tips, code snippets, and more from AtariAge members rem * such as batari, SeaGtGruff, RevEng, Robert M, Nukey Shay, rem * Atarius Maximus, jrok, supercat, GroovyBee, and bogax. rem * rem **************************************************************** rem * rem * Instructions: rem * rem * Press and release fire button to increase the score by one. rem * rem **************************************************************** rem **************************************************************** rem * rem * Create aliases for variables. rem * rem **************************************************************** rem ` rem ` (You can have more than one alias for each variable.) rem ` rem ```````````````````````````````````````````````````````````````` rem ```````````````````````````````````````````````````````````````` rem ` BitOp variable for debouncing the fire button. rem ` dim _Bit1_Debounce_Fire = d rem **************************************************************** rem **************************************************************** rem * rem * Main Loop rem * rem ` __Main_Loop rem **************************************************************** rem * rem * Score color. rem ` scorecolor = $1A rem **************************************************************** rem * rem * Debounce fire button. rem * rem ```````````````````````````````````````````````````````````````` rem ` If fire button not pressed, clear debounce bit and skip. rem ` if !joy0fire then _Bit1_Debounce_Fire{1} = 0 : goto __Skip_Fire rem ```````````````````````````````````````````````````````````````` rem ` If fire button hasn't been released, skip this section. rem ` if _Bit1_Debounce_Fire{1} then goto __Skip_Fire rem ```````````````````````````````````````````````````````````````` rem ` Turn on fire button debounce bit. rem ` _Bit1_Debounce_Fire{1} = 1 rem ```````````````````````````````````````````````````````````````` rem ` Add one to the score. rem ` score = score + 1 __Skip_Fire rem **************************************************************** rem * rem * Nothing would happen without drawscreen. rem ` drawscreen goto __Main_Loop I don't understand how that wouldn't be considered debouncing the fire button. Quote Link to comment Share on other sites More sharing options...
bogax Posted June 8, 2013 Share Posted June 8, 2013 (edited) I don't understand how that wouldn't be considered debouncing the fire button. I'm not sure how to explain any better. maybe I didn't make it clear that what I read 0001010010110110011101110111111 edge detection 0001010010100100010001000100000 debounce 0000000000000000000111111111111 is meant to represent one key press. Your code would increment score 8 times in that example for that single keypress. Thats not debounce Edited June 8, 2013 by bogax Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 8, 2013 Share Posted June 8, 2013 Your code would increment score 8 times in that example for that single keypress. Thats not debounce I only see one being added to the score: ex_debounce_2013y_03m_22d_1716t.bin Quote Link to comment Share on other sites More sharing options...
bogax Posted June 8, 2013 Share Posted June 8, 2013 (edited) I only see one being added to the score: I fyou're doing it on an emulator it's because the keyboard is already debounced. If it's on a real 2600 then most of the bouncing might be hidden by the delay due to drawscreen but you couldn't count on that. Either way it's still not debounce Edited June 8, 2013 by bogax Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 8, 2013 Share Posted June 8, 2013 I your doing it on an emulator it's because the keyboard is already debounced. If it's on a real 2600 then most of the bouncing might be hidden by the delay due to drawscreen but you couldn't count on that. Either way it's still not debounce If flipping a bit off and on can't be trusted, how can anything in a program be trusted? Quote Link to comment Share on other sites More sharing options...
bogax Posted June 8, 2013 Share Posted June 8, 2013 If flipping a bit off and on can't be trusted, how can anything in a program be trusted? What bit are you talking about? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 9, 2013 Share Posted June 9, 2013 What bit are you talking about? This bit: _Bit1_Debounce_Fire{1} The number inside of the curly brackets tells bB what bit you want to turn on or off. Quote Link to comment Share on other sites More sharing options...
bogax Posted June 9, 2013 Share Posted June 9, 2013 This bit: _Bit1_Debounce_Fire{1} The number inside of the curly brackets tells bB what bit you want to turn on or off. I'm not following you then. The problem is when and how you set or reset that bit not the bit itself. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 9, 2013 Share Posted June 9, 2013 I'm not following you then. The problem is when and how you set or reset that bit not the bit itself. Would it help if I converted the debounce section into normal words? Here it is: If the fire button is not pressed, the bit is turned off and the section is skipped. If the fire button is pressed, but the bit is on, the section is skipped. Turn on the bit. Add 1 to the score. Quote Link to comment Share on other sites More sharing options...
bogax Posted June 9, 2013 Share Posted June 9, 2013 (edited) debounce would be something like this (not that this is the way I'd code it) if debounce then key_is_pressed if !joy0fire then j0f = 0 : skip j0f = j0f + 1 if j0f > 2 then debounce = 1 : j0f = 0 goto skip key_is_pressed if joy0fire then j0f = 0 : skip j0f = j0f + 1 if j0f > 2 then debounce = 0 : j0f = 0 skip edit oops, forgot to reset the j0f counter when debounce changes Edited June 9, 2013 by bogax Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted June 9, 2013 Share Posted June 9, 2013 (edited) I guess I'm guilty of perpetuating the incorrect usage of debounce. IIRC I picked up the term and its incorrect usage a few decades ago from a book about programming for the Atari 800. It certainly wouldn't be the first time that an author writing about Atari computers or game consoles had misused a term-- a good example would be the widespread misuse of the term "overscan" among Atari programmers to refer to the lines of vertical blanking at the bottom of a game screen. I see what you mean about debouncing an iffy connection versus edge detection in a signal, bogax, but as I now understand the term I guess debouncing proper isn't necessary when reading the joysticks, fire buttons, console switches, etc., since the're usually being read only once per frame. I presume that any bouncing in the signal before a steady connection is made would most likely occur (on average) sometime between the two reads, while the display is being drawn, such that by the time you read the stick/button/switch during the vertical blanking period a steady connection has already been made. On the other hand, an edge detection routine-- or whatever we should properly call it-- is definitely necessary in some cases, to prevent the program from responding more times than intended when the user pushes the stick in a certain direction, presses the fire button, presses one of the console switches, etc. Edited June 9, 2013 by SeaGtGruff 1 Quote Link to comment Share on other sites More sharing options...
bogax Posted June 9, 2013 Share Posted June 9, 2013 I see what you mean about debouncing an iffy connection versus edge detection in a signal, bogax, but as I now understand the term I guess debouncing proper isn't necessary when reading the joysticks, fire buttons, console switches, etc., since the're usually being read only once per frame. heh once per frame is definitely not true though it may be only noobs (me too) that read the buttons multiple times. It's not at all uncommon to see long strings of if statments reading the same buttons. I generally don't worry about it I'm going to be using Stella. But it's sloppy. I'm pretty sure I've seen the subject discussed here on the forums before but it doesn't come up much so I guess it's not much of a problem. I presume that any bouncing in the signal before a steady connection is made would most likely occur (on average) sometime between the two reads, while the display is being drawn, such that by the time you read the stick/button/switch during the vertical blanking period a steady connection has already been made. I'm not sure you could count on that. My recollection is that 20ms is the usual prescription (time to wait for the bouncing to stop) and that's supposed to be plenty so 16ms is probably enough. But I know I've seen switches (relays actually) that bounced for a lot longer than that. I have no idea what an Atari controller would do and I have no idea what piece of air they pulled the 20ms figure from. On the other hand, an edge detection routine-- or whatever we should properly call it-- is definitely necessary in some cases, to prevent the program from responding more times than intended when the user pushes the stick in a certain direction, presses the fire button, presses one of the console switches, etc. Sure. I wasn't even objecting to calling it debounce (although, like I said, it drives me nuts) It's just that there's a possibility of confusion when some noob comes across actual debounce and it turns out to be something different from what they're expecting. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted June 9, 2013 Share Posted June 9, 2013 Hmm, I see what you mean about multiple ifs per loop, but hopefully it isn't a problem. Perhaps the manner in which people use a joystick helps negate any potential issues with bouncing? People tend to push on them pretty hard, and to mash the fire button pretty hard. I do know what you mean about the incorrect usage of a term driving you nuts. It bugs me the way Atari 2600 programmers use the term "overscan," but I know they aren't going to change, so I decided to shut up about it. As far as "debounce," I've been a major offender, and now that I realize it refers to something different than what I'd thought, I'll try to figure out something else to call it. "Edge detect the fire button" sounds kind of strange compared to "debounce the fire button." Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 9, 2013 Share Posted June 9, 2013 For the common man, Edge Detection is meaningless. Debounce at least made some sense because it contained the word bounce. When you didn't want the fire button or reset switch or select switch to "bounce" in rapid-fire succession 60 times a second if held down, the word Debounce seemed fit. But if Debounce has some deeper meaning in electronics, we could use something like Repetition Restrainer instead. The code I posted can be used to stop a fire button from firing 60 times a second when held down. It can also be used to keep the reset switch from displaying a blank screen if held down. It won't keep resetting and resetting and resetting and resetting and resetting . . . My code fixes it so the game will reset once and ignore that the player still has the reset switch pressed down. The player will have to release the reset switch and press it again for it to work: rem **************************************************************** rem * rem * Reset Program: rem * rem * Any Atari 2600 program should restart when the reset switch rem * is pressed. It is part of the usual standards and procedures. rem * rem ```````````````````````````````````````````````````````````````` rem ` If the reset switch is not pressed, turn off debounce and rem ` skip this section. rem ` if !switchreset then _Bit0_Debounce_Reset{0} = 0 : goto __Skip_Main_Reset rem ```````````````````````````````````````````````````````````````` rem ` If the reset switch hasn`t been released, skip this section. rem ` if _Bit0_Debounce_Reset{0} then goto __Skip_Main_Reset rem ```````````````````````````````````````````````````````````````` rem ` Restart the program. rem ` goto __Start_Restart __Skip_Main_Reset Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted June 9, 2013 Share Posted June 9, 2013 I'm not sure you could count on that. My recollection is that 20ms is the usual prescription (time to wait for the bouncing to stop) and that's supposed to be plenty so 16ms is probably enough I seem to recall that as well. I knew what debouncing was from taking electronics at school, but I still tended to refer to edge detection as debouncing. The 2600 has latches installed for the firebuttons. You write a 1 to bit 6 of the VBLANK register to enable them. They will remain high once enabled until the firebutton is pressed. Once pressed they will remain low until re-enabled. I have never played with the latches as I always found reading the firebuttons once per frame worked well enough. Thinking about it now, I'm not sure how well they would work as I generally turn vblank on at the beginning of overscan and turn vblank off at the start of the kernel. And finally, yes I am using the terms overscan and vblank here, because that is how it is written in the Stella's programming guide and I have no problems with that. I've learned of some other terms before like "front porch" and "back porch" at school, but IIRC those reference are for a horizontal scanline and not the vertical. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted June 9, 2013 Share Posted June 9, 2013 (edited) And finally, yes I am using the terms overscan and vblank here, because that is how it is written in the Stella's programming guide and I have no problems with that. I've learned of some other terms before like "front porch" and "back porch" at school, but IIRC those reference are for a horizontal scanline and not the vertical. Yes, the Stella Programmer's Guide has perpetuated the incorrect usage of "overscan." It is the bible of the Atari 2600 programming universe and we must never go against it, even when it's wrong. That is not because it must never be contradicted, but rather because its influence is so all-pervasive that any attempts to go against it are doomed to fail before they're even begun. As for "front porch" and "back porch," they are used in connection with both the horizontal and vertical timings: The horizontal front porch is the horizontal blanking period that precedes the horizontal sync. The horizontal back porch is the horizontal blanking period that follows the horizontal sync. If the video signal includes a color burst signal, the portion of the horizontal back porch between the end of horizontal sync and the beginning of color burst is called the breezeway. In those cases some people appear to define the horizontal back porch as the horizontal blanking period that follows the color burst. The vertical front porch is the vertical blanking period that precedes the vertical sync. The vertical back porch is the vertical blanking period that follows the vertical sync. These terms are sometimes shortened by dropping the "horizontal" or "vertical" qualifiers when their meanings are clear from the context. Edited June 9, 2013 by SeaGtGruff Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 10, 2013 Share Posted June 10, 2013 Here's the updated fire button code with debounce removed from the REMs and any variable aliases: rem **************************************************************** rem * rem * Repetition Restrainer for the Fire Button rem * rem * Example program by Duane Alan Hahn (Random Terrain) using rem * hints, tips, code snippets, and more from AtariAge members rem * such as batari, SeaGtGruff, RevEng, Robert M, Nukey Shay, rem * Atarius Maximus, jrok, supercat, GroovyBee, and bogax. rem * rem **************************************************************** rem * rem * Instructions: rem * rem * Press and release fire button to increase the score by one. rem * rem **************************************************************** rem **************************************************************** rem * rem * Creates aliases for variables. rem * rem * You can have more than one alias for each variable. rem * rem **************************************************************** dim _Bit1_FireB_Restrainer = d rem **************************************************************** rem **************************************************************** rem * rem * Main Loop rem * rem ` __Main_Loop rem ```````````````````````````````````````````````````````````````` rem ` Score color. rem ` scorecolor = $1A rem ```````````````````````````````````````````````````````````````` rem ` Repetition restrainer for the fire button. rem ` if !joy0fire then _Bit1_FireB_Restrainer{1} = 0 : goto __Skip_Fire if _Bit1_FireB_Restrainer{1} then goto __Skip_Fire _Bit1_FireB_Restrainer{1} = 1 score = score + 1 __Skip_Fire rem ```````````````````````````````````````````````````````````````` rem ` Nothing would happen without drawscreen. rem ` drawscreen goto __Main_Loop 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.