I got it working with kbhit, but still limited to the character repeat rate - the ship just crawls across the screen while the stars are flying by

If a flag is set when the key is pressed that will turn on ship movement, there is no way to turn it off. I store old keypress and compare to mew one, the problem is that that routine is called only when there IS a keypress, so you would have to press again to turn it off.

What I NEED is a function that returns a null value if no key is pressed

you need to do a keyboard isr in that case. i knocked this and tested on my turbo c 2.01

while a key is pressed its value is 1. otherwise its 0. so while user holds RIGHT, it will always = 1, when they let go, its reset to 0.
this does not take into account extended key codes, thats an exercise for the reader 😀

i built it with large model.

tcc -ml kirq.c

1#include <stdlib.h>
2#include <stdio.h>
3#include <conio.h>
4#include <dos.h>
5
6#define KEY_RIGHT   77
7#define KEY_LEFT    75
8#define KEY_UP      72
9#define KEY_DOWN    80
10#define KEY_ESC     1
11
12void interrupt (*old_irq9)();
13
14volatile unsigned char keybtable[256];
15volatile char ct1;
16volatile unsigned int ct2;
17
18void interrupt new_irq9()
19{
20    ct1=inp(0x60);
21    ct2=ct1;
22    ct1=inp(0x61);
23    ct1|=0x82;
24    outp(0x61, ct1);
25    outp(0x61, ct1&0x7f);
26    outp(0x20, 0x20);
27
28    if(ct2 >= 0x80)
29    {
30        keybtable[ct2&0x7F]=0;
31    }
32    else
33    {
34        keybtable[ct2]=1;
35    }
36}
37
38int main(void)
39{
40    old_irq9 = getvect(0x9);
41
42    memset(keybtable, 0, 256);
43    setvect(0x9, new_irq9);
44
45    while(1)
46    {
47        if(keybtable[KEY_DOWN] == 1) printf("down\n");
48        if(keybtable[KEY_UP] == 1) printf("up\n");
49        if(keybtable[KEY_LEFT] == 1) printf("left\n");
50        if(keybtable[KEY_RIGHT] == 1) printf("right\n");
51
52        if(keybtable[KEY_ESC] == 1)
53            break;
54    }
55
56    setvect(0x9, old_irq9);
57
58    return 0;
59}

hey thanks! I will give that a try!

Well - maybe some people (me) have to learn things the hard way!

I got to fooling around with calling INT16H - that is how "tricks of the game programming gurus" describes doing it.
One call for check keyboard buffer, if key pressed then get the key
So I got it working - return zero if nothing in buffer or keycode if key pressed
Here's the problem - you can sit there and hold down a key, and it gives you five zeros for every one keycode!

So next step, try the above code

Typically, your handler will just check the status of keys that interest you, and update global variables to reflect the current status of each key.
Example, a global variable named keyUP represents the state of the UP arrow key. Your INT handler will detect changes to the UP arrow key. If it's a key pressed, set keyUP=1. If key released, set keyUP=0.
Now in your main game loop you just check on keyUP and move your objects according to it.
This way you're not bound to key repeat rate, and you separated the keyboard input logic from your main code, which is cleaner.

I took a break on it for a while but is is coming along
Right now I am just using the keys to "toggle" movement to get around the repetition thing - one press starts moving, second stops.
Made patterns for 5x5 numbers to display score
Alien "ships" are 8x8 characters that switch between X and +
Next step is to get the fire button working...will have to worry about collision detection but I have a good idea how to implement this
It rather looks like some old 80s Atari game

I got spoiled on the commodore64 with the sprite graphics...just point to the pattern and supply coordinates as to where it was supposed to be - collisions were also easy to detect...and they could be scrolled off the screen. Here I can make it look like things are scrolling of the screen, but it will take work. Since I am using malloc to make a screen buffer, I can't scroll it outside or program will crash

Also the commodore 64 sprites were 24 x 21 pixels, but when I tried something that size they seemed WAY too big, hence the 8x8 characters

Long story short - I can do way more here than I could do on the commodore, but it also takes a lot more work to make it happen

As a side note, just how fast is C really? I am am almost wondering if I could have done the same thing with QuickBasic. I have no speed problem whatsoever here (but it is a p3 650)

