I have been hitting my head against the wall, trying to see why the
screen display in glmovie doesn’t work when the callback is set in
SMPEG_setdisplay(). It appears that in this case there is something
wrong with glTexSubImage2D().
What gets displayed on the screen when using the callback is whatever
was left in the texture last time it was loaded successfully. That
means if I run glmovie in its non-callback version, and stop it at some
frame, then run the callback version, what I see on the screen is the
last frame displayed in the previous run.
I have looked closely at what is passed to the display function
(glmovie_draw()) when it is invoked from the callback. There is no
question that the frame pointed to is changing as it should, and there
are no errors generated by any of the OpenGL function calls.
I guess this doesn’t prove that glTexSubImage2D is at fault, but it
certainly implies it. The GL_QUADS generation code clearly works at
least once (or nothing would be displayed), and I’m guessing that it is
working every time, but using an unchanging texture.
I’d appreciate some help from someone who knows more (i.e. anything)
about OpenGL (and SDL). I would have thought that in the callback case
it is still true that the OpenGL calls are made in the same thread (the
main thread) where SDL video was initialized, and therefore we shouldn’t
be running into thread-related problems.
Gib--------------------------------------------
Gib Bogle @Gib_Bogle
1/44 Arthur St Tel: (64-9) 525-6878
Ellerslie, N.Z. Fax: (64-9) 525-6878
I’d appreciate some help from someone who knows more (i.e. anything)
about OpenGL (and SDL). I would have thought that in the callback case
it is still true that the OpenGL calls are made in the same thread (the
main thread) where SDL video was initialized, and therefore we shouldn’t
be running into thread-related problems.
I’ll take a look when I get back home, but that will be a few days. Thank
you for all your effort to research this, btw.
–ryan.
I’d appreciate some help from someone who knows more (i.e. anything)
about OpenGL (and SDL). I would have thought that in the callback case
it is still true that the OpenGL calls are made in the same thread (the
main thread) where SDL video was initialized, and therefore we shouldn’t
be running into thread-related problems.
I’ll take a look when I get back home, but that will be a few days. Thank
you for all your effort to research this, btw.
Yes, thank you very much.
Can you send an updated version of glmovie.c (and any changed smpeg files)
to the SDL mailing list? It sounds like the basic problem was that glmovie
was trying to do OpenGL calls from a different thread, which is a no no.
Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Message: 2
I’d appreciate some help from someone who knows more (i.e. anything)
about OpenGL (and SDL). I would have thought that in the callback case
it is still true that the OpenGL calls are made in the same thread (the
main thread) where SDL video was initialized, and therefore we shouldn’t
be running into thread-related problems.
I’ll take a look when I get back home, but that will be a few days. Thank
you for all your effort to research this, btw.
Yes, thank you very much.
Can you send an updated version of glmovie.c (and any changed smpeg files)
to the SDL mailing list? It sounds like the basic problem was that glmovie
was trying to do OpenGL calls from a different thread, which is a no no.
Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Sam,
As you may have already discovered, the new nVidia driver fixed the
problem, and glmovie.c works as written. The only catch is that I
haven’t managed to get sound to work on my system under Linux (onboard
CMI8738), and unless I disable sound in glmovie it doesn’t play the
video. I do that with the line
SMPEG_enableaudio ( mpeg, 0 );
before
SMPEG_setdisplay(…);
My guess is that glTexSubImage2D() in the earlier driver was faulty.
Gib> To: sdl at libsdl.org
Subject: Re: [SDL] yet more glmovie
From: Sam Lantinga
Date: Mon, 08 Jul 2002 12:43:30 -0700
Reply-To: sdl at libsdl.org