|
|
|
| Could they have done a worse job? |
|
Bob
Free Market Evangelist
September 2000
 |
It generates custom (x86-only) code to stretch a bitmap with a specific ratio. It's a speed optimization. -- |
|
Thomas Fjellstrom
Member #476
June 2000
 |
Read the code /* do_stretch_blit: * Like blit(), except it can scale images so the source and destination * rectangles don't need to be the same size. This routine doesn't do as * much safety checking as the regular blit: in particular you must take * care not to copy from areas outside the source bitmap, and you cannot * blit between overlapping regions, ie. you must use different bitmaps for * the source and the destination. This function can draw onto both linear * and mode-X bitmaps. * * This routine does some very dodgy stuff. It dynamically generates a * chunk of machine code to scale a line of the bitmap, and then calls this. * I just _had_ to use self modifying code _somewhere_ in Allegro :-) */
Shawn wrote that -- |
|
Richard Phipps
Member #1,632
November 2001
 |
How soon will it be changed? |
|
BAF
Member #2,981
December 2002
 |
SciTE crashed on my P2 laptop with some freaky error code. It must not be cpu-dependant. |
|
Matthew Leverton
Supreme Loser
January 1999
 |
Quote: How soon will it be changed? I was just joking. I've had no problems with any Allegro functions (including stretch_blit) on XP SP2. |
|
BAF
Member #2,981
December 2002
|
i wan'st joking though. Scite CVS doesn't work on sp2 |
|
Richard Phipps
Member #1,632
November 2001
|
Quote: I was just joking.
Well thank you. I got very worried.. |
|
Sirocco
Member #88
April 2000
 |
Edited. --> |
|
Bob
Free Market Evangelist
September 2000
|
Quote: I've had no problems with any Allegro functions (including stretch_blit) on XP SP2.
You probably don't run Allegro on an Athlon64 or Opteron either -- |
|
Richard Phipps
Member #1,632
November 2001
|
So it is broken? |
|
Kitty Cat
Member #2,815
October 2002
 |
If it is still broken, it won't be hard to fix. While working on an Allegro port of the Build engine I had to handle this. -- |
|
Richard Phipps
Member #1,632
November 2001
|
Well, if it is broken then please feel free to try to fix it. I also use Stretch_Blit and I'm sure other people here use it even more than me.. Bob: Is it definately broken? |
|
spellcaster
Member #1,493
September 2001
 |
If it is broken, it should be fixed ASAP. I'm using it quite often. -- |
|
BAF
Member #2,981
December 2002
|
Kitty: you made an allegro port of the Build engine? Where is it! I wanted to do that at one point... it'd be cool to see and mess around with. |
|
Richard Phipps
Member #1,632
November 2001
|
Sigh, Can we please have confirmation of whether stretch_blit (or any other allegro routine) is now broken on certain processors with SP2 installed. This is very relevant to me. Rich. |
|
Evert
Member #794
November 2000
 |
Quote: Clearly, when MS fixes those bugs, the apps stop working. I've heard that this is also a common problem with Windows emulators that don't reproduce some bugs as well as documented features... Quote: Another question then, was this issue not discussed by the Dev's? Not that I have any power over them, but just wondering if they were aware of it..
For me personally, this is the first I've heard of it. I'd also be clueless as to how to fix it. Quote: If it is broken, it should be fixed ASAP. I'm using it quite often. Absolutely. As a quick workaround, Allegro's build process can be hacked about to use the C only version of stretch_blit (replace src/i386/istretch.c with src/c/istretch.c around line 116 of makefile.lst and re-run make depend and make). This will incur a penalty loss. If there really is a problem, and it is as easy to fix as KC suggests, then it should be fixed for 4.1.16 WIP and 4.0.4. The latter may take a while longer to be released though and 4.1.16 may not be suitable for Richard. |
|
Bob
Free Market Evangelist
September 2000
|
Quote: If it is broken, it should be fixed ASAP. I'm using it quite often. stretch_blit() is only broken on Athlon64 / Opterons. The fix was mentioned by KC. FBlend is safe - it doesn't generate code. -- |
|
Richard Phipps
Member #1,632
November 2001
|
Then if the fix is that simple, can this be included in both the stable 4.0.x branch and the WIP ASAP? |
|
Evert
Member #794
November 2000
|
Quote: can this be included in both the stable 4.0.x branch and the WIP ASAP? Yes, but this will be 4.1.16 and 4.0.4 respectively. I don't know when you can expect the latter though. |
|
Chris Katko
Member #1,881
January 2002
 |
I have a question, why would you write code on the fly? Isn't that just asking for problems (especially for a cross-platform library)? And what about things that compile on-the-fly like Java and C#? Why aren't they effected (or are they)? -----sig: |
|
gnolam
Member #2,030
March 2002
 |
Quote: And what about things that compile on-the-fly like Java and C#? Why aren't they effected (or are they)? The VMs presumably aren't affected because they use the proper API calls to mark the memory as executable. -- |
|
Rampage
Member #3,035
December 2002
 |
Quote: And what about things that compile on-the-fly like Java and C#? Why aren't they effected (or are they)? Java bytecodes are interpreted by the virtual machine, as long as the VM runs ok, Java programs shouldn't have problems. As for C#, Microsoft is focusing on .NET, they must have found a way to keep it intact. [EDIT] Iiiiii'''mmmm ssssssllllllooooowwwwww. -R |
|
Marcello
Member #1,860
January 2002
 |
Except that .NET is one of the things listed? Marcello |
|
the_y_man
Member #1,770
December 2001
 |
isnt SP2 still going under testing? |
|
BAF
Member #2,981
December 2002
|
no, they released it for network installs (http://www.microsoft.com/downloads/details.aspx?FamilyID=049c9dbe-3b8e-4f30-8245-9e368d3cdb5a&DisplayLang=en) and they are still mirroring it for windows update (they aren't ready for the bandwidth it will use yet). |
|
|
|
