Noob: Allegro Failure.

[Rhys]

Hi, this is my first real post, and my first thread.

Tonight I started my first online Allegro tutorial, I haven't written my own source code yet, I'm not that far in. I've got a few functions down and what not, but I've come across a problem.

The program that I'm running, and I have copied from a website is having a problem. (I know, it's a cheap way to get stuff done, but I'm just assesing it to learn, and it's working.) What I'm trying to achieve is the ability to move text around a black screen. The text is red. once I'd copied it directly from the web page it worked well, all I've done is changed the speed / rest(x); of the moving character. The problem I'm having is the character turns bright green and leaves a brown trail behind itself as it moves across the screen.

I had the same problem when I first changed the movable test from "@" to "MOVE ME", when I'd move the text down it would leave a train of red behind, as I retraced my steps up the page it would reverse itself, basically eating the trail it left.

If anyone has any tips, or knows whats wrong that'd be appreciated.

Code for reference:

Code: Select all

#include <allegro.h>

int x = 10;
int y = 10;

int main(){
 
    allegro_init();
    install_keyboard();
    set_gfx_mode( GFX_AUTODETECT, 640, 480, 0, 0);
    
    while ( !key[KEY_ESC] ){
    
        clear_keybuf();
        
        acquire_screen();
        
        textout_ex( screen, font, " ", x, y, makecol( 0, 0, 0), makecol( 0, 0, 0) );
        
        if (key[KEY_W]) --y;        
        else if (key[KEY_S]) ++y;    
        else if (key[KEY_D]) ++x;
        else if (key[KEY_A]) --x;

        textout_ex( screen, font, "V", x, y, makecol( 255, 0, 0), makecol( 0, 0, 0) );
        
        release_screen();
        
        rest(25);

    }    
    
    return 0;
    
}   
END_OF_MAIN(); 

[/size]

[K-Bal]

I'm not so familiar with Allegro but you should clear the screen on every frame, so that everything from the last frame is deleted before drawing the new one.

[Rhys]

I'm not so familiar with Allegro but you should clear the screen on every frame, so that everything from the last frame is deleted before drawing the new one.

How should I do this, it makes sense so I'll try it. Does it have anything to do "screen_keybuf();" ?

[K-Bal]

I'm not so familiar with Allegro but you should clear the screen on every frame, so that everything from the last frame is deleted before drawing the new one.

How should I do this, it makes sense so I'll try it. Does it have anything to do "screen_keybuf();" ?

Well, I don't know how this works in Allegro but you should just stick with your tutorial and see what happens next

Btw, I'm using SFML which hast a beautiful object orientated design and is easy to work with. Check it out if you haven't decided on your library of choice yet

[Moosader]

clear_keybuf(); has to do with the keyboard I believe (I never use it, actually. It's not that necessary)

Oh, I see, you're drawing blank space where it was so it doesn't do that. No yeah, do this:
(uh, double buffering for the win)

Code: Select all

#include <allegro.h>

int x = 10;
int y = 10;

// Good to keep these as variables so if you want to change it later, it will only
// have to be updated here.
const int SCREEN_WIDTH = 640;
const int SCREEN_HEIGHT = 480;

int main(){
    allegro_init();
    install_keyboard();
    set_gfx_mode( GFX_AUTODETECT_WINDOWED, SCREEN_WIDTH, SCREEN_HEIGHT, 0, 0);
    
    // it's ALWAYS good to draw to a buffer, instead of directly to the
    // screen!  This cuts down on flickering
    BITMAP *buffer = create_bitmap( SCREEN_WIDTH, SCREEN_HEIGHT );
    // Loading images will be like this:
    // BITMAP *image = load_image( "filename.bmp", NULL );
   text_mode(-1);  // gets rid of the black background of the text
   
    while ( !key[KEY_ESC] )
    {      
        if (key[KEY_W]) --y;       
        else if (key[KEY_S]) ++y;   
        else if (key[KEY_D]) ++x;
        else if (key[KEY_A]) --x;

        //Get ready to draw
        acquire_screen();
        vsync();
           
        // Background color
        rectfill( buffer, 0, 0, SCREEN_WIDTH, SCREEN_HEIGHT, makecol( 125, 125, 125 ) );
        
        // Using textout will keep the background color, but this will
        // draw without the black background to the text
        textprintf_ex( buffer, font, x, y, makecol( 255, 0, 0 ), -1, "V" );
       
        // Draw the buffer to the screen
        blit( buffer, screen, 0, 0, 0, 0, SCREEN_WIDTH, SCREEN_HEIGHT );
        // Release the screen
        release_screen();
        // Clean off the buffer for the next draw (will trail if this isn't here)
        clear_bitmap( buffer );
       
        rest(25);

    }   
   
    // Free up your bitmaps after the game is done, otherwise you'll have
    // memory problems.  Research Dynamic Arrays if you don't understand this.
    clear_bitmap( buffer );
    return 0;
}   
END_OF_MAIN(); 

[sparda]

You should really avoid using acquire_screen() (AKA acquire_bitmap(screen)). I mean, I'm sure it's pointless to stress in this example, but for good habit (and taste), I would advice against it. Mostly notably because of the low-level nature of this function, and how it may cause cross-platform problems, if you'd ever want to go fully portable in a huge project, that is.

acquire_bitmap() indirectly causes a mutex lock under both X11 (linux, Unix), and DirectX, and further there is no way of fully determining which graphic procedures require a locked or unlocked state prior to its call in a cross platform way, as systems vary. For example, under DirectX there is automatic unlocking while under X11, there is not. The problem is that these lock prerequisites vary from function to function under the allegro code-base; hence, you should avoid any cross-platform incompatibility, even more so when when there is no lock specificity in the preconditions to a function.

I just though this was important to mention since one of Allegro's strong points is its portability.

[Moosader]

You should really avoid using acquire_screen() (AKA acquire_bitmap(screen)). I mean, I'm sure it's pointless to stress in this example, but for good habit (and taste), I would advice against it. Mostly notably because of the low-level nature of this function, and how it may cause cross-platform problems, if you'd ever want to go fully portable in a huge project, that is.

acquire_bitmap() indirectly causes a mutex lock under both X11 (linux, Unix), and DirectX, and further there is no way of fully determining which graphic procedures require a locked or unlocked state prior to its call in a cross platform way, as systems vary. For example, under DirectX there is automatic unlocking while under X11, there is not. The problem is that these lock prerequisites vary from function to function under the allegro code-base; hence, you should avoid any cross-platform incompatibility, even more so when when there is no lock specificity in the preconditions to a function.

I just though this was important to mention since one of Allegro's strong points is its portability.

What else do you use then? Or is it just not required at all?

[sparda]

What else do you use then? Or is it just not required at all?

Well, to my knowledge it is not required at all. As a matter a fact it can be fatal to a poor program, in some cases. It can also cause lockups when it comes to non-graphic specific functions, because of the locking thingy I mentioned earlier. You should never use it on a memory allocated(AKA create_bitmap), as you'll find that it has no effect whatsoever.

I personally don't use it, since I'll want you guys to play my games, and I'm on Mac, while most of you are on windows (window sluts!). I simply a combination of clear() or clear_bitmap(), vsync() and some simple callbacks.