Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #3033 > unrolled thread

String Input integrated with animation routine

Back to article view | Back to comp.sys.apple2.programmer

Contents

  String Input integrated with animation routine Mark Lemmert <mark.lemmert@gmail.com> - 2016-09-05 11:47 -0700
    Re: String Input integrated with animation routine Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-09-05 14:30 -0700
      Re: String Input integrated with animation routine Michael J. Mahon <mjmahon@aol.com> - 2016-09-05 22:40 -0500
        Re: String Input integrated with animation routine Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-09-06 13:02 -0700
      Re: String Input integrated with animation routine Mark Lemmert <mark.lemmert@gmail.com> - 2016-09-05 20:55 -0700
    Re: String Input integrated with animation routine mmphosis <mmphosis@macgui.com> - 2016-09-05 23:27 +0000
    Re: String Input integrated with animation routine gids.rs@sasktel.net - 2016-09-05 20:04 -0700
      Re: String Input integrated with animation routine Mark Lemmert <mark.lemmert@gmail.com> - 2016-09-05 21:10 -0700

#3033 — String Input integrated with animation routine

I’m working on writing a string input routine which is integrated with my animation routine so that game players can type in whole words while still seeing animated effects on the screen.

The approaching I’m using is to check $C000 for a key press over and over in the animation routine and on BPL pass control to my string input routine, which is recursive in nature. 


I’m up to 12 keypress checks in the animation routine and I can still type faster than my code can process the keystrokes. If I disable animation, everything works fine so I’m pretty sure more keypress checks in animation is a solution. 

So far I’ve been eyeballing it when deciding where to add the keypress checks. It is a fairly lengthy animation routine, potentially animating up to 187 graphic tiles on the screen (2 screen bytes X 16 lines each) But, if 12 checks isn’t getting it done I’m thinking it may be time to get more scientific about it where to add more checks.  

I am wondering if anyone has any suggestions on a clock cycle interval to shoot for? For example, do a keypress check roughly every X clock cycles.


Thanks for any suggestions anyone has.


Mark

[toc] | [next] | [standalone]

#3034

On Monday, September 5, 2016 at 11:47:17 AM UTC-7, Mark Lemmert wrote:
> I’m working on writing a string input routine which is integrated with my animation routine so that game players can type in whole words while still seeing animated effects on the screen.
> 
> The approaching I’m using is to check $C000 for a key press over and over in the animation routine and on BPL pass control to my string input routine, which is recursive in nature. 

This sounds like this potentially could be a bottle neck.  Are you using a data driven approach hashing off string lengths?  Can you post your recursive algorithm?

> I’m up to 12 keypress checks in the animation routine and I can still type faster than my code can process the keystrokes. If I disable animation, everything works fine so I’m pretty sure more keypress checks in animation is a solution. 
> 
> So far I’ve been eyeballing it when deciding where to add the keypress checks. It is a fairly lengthy animation routine, potentially animating up to 187 graphic tiles on the screen (2 screen bytes X 16 lines each) But, if 12 checks isn’t getting it done I’m thinking it may be time to get more scientific about it where to add more checks.  
> 
> I am wondering if anyone has any suggestions on a clock cycle interval to shoot for? For example, do a keypress check roughly every X clock cycles.

Hmm, doing the math, I would have thought 12 chars per second would be plenty fast enough.

Average Words Per Minute ranges from ~20 .. ~120+. 
Assuming there are 5x Characters Per Minute (*), that means 100 .. 600 Characters Per Minute.
And per second 1.666 ... 10 characters / sec

Calculating cycles / char:

6502 Hz ~= 14.31818 MHz / 14 = 1.022+ MHz.  Let's assume 1 MHz for simplicity.  That means a fast typer @ 120 words / minute would need to check keypresses every:

1,000,000 cycles/second / 10 characters / sec = 100,00 cycles.

Unless I screwed up my math (which is quite possible), maybe you are way over the 10 chars/sec "speed limit" ? :-)

I would try to figure out how many max characters / second is reasonable, and then work out how many clock cycles inbetween presses you need to check.

