I find I prefer to use the WASD setup for moving around in games*, but I'd like to actually type "W", "A", "S", and "D" on the function code instead of "30", "31", and "32", and... I keep forgetting what the code for "W" is.
Yeah, there is a way to look up the codes in the GLBasic SDK, which is convenient, but it would be even more convenient not to have to use those numbers (preferably not even set up pointers for them).
* Well I prefer gamepads even more, but I have to first learn how to set up ways for the player to map controls in the options.
EDIT: I have a program to help with listed on this post. (http://www.glbasic.com/forum/index.php?topic=8759.msg74581#msg74581)
You could try INKEY$() !
Answer is same as for Your other topic - about sprites..
You can replace function parameters with variables so:
CONSTANT mykey_W% = 17
Global mykey_A% = 30
if Key(mykey_W%)
''something
endif
if Key(mykey_A%)
''something
endif
You can use in example
global key_L = key(203)
global key_R = key(205)
global key_U = key(208)
global key_D = key(200)
global key_Fire = key(57)
in the loop
/.../
if key_L // In the if coomands, if you don't put nothing GLbasic want say "true" , you can put key_L=false or key_L it's
// the same... obviously, if you need check like false put key_L=false
do something
endif
and so on....
/.../
Why is such as inconvenience to look-up or store global constants for the key-code values because they would only be used once in code?
Quote from: MrTAToad on 2012-Nov-28
You could try INKEY$() !
Is that for mapping a command to a specific key, or just for pressing any key? The info on the tutorials make it look like the latter, while I'm looking for the former.
Quote from: matchy on 2012-Nov-28
Why is such as inconvenience to look-up or store global constants for the key-code values because they would only be used once in code?
For readability, for one thing. GLBasic is a lot more readable than C++ for the most part, but having to enter a code for keys instead of "KEY_X" is not one of those things.
If you want the latter, then you will need to check all scan codes unfortunately.
Quote from: MrTAToad on 2012-Nov-29
If you want the latter, then you will need to check all scan codes unfortunately.
What I mean is a way to write a code so I wanted the program to read me pressing "A", I could actually write "A" as the variable, not "30".
Can that be done with GLBasic, preferably without having to use a pointer (which would mean I'd still have to use the key code at some point)?
I think about a way. Might add constants in a file in samples/common for this.
Quote from: Kitty Hello on 2012-Nov-29
I think about a way. Might add constants in a file in samples/common for this.
Correct me if I'm wrong, but do you mean a file that just provides pointers for all the key codes, and a program just has to call that file?
Some sort of scan code to ASCII (or text is needed). Its not hard (just need an array of strings) - the problem is describing things volume control, mail programs etc etc
Quote from: MrTAToad on 2012-Nov-30
Some sort of scan code to ASCII (or text is needed). Its not hard (just need an array of strings) - the problem is describing things volume control, mail programs etc etc
Okay, I'm honestly lost there. Could you spell out what that means?
Also, I'm correcting a mistake on a previous post. I claimed C++ let you type in key names, and forgot that was a feature of Allegro for C++, not C++ by itself.
Take a look at this thread http://www.glbasic.com/forum/index.php?topic=8734.0 (http://www.glbasic.com/forum/index.php?topic=8734.0), Siatek's very useful input program. If it is not exactly what you are after then at least it will save you typing out all the keycodes & naming them :D
Also you mentioning pointers confuses me a bit, do you mean variables?. As far as I recall a "Pointer" points to the contents or the location of a variable, whereas a variable is just a name assigned to a value you want to store/modify (both examples simplified as could easily fill a page with a full definition of both).
Lee
Quote from: fuzzy70 on 2012-Nov-30
Take a look at this thread http://www.glbasic.com/forum/index.php?topic=8734.0 (http://www.glbasic.com/forum/index.php?topic=8734.0), Siatek's very useful input program. If it is not exactly what you are after then at least it will save you typing out all the keycodes & naming them :D (1)
Also you mentioning pointers confuses me a bit, do you mean variables?. As far as I recall a "Pointer" points to the contents or the location of a variable, whereas a variable is just a name assigned to a value you want to store/modify (both examples simplified as could easily fill a page with a full definition of both). (2)
Lee
1. I'm looking at that link. I'll see if it works.
2. Well perhaps "pointer" isn't the right term then. It's whatever term would apply to seeking an alternate name for this.
Problem with scancode vs. keycaption is, that you dont know what keycaption which scan code has. For example:
On us/uk keyboard key(44)=z and key(21)=y
But on ger keyboard key(44)=y and key(21)=z
Of cause you could solve this when you know the keyboardlayout, but thats nothing that you can do in native GLB.
Thats why you have ascii codes and scancodes and it would be a really bad idea to drop one of them, its horses for causes!
Generally i dont really understand the problem in typing a few numbers (in a good game you wont type them in code at all, but read them from a ini, cause you allow users to change keys), if you have problems to work with key codes (at least big enough problem to start a thread about it), how do you code, what do you do, when you hit a real problem?
There is an example project in _Projects that may be what you are looking for - it has a scancode to text array. Unfortunately it needs a bit of a tweek to slow things down.
Quote from: MrTAToad on 2012-Nov-30
There is an example project in _Projects that may be what you are looking for - it has a scancode to text array. Unfortunately it needs a bit of a tweek to slow things down.
Do you mean as part of the the samples that come with the SDK download?
A software keyboard may be another thing because it will at least be the same array for all platforms.
Quote from: matchy on 2012-Nov-30
A software keyboard may be another thing because it will at least be the same array for all platforms.
Would those integrate with the program code somehow?
Quote from: Lord_TNK on 2012-Nov-30
Quote from: MrTAToad on 2012-Nov-30
There is an example project in _Projects that may be what you are looking for - it has a scancode to text array. Unfortunately it needs a bit of a tweek to slow things down.
Do you mean as part of the the samples that come with the SDK download?
Thats right
Quote from: MrTAToad on 2012-Dec-01
Quote from: Lord_TNK on 2012-Nov-30
Quote from: MrTAToad on 2012-Nov-30
There is an example project in _Projects that may be what you are looking for - it has a scancode to text array. Unfortunately it needs a bit of a tweek to slow things down.
Do you mean as part of the the samples that come with the SDK download?
Thats right
It's the one in the folder "KeydefMenu", or another one?
Thats the one...
Quote from: MrTAToad on 2012-Dec-01
Thats the one...
Okay, that thing. It's just a game, and the code still uses key codes. So it's not what I had in mind.
EDIT: Although there's something in the "Common" folder. I'm checking that out.
Quote from: kanonet on 2012-Nov-30
(in a good game you wont type them in code at all, but read them from a ini, cause you allow users to change keys)
Thats actually a great idea even in non-game programs also.
And store builtin key definitions into an array.
On that note, is there a good tutorial on how ini files work? Because the help files aren't really clear.
The help file is not clear? Ok i dont know about the English one, but the sample in the German help file shows everything that is needed and i guess in English its the same? Anyway, the inis are really easy to use:
// An ini looks like this:
[section1]
key1=value1
value1 is the information that you want to store there, section and key1 are the the information that you need to find that value when you load it. A ini file can contain as many sections as you want, but every section needs a unique name (in the same ini file). Each section can have as many keys as you want, but each key has to be unique in the same section. Each key can be empty or has exactly one value. Everything behind the '=' is the value, it can be numbers strings,... but maybe its better to avoid escape codes (not sure).
// write to ini:
KILLFILE "test.ini" // just in case there is an old ini with this name -> delete it
INIOPEN "test.ini" // open the ini so we can read/write it
LOCAL attackkey% = 57 // lets say you want to store your attack key (in my sample its 57 = space bar)
// store your value in the ini, by telling which section and key you want it. you need to remember that section+key if you want to reload it later
INIPUT "section1", "key1", attackkey // you can do as many INIPUT now as you want; btw it want value to be a string, but if you input a number it will automatically convert it for you
INIOPEN "" // finally stop working on this ini, write it to HDD and close it
After doing this your ini test.ini will look like this:
[section1]
key1=57
We can now read it into your program and use it:
// read ini:
INIOPEN "test.ini" // open the ini so we can read it
LOCAL attackkey%
// now read your key, you need to know from what section and key you want to read (and you can add a parameter what value you want to return if the section or key not found)
attackkey = INIGET$("section1", "key1", 28) // it returns an string, but it automatically converts it into a integer if you do it like this
INIOPEN "" // again close the ini when you have read all the values that you want
// later in your program use the value that you just have read:
IF KEY(attackkey) THEN DoSomething()
Its easy, right?
Btw. I expanded the keydef sample to work with mouse/keyboard/joystick, work with primary and secondary key, support displaying the names of the defined keys (for us and ger keyboard layout) and being encapsulated and easy to use, maybe you want to have a look at this:
http://www.glbasic.com/forum/index.php?topic=5695
@kanonet: So let me see if I got this right.
The first sample you used is a template for an ini file, or at least an ini file for using pointers and alternate commands.
The second is how you create an ini file. I don't think the help tutorials tell that, or at least not in a way as clear as you stated. So I guess a program includes that as a function to make such files when needed?
The third is what the ini file is according to the template. Is the [section1] thing to note different sections in an ini file to call, or is that just a variable name you chose?
And the fourth is to read it, and I assume a full program will include functions for both making them and reading them.
yes 1st is just to show you how an ini file looks like. [section1] just shows you that you in a section, you can have multiple of them, most times to keep thinks easier to organise/read. Example, lets say you write all your game settings into one file:
[options]
screenx=640
screeny=480
fullscreen=1
[keys]
attack=57
forward=200
backward=208
So you dont need to hardcode this, you can easily read/write it to ini, and the player can change it (in ini, or in options menu if you code one). You need to have a section, even if your file just contains one. For more information about ini files check this: http://en.wikipedia.org/wiki/INI_file
Correct 2nd is a tiny example how you could write an ini, 3rd is how this ini will look like, that my sample produces and 4th is a short sample how to read and use this particular ini. full program will at least need a read function, but if you allow the user to change keys in a options menu, you may want to write them back in the ini (so he does not to change keys after next restart again), so you will also need a write function. Its really easy, just play around with the code and write/read some fun nonsence ini files, just for practice. The best way to learn coding is just to test everything on your own, you will make mistakes (sometimes) but you will learn from them and dont forget what you have learned.
Btw if you have a look at that keydeftingy that i linked at the end of my last post, its designed to let the user select controls and read/write them to ini (you will have to stick it into your general ini saving routine).
Thanks for the help. Now I would use the file you linked, but I have a US keyboard, so I'll have to do a lot of tweaking anyway.
Also, I'm not afraid to experiment (there are a few things I'm trying to do with my programs right now), just that I want to know what's even possible with this language, and want to avoid screwing up my system as much as possible.
No problem the helpful community is one of the strong points of this language, so im happy when i can help too.
My keydef has ini for german keyboard layout and one for us. So just use the us one instead of the german and you will need to do less tweaking. Btw i just realised that there is a huge overhead in my code so i will do a rewrite in next weeks.
Quote from: kanonet on 2012-Dec-01
No problem the helpful community is one of the strong points of this language, so im happy when i can help too.
My keydef has ini for german keyboard layout and one for us. So just use the us one instead of the german and you will need to do less tweaking. Btw i just realised that there is a huge overhead in my code so i will do a rewrite in next weeks.
Well get back to us when you do, because I think we all prefer simpler code for any task.
Okay, I figured out how to use "INKEY$()" to make a program accept w, s, a, and d. I just can't figure out how to make the program accept their input in a function. And the help for the SDK really doesn't tell me. Heck, the program won't even compile (as to most of the program samples in the tutorial, but that's for another thread).
Here is the program code. I want to replace the inputs for KEY (17), (30), (31), and (32) with the letters, and "spacebar" for (57).
SETCURRENTDIR("Media") // go to media files
SETTRANSPARENCY RGB (244, 124, 0)
LIMITFPS 60
LOADSPRITE "whatever.bmp", 5 //Any picture will do. I used a 32x32 png.
GLOBAL shield% = 5
GLOBAL spritex = 128
GLOBAL spritey = 128
GLOBAL spritespeed = 1
GLOBAL w$ = INKEY$()
GLOBAL a$ = INKEY$()
GLOBAL s$ = INKEY$()
GLOBAL d$ = INKEY$()
GLOBAL spacebar$ = INKEY$()
WHILE KEY (01) = FALSE
MovePlayer()
DrawScreen()
WEND
FUNCTION MovePlayer:
LOCAL dirx, diry
IF KEY (17)
diry = -1
ENDIF
IF KEY (30)
dirx = -1
ENDIF
IF KEY (31)
diry = 1
ENDIF
IF KEY (32)
dirx = 1
ENDIF
spritex = spritex + (spritespeed * dirx)
spritey = spritey + (spritespeed * diry)
//turns the spacebar into a dash button
IF KEY (57) THEN spritespeed=3
IF NOT KEY (57) THEN spritespeed=1
IF spritex < 0 THEN spritex = 0
IF spritex > 608 THEN spritex = 608
IF spritey < 0 THEN spritey = 0
IF spritey > 448 THEN spritey = 448
ENDFUNCTION
FUNCTION DrawScreen:
DRAWSPRITE shield, spritex, spritey
SHOWSCREEN
ENDFUNCTION
you will need to define a huge list which is slow.
i think what youre trying to do is much harder than it sounds...or time consuming rather.
have you tried KEYCODE tool?
you need to map out your key codes.....the keyboard sends these...not letters.
Quote from: Hemlos on 2012-Dec-04
you will need to define a huge list which is slow.
i think what youre trying to do is much harder than it sounds...or time consuming rather.
have you tried KEYCODE tool?
you need to map out your key codes.....the keyboard sends these...not letters.
I know about the keycode tool. I just think it's less confusing to type out the name of a key than try to remember the code for all of them.
Plus I can just post a list of "INKEY$()" strings and use that as an extra file for all my programs, so it would just be work right now, not later.
I only see a couple of problems for that approach.
(http://upload.wikimedia.org/wikipedia/commons/2/25/KB_United_States_Dvorak.svg)
(http://upload.wikimedia.org/wikipedia/commons/b/b9/KB_France.svg)
(http://upload.wikimedia.org/wikipedia/commons/3/36/KB_Germany.svg)
(http://upload.wikimedia.org/wikipedia/commons/e/e1/KB_Svorak.svg)
Look on these pictures. with some of these keyboards your game would be controlled with keys all over the keyboard. This is exactly why all computers uses scan-codes to control what keys are pressed instead of a letter. This is just they way things work when programming low-level things.
It starts with 1 in the upper left and then goes straight over the whole keyboard (with some exceptions here too ofcourse), row after row. This way the keys will be on the same location for almost all keyboards. You will still get problems in some areas but this is why you always should have a way for the user to change keys themselves.
So I'm affraid the easiest way is to just get used to the scancode way like all other gameprogrammers have been the last 40 years :-) Well obviously not games like nethack that has about three-four functions for each button on the keyboard...
1. I didn't realize that keycodes were the same, even if the names of the keys were not.
2. I'd still like to know how to do it anyway, since that would mean I know more about the language and programming.
3. Even then, the games I make will have button customization, since that will just be convenient for the players.
Quote from: Lord_TNK on 2012-Dec-041. I didn't realize that keycodes were the same, even if the names of the keys were not.
I did tell you about this on the 1st page of this thread. :P
Quote from: kanonet on 2012-Nov-30
Problem with scancode vs. keycaption is, that you dont know what keycaption which scan code has. For example:
On us/uk keyboard key(44)=z and key(21)=y
But on ger keyboard key(44)=y and key(21)=z
Sorry. :-[
Quote from: kanonet on 2012-Dec-05
Quote from: Lord_TNK on 2012-Dec-041. I didn't realize that keycodes were the same, even if the names of the keys were not.
I did tell you about this on the 1st page of this thread. :P
Quote from: kanonet on 2012-Nov-30
Problem with scancode vs. keycaption is, that you dont know what keycaption which scan code has. For example:
On us/uk keyboard key(44)=z and key(21)=y
But on ger keyboard key(44)=y and key(21)=z
Sorry. :-[
Well I honestly didn't quite know what that meant a few days ago. Still learning this, but also glad you're all here to help.