|
|
|
This thread is locked; no one can reply to it.
|
| allegro 4.4 ASM build possible ? |
|
Larkin
Member #11,125
July 2009
|
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.
|
|
Thomas Fjellstrom
Member #476
June 2000
 |
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. -- |
|
Evert
Member #794
November 2000
 |
Larkin said: Is it possible to setup 4.4 the same with cmake ?
Maybe if you modify the CMake files. You really shouldn't though. |
|
Larkin
Member #11,125
July 2009
|
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"} The 3D code is ugly and I'm bad in 3D math so a friend had to do it for me.
|
|
Evert
Member #794
November 2000
|
Larkin said: It is too big to be included here (64k limit), here is the link.
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. |
|
Larkin
Member #11,125
July 2009
|
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.
|
|
Evert
Member #794
November 2000
|
Larkin said: 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. Oh, it probably is. But without a test case that shows the problem, it's still almost impossible to debug. Quote: Nobody will repeatedly press the keys to change the view angle so fast - except me. 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. |
|
Larkin
Member #11,125
July 2009
|
Evert said: 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.
|
|
|