Any chance you could post a .dsk image ?

(*) https://en.wikipedia.org/wiki/Words_per_minute

[toc] | [prev] | [next] | [standalone]

#3040

Michael Pohoreski <michael.pohoreski@gmail.com> wrote:
> On Monday, September 5, 2016 at 11:47:17 AM UTC-7, Mark Lemmert wrote:
>> I’m working on writing a string input routine which is integrated with
>> my animation routine so that game players can type in whole words while
>> still seeing animated effects on the screen.
>> 
>> The approaching I’m using is to check $C000 for a key press over and
>> over in the animation routine and on BPL pass control to my string input
>> routine, which is recursive in nature. 
> 
> This sounds like this potentially could be a bottle neck.  Are you using
> a data driven approach hashing off string lengths?  Can you post your recursive algorithm?
> 
>> I’m up to 12 keypress checks in the animation routine and I can still
>> type faster than my code can process the keystrokes. If I disable
>> animation, everything works fine so I’m pretty sure more keypress checks
>> in animation is a solution. 
>> 
>> So far I’ve been eyeballing it when deciding where to add the keypress
>> checks. It is a fairly lengthy animation routine, potentially animating
>> up to 187 graphic tiles on the screen (2 screen bytes X 16 lines each)
>> But, if 12 checks isn’t getting it done I’m thinking it may be time to
>> get more scientific about it where to add more checks.  
>> 
>> I am wondering if anyone has any suggestions on a clock cycle interval
>> to shoot for? For example, do a keypress check roughly every X clock cycles.
> 
> Hmm, doing the math, I would have thought 12 chars per second would be plenty fast enough.
> 
> Average Words Per Minute ranges from ~20 .. ~120+. 
> Assuming there are 5x Characters Per Minute (*), that means 100 .. 600
> Characters Per Minute.
> And per second 1.666 ... 10 characters / sec
> 
> Calculating cycles / char:
> 
> 6502 Hz ~= 14.31818 MHz / 14 = 1.022+ MHz.  Let's assume 1 MHz for
> simplicity.  That means a fast typer @ 120 words / minute would need to
> check keypresses every:
> 
> 1,000,000 cycles/second / 10 characters / sec = 100,00 cycles.
> 
> Unless I screwed up my math (which is quite possible), maybe you are way
> over the 10 chars/sec "speed limit" ? :-)
> 
> I would try to figure out how many max characters / second is reasonable,
> and then work out how many clock cycles inbetween presses you need to check.
> 
> Any chance you could post a .dsk image ?
> 
> (*) https://en.wikipedia.org/wiki/Words_per_minute

A reasonable analysis, but, since 100,000 cycles is about 100 milliseconds,
I'd recommend sampling the keyboard at least ten times as often. 

When someone types a common word, the keystroke rate is much higher than
the average, and this is the case especially for common letter pairs, like
"th". 

Best oversample, particularly since it only costs 6 cycles to check for a
key when none has been pressed. 

If you have loops in your animation routine (and you almost certainly do),
put a keyboard poll inside the loop--for example, after updating each tile.


Consider how little time may elapse between pressing a key with a finger on
the left hand and the next key press with a finger from the right. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#3047

On Monday, September 5, 2016 at 8:40:24 PM UTC-7, mjm...@aol.com wrote:

> A reasonable analysis, but, since 100,000 cycles is about 100 milliseconds,
> I'd recommend sampling the keyboard at least ten times as often. 

I *knew* I should of included the ms delay between chars. :-)

Considering some drummers can detect as little as 1ms of input lag then yes, over-sampling is definitely the right solution.

> When someone types a common word, the keystroke rate is much higher than
> the average, and this is the case especially for common letter pairs, like
> "th". 

Agreed that characters tend to "bursty".  I didn't convey that point (at all) -- thanks for bringing that up.
 
> Best oversample, particularly since it only costs 6 cycles to check for a
> key when none has been pressed. 
 
Yup, agree that is probably the best solution.

> If you have loops in your animation routine (and you almost certainly do),
> put a keyboard poll inside the loop--for example, after updating each tile.
 
