Section of Code Lagging the Program

Section of Code Lagging the Program

AceBlkwell

Member #13,038

July 2011

All,

So, beating the program lag some more, I’ve run into a weird situation that doesn’t make sense to me. I can accept and admit the flow isn’t the best. I’m also sure if I restructured the program it might make my lag go away. What I can’t understand is the reason for the lag based on the testing below.

Here is the short code.

#SelectExpand
  1void star_background()
  2{
  3  static int y1 = 0;
  4    static int y2 = -480;
  5
  6   al_clear_to_color(COLOR::BLACK);
  7  al_draw_bitmap(still, 0,0,0);
  8    al_draw_bitmap(stars, 0,y1, 0);
  9    al_draw_bitmap(stars, 0,y2, 0);
 10      y1++;
 11       y2++;
 12     if(y1>480)
 13        y1 =-480;
 14      if(y2>478)
 15           y2 = -480;
 16
 17} // end of star_background

If I comment out the Still command, my lag goes away.
If I uncomment the Still command and comment out stars (y1) my lag goes away.
If I uncomment the stars(y1) command and comment out stars (y2) my lag goes away.

It’s like having 3 bitmaps drawn is causing the lag.

If I leave the bitmap drawings and comment out the math, still lags
If I comment out all ref to y1 and y2, and use an actual number in place of y1 and y2. I still have the lag.
If I put everything back to original and replace one of the stars with a different bitmap. So that I have 3 unique bitmaps. I still have the lag.
I replaced both bitmaps Stars and Still with smaller, different bitmaps, I still have the lag.

I’m not that stressed over it because I can do away with the Still bmp or I can rewrite a big section of code to clear the lag. I was just curious if this made sense to anyone as to why this would happen?

DanielH

Member #934

January 2001

Nothing seems unusual in that bit of code. It has to be something else. Unless they are huge bitmaps or memory bitmaps.

Were they loaded/create before or after display?

I'd like to see entire project if it's not too much to ask.

YouTube Coding Channel

AceBlkwell

Member #13,038

July 2011

Daniel,

I’ll pull the data together. I tried one more test. I got to thinking it may be computer specific. So I ran the program on a faster machine. The lag wasn’t as bad, but like the previous machine, the lag increased the longer I ran the program. Both machines were running Windows. The first was Win 10 and the second Win 11.

I then compiled and ran the program on the second machine under Linux / Kubuntu. It ran great. So I’m not sure if it’s a Windows thing or poor programming. Likely the latter.

I’ll work on the program files.

Do you know if this site allows compressed files? Otherwise if will be about 10-15 small files.

** UPDATE ** Try to add files. Site doesn't seem to allow anything but text files. Not sure how to get the pictures and ttf files to you. Let me know if I've missing something.

Edgar Reynaldo

Major Reynaldo

May 2007

Don't call display_print inside the if ev.type == ALLEGRO_EVENT_TIMER call. Just set redraw to true and use up the rest of the events like it shows above.

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math. In either case, I’ll ride this wagon until the wheels fall off. Thanks to those that keep it running

AceBlkwell

Member #13,038

July 2011

Thanks Edgar. That's similar to Daniel's advice. Can you explain reason for that? Here is why I ask.

ev.timer
{
display print
}

ev.timer
{
set bool variable to true
}

if(bool)
{
display print
}

I'm not seeing the difference. Every time in timer your going to see bool back to true and the next if condition will print. I'm not disagreeing, just asking for educational purposes. Thanks.

DanielH

Member #934

January 2001

We've mentioned it before, but you need to load bitmaps AFTER creating the display.

Order matters

If there is not display to connect the bitmaps to then they become memory bitmaps and not video bitmaps.

Memory bitmaps - memory stored on computer - slow drawing due to slow transfer to GPU
Video bitmaps - memory stored on the GPU - fast because it's already there

Options:
1. load after display
2. load before display but right after display is created you convert them to video bitmaps
void al_convert_memory_bitmaps();

----

The drawing in the timer event is problematic. Look at bitmap.c (in the examples folder). It uses a refresh variable to set if drawing needs to occurs. Yes, timer sets it every tic. However, drawing is skipped if other events are already in the queue and needed to be processed. Your not skipping drawing. drawing should be last and only if everything is done since it takes the longest to process.

Mouse events, display events, ...

YouTube Coding Channel

Edgar Reynaldo

Major Reynaldo

May 2007

AceBlkwell said:

Thanks Edgar. That's similar to Daniel's advice. Can you explain reason for that? Here is why I ask.

#SelectExpand
  1ev.timer
  2{
  3display print
  4}
  5
  6Vs
  7
  8ev.timer
  9{
 10set bool variable to true
 11}
 12
 13if(bool)
 14{
 15display print
 16}

I'm not seeing the difference. Every time in timer your going to see bool back to true and the next if condition will print. I'm not disagreeing, just asking for educational purposes. Thanks.

There's a big difference in a proper event loop that uses up all the events in the queue before performing a redraw. You're essentially getting backed up events in your queue that make it slower and slower because it's responding to timer events that happened in the past. It never catches up to the present.

AceBlkwell

Member #13,038

July 2011

Thanks guys, I think it's starting to sink in. I'll do some rearranging and see what happens. I appreciate the insight.

DanielH

Member #934

January 2001

No problem. Let us know if our suggestions did anything to improve performance.

YouTube Coding Channel

Dizzy Egg

Member #10,824

March 2009

I managed to run your program and did a few things to get rid of the lag (as suggested by the other guys):

Moved create display before bitmap creation in a_init():

init_confirm(al_init(), "allegro");
init_confirm(al_install_keyboard(), "keyboard");
init_confirm(al_install_mouse(), "mouse");
init_confirm(al_init_font_addon(), "font_addon");
init_confirm(al_init_ttf_addon(), "ttf_addon");
init_confirm(al_init_primitives_addon(), "primitives");
init_confirm(al_init_image_addon(), "image addon");

disp = al_create_display(640, 480); //BEFORE BITMAP CREATION!
init_confirm(disp, "display");

And I added a redrawScreen bool to main, which gets set in the timer event:

if(event.type == ALLEGRO_EVENT_TIMER)
{
    redrawScreen = true;
} // end timer event check

Finally I added a new condition to the end of the while(!bQuite) loop:

if (redrawScreen)
{
    redrawScreen = false;
    al_set_target_bitmap(buffer);
    al_clear_to_color(COLOR::BLACK);
    al_draw_bitmap(titlescr, 0, 0, 0);
    al_set_target_bitmap(target);                                     // have to return target bitmap to target or flipping wont work
    al_draw_scaled_bitmap(buffer, 0, 0, nBufferWD, nBufferHT, 0, 0, nDispWD, nDispHT, 0);
    al_flip_display();
}

After those steps the lag was gone. Maybe a good starting point if you're still working on a fix.

----------------------------------------------------
Please check out my songs:
https://soundcloud.com/dont-rob-the-machina

AceBlkwell

Member #13,038

July 2011

Thanks for taking the time you guys. I'll work through the changes in the next few days so that I understand what is taking place. I'll keep you updated. I appreciate you all looking at this with me.

** UPDATE **
I move the display creation before the before the bitmaps. That solved the problem. I'm going to continue work on cleaning up the code. I'm going to try using a redraw/bool approach as suggested. Thanks again.