All,

I’ll try to be to the point while still giving enough info to understand the issue

I finished my game for grandkids. It works as intended in Windows. I can run from Windows or the compiler. When I go to Linux I run into issues. The program won’t run from the terminal. The Allegro alligator window opens but nothing happens. I can’t get the window to close. When I run from the compiler, the game works fine. The options on the title screen works fine. The issue is with the “setup” option. When chosen, the screen flickers as you move the mouse. I mean the title screen keeps popping up. The setup screen is a simple black screen with colored text. The text highlight as the mouse hovers. If you stop moving the mouse you will have the correct black screen and text or the colors texts on a transparent silver background allowing the title screen to bleed through. Occasionally it will just show the title screen. If you guesstimate where the screen sizes are located, they function as expected.

I haven’t had a chance to dive into it yet. When running from the compiler in Linux I noticed this error on the exit of the game. I don't get in Windows.

free(): double free detected in tcache 2

I looked this up online but the explanations seem to address specific coding without telling what the cause is. I read a lot of <i>“You shouldn’t put this there”<i> or <i>“You really don’t need this or that”<i> I didn’t see anything saying <i>“This error is due to array over run or lack of memory allocated?<i>

In short, I’m hoping this type of screen result isn’t unheard of. Also that someone here knows what the free(): error is all about. Thanks.

Daniel,

Thanks. I'm attaching the code files. The site isn't allowing ZIP files, picture files or ttf files. You can use any picture files. Mine are 640x480. On the start up since yo won't have button locations, you can use P for play, S for setup, and Q for quit. Works with mouse or keyboard.

Let me know what you find out.

UPDATE. I believe the reason pictures and ZIPs wont upload is the lapse in time. The 11 files at 37K total bytes I uploaded took 20 min or better.

I need to correct you on something. The compiler compiles and links but in no way does it ever run the program. That's the terminal you're running that runs the program. I think I know what you meant, but terminology needs to be clear.

The display has 2 internal bitmaps (the front buffer which is what you see, and the back buffer which you should draw to). When you flip_buffer, they switch positions. The front becomes the back and vice-versa. If you only grab the back buffer once then you risk having target point to the front buffer after a flip. And you do not want to draw to the front buffer. Only the back buffer. Drawing to the front buffer will have graphical glitches, screen tearing, etc.

Not instance referring to object instances. I mean instance as in each instance of a set of code.

I said to grab the buffer every instance. Meaning, you have multiple sections where you draw to display. You need to get the current target each time. That way you insure you are only drawing to the correct buffer.

1. get current target bitmap
2. set target to your bitmap
3. draw to your bitmap
4. set target back to saves bitmap
5. draw your bitmap to display
6. flip display

// Another option is just to get display's backbuffer.
al_set_target_bitmap(al_get_display_backbuffer(display));

1. set target to your bitmap
2. draw to your bitmap
3. set target to display's backbuffer
4. draw your bitmap to display
5. flip display

There is a display option to request that the display is created with only a single buffer. That would then make it acceptable to only grab target at the beginning.

Just remember, the buffers belong to the display and will get destroyed internally when you destroy the display. Never destroy yourself or you will get the double free error.

Also, if you go the single buffer route make sure you vsync before drawing to the target. Never want to draw mid-refresh or you will have graphical glitches. Nothing major.

In computer science, a buffer is a temporary storage area in memory that holds data while it's being moved from one place to another

It is common to call the bitmap, you draw to, the buffer (double buffer, triple buffer etc). It's a hidden bitmap (storage area) for the drawing until flipped. Flpping "moves" it to the front.

You can consider the front bitmap the display as that it what is viewed and the back bitmap a buffer until a flip.

as for quotes around file name: it will do that if spaces in the filename. Windows does it to. You cannot have spaces in a command. for example: Say you had a text file called "This is my text file.txt" and tried to open it ">type This is my text file.txt". It will look for a a file called "This" with arguments "is my text file.txt".

As for the x error: Do you have nvidia? Are the drivers updated? Just googled the error brought a few suggestions.

Edgar,

You are right, I should debug on my own. What once was meant as a joke, has become evident. If I didn't ask silly questions that I could research my self, no one would be on this site unfortunately. I often reply back and forth just to keep the site engaged.

Daniel,

I think you are right. I looked up the error yesterday afternoon and seen it was a potential NVIDIA issue. I even found a work around that I haven't tried yet for fear of causing other stuff not to run. Something I've had happen before. I was going to respond last night but couldn't find the time. Example, logging on and finally getting to a response screen today has taken me over 16 mins. That's a long time to wait if you are just trying to get out a quick blurb.

Thanks again all.

Ace, I was in no way suggesting you don't need help or you should do it all on your own. Some things (like debugging) are best done on the original computer that is having the problem. Oftentimes a program will crash or stop without an obvious cause, and that is when you want to run it through the debugger.

This site is just about dead. ML has shown no interest in maintaining it for quite a few years now, and everyone has moved to Discord. In its day allegro.cc was the bomb. But now it's gone kablooey. It takes forever to load and most people are fed up with the problems this site has now.

That said, I'll be glad to continue to help you with your programs here if you must or on Discord where you can get a much faster and more useful response.

DanielH and I are about the only other people who still put up with this site, and it takes a while to reply, but I'll help if I can.

Edgar aka Modulo5k aka Bugsquasher