Traditionally, the main loop of games don't due this, but this is a great example of where this has nice payoffs.
 
> Consider how little time may elapse between pressing a key with a finger on
> the left hand and the next key press with a finger from the right. 

Depending on the player, this can be as little as 0 ms. :-) i.e. At almost the same time.

[toc] | [prev] | [next] | [standalone]

#3041

Thanks for your feedback.

As it turns out, I think the problem is now fixed. I had a JSR $FCA8 at the very end of the animation routine to insert a delay. I didn’t think it was consuming that many clock cycles compared to the rest of the animation loop, but apparently I was way off on that. I replaced the JSR $FCA8 with a simple delay loop which checks for a key press on each iteration and everything works great, even with all the other keypress checks removed.



On Monday, September 5, 2016 at 4:30:23 PM UTC-5, Michael Pohoreski wrote:
> On Monday, September 5, 2016 at 11:47:17 AM UTC-7, Mark Lemmert wrote:
> > I am wondering if anyone has any suggestions on a clock cycle interval to shoot for? For example, do a keypress check roughly every X clock cycles.
> 
> Hmm, doing the math, I would have thought 12 chars per second would be plenty fast enough.
> 
> Average Words Per Minute ranges from ~20 .. ~120+. 
> Assuming there are 5x Characters Per Minute (*), that means 100 .. 600 Characters Per Minute.
> And per second 1.666 ... 10 characters / sec
> 
> Calculating cycles / char:
> 
> 6502 Hz ~= 14.31818 MHz / 14 = 1.022+ MHz.  Let's assume 1 MHz for simplicity.  That means a fast typer @ 120 words / minute would need to check keypresses every:
> 
> 1,000,000 cycles/second / 10 characters / sec = 100,00 cycles.
> 
> Unless I screwed up my math (which is quite possible), maybe you are way over the 10 chars/sec "speed limit" ? :-)
> 
> I would try to figure out how many max characters / second is reasonable, and then work out how many clock cycles inbetween presses you need to check.
> (*) https://en.wikipedia.org/wiki/Words_per_minute

Thanks for the help with the formula and calculations! I am sure this will come in handy. 



> > I’m working on writing a string input routine which is integrated with my animation routine so that game players can type in whole words while still seeing animated effects on the screen.
> > 
> > The approaching I’m using is to check $C000 for a key press over and over in the animation routine and on BPL pass control to my string input routine, which is recursive in nature. 
> 
> This sounds like this potentially could be a bottle neck.  Are you using a data driven approach hashing off string lengths?  Can you post your recursive algorithm?
> 

Sure. It's working now, but for what it's worth:


NPC.TALK.INPUT.LOOP	
NPC.TALK.INPUT.KEYIN
	LDA ANIMATION.CALLED_BY
	BEQ .KEYIN.LOOP
		
	LDA KEYIN.SAVED ;restore keypress captured in animation routine.
	LDX KEYIN.STRING.XREG
	LDY KEYIN.STRING.YREG
	JMP .ALTERNATE.ENTRANCE
	
.KEYIN.LOOP ;wait for keypress
		LDA #$01				;reset to "not tracked" value
		STA ANIMATION.CALLED_BY
		
		STX KEYIN.STRING.XREG
		STY KEYIN.STRING.YREG

		LDA $C08B
		LDA $C08B
	JSR ANIMATION.UPDATE	;continue updating animation while waiting for keypress
		LDA $C083				
		LDA $C083	

		LDX KEYIN.STRING.XREG
		LDY KEYIN.STRING.YREG	

		LDA #$00				;reset to "not tracked" value
		STA ANIMATION.CALLED_BY

	LDA KB_BUFFER
    BPL .KEYIN.LOOP				;loop until key is pressed
