I used to build allegro 4.0 and 4.2 with MSCV6 and djgpp for the assembler stuff. Is it possible to setup 4.4 the same with cmake ? I have small problems with my old game code which is working perfectly fine with 4.0/4.2 ASM builds but not with a C only build. I tried 4.2 and 4.4 C only builds without success.

The assembler stuff has not been maintained in so long, the C code is faster, and can be broken occasionally. Which is why it was removed from 4.4. There is no more ASM in 4.4 afaik. At least not in the Windows port.

You'll have to make sure you recompile your game when you switch allegro versions. That should get rid of the issues. And if it doesn't, try defining ALLEGRO_NO_ASM+ALLEGRO_USE_C (though that should be the default in 4.4).

After all that, and it still doesn't work, please describe the problems you are having in detail.

Maybe if you modify the CMake files. You really shouldn't though.
As I asked in the other thread, do the Allegro examples show the same problem you're experiencing?
Matthew pointed out something I hadn't thought of: do you use any additional libraries and external addons? Does the problem show up with vanilla Allegro? Did you recompile all the external addons you're using for 4.4?

I use the alfont library and did recomple everything. Examples do not show same problems.

I have some 3D code, written by a friend which is creating a 3D landscape. I can view the landscape from different angles, redrawing the map. I did put this on different keys. If I toggle between these two views very fast I get a black landscape sometimes. The behavior is not consistent though, as often the map is drawn correctly but sometimes it is not. This is with C only builds of 4.2 and 4.4, with ASM builds of 4.0 and 4.2 the problem does not arise.

Here are screenshots. First two show map on different angles, the black hex fields are ok as I use fog of war. Third shows what happens if it fails to redraw correctly. Notice that the sprites on top of the landscape are drawn, just the 3D stuff is missing. The map bitmap is cleared to black before drawing stuff.

{"name":"scape1ok.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/4\/d48188d2a664058bd512debb8449060b.png","w":806,"h":625,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/4\/d48188d2a664058bd512debb8449060b"}
{"name":"scape2ok.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/f\/1f821ebacd05550bf8b3c17c826b7cdb.png","w":806,"h":625,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/f\/1f821ebacd05550bf8b3c17c826b7cdb"}
{"name":"scape3bad.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/b\/4bcbe4f876d16ef41d35da1af5941a58.png","w":806,"h":625,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/b\/4bcbe4f876d16ef41d35da1af5941a58"}

The 3D code is ugly and I'm bad in 3D math so a friend had to do it for me.
It is too big to be included here (64k limit), here is the link.

C source

Unfortunately that's not a complete program that someone can compile and run to try and duplicate the problem. Looking at a section of your source code will not be enough to find the problem, I think.
For someone to even attempt to debug this, we'll need a program that we can run and test. Preferably the smallest one we can get.
I know it's a hassle and annoying, but could you check whether the problem can be reproduced by a program that just draws the 3D elements? Basically simplify the code as much as possible.
Is there some systematics to when the problem occurs? Specific viewing angles, say?
Try logging the output from the polygon drawing functions (warning: potentially lots of data, make sure you can reproduce the bug with, say, a single keypress after the program loads or you'll have a ton of data to wade through).

I posted the code so someone can check which allegro functions are involved. I thought the fact that the ASM version of allegro made no problems is a hint that the problem is most likely allegro related. I will see wether I can isolate the critical code in a simple enough example but most likely it will take to much time compared to the small problem. Nobody will repeatedly press the keys to change the view angle so fast - except me.

Thanks for listening.

Oh, it probably is. But without a test case that shows the problem, it's still almost impossible to debug.

You'd be amazed. But the speed at which the angle is changed should make no different, because the drawing operation can only depend on the actual value of the angle, not on the time elapsed between its current value and the previous value.

I thought the same but I can reproduce the bug much better when repeatedly calling the drawing operation. I know it makes no sense if it is single threaded and no other thread can interfere but it is what I experience. I get the best bug reproduction when hammering the same key = drawing with same angle.

I destroy and recreate the map bitmap with every draw operation and would think it is a bug in my code but it worked flawlessly with allegro 4.0 ASM for nearly 7 years.