Follow-up Comment #9, bug #17573 (project wesnoth):
The updated patch should have the effect of increasing the CPU requirements
during runtime, which will have a negative effect on are unaffected by this,
especially older systems that are taxed by Wesnoth as it is currently.
This issue occurs when memcpy() runs backward, so I think it would be better
to test memcpy() before implementing a workaround. This can be done by doing
the following:
char tarray[3] = {1,2,3};
memcpy(tarray + 1, tarray, 2);
If memcpy runs backward, tarray will store {3,3,3}. If memcpy runs forward,
tarray will store {2,3,3}. We could test tarray[0] to determine whether or not
the SDL bug is triggered.
I will not have time to implement this until Friday, but I think Thonsew's
patch could be modified to run a memcpy() test once, store the result and then
do the blit according to that result each time this code is invoked, which
could be done with negligible overhead on older systems that have a forward
memcpy(). It is less work than my previous suggestion and will only slow down
the systems that have a reverse memcpy().
By the way, there is some irony in that the reverse memcpy() was implemented
on the premise that it would make things faster on certain architectures,
while the reverse seems to be true due to workarounds people are implementing
to counter the bugs it triggered.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?17573>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs
