Following up on my Linux Vs Windows FPS question. A quick recap, when I compile my match game in Windows 10, the game functions pretty good considering where I'm at in the fine tuning. However when I compile in Linux Kubuntu 22, the game works the same initially but quickly starts lagging. After about 3-4 attempts to match colors (concentration type game for grandkids) it lags to the point you can't tell if it's read your response or not.
Well this weekend I was showing someone the program and got the same lag until I used the keyboard instead of mouse to flip the cards. The game allows for both. So my question, would there be a difference in mouse reaction OS to OS? It doesn't appear to be so with the keyboard. Thanks
Show your event handling code and game loop.
Is the same code as before or have you fixed that? There has got to be something else.
As always, code please.
Thanks guys, I'll clean my code up and post it.
UPDATE: Until then, The need for seeing the code would imply that code flow can affect variation in performance machine to machine. Is this the case? Meaning if the code is lacking (and I'm sure it is in some areas) wouldn't it be the same lacking code on both Windows and Linux? I would think the issue would lie in the OS or the machine itself. Just thinking out loud.
No code means we are guessing what the problem could be instead of giving clear answers.
Ok all. Here is the code that involves drawing to screen.
Main with title screen
This is the game play function with the draw function.
BTW, the format doesn't keep the spacing accurately.
It looks like you’re still calling draw_blocks multiple times in the loop. You should only draw once per loop. As you are flipping the display and also using al_rest it will have adverts effects. It may not be as noticeable on windows because of the dwmflush calls/vsync etc. you should update the logic and draw/delay once per loop.
Ideally you would use a timer and only draw when the timer clicks.
You're still drawing once for every event. Think about MOUSE_AXES events. They will pile up trying to draw. There's nothing wrong with the OS or the mouse.
Thanks for the expertise guys,
Looking over the code, I see a circumstance where I draw twice in one loop. I have specific conditions for each of the draw calls. They shouldn’t all draw in a single loop. I’ll have to read closer to see if there is a circumstance where multiple draws are active in a single loop. Currently I have different conditions to be met for each draw. Then I have a default should none of the previous condition be met. I see where the default gets drawn each time through the loop regardless of the other conditions. I need to condition it in some way too I supposed.
Here is why I put the different draw calls. Originally I didn’t have this. As a person chooses the first card, it stays flipped because of a bool variable change. However, when the second card / block is chosen that doesn’t match, all the flip variables are zeroed out. This happens so fast that you don’t get to see your second card. I had to add a rest of 2.0 sec but only when two cards have been chosen and don’t match.
In any case, I’ll rethink the code flow and try to work off of a timer. Thanks again.
The typical event loop is driven by a timer or vsync. Why don't you just try it first and see how you like it?
I agree Edgar. I'll look into a timer. Obviously you guys know a lot more about it than I do. I'll keep you posted. I've also being thinking of how to reduce the draw call to a single call from the timer event. Instead of various locations. That may help as well. Thanks.
Simple loop system with input handling, logic processing and output.
draw_cards would go in the draw loop ONCE. If you need a delay timer to show the face before turning over, then add another variable just for that. Set it to some arbitrary time that counts down every logic tick. When zero flip the cards back over.
You can also achieve it by handling the logic when you get an ALLEGRO_EVENT_TIMER. Remember to start the timer. It won't start itself.
\