ncurses, c: keypad-home & keypad-end don't work properly

[Ido.Y...@gmail.com]

Hi,
I have the following c code that determins user input for movment:

switch (getch()) {
case KEY_UP:
<snip>
break;

case KEY_DOWN:
<snip>
break;

case KEY_LEFT:
<snip>
break;

case KEY_RIGHT:
<snip>
break;

case KEY_HOME:
<snip>
break;

case KEY_PPAGE:
<snip>
break;

case KEY_END:
<snip>
break;

case KEY_NPAGE:
<snip>
break;
}

Now almost all of these keys function as expected, except KEY_HOME and
KEY_END:
they are not triggered by the home/end keypad keys (only the other
home/end key above the arrow keys).

Any idea what's wrong?

Thanks in advance,
Ido.

[Martin Read]

Ido.Y...@gmail.com wrote:
>Now almost all of these keys function as expected, except KEY_HOME and
>KEY_END:
>they are not triggered by the home/end keypad keys (only the other
>home/end key above the arrow keys).

Try checking for KEY_A1 (top left of keypad) and KEY_C1 (bottom left of
keypad).
--
Martin Read - my opinions are my own. share them if you wish.
\_\/_/ http://www.chiark.greenend.org.uk/~mpread/dungeonbash/
\ / "tempted white eyes blinded by the night hollow like the towers from the
\/ inside laura's a machine she's burning insane" fields of the nephilim

[Ido.Y...@gmail.com]

Martin Read wrote:
> Try checking for KEY_A1 (top left of keypad) and KEY_C1 (bottom left of
> keypad).

Doesn't work either :(. getch() gets a keypress (the loop get one step
forward), but it isn't recognised as KEY_A1 or KEY_C1.

Another idea perhapse?

Ido.

[Ido.Y...@gmail.com]

Ido.Y...@gmail.com wrote:
> getch() gets a keypress (the loop get one step
> forward), but it isn't recognised as KEY_A1 or KEY_C1.

I had another idea, and it brought some strange results: i tried to
print the int value of the char being pressed- the home above the arrow
keys give 262 (as it should), the end above the arrow keys gives 360
(also as it should) but the home & end on the keypad _both_ give the
same value of 126!

Strange...How can i solve this problem?

Ido.

[Radomir 'The Sheep' Dopieralski]

At 31 Jul 2006 23:50:57 -0700,
Ido.Y...@gmail.com wrote:

Have you tried to enable the numpad mode in ncurses?

--
Radomir `The Sheep' Dopieralski

"Computer Science is no more about computers than
astronomy is about telescopes." [Edsger Wybe Dijkstra]

[Ido.Y...@gmail.com]

Radomir 'The Sheep' Dopieralski wrote:
> Have you tried to enable the numpad mode in ncurses?

Do you mean keypad mode? I have seen no mention of 'numpad' in
ncurses.h (keypad is on BTW)

Ido.

[Radomir 'The Sheep' Dopieralski]

At 31 Jul 2006 23:59:46 -0700,
Ido.Y...@gmail.com wrote:

Yes, sorry.
Have you tried it with different terms?

For example, linux console, xterm, vt100...

It may be a question of bad terminal definition...

[Ido.Y...@gmail.com]

Radomir 'The Sheep' Dopieralski wrote:
> Have you tried it with different terms?
> For example, linux console, xterm, vt100...
> It may be a question of bad terminal definition...

Bravo! The Sheep to the rescue once more...
I've tried it with xterm instead of the GnomeTerminal I normally use
and it works now.

Thanks a lot to both of you guys.

Ido.

[Yendor]

look at

http://roguelike.cvs.sourceforge.net/roguelike/arogue5.8/mdport.c?revision=1.3&view=markup

if you want to see how i added keypad support to the origianl versions
of rogue. it is fairly involved because ncurses, pdcurses and various
terminal emulators do things slightly differently (windows version of
pdcurses has best support). there is a function md_getchar(WINDOW *win)
that returns the next keystroke while converting all keypad entry into
standard rogue movement keys. It handles the standard curses defined
keystrokes or attempts to decode the raw keystrokes if the curses
implementation fails to process the key.

[Ido.Y...@gmail.com]

Yendor wrote:
> if you want to see how i added keypad support to the origianl versions
> of rogue. it is fairly involved because ncurses, pdcurses and various

> terminal emulators do things slightly differently.

Thanks for the tip, it is surley more portable then my solution, but
atm i want to frist get the basic game complete before I worry about
such things. After all- it can always be changed later, and the
keyboard input routine are kind of used as a black box for the rest of
the code so I'd wager it wouldn't be more difficult to add it later
then it is now.

Ido.

[Ray Dillinger]

Ido.Y...@gmail.com wrote:

> Thanks for the tip, it is surley more portable then my solution, but
> atm i want to frist get the basic game complete before I worry about
> such things. After all- it can always be changed later, and the
> keyboard input routine are kind of used as a black box for the rest of
> the code so I'd wager it wouldn't be more difficult to add it later
> then it is now.

The tip we should all take to heart though is that if we want to
make a portable game we need to "wrap" the input routines. Something
needs to have a chance to postprocess what Curses gives you and make
odd bits of it into the codes your game uses (and while we're at it,
give the user the chance to remap inputs to different keys).

I dunno though; there is some joy in nonportable input if it lets
you distinguish between, say, keypad-9 and keyboard-9. Or check the
shift state when somebody hits an arrow key. Etc... messing with
raw IOCTLs and hardware scancodes directly gets you stuff you can't
do portably. But it also multiplies the number of ways things can
go wrong, and most roguelikes that use more than just curses-
compatible input routines also manifest some annoying bugs when
used with a different keyboard layout.

Bear

[Ido.Y...@gmail.com]

Ray Dillinger wrote:
> The tip we should all take to heart though is that if we want to
> make a portable game we need to "wrap" the input routines. Something
> needs to have a chance to postprocess what Curses gives you and make
> odd bits of it into the codes your game uses (and while we're at it,
> give the user the chance to remap inputs to different keys).

Sure, in production code, after I've implemented all the basics, not in
a project i started 3 days ago...
When (if) I'll get all the basic functionality coded, I'll start
thinking about things like that.

Ido.

[kalikiana]

I encountered similar problems with "special" keys. Under a linux
terminal the 'end' key behaved like an 'arrow left' key. And under
windows sometimes 'page up' and 'page down' let the console window
crash (disappear). By the way, I'm using my own wrapper. And I did not
yet find a way to fix this, so I decided to leave 'special' keys for
now and concentrate on numpad and letters only.