[AD] I'm back, with patches

[allegrovp@xxxxxxxxxx]

[Note that I'm no more subscribed to AD, so please CC any replies to
me otherwise I won't be seeing them]

Hello there,

After half a year of absence, I've eventually gone back to Allegro game
coding, and I've downloaded Allegro 4.1.13.

First, thanks for applying some of my patches. I have a few questions
about those here.
Second, there are some problems building (though one was specific to me,
but it uncovers a real bug anyway). Patches references here are on
http://lyrian.kezako.net/a13/ as this mail system doesn't support
attaching files, and I seem to recall people not liking inline patches
(and IIRC there's a 10K limit here, which should be reached by this).

First, about my previous patches:

- about passing a previous object to a "grab update" command:

half the patch was applied (thanks for the renamings and signature
changes, btw, there were so many conflicts I had to undo and redo all
my changes by hand :)) and one of the reasons (though not the main
one) for it was left out: the (image) plugin specific properties for
XPOS and friends were conveniently moved to a generic "options" list,
and with the patch as applied, they're still there in the grab params
structure (much better than to have them passed directly to plugins'
grab routines though). This means that adding further plugin specific
properties like this (eg, for alogg (ahem), OGGQ (quality of encoding)),
one would have to add a member to that params list structure, rather
than using the generic list. This is not very good a solution, as it
means one needs to change Allegro to add such a property to a plugin.

The change to that particular patch also introduced a bug which is
fixed by prop_dup.diff (a property list being clone did not clone
the actual data, two property lists were sharing the data, leading
to double free). The non-duplication of these makes me think that the
original idea maybe was to "detach" the properties, so if that's the
case then ditch this patch and do that instead. The patch fixes the
crash anyway for the time being.

- about sincos:

I had been working on it (at long last), but could not get rid of a
float<->double problem so I didn't submit it. I see this has now been
done, but only does the i386 case. My existing patch (sincos.diff)
uses Linux's sincos/sincosf routines, which seem to include various
tests for the input parameters. Would the above patch still be useful
for other architectures, or do I just leave it ?


Now, various build problems:

- setup.diff actually includes <sys/time.h> on Linux
- depmod.diff properly uppercases module name (the previous version
  could get expanded by bash, so tr would be passed rubbish)
- cpptest.diff makes the thing work with Fortify (which defines new
  and delete)
- export.diff allows a C++ program to include datedit.h

Not really build problems, but:

- yield_timeslice: freezes the program on my machine - setting tv_usec
  to zero (instead of 1) fixes the problem - I'm unsure why since I
  also use select with a non zero timeout in my own game, and it just
  works fine (stock 4.1.13 grabber and test freeze). This is probably
  related to me using signals (rather than threads) and SIGVTALRM (rather
  than SIGALRM), so I wouldn't worry too much about it if it works for
  other people.


And last, new patches entirely (done 6 months ago, so let's see if
I recall the reasons for them):

- mouse_object.for-pristine-a13.diff adds a flag
- get_filename.diff fixes a pathological performance behavior (would
  walk and walk strings a *lot* of times) - note: it is very slightly
  slower in UCS-2, but *much* faster in UTF-8.
- load_prop.diff exposes some useful datafile property internals
- word.diff changes the detection of "hotkey-able" letters so that
  my alogg plugin has a much nicer choice of hotkey :)

Ah, yes, I just remember it: I was reading the diffs, and I spotted
the following line in mingw32._tx:

> download it hrom '<link>http://alleg.sourceforge.net/wip.html</a>'. Note

s/hrom/from/

--
Vincent Penquerc'h