On 12/24/2021 7:49 AM, TK Chia wrote:
Hello Daniel, hello Jim,
Thanks for the tests!
Both games use a combination of kbhit + getch (with the arrow keys
taking an extra getch, if the first one yields either 0 or 224).
[...]
Right now I'm writing a new real mode game (actually, a demake of my
WIP protected mode game, https://montyontherun.itch.io/sub), using
ia16-gcc and reading the keyboard with inline ASM by invoking int 16
and int 21. Would that be safer? If so, I can modify all my games to
use that option, if so.
Apparently DJGPP uses int 0x16 to implement kbhit (), but int 0x21 to
implement getch () --- I am not sure why --- and this might be a source
of the "double keypress" problem. (I.e. there might be a DJGPP bug.)
In general, I think it is best to stick to one way of getting keyboard
input (different OS interfaces may have different buffers for keyboard
input, and thus slightly different ideas on which keys have been
processed or not).
So, if you poll for keyboard input using int 0x16, then you should also
consume the keyboard input using int 0x16; if you poll using int 0x21,
then consume using int 0x21 as well; if you poll using an IRQ 1 handler,
then consume the input there as well; etc.
If you still want to build your code to build under DJGPP, perhaps
instead of writing inline assembly, you can consider using the
_bios_keybrd (.) function (<bios.h>). This function will consistently
call int 0x16 to read keyboard input. :-) It is also supported by Open
Watcom, and by my libi86 + gcc-ia16.
That's what I tried to tell you guys at the last online meeting. Mixing
the different levels of access (DOS (INT21h), BIOS (INT16h) and direct
I/O port calls) is most likely to cause some issues. Even more so in
environments that switch between real mode and protected mode, like
DJGPP. At least one has to be careful to consider the exact state of
things like keyboard buffer etc when doing so...
Ralf
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
