Double buffer in mode 13H

[sinsi]

Blind as a bat lol.

9C is the release code for enter
Makes sense when you think about it...

[NoCforMe]

... ohhhhh, <Enter> from starting the program at the DOSBox prompt? And 01 is the make code for ESC. (Because that's what I'm looking for to exit the key-logging loop.)

OK, my head doesn't hurt so much now. My only disappointment is that there's no time machine there ...

[NoCforMe]

More proof of concept: I ran my keylogger again. Hit the following keys as quickly as possible:

• Right arrow down
• Left arrow down (r.arrow held down)
• Release right arrow (l.arrow held down)
• Release left arrow

Got this in the log file:
Key: 00E0 - r.arrow down
Key: 004D -    "    "
Key: 00E0 - l.arrow down
Key: 004B -    "    "
Key: 00E0 - r.arrow up
Key: 00CD -    "    "
Key: 00E0 - l.arrow up
Key: 00CB -    "    "
Key: 0001 - <Esc>

So it works. OP, you can use something like this scheme in your game. Suggestion: set a flag or three, use them to drive your sprite-moving code.

(I think this can be done without a 128-key map, though that is one option. Anything beyond this in game design is far out of my wheelhouse.)

Oh, one more thing: in the INT 15h ISR, add this (the XOR AL, AL, which also clears the carry flag) to throw the keystrokes away so you don't get a million keys coming up when the program exits:

Code Select Expand

INT15_ISR LABEL FAR

; We're looking for AH=4Fh:
CMP AH, 4Fh
JNE isr99

; Stash keycode:
MOV CS:Keycode, AL
XOR AL, AL ;Throw keycode away.
isr99: JMP CS:[OldINT15Vector]


[daydreamer]

in my code I have .inc file with lots of VK_ESCAPE codes for DOS,so you can use it for easy port between windows 32 or 64 bit and DOS 16 bit

[NoCforMe]

I'm using dosbox.

Same here.

Here's something for ya: a working demo that moves a sprite around on the screen. Proves that the INT 15h/AH=4Fh interface works. It's pretty dumbass: uses all 4 cursor keys to move the sprite 1 pixel at a time (the right cursor moves it more just for ha-has). I'm simply erasing the sprite for each move, then redrawing it.

I was thinking about that this am: how in a real game you'd need to implement transparency in the sprite, which would complicate things. Where I'm able to do a block move here (using REP MOVSW), you'd have to do a pixel-by-pixel move, watching out for your transparency color. It could be done, but would be slower.

Anyhow, lemme know whatcha think.

[NoCforMe]

Here's something else for you, @popcalent: this little utility shows you all 256 colors in color mode 13. Works for me in DOSBox. Hit any key to toggle between showing the color #s and just showing color blocks. ESC exits.

Heh; what d'you think of my nice blocky number font? Created it myself with my font maker program.

[popcalent]

Hey!

I've been disappeared for a while. Sorry about that. I've been dealing with other stuff. I'll try to get back to this project as soon as possible. Thank you very much to all who contributed and will continue to help!