[AD] Clear MMX bug! -> Repair

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


When I compiled the new allegro version (3931), the DJGPP version works fine and fast, test.exe tools workes fine and more fast. OK
Then I compiled the MSVC version, OK. I use the test but this crash when I select a new graphics mode, 
- What? 
Repeat the process and test.exe crash again, Why? I debug the test.exe
and it crash when free some bitmaps (destroy_bitmap(x)), I consult the MSCV help and use the source code of MSVC. 
Test crash becase MSVC when use malloc, it create a start heap and end heap for memory allocation, and when free memory it see that heaps are fine, but end heap of bitmap are corrupt.

The new code only access bitmaps with clear_mmx and blit_mmx (masked_blit_mmx). The problem is this. I did some test and bug is in clear_mmx 8 and 16 bits. 
I attach the diff file for better pacth.


Robert Ohannessian:
When you align the bitmat->dat dest dir for mmx use you calcule the new width but not save this correctly (change position of registers) you overwrite the new value and use the old width not aligned, this store more pixels than memory reserved.  
-You say that not segment decodify is faster on PMMX and K6-2, ok but can other processors use mmx instrucctions? Better processors include this feature but worse processor not include mmx.
-Why you store clear value in 4*4 pixels? Why not 4 pixels only? And your code will be small, and you won't have to do end line code.


Shawn:
If before use blit for mouse handler we save fpu word manually in asm and after we restore(with specified instructions), mouse will be able to use the new mmx blit? this is 50% faster for short bitmaps.



_________________________________________________________
http://www.latinmail.com.  Gratuito, latino y en español.

Attachment: blit.zip
Description: Binary data



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/