a problem of velocity in a procedure

[PG472]

hi all , i'm actually programming a wall-breaker like and i have a problem of velocity in one procedure

i draw a "bat" like this ----->    XXXX

so it's very..simplified  :P

to move the bat , i use keyboard but there is a "latency time" quite important (in my opinion^^)  between i tape the key and what's display on the screen

this is the procedure to move the bat:

Code Select Expand

deplacement PROC

PUSH AX   
PUSH BX
PUSH CX
PUSH DX

MOV DX, 0
MOV AX, 0

MOV AH, 6
MOV DL, 255
int 21h






CMP AL, 113
JZ vers_la_gauche

CMP AL, 100
JZ vers_la_droite

JMP fin



vers_la_gauche: ;on the left
CMP B.ES:[4], 4
JLE fin
CALL dropraquette
SUB B.ES:[4], 2
JMP suite


vers_la_droite: ;  on the right
CMP B.ES:[4],160
JZ fin
CALL dropraquette
ADD B.ES:[4], 3
JMP suite
/code]

the "JMP suite" is a jump to the "bat procedure"and others  to erase/draw/calculate the new position of the bat

i don't know if the problem come from this procedure or if it's a problem in the "erasiing procedure"

thanks in advance :)


[FORTRANS]

Hi,

   Is this a text mode or graphic mode program?  If grapphic
what mode?

Steve

[redskull]

If you run this as a DOS program under NTVDM (on an NT system DOS box), be aware that it has a delay built into the console; constrast the response of cmd.exe (a win32 program) with the response of command.com (a dos program).  If it's still slower than that, consider posting more of the code for us to see.

-r

[PG472]

@FORTRANS: it's in text mode (0B800h) .

i use emu8086 under windows 7 (and tested under winXP )

@ redskull: thanks :bg i didn't know that ( poor boy i am  :toothy) .i thinks it could be the reason why it's to slow . it's one of my first program in 16bits so i think all works normally even if this  (relative) slowness is strange for me  :P

[FORTRANS]

Hi,

   redskull; interesting.  In a window I can see some roughness
in the response to the keyboard.  Not really slow.  Full screen
seems okay.  Do you see something more severe?  (Win2k/XP.)

   PG472; I would try not using emu8086 and see if the response
is better.  I don't have any experience with emu8086, so that's
about the only suggestion I can make other than to run 16-bit
programs full screen.

Regards,

Steve N.

[redskull]

It's been awhile since I was knee-deep in the ntvdm code, but IIRC it uses a pretty non-standard handler.  Instead of the normal way of processing console events, it uses some undocumented call (GetConsoleInputWaitHandle) to get a handle to an Event that's triggered whenever input occurs, and then waits on it using WaitForMultipleObjects.  Whenever it gets signaled, a loop goes through and essentially flushes out all the events in the queue at once.  Then, before waiting on the event again, it sleeps for 10ms, presumably to let several events "build up" in the queue before flushing them out again.  This is all part of ntvdm!nt_event_loop, if you use WinDbg. 

Code Select Expand


ntvdm!nt_event_loop:
0f03baf0 8bff            mov     edi,edi
0f03baf2 55              push    ebp
...
0f03bc54 6a0a            push    0Ah
0f03bc56 ff151011000f    call    dword ptr [ntvdm!_imp__Sleep (0f001110)]

Even after all that, it still has to turn the console event into simulated DOS keyboard input, and then display it (all of which takes more than a few kernel traps).  It all goes pretty quick, but not as quick as *real* interrupts.

I can't go 'full screen' with my widescreen monitor, but there's an ouput delay as well; get a recursive directory listing in command.com, and compare the print speed while you wiggle the mouse over the console window, and with the mouse somewhere else

-r

[FORTRANS]

Hi,

   Thanks for the insight.  I'm not seeing it very much here
though.  Just a little when windowed.  Of course as I get an
error message about a registry error each time COMMAND gets
run, I may have other things affecting performance.  I also try to
do most of my DOS work in a different environment anyway.

Regards,

Steve

[MichaelW]

I think the "latency time" is probably due to the keyboard typematic delay, the length of time after a key is pressed (and held) before the keyboard controller starts repeating the key. This delay is programmable, typically in the range 250 to 1000 milliseconds. Test1.asm in the attachment demonstrates the effect at the minimum value for the delay. Test2.asm uses a MultiKey-style keyboard handler to eliminate both the typematic delay and the dependency of the bat speed on the typematic rate, and a millisecond timer to allow fine control of the speed. Under the Windows 2000 NTVDM the motion is rough when the application is running in a window, but smooth as butter when running full screen.

The code in the attachment has had only a minimal amount of testing, and only under Windows 2000.

[FORTRANS]

Hi,

   Nice code, thank you.  Will confirm good movement in full
screen, and some funny jerks in a window with Windows 2000
and test2.

Regards,

Steve N.

[MichaelW]

Testing under DOS, the keys are being placed in the key buffer, quickly filling it and causing the BIOS to beep each time it discards a key. The code looks right to me, but clearly there is a problem.

Edit:

I can correct the problem by substituting this:

Code Select Expand


    ;--------------------------------------------------
    ; *TEST*
    ; Empty the key buffer to keep it from filling up.
    ; To manage the circular key buffer the BIOS uses
    ; two pointers, one that points to the next key in
    ; the buffer and one that points to the last. When
    ; these pointers are equal, the buffer is empty.
    ;--------------------------------------------------

    push es
    push 40h
    pop es
    mov bx, 1ah
    mov ax, es:[bx]
    mov es:[bx+2], ax
    pop es


For the code that is supposed to clear the Interrupt 9 handler's carry flag. The problem with this method is that it will effectively disable any other type of keyboard input.

Edit2:

My problem is apparently due to a bug in the Phoenix BIOS of the test system. After verifying in multiple references that my return condition is correct, and verifying that the problem is not in the code that modifies the flags on the stack, I decided to test under DOS on a different system. On that system the test2.exe from the attachment worked as it was supposed to. The internal speaker for that system is not connected, but even without sound the problem should be apparent, because the code that makes the sound monopolizes the CPU for something like a half second. Still, it would be good if someone could verify my results.

[PG472]

I think the "latency time" is probably due to the keyboard typematic delay, the length of time after a key is pressed (and held) before the keyboard controller starts repeating the key. This delay is programmable, typically in the range 250 to 1000 milliseconds. Test1.asm in the attachment demonstrates the effect at the minimum value for the delay. Test2.asm uses a MultiKey-style keyboard handler to eliminate both the typematic delay and the dependency of the bat speed on the typematic rate, and a millisecond timer to allow fine control of the speed. Under the Windows 2000 NTVDM the motion is rough when the application is running in a window, but smooth as butter when running full screen.

The code in the attachment has had only a minimal amount of testing, and only under Windows 2000.

thanks for this code :) very interresting.

i modified "bat" and "bat move" proc and now it's quite faster

[FORTRANS]

Still, it would be good if someone could verify my results.

Hi,

   Tested on one system with DOS 6.20 and test1.exe and test2.exe
performed as expected.  Looks good to go.  I can test on another if
wanted.

Regards,

Steve N.

[MichaelW]

Thanks Steve, I think the one test should be sufficient. The system with the problem should have had a BIOS upgrade while the manufacturer (Micron Electronics) was still around, but unfortunately I didn't have control of it at the time.