Hi all;
I am trying to get ffplay working on WinCE via SDL. I managed to
compile SDL fine, only GAPI is enabled. But when I try to play a video
with ffplay I just see a blank screen with only borders, no video no
image. FFplay seems to work since the audio is working fine.
Is there a way to debug this or should I assume gapi is broken in SDL trunk?
Best Regards.–
?smail D?NMEZ
Hi again;On Fri, Jul 17, 2009 at 1:43 PM, ?smail D?nmez<@Ismail_Donmez> wrote:
I am trying to get ffplay working on WinCE via SDL. I managed to
compile SDL fine, only GAPI is enabled. But when I try to play a video
with ffplay I just see a blank screen with only borders, no video no
image. FFplay seems to work since the audio is working fine.
Replying to myself, I don’t even see gapi debug messages on console so
I am not sure SDL is initializing GAPI at all. Is there a way to debug
SDL rendering process so I can see whats going wrong?
Regards.
–
?smail D?NMEZ
Hi Ismail,
sorry, just got your private eMail…
Is there a way to debug this or should I assume gapi is broken in SDL
trunk?
Theres always a way to debug 
Please note that GAPI is officially deprecated and is already removed
from current devices. The gapi renderer will not be developed any further.
You should definitely switch to the DDraw Renderer. Both the Gapi and
the DDraw Renderers are pretty primitive ones which are basically only
capable of giving you a screenbuffer. You should therefore use the
software renderer to take advantage of all the SDL blitting stuff.
Your setup should then look something like this:
…
SDL_InitSubSystem( SDL_INIT_VIDEO );
SDL_putenv(“SDL_VIDEO_RENDERER=software”);
SDL_putenv(“SDL_VIDEO_RENDERER_SWDRIVER=ddraw”);
…
if you’re still keen on the gapi driver, all the code lies in
win32/SDL_gapirender.c,
you should at least get some debug info about the chosen display
settings etc.
See line 36 to enable basic debug output and line 67 for some further
logging…
Hope this helps a bit.
Regards
Stefan
Hi! and thanks for replying;
Hi Ismail,
sorry, just got your private eMail…
Is there a way to debug this or should I assume gapi is broken in SDL
trunk?Theres always a way to debug
Please note that GAPI is officially deprecated and is already removed from
current devices. The gapi renderer will not be developed any further.
You should definitely switch to the DDraw Renderer. Both the Gapi and the
DDraw Renderers are pretty primitive ones which are basically only capable
of giving you a screenbuffer. You should therefore use the software renderer
to take advantage of all the SDL blitting stuff.
Your setup should then look something like this:
So far so good but cegcc does not ship a ddraw.h hence I can’t enable
it while compiling SDL, any replacement for that one?
…
SDL_InitSubSystem( SDL_INIT_VIDEO );
SDL_putenv(“SDL_VIDEO_RENDERER=software”);
SDL_putenv(“SDL_VIDEO_RENDERER_SWDRIVER=ddraw”);
I will try this with GAPI for now.
…
if you’re still keen on the gapi driver, all the code lies in
win32/SDL_gapirender.c,
you should at least get some debug info about the chosen display settings
etc.
See line 36 to enable basic debug output and line 67 for some further
logging…
Thanks!On Mon, Jul 20, 2009 at 6:18 PM, Stefan Klug<klug.stefan at gmx.de> wrote:
–
?smail D?NMEZ
Hi again,
…
SDL_InitSubSystem( SDL_INIT_VIDEO );
SDL_putenv(“SDL_VIDEO_RENDERER=software”);
SDL_putenv(“SDL_VIDEO_RENDERER_SWDRIVER=ddraw”);I will try this with GAPI for now.
Tried this and “gapi” as software driver and ffplay is telling me;
SDL: could not set video mode - exiting
Regards.–
?smail D?NMEZ
Hi;On Mon, Jul 20, 2009 at 6:31 PM, ?smail D?nmez<@Ismail_Donmez> wrote:
Hi again,
…
SDL_InitSubSystem( SDL_INIT_VIDEO );
SDL_putenv(“SDL_VIDEO_RENDERER=software”);
SDL_putenv(“SDL_VIDEO_RENDERER_SWDRIVER=ddraw”);I will try this with GAPI for now.
Tried this and “gapi” as software driver and ffplay is telling me;
SDL: could not set video mode - exiting
ffplay is trying to use SDL_HWSURFACE|SDL_ASYNCBLIT|SDL_HWACCEL flags,
guess that might be the problem.
Regards.
–
?smail D?NMEZ
Hi again;On Mon, Jul 20, 2009 at 6:33 PM, ?smail D?nmez<@Ismail_Donmez> wrote:
Hi;
On Mon, Jul 20, 2009 at 6:31 PM, ?smail D?nmez<@Ismail_Donmez> wrote:
Hi again,
…
SDL_InitSubSystem( SDL_INIT_VIDEO );
SDL_putenv(“SDL_VIDEO_RENDERER=software”);
SDL_putenv(“SDL_VIDEO_RENDERER_SWDRIVER=ddraw”);I will try this with GAPI for now.
Tried this and “gapi” as software driver and ffplay is telling me;
SDL: could not set video mode - exiting
ffplay is trying to use SDL_HWSURFACE|SDL_ASYNCBLIT|SDL_HWACCEL flags,
guess that might be the problem.
Tried the following code:
w = 656;
h = 478;
flags = SDL_SWSURFACE;
SDL_SetVideoMode(w, h, 24, flags);
and it fails.
Regards.
–
?smail D?NMEZ
?smail D?nmez schrieb:
Hi again;
Hi;
Hi again,
…
SDL_InitSubSystem( SDL_INIT_VIDEO );
SDL_putenv(“SDL_VIDEO_RENDERER=software”);
SDL_putenv(“SDL_VIDEO_RENDERER_SWDRIVER=ddraw”);
I will try this with GAPI for now.
Tried this and “gapi” as software driver and ffplay is telling me;SDL: could not set video mode - exiting
ffplay is trying to use SDL_HWSURFACE|SDL_ASYNCBLIT|SDL_HWACCEL flags,
guess that might be the problem.Tried the following code:
w = 656;
h = 478;
flags = SDL_SWSURFACE;
This doesn’t look like a device resolution. Was this resolution really
returned by a call to SDL_GetDisplayMode()?
Try something like:
count = SDL_GetNumDisplayModes();
for(i=0; i<count; i++) {
SDL_GetDisplayMode(i, &mode);
printf(“SDL: %d x %d\n”, mode.w, mode.h);
}
count = SDL_GetNumRenderDrivers();
printf(“RenderDrivers: %i\n”,count);
for(i=0; i<count; i++) {
SDL_GetRenderDriverInfo(i,&rinfo);
printf(“name: %s\n”,rinfo.name);
}
to get more info about the supported modes.
Regards Stefan> On Mon, Jul 20, 2009 at 6:33 PM, ?smail D?nmez wrote:
On Mon, Jul 20, 2009 at 6:31 PM, ?smail D?nmez wrote:
?smail D?nmez schrieb:
So far so good but cegcc does not ship a ddraw.h hence I can’t enable
it while compiling SDL, any replacement for that one?
Yes thats really sad. I’m not happy with this, but for copyright reasons
it’s not possible to add a M$ ddraw.h to cegcc. One would have to
reverse engineer ddraw.h to get it added but I don’t have the time to do
that.
But creating your own from the M$ SDK is not that difficult…
And its really worth it. I had some severe performance problems with
gapi on windows mobile 6.1 (e.g. blitting times of 50ms whilest ddraw
needed 5ms)
Regards
Stefan
Hi,On Tue, Jul 21, 2009 at 9:06 AM, Stefan Klug<klug.stefan at gmx.de> wrote:
?smail D?nmez schrieb:
Hi again;
On Mon, Jul 20, 2009 at 6:33 PM, ?smail D?nmez<@Ismail_Donmez> wrote:
Hi;
On Mon, Jul 20, 2009 at 6:31 PM, ?smail D?nmez<@Ismail_Donmez> wrote:
Hi again,
…
SDL_InitSubSystem( SDL_INIT_VIDEO );
SDL_putenv(“SDL_VIDEO_RENDERER=software”);
SDL_putenv(“SDL_VIDEO_RENDERER_SWDRIVER=ddraw”);I will try this with GAPI for now.
Tried this and “gapi” as software driver and ffplay is telling me;
SDL: could not set video mode - exiting
ffplay is trying to use SDL_HWSURFACE|SDL_ASYNCBLIT|SDL_HWACCEL flags,
guess that might be the problem.Tried the following code:
w = 656;
h = 478;
flags = SDL_SWSURFACE;This doesn’t look like a device resolution. Was this resolution really
returned by a call to SDL_GetDisplayMode()?Try something like:
count = SDL_GetNumDisplayModes();
for(i=0; i<count; i++) {
? ? ? ?SDL_GetDisplayMode(i, &mode);
? ? ? ?printf(“SDL: ?%d x %d\n”, mode.w, mode.h);
}count = SDL_GetNumRenderDrivers();
printf(“RenderDrivers: %i\n”,count);
for(i=0; i<count; i++) {
? ? ? ?SDL_GetRenderDriverInfo(i,&rinfo);
? ? ? ?printf(“name: %s\n”,rinfo.name);
}to get more info about the supported modes.
Device reports 480 x 800 as the only supported mode (in portrait mode,
as expected). So I tried
SDL_GetVideMode( SDL_SetVideoMode(480, 800, 0, SDL_FULLSCREEN)
and still no luck, also tried 16 as bpp. Device reports gdi, gapi &
software as rendering drivers.
Regards and thanks for your invaluable help!
–
?smail D?NMEZ
Hi,
?smail D?nmez schrieb:
So far so ?good but cegcc does not ship a ddraw.h hence I can’t enable
it while ?compiling SDL, any replacement for that one?Yes thats really sad. I’m not happy with this, but for copyright reasons
it’s not possible to add a M$ ddraw.h to cegcc. One would have to reverse
engineer ddraw.h to get it added but I don’t have the time to do that.
One question. Do I have to compile in ddraw support in SDL to use
software ddraw renderer? I am asking since the machine I have just
have a SoC graphics support and not much strong hardware.
But creating your own from the M$ SDK is not that difficult…
And its really worth it. I had some severe performance problems with gapi on
windows mobile 6.1 (e.g. blitting times of 50ms whilest ddraw needed 5ms)
Thanks I will look into this depending your answer to my question above 
Regards.On Tue, Jul 21, 2009 at 9:14 AM, Stefan Klug<klug.stefan at gmx.de> wrote:
–
?smail D?NMEZ
?smail D?nmez schrieb:
Device reports 480 x 800 as the only supported mode (in portrait mode,
as expected). So I triedSDL_GetVideMode( SDL_SetVideoMode(480, 800, 0, SDL_FULLSCREEN)
and still no luck, also tried 16 as bpp. Device reports gdi, gapi &
software as rendering drivers.
hm that sounds strange… seems there is no way around firing up a
debugger and having a deep look.
Did you ever get GAPI to work (without sdl)? SDL loads gx.dll on
runtime. Are you sure that this succeeds?
What about the dib backend. In my tests it gave better performance than
the GAPI backend (at least on newer devices).
Regards Stefan
Hi,
?smail D?nmez schrieb:
Device reports 480 x 800 as the only supported mode (in portrait mode,
as expected). So I triedSDL_GetVideMode( SDL_SetVideoMode(480, 800, 0, SDL_FULLSCREEN)
and still no luck, also tried 16 as bpp. Device reports gdi, gapi &
software as rendering drivers.hm that sounds strange… seems there is no way around firing up a debugger
and having a deep look.
Fighting with gdbserver atm.
Did you ever get GAPI to work (without sdl)? SDL loads gx.dll on runtime.
Are you sure that this succeeds?
Never tried that but TCMP manages to play video files so my guess is
GAPI and/or ddraw works on the device.
What about the dib backend. In my tests it gave better performance than the
GAPI backend (at least on newer devices).
Should I enable those via SDL_putenv(“SDL_VIDEO_RENDERER=…”) ? Btw
I got some confusion over this driver deal:
Regards.On Wed, Jul 22, 2009 at 11:13 AM, Stefan Klug<klug.stefan at gmx.de> wrote:
–
?smail D?NMEZ
?smail D?nmez schrieb:
Hi,
?smail D?nmez schrieb:
So far so good but cegcc does not ship a ddraw.h hence I can’t enable
it while compiling SDL, any replacement for that one?Yes thats really sad. I’m not happy with this, but for copyright reasons
it’s not possible to add a M$ ddraw.h to cegcc. One would have to reverse
engineer ddraw.h to get it added but I don’t have the time to do that.One question. Do I have to compile in ddraw support in SDL to use
software ddraw renderer? I am asking since the machine I have just
have a SoC graphics support and not much strong hardware.
That shouldn’t matter, as long as you’re only blitting to the screen,
the graphics chip isn’t that much involved.
You’ll have to compile SDL with ddraw support, but the ddraw.dll is
loaded at runtime…
Regards
Stefan> On Tue, Jul 21, 2009 at 9:14 AM, Stefan Klug<@Stefan_Klug> wrote:
Hi,On Wed, Jul 22, 2009 at 11:17 AM, Stefan Klug<klug.stefan at gmx.de> wrote:
?smail D?nmez schrieb:
Hi,
On Tue, Jul 21, 2009 at 9:14 AM, Stefan Klug<klug.stefan at gmx.de> wrote:
?smail D?nmez schrieb:
So far so ?good but cegcc does not ship a ddraw.h hence I can’t enable
it while ?compiling SDL, any replacement for that one?Yes thats really sad. I’m not happy with this, but for copyright reasons
it’s not possible to add a M$ ddraw.h to cegcc. One would have to reverse
engineer ddraw.h to get it added but I don’t have the time to do that.One question. Do I have to compile in ddraw support in SDL to use
software ddraw renderer? I am asking since the machine I have just
have a SoC graphics support and not much strong hardware.That shouldn’t matter, as long as you’re only blitting to the screen, the
graphics chip isn’t that much involved.
You’ll have to compile SDL with ddraw support, but the ddraw.dll is loaded
at runtime…
Btw I add “-Wl,–image-base -Wl,0x10000” to EXTRA_LDFLAGS to make SDL
compile per your suggestion from older emails to sdl list. Would that
affect the stability of the library?
Regards.
–
?smail D?NMEZ
Hi,On Wed, Jul 22, 2009 at 11:13 AM, Stefan Klug<klug.stefan at gmx.de> wrote:
?smail D?nmez schrieb:
Device reports 480 x 800 as the only supported mode (in portrait mode,
as expected). So I triedSDL_GetVideMode( SDL_SetVideoMode(480, 800, 0, SDL_FULLSCREEN)
and still no luck, also tried 16 as bpp. Device reports gdi, gapi &
software as rendering drivers.hm that sounds strange… seems there is no way around firing up a debugger
and having a deep look.Did you ever get GAPI to work (without sdl)? SDL loads gx.dll on runtime.
Are you sure that this succeeds?What about the dib backend. In my tests it gave better performance than the
GAPI backend (at least on newer devices).
I am able to see a black screen with SDL_VIDEO_RENDERER_SWDRIVER=gdi"
. SDL automatically puts device into portrait mode, that might be the
reason for black screen. But sure I am getting somewhere! Thanks!
Regards.
–
?smail D?NMEZ
?smail D?nmez schrieb:
Should I enable those via SDL_putenv(“SDL_VIDEO_RENDERER=…”) ? Btw
I got some confusion over this driver deal:
- Do I have to compile in ddraw support to have ddraw software driver?
- ie. can I use SDL_putenv(“SDL_VIDEO_RENDERER_SWDRIVER=ddraw”)
without enabling ddraw support in SDL?Regards.
AHH ok I think I got it. The Software driver acts as a layer on top of
another driver.
SDL 1.3 expects all render drivers to expose their native functionality.
If the user/programmer requests an action not supported by the render
driver (lets say creating 24bit rgb surface, if the screen is 16bit 565)
the action will fail. No fallback is provided.
Here comes the Software renderer into play. The software renderer
emulates all functionality provided by sdl. The actual render driver
(set by SDL_VIDEO_RENDERER_SWDRIVER=ddraw) only has to be able to do
blitting in its native device format.
As in current WinCE devices the ddraw drivers are rarely hardware
accelerated and the SDL software renderer is pretty well optimized this
is the best way to go.
So yes, you need to compile with ddraw and then use the software
renderer on top of the ddraw renderer.
But as soon as you use the software renderer
SDL_putenv(“SDL_VIDEO_RENDERER=software”);
the only way to tell the software renderer which backend to use is to
SDL_putenv(“SDL_VIDEO_RENDERER_SWDRIVER=ddraw”);
Hope this helps.
Cheers
Stefan
Btw I add “-Wl,–image-base -Wl,0x10000” to EXTRA_LDFLAGS to make SDL
compile per your suggestion from older emails to sdl list. Would that
affect the stability of the library?Regards.
I don’t think so (but I’m not sure). I think the worst thing which could
happen is that WinCE has to do runtime relocations, which might hurt
performance.
If I remember correctly, the problem was a jump to a library function
which failed to link, if the image base was too high.
I don’t know what happens to this jump on runtime relocation…scary.
Any lowlevel compiler hackers out there?
Hi,
?smail D?nmez schrieb:
Should I enable those via SDL_putenv(“SDL_VIDEO_RENDERER=…”) ? Btw
I got some confusion over this driver deal:
- Do I have to compile in ddraw support to have ddraw software driver?
- ie. can I use SDL_putenv(“SDL_VIDEO_RENDERER_SWDRIVER=ddraw”)
without enabling ddraw support in SDL?Regards.
AHH ok I think I got it. The Software driver acts as a layer on top of
another driver.
SDL 1.3 expects all render drivers to expose their native functionality. If
the user/programmer requests an action not supported by the render driver
(lets say creating 24bit rgb surface, if the screen is 16bit 565) the action
will fail. No fallback is provided.
Here comes the Software renderer into play. The software renderer emulates
all functionality provided by sdl. The actual render driver (set by
?SDL_VIDEO_RENDERER_SWDRIVER=ddraw) only has to be able to do blitting in
its native device format.
As in current WinCE devices the ddraw drivers are rarely hardware
accelerated and the SDL software renderer is pretty well optimized this is
the best way to go.
Thanks for the lengthy explanation!
So yes, you need to compile with ddraw and then use the software renderer on
top of the ddraw renderer.
But as soon as you use the software renderer
SDL_putenv(“SDL_VIDEO_RENDERER=software”);
the only way to tell the software renderer which backend to use is to
SDL_putenv(“SDL_VIDEO_RENDERER_SWDRIVER=ddraw”);
Sadly my device does not support ddraw (checked ROM, there is no
ddraw.dll), and since GAPI crashing too and only GDI showing a black
window I should look for other solutions.
Regards.On Wed, Jul 22, 2009 at 2:54 PM, Stefan Klug<klug.stefan at gmx.de> wrote:
–
?smail D?NMEZ
Hi,On Wed, Jul 22, 2009 at 2:59 PM, Stefan Klug<klug.stefan at gmx.de> wrote:
Btw I add “-Wl,–image-base -Wl,0x10000” to EXTRA_LDFLAGS to make SDL
compile per your suggestion from older emails to sdl list. Would that
affect the stability of the library?Regards.
I don’t think so (but I’m not sure). I think the worst thing which could
happen is that WinCE has to do runtime relocations, which might hurt
performance.
If I remember correctly, the problem was a jump to a library function which
failed to link, if the image base was too high.
I don’t know what happens to this jump on runtime relocation…scary.
Any lowlevel compiler hackers out there?
Btw this hack is still required to compile SDL on WinCE (at least this
is the case with cegcc).
Regards.
–
?smail D?NMEZ