Hi, I'm not sure if this is the correct part of the forum for this type of question, but I received amazing support with my previous 'magic pink' question, so I thought I'd dump this here.
What is the best way to take keyboard commands and turn them into sprite movements. Take tetris for example, only instead of rotating the blocks, you only need to move them from right to left. How would one go about doing this?
Here are some ideas I've had, I know they are crummy, but I'm having a major brain-fart here.???

As you can clearly see, I'm having a hard time grasping how to set and move a 'tile/block'. If anyone would care to drop some pseudo, I'd be MUCH appreciative!

Also, you shouldn't specifically say "block.posY = block.posY + 64", but use a constant for 64. In the header file, put "#define BLOCK_SIZE 64" or something similar. Then you can simply use "block.posY = block.posY + BLOCK_SIZE", which is the prefered way to do it. It prevents minor errors such as typos (63 or 65 instead of 64 would cause quite a problem in your case), and is very useful if you ever wish to change the block size. You would then only need to change it in one location (the #define) rather than possibly 100s.

Aside from that, as Birdeeoh said, you need to do bounds checking. I prefer to do pre-checking, though, when available.

psuedo code:

if( key[KEY_LEFT} and ( X - BLOCK_SIZE > left boundary ) ) {
  X = X - BLOCK_SIZE; }

if( key[KEY_RIGHT] and ( X + BLOCK_SIZE < right boundary ) ) {
  X = X + BLOCK_SIZE; }

On second inspection yes you had x and y axis mixed up. I wasn't paying attention to that detail because you had the gist of it correct!

In the followup code you posted, I have a reccommendation, as well as a question about a few possible typos...
For key[KEY_RIGHT] you have the check
if(block.posX - BLOCK_SIZE < RIGHT_BOUNDS)
and for key[KEY_LEFT] you have
if(block.posX - BLOCK_SIZE > RIGHT_BOUNDS)
I think you're missing a LEFT_BOUNDS and/or have your greater/less than signs backwards...

But my general reccommendation would be to do the whole thing this way -

Of course the actual check may be more like
if( block.posX <= LEFT_BOUNDS )
depending on how you actually define your boundries.

For me this is cleaner stylistically/logically, but whatever makes sense to you!

That's going to work, but it it might move the blocks too fast.

My first thought was "what? are you crazy?" then I realized we're talking about a tile-based coordinate system and the example given was tetris style. In that case, indeed moving the block one space over every single frame would be WAY too fast

However your approach lends itself to a problem - have you ever played a tetris-like game where you hold the key down and you KNOW they are relying on the key-repeat because there's a long delay before the block starts moving?

To do this, you'll need to set it up properly first. Perfect function, Allegro has -
void set_keyboard_rate(int delay, int repeat);
Tinkering around for the right repeat rate is up to the programmer. But the delay should most definitely be zero - that is, for a Tetris-type application.

I'd have to make a slight mod to the given code though -

while( keypressed() ) 
{
    switch (readkey() >> 8) 
    {
        case KEY_LEFT:
            // do whatever...
            break;

        case KEY_RIGHT:
            // do whatever...
            break;
    }
}

Notice the big difference between if( keypressed()) and while( keypressed()) - it's very possible the user could press two keys, press the same key twice, or the repeat rate will put two keys in the buffer inbetween two distinct frames. If you only handle one keypress per frame the buffer is going to back up. Gotta empty it out every iteration of your main loop

Good catch Jonny - I wasn't even thinking about the specific application (assuming it is actually tetris-like)

I don't think the keyboard can send anywhere near 50 key presses per second...

Interesting discussion....Birdeeoh, can you explain to me what "readkey() >> 8" really means and how it works in the code you had posted earlier? I understand how that shifts the value of what readkey() returns so that it returns the scancode (or whatever)...but, what is this about the delay and such?

C Bird, X generally represents horizontal positions, and Y represents vertical positions. Z would be depth, but in 2D there is no depth. Although, if you really wanted to mix up your variable names, yes, you could youse Y to represent the horizontal position, and X for vertical, but that's a bad practice. As for the "best" method of preventing the block from going out of bounds, I would suggest a pre-test (as I posted code to above). A post-test also could work, but I think it makes more sense to prevent the block from moving outside boundaries, than allowing it to and snapping it back into boundaries. Either way, this would happen so fast that the user would not notice it had gone out of boundary. It's all up to you and what you feel more comfortable with.

Thanks. I learned a little bit from you there, although it was a little bit more than needed :p Based on what you had said earlier, I thought that you were saying readkey() automatically included some sort of delay mechanism (other than the key_up thing). Thanks for clarifying though.

For one, tetris-style games don't ALWAYS change the speed as the level advances. I remember many a tetris clone where I could rely on the key-repeat action at earlier levels but at later levels I have to start going into turbo-key-press mode manually. And plenty where the auto-repeat was too fast for earlier levels but the only thing to rely on later

But if this is a desirable thing for the programmer...

I always cringe a little regarding locking anything into the logic frame rate without taking into account that the logic rate can be quite dynamic over the course of execution =/

set_keyboard_rate() is such an inexpensive call, it may be worth looking into.

But, I agree a custom delay is quite reasonable - for a case this simple I'd probably hook into keyboard_lowlevel_callback and keep my own motion flag

Are you drawing your sprite directly to the screen?

There are several different ways to draw/output your graphics (e.g. double buffering, page flipping, tripple buffering, etc.). Double buffering is pretty easy to understand. In a few words, you draw everything to the buffer after all your logic occurs each game loop and then draw the buffer to the screen. Before you start drawing to the buffer, do:

clear(buffer)

And then continue your drawing. Make sense?

You are the programmer, how well did it fair to you?

Here's my 2 cents:

Remember, clear(buffer) clears the buffer, so doing clear after drawing something to the buffer will nullify that drawing.

Not the most efficient way but the easiest way would be to store the location of each fallen block or store a 2d array representing the tilemap that is the game board and which spaces are filled.

How else will you do "hit detection" with the currently active block if you don't know the layout of the gameboard?

Then each refresh cycle its quite easy to just redraw the entire gameboard - speed shouldn't be an issue with a game this simple, and with double buffering/page flipping you won't see any screen artifacts.

Steven Silvey:
ahh, makes much more sense now, hehe. Sorry about that. So this is how i should run my drawings (roughly):

// clear the buffer each pass
clear(buffer)
// draw the sprite to the clean buffer
draw_sprite(buffer, currrentBlock, currentBlock.x, currentBlock.y)
// update the screen with the buffer
blit(buffer, screen, 0, 0, 0, 0, SCREEN_W, SCREEN_H)

so here is my modified code: