All,

I've create a simple game that can use mouse or keyboard. When I compile with a Dell Latitude with Win 10, it functions fine. When I compile on Kubuntu 22.04 on Acer Nitro it lags. It starts out fair enough but the cursor I created starts leaving a trail. Also as I click the cards (match game) The first set does fine, the next a little slower and eventually you can't tell if it took your command it so slow. Again, this is only on the Linux compile.

I haven't set frames per second as I've seen on some of the tutorials. Is this the issue? Maybe the default FPS are different between the two machines? Thanks.

You'll have to show code. Odd that it is slow on Linux. Are you running it in a virtual machine?

Thanks Edgar. I was surprised as you. I'm running Kubuntu in a dual boot. At first I thought it was a mingw32 (Windows) Vs a Linux GCC issue. Then I remembered that the tutorials I'd seen applied a frames per second command. I haven't had a chance to try it yet. I thought maybe by not defining FPS, the default difference between the two setups might be causing an issue.

In any case, here are the cards and drawing functions. There is a rest if the two cards / blocks don't match but thats not the lag. Lag come in after the cards flip back over to white and I click another block. A couple times of this and it's 1 to 3 secs waiting and I can't tell if my click was registered or not. Plus there is the cursor trailing. That's not critical. I can take it out and use the system cursor only. I just put it in to see if I could get it to work

It might help to have the structure code.

don't know if this will help or not but

Take the al_flip_display out of the draw_cards and put in main loop. You call draw_cards twice during one loop.

Thanks Daniel, I'll give it a shot. I'll let you know what happens.

Actually I see 5 times you have draw_cards. five times the display gets flipped. But you only clear the screen at the beginning.

Might but hello with lag, but your trailing graphics.

Thanks Daniel. Times like these I miss the old days of MS Quick C. It had a step function that treated your code like a BASIC line interpreter. You could execute your code line at a time. It allowed you to watch the values of listed variables as well as seeing if your code made it in to loops or functions as expected. Was a big help in trouble shooting. Now I have to pepper in print statements to monitor variable and position in the code. But I digress. Thanks again.

You can always put in some breakpoints and step through the code checking variables and each step as you go!!

You've really got to format your code better with proper indentation and a single brace style. It makes it hard to read.

Also, your event loop needs a little work. Wait for an event as long as the queue is not empty (it will be an instant wait). Draw once. Do logic once for each tick of the system timer.

Finally, learn to use gdb, the gnu debugger. It will let you step through code and print out values of variables. Check out my debugging guide on the wiki here :

https://github.com/liballeg/allegro_wiki/wiki/Debugging-and-logging-with-A5#debugging-with-gdb

Thanks for the recommendation Dizzy and Edgar. I'll check them out. Being able to step through would be a big help.

As for code, I agree it's a little sketchy. First off, I wasn't planning on sharing . My original question was about the possible impact of not using FPS. I usually do a better job of cleaning up once the program is going into final phase. As for this code, I've patch worked it together. Recently I moved it into the game_play function. It was all in one function (main). I've been adding aspects (letter location, mouse use) as I went just to see if I could do it.

Plus I'm primarily self taught, I'm sure I've developed poor habits. I need to read other's code for template ideas.

Thanks All.

No time to learn like the present. That GDB guide has most all the commands I use anyway.

Look up style guides for tips on formatting your code. I use something like this :

int main(int argc , char** argv) {// braces go on the end of the line
   // 3 space indent for new block, eliminates the need for braces (in Python)
   if (condition1) {
      dothis();
   else if (condition2) {/// all ifs and elses in the same clause go at the same indentation
      dothat();
   } else {
      stop();
   }
}// closing brace goes on the same indentation level with the line of the starting brace

This is typical C++ style. C users probably want the opening brace on its own line.

As for an event loop, you need to exhaust all events. You were drawing something like 5 times per event, which would make it horribly slow and back up the event queue.

This is a typical event loop for me :

Don't listen to these heathens!

Open curly brace on new line!!

There are arguments both ways. There is no 'correct' way to do it.

But yes, break those coding habits early. Proper indentation. Separate input from logic from drawing.

1. process input (events)
2. run logic based on that input
3. draw

You can draw every time pass through the loop or draw only when something happened. That is why Edgar had a redraw boolean. It only triggered a redraw because logic processing occurred.

Bah. You're just artificially boosting your LOC. Compensate much? XD

It's as bad as people who pronounce gif as gift without the 't' instead of jif!

I use same line opening brace in Java and new line opening brace in C/C++, mainly because my enforced gradle tasks demand I do!

Just to add to the debate 😎

   if (condition1) {
      dothis();
   else if (condition2) {/// all ifs and elses in the same clause go at the same indentation
      dothat();
   }

Close your braces.

Ok to carry it further. In Edgar's example that Polybios referred to, should we use braces for ease of reading when they aren't needed?

With a single statement after the if condition, couldn't you do this?

if (condition1)
dothis();
else if (condition2)
dothat();

I can't get the proper formatting. I have the dothis and do that indented.

In my opinion, using brackets is always preferred, it just makes it easier to read and means you'll make less mistakes when coming back to add code etc.

When you say you couldn't get proper formatting, did you mean on here? Just wrap it in code tags to get formatting. Ie, I would do:

if (condition1)
{
    dothis();
}
else if (condition2)
{
    dothat();
}

It will also mean anyone else looking at your code will have an easier time!!

Ok Dizzy, which formatting are you referring to? If I just add spaces the site ignores them, If I do the code format it put the code in a separate box. Thanks.

Hmm, yeah just code tags....I'm not sure why it sometimes puts it in a box!? Maybe over a certain number of lines? Let me test it!

if (true)
{
}

Yeah I think it's just if you have too many lines it puts it in a box!!

Ace - click formatting help right next to preview in reply to post.

<code>code goes here</code> code tags

Thanks Edgar, I've use the Formatting help box several times. I thought it put everything in a code box not just format it.

So Dizzy your saying

See no matter how few lines I get the box.

Yes, that's bad in my opinion. Too easy to add a line and have a dangling if.

Oh that’s odd! I only seem to get a box of add lots of lines! Maybe a newline/carriage return OS thingy…

I agree Edgar. I was minimizing to see if I got the correct formatting.

I also agree the braces are clearer. I've had a few times where the indention gets messed up in copy/paste and shifting code around. With a single line if/else, followed by a mis-indented line, it's easy to forget what goes with what.