well... long time ago...

When i were playing around "demoscene" world, i have learned that we never use interrupts on dos because they are too slow.

i found this small code lost on hdd that can help you

1/*
2  aPPLiCATiON..: Graphic Library
3  vERSiON......: 1.2a
4  uPDATED......: 13-Jan-2k2
5  rELEASE......: 17-Nov-2k1
6  aUTHOR(s)....: LoStSOul
7  lANGUAGE.....: C/C++ (DOS)
8  nOTES........: Use 80286, 8087/80287 instructions
9  cOMPiLE......: Borland C++ 3.1
10  cOMPiLE Flags: -f287 (something like thiz)
11*/
12
13#include "dtypes.h"
14
15#ifndef GLIB_H
16#define GLIB_H
17
18/* Functions
19  SetVideoMode(word mode);
20  ClearScreen(word dest);
21  PutPixel(int dst, int x, int y, byte color);
22  FlipScreen(int src, int dst);
23  PutPixel(int dst, int x, int y, byte color);
24  WaitVerticalRefresh();
25  SetRGB(byte color, byte r, byte g, byte b);
26  GetRGB(byte color, byte r, byte g, byte b);
27
28  DrawHLine(int where, int x1,int x2,int y1, byte color);
29  DrawVLine(int dst, int x1,int y1, int y2, byte color);
30  DrawLine(int dst, int x1, int y1, int x2,int y2, byte color);
31*/
32
33void SetVideoMode(int mode){
34 asm mov ax, mode
35 asm int 0x10
36}
37
38void ClearScreen(int dst, byte color){
39 asm	mov  cx, 32000;
40 asm	mov  ax, dst
41 asm	mov  es, ax
42 asm	xor  di, di
43 asm	mov  al, [color]
44 asm	mov  ah, al
45 asm	rep  stosw
46}
47
48void FlipScreen(int src, int dst){
49 asm  mov  dx, ds
50 asm  mov  ax, [dst]
51 asm  mov  es, ax
52 asm  mov  ax, [src]
53 asm  mov  ds, ax
54 asm  xor  si, si
55 asm  xor  di, di
56// asm  mov     cx, 16000
57 asm  mov  cx, 6000
58// asm  inc     dx
59 asm  rep  movsw
60 asm  mov  ds, dx

61}
62
63
64void PutPixel(int dst, int x, int y, byte color){
65 asm mov ax, dst
66 asm mov es, ax
67 asm mov ax, y
68 asm shl ax, 6
69 asm mov bx, ax
70 asm shl ax, 2
71 asm add ax, bx
72 asm add ax, x
73 asm mov di, ax
74 asm mov al, color
75 asm mov [es:di], al
76}
77
78void WaitVerticalRefresh() {
79  asm mov dx, 0x3DA
80 lp1:
81  asm in al, dx
82  asm and al, 0x08
83  asm jnz lp1
84 lp2:
85  asm in al, dx
86  asm and al, 0x08
87  asm jz lp2
88}
89
90void SetRGB(byte color, byte r, byte g, byte b){
91 asm mov dx, 0x3c8
92 asm mov al, color
93 asm out dx, al
94 asm inc dx
95 asm mov al, r
96 asm out dx, al
97 asm mov al, g
98 asm out dx, al
99 asm mov al, b
100 asm out dx, al
101}
102
103void GetRGB(byte color, byte r, byte g, byte b){
104 asm mov dx, 0x3c7
105 asm mov al, color
106 asm out dx, al
107 asm inc dx
108 asm mov al, r
109 asm out dx, al
110 asm mov al, g
111 asm out dx, al
112 asm mov al, b
113 asm out dx, al
114}
115
116void DrawHLine(int dst, int x1,int x2,int y1, byte color){
117 asm    mov ax, dst
118 asm	mov es, ax
119 asm	mov ax, y1
120 asm	mov di, ax
121 asm	shl di, 1
122 asm	shl di, 1
123 asm	add di, ax
124 asm	mov cl, 6
125 asm	shl di, cl
126 asm	mov bx, x1
127 asm	mov dx, x2
128 asm	cmp bx, dx
129 asm	jl lp1
130 asm	xchg bx, dx
131lp1:
132 asm    inc dx
133 asm	add di, bx
134 asm	mov cx, dx
135 asm	sub cx, bx
136 asm	shr cx, 1
137 asm	mov al, color
138 asm	mov ah, al
139 asm	ror bx, 1
140 asm	jnb lp2
141 asm	stosb
142 asm	ror dx, 1
143 asm	jnb lp3
144 asm	dec cx
145lp3:
146 asm    rol dx, 1
147lp2:
148 asm    rep
149 asm	stosw
150 asm	ror dx, 1
151 asm	jnb lp4
152 asm	stosb
153lp4:
154}
155
156void DrawVLine(int dst, int x1,int y1, int y2, byte color){
157 asm	mov ax, x1
158 asm    mov bx, y1
159 asm	mov dx, y2
160 asm	cmp bx, dx
161 asm	jl lp1
162 asm	xchg bx, dx
163lp1:
164 asm    mov di, bx
165 asm	shl di, 1
166 asm	shl di, 1
167 asm	add di, bx
168 asm	mov cl, 6
169 asm	shl di, cl
170 asm	add di, ax
171 asm	mov cx, dst
172 asm	mov es, cx
173 asm	mov cx, dx
174 asm	sub cx, bx
175 asm	inc cx
176 asm	mov al, color
177 asm	mov bx, 0x13f
178lp2:
179 asm    stosb
180 asm	add di, bx
181 asm	loop lp2
182}
183
184
185void DrawLine(int dst, int x1, int y1, int x2,int y2, byte color){
186  int dx,dy,sx,sy,k;
187  sx = 1;
188  sy = 1;
189  dx = x2-x1;
190  if (dx<0) {dx=-dx; sx=-1;}
191  dy= y2-y1;
192  if (dy<0) {dy=-dy; sy=-1;}
193//  k= -(dx shr 1);
194  k = -(dx / 2);
195  PutPixel(dst, x1,y1, color);
196  while ((x1 != x2) || (y1 != y2)){
197     if ((k >= 0) && (y1 != y2)){
198	y1 =y1+sy;
199	k = k - dx;
200	PutPixel(dst, x1,y1, color);
201       }
202     else {
203       x1 = x1 + sx;
204       k = k+dy;
205       PutPixel(dst, x1,y1, color);
206     }
207  }
208}
209
210#endif

