Closed Viza74 closed 5 years ago
Check the snake example from line 67.
Joystick works like usual with PEEKing at 56320 for Port #2 and at 56321 for Port #1.
Hmm, in which version?... There is no code for joystick neither in master nor develop branch. I copied the input routine from there to begin with :) I can probably implement it trough peek/poke-ing, but IMHO it would be worthwhile to support the mentioned functions "natively" from the language itself.
Sorry, the first line was meant for INKEY input. ;)
For joystick: It works through POKE and PEEK like in BASIC. In my game I do it like this:
game_loop:
j = peek(56320)
if j = 126 then call moveup : goto loop_repeat
if j = 125 then call movedown : goto loop_repeat
if j = 123 then call moveleft : goto loop_repeat
if j = 119 then call moveright : goto loop_repeat
loop_repeat:
goto game_loop
moveup, movedown, etc. are PROCs which move the player sprite. Basically it looks like this:
proc movedown
\yy = \yy + 1
poke 53249, \yy
for t = 0 to \move_speed : next t
endproc
yy is a global variable which contains the current position of the sprite. move_speed is a CONST, which is set to 512 in my game. It slows down the movement. ;)
You're right, they could be implemented directly, but would enlarge the library code and therefore shrinks the available memory.
Thanks for the code!
Well, it is short enough to not need any support in the form of language commands, but not very friendly looking :) Maybe compile time constants can help without using memory?... Something like:
joy2 = peek(_JOY2STATE_)
if joy2 = _JOY2UP_ then blahblah
Although this still could be unfriendly because of the high number of required constants. :-/
It's like I would do it with BASIC, but less GOSUBs. :)
In another issue I asked for the possibility to include source files. This would help me a lot to clean up my code and I could store constants or procs in extra libraries. Casba also mentioned predefined constants there.
INKEY
is nothing but a wrapper around the KERNAL GETIN function which consumes the input and will return 0 the next time it is called.
The documentation ("The INKEY()
function returns the keyboard code of the currently pressed key") is very misleading - I'll fix that.
Joystick support would be a cool feature. Also, another function that checks if a key is currently pressed, would be nice in the future. I think I'll get back to this after v2 is done. :-)
@Viza74 I was also thinking about predefined constants, like _JOY1_
. It would be very cool if someone could write a complete list of constants, like _BACKGROUND_
, _BLACK_
, _YELLOW_
, _SPRITE0POSX_
or whatever, I think there could be hundreds of them. Could be useful to have a look at the cc65 compiler, they've done a similar job already if I remember well.
@oliverhermanni instead of slowing down the code with an empty FOR
loop, I'd suggest you to wait for a new frame in each loop. This way you'll get a smooth 50 fps animation! Check the code here in the Bouncing Ball example:
I'll start with the constants. I already have some of them. Any format you prefer?
Cool, thanks! Any format will do, e.g. a text file or a spreadsheet... Numbers can be decimal or hexa as well.
These features will be implemented later in userland extensions.
inkey() seems to be only fireing once in the frame the key was pressed, which limits its use in games quite a lot. Is there a way to get the current up/down state of a key (and of the joy if we are at it)?