1. Huge issue is al_convert_mask_to_alpha. It should be done once right after the bitmap is loaded or created. That function goes through every pixel. Does a comparison to your color and sets alpha to zero if there is a match. EVERY pixel. Very time consuming.
2. is target restored? Don't set it to another bitmap if not restored back to original bitmap.
3. SEPARATE logic and drawing. Logic timing should be consistent. Drawing should be done when it can and when all logic is done.

My preferred order
1. process all input
2. do all logic based on current input states (set to process consitently at 30 times per second using a timer).
3. do all drawing when all done with logic (FPS is based on how many times I can still draw the screen per second)
4. goto 1.

Thanks guys. I thought I was probably calling a single call over and over. I did the same thing with random number seed.

Daniel,
I have a few lines of setting target to buffer and back to target etc. I'm not sure why. If I take out the "target" bitmap, the process doesn't work. My limited logic tells me I should be able to make the buffer the target bitmap and run with it, but if I don't flip back and forth, some of the scaling commands don't work. In short, I don't understand how that process works so I'm dropping copied code and if it works I just go with it. I'm sure I'm misusing at some level.

Thx all,

So Daniel, I don't necessarily need a "target" bitmap?

I'm trying to understand why one would need to write to buffer_one, then write buffer_one to buffer_too, then buffer_too to the display? Seems like buffer_too is an extra step.

Can you give me an example of why you would need to do that?

Thanks Daniel,

One more question concerning buffers. I've been drawing to a buffer bitmap and then flipping it to the display. Are you saying the display already has a buffer by default? Or is drawing to the display literally drawing to the screen directly?

Thanks.

Daniel thanks for the insight. I think I'm going to try Option 2.

All,

Ok, I moved my al_convert_mask_to_alpha() to where I initialize the bitmap files. I removed all references of going back and forth with target / buffer bitmaps. The visual aspect of the program looks great. The moving star background works well. However, my lag is still present and it grows longer between clicks.

My question is, is there something that would cause the event queue to lag? I’ve put in std::cout print outs at different locations in the program. Granted not scientific or exact, but it does expose variations. At program start, each time through the game loop the timer is checked (timer event) so looking at my output I have a one to one condition, maybe an occasional one to two.

“Loop Check”
“Timer Check”
“Loop Check”
“Timer Check”
“Loop Check”
“Timer Check”

(Loop check is located just underneath the while() statement. The Timer check is the first item in the if(event.type == ALLEGRO_EVENT_TIMER) section)

Then as I start clicking as part of the game, the gap between them grows to one Timer Check to five or six Loop Checks. If I stop clicking after 5-10 sec it goes back to one to one. It’s almost like the event queue, which would include key down and mouse clicks slows down or doesn’t samples as fast. I must point out, if you have the patience, the games functions as it should. It's just the mouse click results lag horribly.

While the star code earlier in the thread may not be problematic, when I comment it out my lag issue goes away. Maybe it’s the bitmaps being used with in the star code.

Any ideas / comments are welcome. If I don’t hear back, have a great 4th holiday.

You're likely drawing once for every mouse or keyboard event. That's a no-no. Post your event handling code.

ALL drawing functions draw to the target bitmap. What's your target? Is it the display's back buffer or your buffer?

If you don't use a buffer and always draw to the display then you don't need to mess with the targeting.

