Hello,

I am developing a roguelike in Ruby using Gosu library. I am still learning and this is a great way to learn Ruby. Gosu has so far satisfied most of my needs, though there are some things that could see improvement. So here I am with feedback.

First, keyboard input constants (KbLeft, for example) - there are many missing, such as brackets ([ ]). Why is that? Also, I would like to be able to determine whether CAPS LOCK and NUM LOCK are active (for switching between movement keys and numbers on numeric keypad, for example). I'd love to see Gosu cover all this by default.

Second, TextInput. The implementation is basic at best and does not meet my expectations, so I was forced to come up with my own solution. I believe that TextInput should be revised; I am hoping for a sane implementation of text field. In the current incarnation, it simply eats keys that could be important for other things.

Next, there are methods for drawing a line or triangle, but none for drawing a single pixel. I find it rather silly to have to use draw_line to draw a single pixel. Just thought I'd mention this.

That is it... for now. I hope to hear from you lot shortly. Well then, back to work for me.

-M.

P.S.: Here is an early screenshot of the said roguelike.

For put_pixel (and get_pixel) and a bunch of other extra draw methods check out texplay http://banisterfiend.wordpress.com/2008/08/23/texplay-an-image-manipulation-tool-for-ruby-and-gosu/

Plugs right into Gosu in a very good manner, and it's also very easy to deploy (as opposed to rmagick)

> there are many missing, such as brackets ([ ]). Why is that?

There are basically constants for buttons that exist on every keyboard around the world. Brackets are not among them. ;) But I think they should be added with the same implication with which I added KbA etc. recently—that they map to the physical key of that name on an US keyboard. (i.e. KbBracketLeft would be 'Ä' in Germany just like KbZ is 'Y' here.)

> Also, I would like to be able to determine whether CAPS LOCK and NUM LOCK are active (for switching between movement keys and numbers on numeric keypad, for example). I'd love to see Gosu cover all this by default.

I haven't yet seen a game that pays respect to those. ;) I vaguely put it on my ToDo list, but not with a very high priority.

> Second, TextInput. The implementation is basic at best and does not meet my expectations, so I was forced to come up with my own solution. I believe that TextInput should be revised; I am hoping for a sane implementation of text field.

It will be revised, but mostly to work with more special cases (IMEs). What did bug you about it precisely for non-exotic text?

> Next, there are methods for drawing a line or triangle, but none for drawing a single pixel. I find it rather silly to have to use draw_line to draw a single pixel. Just thought I'd mention this.

Drawing single pixels is something that should be avoided with OpenGL. In fact a single-pixel Image would be more reliable than draw_line which seems to be doing something different on every driver already. Gosu could create the 1x1-texture internally and offer drawPixel. What are you using it for in the roguelike?

Thanks for your replies.

Yeah, it would be lovely to have a standardized keyboard - after all the ones we have are still using the same design used decades ago. One'd think in the age of IT exposion we'd come up with more cleverly designed keyboards, but no. Oh well. Figure I'll have to come up with an in-game key mapping tool that would let user bind common commands to keys of choice. But not now - for now I'm following the KISS principle: Keep It Simple, Stupid.

As for Caps Lock and Num Lock - there are two kinds of players: those that use arroy keys and those that use numeric keypad instead. Also there are those that use top row to type numbers and again ones that prefer the numeric keypad again. Figure it is kinda pointless to cater to everyone's peculiar preference, but hey, if this can be done, why not? At least it'd be another feature to slap onto the change log. ;)

As for TextInput, it eats keys that are used for tasks not related to the TextInput. Perhaps it would be nice if the list of keys it eats as well as characters it accepts would be nice, you know, for documentation surprises, to avoid any unpleasant surprises. Right now, I'm going blind as a bat. Well, no biggie, I get to learn much more by implementing own solution.

I'll also look into TexPlay something in the future. Thanks for the heads up!

As for TextInput eating too many keys, there is a contribution on this in the Issue Tracker that I will look into soonish :)

>> Also, I would like to be able to determine whether CAPS LOCK and NUM LOCK are active (for switching between movement keys and numbers on numeric keypad, for example). I'd love to see Gosu cover all this by default.

> I haven't yet seen a game that pays respect to those. ;) I vaguely put it on my ToDo list, but not with a very high priority.

Actually, I have seen it some times and it can be useful, i.e. hold down Shift -> run, CapsLock -> toggle walk/run

Indeed, those are handy toggles. Then again it is easy enough to toggle caps=1-caps on each keypress, where initial value is 0. I just have to find the ID for that key...

Anyway, I notice that there are no constants for single and double quotes. I was kinda hoping one'd be able to type a name like this:

Bob "Square" Pants

Guess I should go see about manually adding those missing keys and hope they're the same across different keyboards. Any suggestions or ideas on this?

All available constants are explicitly not and never for typing things. Neither ' nor " is a non-modified key press on my keyboard, and German users are much more likely to want to type Bläßhuhn Schmidt as their name. Even KbZ is not the Z key. Anything you construct will only work in the US and maybe Asian countries when people don't want to use their native language. Suggestion: Don't :)

This is really what TextInput is for, which will even let me do alt+L to type a @ on my German Mac keyboard. Or ´+a to type an á (well not really implemented everywhere yet). If you have problems with TextInput eating specific keys, please be more precise about those so they can be fixed.

I am just touching TextInput and will likely not change anything with regards to what keys it "eats". If you are serious about this feature, please specify which keys, on which OS, should be able to be "saved" :)

Oh, don't worry about it, do what you feel is most appropriate. Should the need for alternative functionality arise, one can always come up with own implementation. Keep up the good work!

My point is that one can not without annoying 100% of non-US users, so I'd like to have a Definite Way Of Doing It :) But thanks.