Re: [paragui-users] pg_application

[Teunis Peters]

On Tue, 27 May 2003, Alexander Opitz wrote:

> Am Dienstag, 27. Mai 2003 01:59 schrieb Teunis Peters:
> > It's not good in a "this can cause a fatal crash to X" way...
> > but multiple threads handling event tossing shouldn't be a big deal.  At
> > least not with SDL's event handlers which are quite multithread friendly.
>
> But threading is never good for games (only a thread for a server for network
> games).

Makes a certain amount of sense.  Certainly affects latency (outside of
linux).  On the whole I've found that effective uses of threads and queues
can actually improve efficiency on linux versus single threads.  But linux
has -REALLY- efficient multithreading.  As of the 2.5 kernels (afaik) the
latency on a thread switch's almost acceptable to RT-linux standards...
*G*

> > Oh really?  hrm.  I'll have to look into that...  I stopped using this
> > method at some point so I'm not sure how (or if) it works anymore.
>
> I've found it ... dblbuffer call the function "SetBulkMode(true)" and then
> the Quit Event isn't catched ... but now I have a stupid cursor (with
> scrolling background but the dblbuffer have no background).

hrm.  Background and various other texture things in paragui need a
SERIOUS rethink.  At this point cursors work - or at least the ones in the
OpenGL trunk aren't a hack :)
But I'm not sure how to approach it yet.   The most efficient way in the
paragui/opengl trunk is to maintain a texture object that handles when/if
translucency/alpha and such are set - particularily since SDL isn't always
consistent and OpenGL has drastically different restrictions (read:
opengl has none :)

> > A seperate loop for displaying is rather risky with SDL.  With OpenGL it's
> > out and out not allowed.
>
> I don't get pgmpeg to compile ... after some changes in the configure.in it
> takes paragui2 ... but it seems to have an older API of paragui2 (paragui 1.1
> from the savannah web site)

Try the opengl branch  in the "plugins/mpeg" directory...  It's pretty
much pgmpeg but rebuilt to paragui/opengl - although it's pretty similar
to paragui/non-opengl and after looking at the custom texture stuff (use
the old code :) it should compile without a hitch.  And run too.

> > Multiple rendering thread behaviors btw:
> >     - to memory context: no prob
> >     - to FBcon : no prob
> >     - to Windows/DirectX : careful locking required, sometimes locks
> >     - to nVidia/OpenGL : no prob
> >     - to Matrox/OpenGL : system lockup, poweroff only solution.
> >             current solution: X aborts the program
>
> Hmmm, I've a dream ... that all drivers works in the same way ... *dream*

That's my headache with the multiple driver thing and SDL actually.
If you just assume that rendering from multiple threads crashes
everything and account for it, your program should work everywhere :)

or if you DO allow rendering - only do it to memory textures.

One of the things I setup the opengl/paragui system is to allow memory
textures for rendering everywhere and the main thread syncs them to
graphics memory when they change.  All that rendering directly to the
desktop's driving me crazy with all the problems.

Now if only SDL's handling of alpha/translucency/colourkey was CONSISTENT!!!!!
Part of my headache is current paragui is programmed for SDL's
inconsistencies...  augh it'd take a bit to describe 'em all so I'll
describe 'em later.  Because it IS important.

G'day, eh?
        - Teunis