If anyone is interested...
I have a row of space-invaders type aliens that move across the screen
When you press space bar a "missile" does launch
I can detect collisions and increment/display a score BUT that is all that happens

Next steps:
Detect with which ship the missile has collided so it can be "turned off"
Set it up so more than one missile can be fired at a time

I had to slow the stars WAY down because everything was running on the same clock - stars, aliens, missile all moving at the same speed. Now the stars are like 1/4 and the aliens like 1/2 - only the missile moves at full speed

It is every so slightly jerky - I think that's the screen buffer being copied into video memory. I have a feeling if I were really going to do it right that would have to be an assembly language routine

This is no small programming task (or maybe I am just rusty as heck)

ncmark wrote on 2024-07-13, 19:57:

As a side note, just how fast is C really? I am am almost wondering if I could have done the same thing with QuickBasic. I have no speed problem whatsoever here (but it is a p3 650)

Depends on what you do. Graphics in DOS weren't HW-accelerated (e.g. color-keyed bitblts), so it eats a lot of CPU cycles even for the fastest asm code. You could get away with, say, a turn-based game. But drawing every pixel every frame in interpreted QuickBasic is not going to run smooth on a 650MHz CPU IMO (e.g. an FPS game).

C with a decent compiler isn't supposed to be that different to coding in asm (perf-wise). Maybe even faster than hand-written asm if that asm code was written naively anyways.

This is all assuming your algorithms themselves are fast. Slow algorithms will be slow no matter what language you use.

I am not sure I could think of a better way to do it
I could have two screen buffers maybe, go through and compare, and only write to video memory those that have changed
BUT that would chew up a lot of cycles doing the checking
I guess it is a question how slow is writing to video memory
it speed up a LOT when a made the video buffer versus reading the entire screen and re-writing