Le 06/10/2018 à 19:39, Le_Forgeron a écrit :
> Le 06/10/2018 à 12:04, William F Pokorny a écrit :
> 
>> Glad to hear you are making progress.
>>
> 
> And at the current state, I learn that libsdl (1.2 and 2) is not thread
> friendly, it wants (nah, requires) that the thread that make the display
> and pull event to be the MAIN thread (and not another child, even if
> alone to make the calls)...
> 
> But it's working with libsdl2. As a kludge so far.
> 

Now integrating... and the more I know libsdl & libsdl2, the more I hate
them.

I was hoping to have both kind of display available, when both are
installed, and selecting the one which is present when one only is
there, even allowing the user to select explicitly amongst SDL, SDL2, or
text.

They made incompatible API, on purpose they said... so it might have
been possible.

But :
* their include files define the same macro and define, but do not use
the same protection mechanism (that part, I can handle more or less, not
elegant, but doable)
* they kept some identical function interface, including SDL_Init() !!
which means the first linked library initialize its internal structure
and blocks the initialization for the second library, and without
initialized structure, other calls crash.

So back to the blue-print, to make a choice between SDL2 and SDL when
both are present... and maybe restoring the raw X11 port, updated for
the new rendering mode of block, that one could be safe to live in
parallel with SDL(1/2). [should I nickname SDL Ranma ? maybe, as you can
only have one at the same time, but at least Ranma 1/2 is a funny anime,
and I like Ranma, not SDL)


Given the added value of SDL2 vs SDL (the title of the window is set and
updated on pause with SDL2), the hierarchy seems obvious when both are
available.
(yet, have to allow --without-..  to allow user to force the choice)

See you next week.

Post a reply to this message