.ALTERNATE.ENTRANCE
    STA KB_BUFFER_ACK       ;clr last key
	;ACC = keypress captured
	CMP #$88 ;left arrow key and delete key (AppleWIN) 
	BEQ .BACKSPACE.PRESSED	;if backspace is pressed, erase character in left adjacent column, move cursor 1 column left, and restart loop. 
	CMP #$FF ;delete key (real Apple II, Virutal ][)
	BEQ .BACKSPACE.PRESSED	;if backspace is pressed, erase character in left adjacent column, move cursor 1 column left, and restart loop. 
	CMP #$89	;was tab key pressed
	BEQ	.TOGGLE.VOICE_MODE_STEP
	CMP #$8D	;was return key pressed?
	BEQ	.END.INPUT_STEP ;if yes then end input. Return key is not written to NPC.TALK.KEYWORD
	STA NPC.TALK.KEYWORD,Y	;save input value

	
		;ACC = keypress
	JSR COUT				;print key press to video screen VIA HRCG controller

.INCREMENT_INDEX
	INY						;increment keyboard input array index	
	DEX						;decrement loop counter
	BEQ	.END.INPUT_STEP			;if counter (# of characters to input) = $00 then exit loop
	STX KEYIN.STRING.XREG
	STY KEYIN.STRING.YREG

	JMP .ITERATION.DONE

.TOGGLE.VOICE_MODE_STEP
	JMP .TOGGLE.VOICE_MODE

.END.INPUT_STEP
	JMP .END.INPUT
	
.NPC.TALK.INPUT.LOOP_STEP
	JMP NPC.TALK.INPUT.LOOP
	
.BACKSPACE.PRESSED	;if backspace is pressed, erase character in left adjacent column, move cursor 1 column left, and restart loop. 	
	LDA KEYIN.STRING.LEFT_EDGE ;load the left edge of the input field
	CMP HTAB ;is the cursor at the left edge? 
	BCS .ITERATION.DONE ;if yes, then don't permit backspace, get next input character
	DEC HTAB
	JSR UPDATE.CHAR.POS

.UPDATE.INDEX
;UPDATE INDEX/COUNTERS TO REFLECT BACKSPACE	
	INX						;add one back to the character input counter
	DEY						;subtract one from the keyboard input array index
	STX KEYIN.STRING.XREG
	STY KEYIN.STRING.YREG
	
	LDA #$A0						;ASCII CODE: space
	JSR COUT

	DEC HTAB
	JSR UPDATE.CHAR.POS
	;**FALLS THROUGH**


.ITERATION.DONE

	LDA ANIMATION.CALLED_BY
	BEQ .NPC.TALK.INPUT.LOOP_STEP2
	;**FALLS THROUGH**

	
.ANIMATION_MANAGER.RETURN
	RTS ;return to animation manager


.NPC.TALK.INPUT.LOOP_STEP2
	JMP NPC.TALK.INPUT.LOOP
	

.END.INPUT				
.ADD.STOP_VALUE			
	LDA #NPC.TALK.KEYWORD.STOP_VALUE
	STA NPC.TALK.KEYWORD,Y
	JMP .EXIT
	
.TOGGLE.VOICE_MODE	;switch between NORMAL/YELL/WHISPER				
	INC NTALK.VOICE_MODE
	LDA NTALK.VOICE_MODE ;load current voice mode ($00 = normal, $01 = yell, $02 = normal)
	CMP #NTALK.VOICE_MODE.MAX  ;is variable ready to flip back to $00?
	BNE .UPDATE.VOICE_MODE.DISPLAY ;if no, the value after the INC above stands, resume gathering player input
	LDA #$00
	STA NTALK.VOICE_MODE ;if yes, then flip NTALK.VOICE_MODE to #$00 (normal voice)

.UPDATE.VOICE_MODE.DISPLAY
	JSR UPDATE.VOICE_MODE.DISPLAY
	JMP .ITERATION.DONE


.EXIT	
;RESTORE CURSOR POSITION
		LDA CURSOR.POSITION.SAVED+$0
		STA HTAB	
		LDA CURSOR.POSITION.SAVED+$1
		STA VTAB
	JSR	UPDATE.CHAR.POS

;Fix stack if calling routine was animation manager
	LDA ANIMATION.CALLED_BY
	BEQ .RESTORE.REGISTERS

	
	; PLA ;registers saved at entrance to NPC.TALK.INPUT
	; PLA

	LDX #$00 ;init counter
.POP.LOOP
	PLA ;pop a value off the stack
	INX
	CPX #$0B 
	BNE .POP.LOOP


;RESET CALL TRACER
	LDA #$00				;reset to "not tracked" value
	STA ANIMATION.CALLED_BY
	
.RESTORE.REGISTERS	
	PLA
	TAY
	PLA
	TAX	

	RTS ;return to the routine that called NPC.TALK.INPUT	


;------end of recursive string input routine, the rest are code excerpts from the animation routine which is integrated with the string input routine. 

ANIMATION.UPDATE
     ;<code for animation loop>

.EXIT
	LDA ANIMATION.SCREEN.TALLY		
	CMP #ANIMATION.DELAY_TRIGGER1	;DETERMINE IF DELAY SHOULD BE SKIPPED BASE ON # OF ANIMATED TILES ON CURRENT VIEW SCREEN
	BCS .SKIP1

	LDX #$00 ;init delay counter, lo byte
	LDY #$00 ;init delay counter, ho byte
.WAIT.LOOP1	
	LDA ANIMATION.CALLED_BY			;get calling routine code, if available
	BEQ .KB_BUFF.CHECK10.DONE		;if no code is available, then assume that animation manager was not called by a string input routine and use the standard ROM wait routine to generate the delay.
	JSR NPC.TALK.INPUT.CHECK.KB_BUFF
.KB_BUFF.CHECK10.DONE
	INX ;increment lo byte delay counter
	BNE .WAIT.LOOP1
	INY ;increment ho byte delay counter
	CPY #$20 ;arbitrary value tuned to the visually observed animation speed
	BNE .WAIT.LOOP1	
	;**FALLS THROUGH**

; ;Standard ROM Wait Routine
	; LDA #$FF
	; JSR WAIT 				;IF NO, INSERT DELAY
	
.SKIP1
	LDA ANIMATION.SCREEN.TALLY		
	CMP #ANIMATION.DELAY_TRIGGER2	;DETERMINE IF DELAY SHOULD BE SKIPPED BASE ON # OF ANIMATED TILES ON CURRENT VIEW SCREEN
	BCS .DELAY_DONE	

	LDX #$00 ;init delay counter, lo byte
	LDY #$00 ;init delay counter, ho byte
.WAIT.LOOP2
	LDA ANIMATION.CALLED_BY			;get calling routine code, if available
	BEQ .KB_BUFF.CHECK11.DONE		;if no code is available, then assume that animation manager was not called by a string input routine and use the standard ROM wait routine to generate the delay.
	JSR NPC.TALK.INPUT.CHECK.KB_BUFF
.KB_BUFF.CHECK11.DONE
	INX ;increment lo byte delay counter
	BNE .WAIT.LOOP2
	INY ;increment ho byte delay counter
	CPY #$20 ;arbitrary value tuned to the visually observed animation speed
	BNE .WAIT.LOOP2		
	
	; LDA #$FF
	; JSR WAIT 				;IF NO, INSERT DELAY
	

.DELAY_DONE



NPC.TALK.INPUT.CHECK.KB_BUFF ;check fpr keypress
;Note: periodically called during the run time of ANIMATION.UPDATE
;to check for a keypress on behalf of NPC.TALK.INPUT.KEYIN, a recusive subroutine.
;This check is only done if ANIMATION.UPDATE was called by NPC.TALK.INPUT.KEYIN

	LDA KB_BUFFER
    BPL .KB_BUFF.CHECK.DONE 	;branch if no value in lastkey buffer
	STA KEYIN.SAVED ;save captured keypress
			
	TXA ;save registers
	PHA
	TYA
	PHA
	JSR NPC.TALK.INPUT.KEYIN	;the subroutine which manages string input for the NPC.TALK module


	PLA ;restore registers
	TAY
	PLA
	TAX

.KB_BUFF.CHECK.DONE	
	RTS ;return to the kb_buff check within ANIMATION.UPDATE that initiated the call
	 

  

[toc] | [prev] | [next] | [standalone]

#3035

Here is a keyboard test program using the Monitor WAIT routine between polls
of the keyboard ...

 100  DATA169,1,32,168,252,173
 110  DATA0,192,16,246,44,16
 120  DATA192,201,155,240,7,32
 130  DATA240,253,169,0,240,232
 140  FOR I = 768 TO 792: READ B
 150  POKE I,B: NEXT : DATA96
 160  INPUT "WAIT (0 TO 255)=";A
 170  LET N = A + (A = 0) * 256
 180  LET D = 13 + 5 / 2 * N * N
 190  PRINT "="27 / 2 * N + D;
 200  PRINT " CYCLES"
 210  PRINT "PRESS ESC TO QUIT"
 220  POKE 769,A: CALL 768

KEGSMAC, the emulator I am using, always captures the keystrokes, so I
wasn't able to test this program very well.

[toc] | [prev] | [next] | [standalone]

#3038

On Monday, September 5, 2016 at 12:47:17 PM UTC-6, Mark Lemmert wrote:
> I’m working on writing a string input routine which is integrated with my animation routine so that game players can type in whole words while still seeing animated effects on the screen.
> 
> The approaching I’m using is to check $C000 for a key press over and over in the animation routine and on BPL pass control to my string input routine, which is recursive in nature. 
> 
> 
> I’m up to 12 keypress checks in the animation routine and I can still type faster than my code can process the keystrokes. If I disable animation, everything works fine so I’m pretty sure more keypress checks in animation is a solution. 
> 
> So far I’ve been eyeballing it when deciding where to add the keypress checks. It is a fairly lengthy animation routine, potentially animating up to 187 graphic tiles on the screen (2 screen bytes X 16 lines each) But, if 12 checks isn’t getting it done I’m thinking it may be time to get more scientific about it where to add more checks.  
> 
> I am wondering if anyone has any suggestions on a clock cycle interval to shoot for? For example, do a keypress check roughly every X clock cycles.
> 
> 
> Thanks for any suggestions anyone has.
> 
> 
> Mark


A check could be made for a keypress after each screen draw for each animated character.  So this would allow 187 checks for the cycle of all the animations.

The only animated character that would have a slight pause before it is drawn, is the one just after the actual keypress and is next in sequence.

2 screen bytes by 16 lines isn't very much and should easily handle an input character without a significant delay before the next animation.

And you have that backwards.  A check for keypress should result in a BMI to pass control over to the string input routine, which should only handle one character input at a time, then return to the animation sequence.


So in conclusion, you really only need one keypress check, which comes after the end of each animated draw cycle.  If $C000 goes negative, then handle the keypress, otherwise continue with animation routine.

And the keypress input routine should only handle once keypress at a time, store it into a buffer, print it to screen and return to the animation routine.

The input routine could also handle the RETURN key, in which it then retrieves the word or command from the buffer and handles it appropriately.

[toc] | [prev] | [next] | [standalone]

#3042

On Monday, September 5, 2016 at 10:04:25 PM UTC-5, gid...@sasktel.net wrote:

> So in conclusion, you really only need one keypress check, which comes after the end of each animated draw cycle.  If $C000 goes negative, then handle the keypress, otherwise continue with animation routine.

> 2 screen bytes by 16 lines isn't very much and should easily handle an input character without a significant > delay before the next animation.

There is a lot of code that determines whether each tile should have animation drawn for it, which has grown bulky due to a lot of corner cases, and is probably due for some reorganization. Regardless, it turns out you were spot on in your assessment. As mentioned in my reply to Michael, it turns placing a keypress check in my delay loop is enough, which only runs after the main animation loop. I added one more at the start of each iteration of the main animation loop just be extra sure. 



> And you have that backwards.  A check for keypress should result in a BMI to pass control over to the >string input routine, which should only handle one character input at a time, then return to the animation >sequence.

Ah, right :-)

I had BPL stuck in my head; I'm actually doing LDA $C000, then BPL to skip ahead if no keypress detected, then if BPL isn't true call the input routine

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web