If you use a buffer and want to draw to that buffer then you need to change the current target to that buffer. Draw to the buffer. Then change the current target again back to previous target (the display's back buffer). Then draw your buffer to the display.

Scaling is tricky if you don't use a buffer. You would have to scale each bitmap drawn to the display and calculate the scaled position. Or use transforms, which is what the scale functions use in the background.

I find it so much easier to use a buffer and scale it once after I draw everything to it.

There's a bit of confusion on 'target' especially. It's just a bitmap. By default it is the display's back buffer bitmap.

I didn't make the names

Target = Destination
Buffer = temp storage

In allegro 4 and previous, you could specify the target as a parameter
void blit(BITMAP *source, BITMAP *dest, int source_x, int source_y, int dest_x, int dest_y, int width, int height);

in this function dest is the target bitmap of the draw call.

In allegro 5, target is implied
void al_draw_bitmap(ALLEGRO_BITMAP *source, float dx, float dy, int flags);

Like I said, you don't need your bitmap if you draw directly to the display back bitmap.

void display_print(CARDS Cards[],int nError,int nGameOver,int nTurnPos,int nPlayer[])
{
  // draw to display's back buffer
  star_background();
  display_verbiage(nError,nGameOver,nTurnPos,nPlayer);
  draw_cards(Cards);

  // swap front and back buffers
  al_flip_display();
}

Couple things I see

I'll preface this by saying this is my opinion.

Your braces don't match. The end brace for timer is labeled // end while. That puts the draw call inside the timer code.

    if(event.type == ALLEGRO_EVENT_TIMER)
    {
      if(bDraw == true)
          nRest--;
      if(bDraw == true && nRest == 0)
        bDraw = false;
    } // end timer

    // Never link drawing to a timer. NEVER. Timers are for logic. 
    display_print(Cards,nError,nGameOver,nTurnPos,nPlayer); 
    // drawing should happen every time something changes on the screen. 
    // a boolean dirty variable can be used if it's dirty and needs a refresh
    // that should be set by the logic not the timer. dirty = (did_something_change)

That is probably most of your lag problem ... maybe. I don't like waiting for events.

the other lag I see is that you are doing a ton of logic during an event. That can't be helped unless you make some variables to store your input.

The timer should regulate the logic not your input events. That way the logic is running at the same speed regardless the computer speed. Input events are there to set your keyboard/mouse state variables (if you had them). They should be short and fast. They should not to tie up processing speed by doing logic in the events themselves.

All you need is 2 extra variables

bool mouse_is_being_pressed = false;
bool mouse_was_pressed_since_i_last_did_logic = false;

These are set in your mouse button up/down events.

if(event.type == ALLEGRO_EVENT_MOUSE_BUTTON_DOWN)
{
    mouse_is_being_pressed =
    mouse_was_pressed_since_i_last did_logic = true;
}
if(event.type == ALLEGRO_EVENT_MOUSE_BUTTON_UP)
{
    mouse_is_being_pressed = false;
}

Your mouse_axes event code is short enough it's fine. Then all the logic code you currently have in your button up/down should be put in the timer. or another function to keep clean.

if(event.type == ALLEGRO_EVENT_TIMER)
{
    if (mouse_was_pressed_since_i_last_did_logic)
    {
        // do your code that checks
    }
    else
    {
    }

    mouse_was_pressed_since_i_last_did_logic = false;
}

add the same for keyboard if you need to

I have heard that too and I've been trying to stop it. They think they can get uniform control by putting the drawing in the timer.

The logic handles control not the drawing.

The logic should be in the timer if you want uniformity. The drawing should either be done every loop or using the dirty boolean like I said.

Try putting the draw call outside of timer for the time being and see if that helps at all.

There are a couple other little things:

That's if it's an int. If it's a bool then you can use:
if (!bTurn) {nTurn = !nTurn; bTurn = false;}

No big deal, but I find it funny you didn't use a switch for the event types, but went with ifs. Then for something small with 2 choices you used a switch. Just a personal thing.

---

One thing you could to to decrease processing time. Multiplcation is expensive. Avoid if necessary or do some precalculations. Add a few extra variables to Cards[] and store already calculated values.

        if(nPos_x >= (Cards[count].fTX*fPercent_Diff_WD) && nPos_y >= (Cards[count].fTY*fPercent_Diff_HT))
        {
           if(nPos_x <= (Cards[count].fBX*fPercent_Diff_WD) && nPos_y <= (Cards[count].fBY*fPercent_Diff_HT))

Daniel, I think the program has a larger issue. I moved the draw command but it didn't help, maybe even increased the lag. I'll dig deeper.

Edgar, I appreciate the insight. I'll look into it. I wouldn't dream of questioning someone who knows far more than I but someone on here stated part of my original issue was using if else. They suggested using ifs only. Does it really matter either way? Thanks.