pmgraphics Posted June 26, 2019 Share Posted June 26, 2019 I have a small graphics program that uses the below OPEN statement, and the program runs until a key is pressed. Once a key is pressed the goto is executed to return to the user to the menu for another run. 680 U=1:OPEN #1,4,0,"K:":GET #1,X:CLOSE #1 690 PUT #6,125:GOTO 90 In my program I wanted a similar thing where if I press the space bar during play something happens. I included the following 55 IF WC>0 THEN OPEN #1,4,0,"K:":GET #1,EMP:CLOSE #1 56 IF EMP=32 THEN GOTO 815 but once WC is greater than zero all programming halts and waits for input from the keyboard instead of waiting in the background for a key to be pressed. Pressing the space bar does trigger the coded at line 815, but then returns to waiting for input, instead of continuing the program. My goal is to use the space bar during game play to trigger the event as programmed at line 815 and to keep game play going, like Atari Defender. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted June 26, 2019 Share Posted June 26, 2019 (edited) it's usually best that if the key does not equal 32 to fall through to the normal routine otherwise execute whatever is at 815 you might have re organize a little to do so... you would not have to track wc that way... why are you using an input method that insists on pausing things? you can read the keys without waiting.... Edited June 26, 2019 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Preppie Posted June 26, 2019 Share Posted June 26, 2019 I've been away from the atari for a long time but I think you need to be using PEEK(764) to read the keyboard instead of opening a channel which pauses everything until it gets input. Sorry I don't have time to test that atm. Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted June 26, 2019 Share Posted June 26, 2019 Have a read through this thread where an equivalent of 'inkey$' was asked for Quote Link to comment Share on other sites More sharing options...
pmgraphics Posted June 26, 2019 Author Share Posted June 26, 2019 (edited) After reading the inkey thread I placed the following between my reading the trigger and reading the stick, within my main game loop. It works but it takes about 3 seconds of holding down the space bar to be detected. Other code in the loop executes near instantly. TR=PEEK(644) IF TR=0 THEN GOSUB 200 ... POKE 764,255:IF WC>0 THEN EMP=PEEK(764):IF EMP=33 THEN GOTO 815 STK=PEEK(632) ... uPDATE: I moved the POKE 764,255 to the start of my main game loop instead of just before the peek, and now it detects the key press immediately. Edited June 26, 2019 by pmgraphics Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted June 26, 2019 Share Posted June 26, 2019 You can set the poke once early on and then reset the poke after a successful peek and key detection. You are wasting speed by poking for no reason. Quote Link to comment Share on other sites More sharing options...
pmgraphics Posted June 27, 2019 Author Share Posted June 27, 2019 19 hours ago, _The Doctor__ said: You can set the poke once early on and then reset the poke after a successful peek and key detection. You are wasting speed by poking for no reason. In this situation I need to clear the keyboard to prevent "stored" key press. Since the player only uses the key press at certain times, if pressed when the game is not ready for it, the moment it is ready the condition is triggered since the key press was waiting in the buffer, and executes instantly. that was one reason why I had a one-liner starting with the poke 764,255, so the keyboard was cleared always prior to peeking, but as noted that was very unresponsive, thus I moved it to the top of the loop which improved response time. is there another way to not have a buffered key press? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 27, 2019 Share Posted June 27, 2019 Just (optionally) clear CH with $ff it at the very start of the program and then only clear it again after reading it and finding it to be not equal to $ff (i.e. a key was pressed). The only time there'll be a pending code in the register when your application starts is if the program which launched your program didn't clear the register after reading the last key directly from CH, or if the user hit a key while the program was loading. 1 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.