SDL 1.2 with dispmanx backend


80 posts   Page 2 of 4   1, 2, 3, 4
by Vanfanel » Fri Dec 14, 2012 3:50 pm
@Shawty: right, sir! :)
Posts: 268
Joined: Sat Aug 18, 2012 5:58 pm
by Mequa » Fri Dec 14, 2012 4:37 pm
Vanfanel wrote:@Mequa: The Raspbian makefile has a missing library route.

Thanks for spotting this. Makefile_raspbian has been fixed, and has now been updated in XAMOS.zip and XAMOS_src.zip.
*UPDATE* This is available now in the above files.

Vanfanel wrote:Are there any calculations/waits inside the interpreter code to archieve a constant frame rate? PLEASE, take into account SDL_Flip() blocks until next vsync arrives, so these internal delays are meant to keep a constan frame rate in SDL backends with broken (non-blocking) SDL_Flip().

The pertinent code is as follows:
Code: Select all
      // Update the screen:
      if (useopengl)
      {
#if defined(USESDL) && !defined(GLES)
         SDL_GL_SwapBuffers();
#endif
#if defined(USESDL) && defined(GLES)
         //eglSwapBuffers(g_eglDisplay, g_eglSurface);
#endif
      }
      else
      {
         if (SDL_Flip(screen) == -1)
            return; // -1
      }

      // Cap the frame rate:
      //if (!useopengl) // TODO - Vsync not supported on all platforms?
#if defined(USESDL) && !defined(GLES)
         if (fps.get_ticks() < 1000 / FRAMES_PER_SECOND)
            SDL_Delay(( 1000 / FRAMES_PER_SECOND ) - fps.get_ticks());
#endif

OpenGL ES is not yet working with XAMOS, however the GLES flag is used when building for Raspbian to also disable any such delay.
User avatar
Posts: 49
Joined: Sun Sep 09, 2012 9:54 pm
Location: UK
by Vanfanel » Sat Dec 15, 2012 11:16 am
Mequa: Demos are running at 30FPS after removing the FPS adjustment delay you posted.
I'm not diving into the code and there could be multiple causes to this, but maybe it's expected after all, isn't it?
Posts: 268
Joined: Sat Aug 18, 2012 5:58 pm
by recliq » Sat Dec 15, 2012 1:25 pm
Vanfanel: This is working great with VICE, thanks for the great work.
HOwever I have once issue: It always scales to fullscreen not respecting aspect ratio. For example using VICE with 800x600 resultion is scaled to 1920x1200 on my 16/10 monitor. Is there a way to maintain 4/3 aspect ratio when scaling?
Posts: 38
Joined: Wed Jun 13, 2012 4:56 pm
by Mequa » Sat Dec 15, 2012 2:50 pm
Vanfanel wrote:Mequa: Demos are running at 30FPS after removing the FPS adjustment delay you posted.
I'm not diving into the code and there could be multiple causes to this, but maybe it's expected after all, isn't it?

Not bad for now. Does the framerate drop below 30FPS?
On X I get no more than 12FPS.

I think OpenGL ES would be faster though - instead of blitting surfaces, it would map textures to quads.
That would take the load off the ARM and give the XAMOS interpreter more room to work. I'm quite confident the Pi could achieve 60FPS running the XAMOS interpreter with OpenGL ES output.
User avatar
Posts: 49
Joined: Sun Sep 09, 2012 9:54 pm
Location: UK
by Vanfanel » Sat Dec 15, 2012 3:10 pm
@Mequa: I'm thinking about using GLES on the dispmanx SDL backend for the same purpose.

@recliq: I believe it can be done, yes, but for now (until I get some kind of accelerated blitting, wich is top priority now) you can boot your Pi in a 4:3 mode and disable 16:9 stretching on your monitor.
Posts: 268
Joined: Sat Aug 18, 2012 5:58 pm
by Shawty » Sat Dec 15, 2012 3:39 pm
@vanfanel - I'm pleased to let you know it's all fixed now.

and I've no idea what you did, BUT......

You've also fixed the issue I was experiencing in my "Pi Graphical Oddness" topic elsewhere in this forum.

Mad Props to you :-)
Still crazy (Even since the days of my BBC Model B) BEST and only way to be ;-)

IM: @shawty_ds on twitter (and a few other places too)
if you remember the Acorn and BBC days then I was "!Shawty! of DSPD" (Author of the BBC B soundtracker suite)
User avatar
Posts: 48
Joined: Fri Nov 16, 2012 1:22 am
Location: North East UK
by ghans » Sun Dec 16, 2012 12:46 pm
Could this be of possible interest to the guys of libsdl.org ?
I mean , can't those changes be included in SDL ,
so that people can enable HW Scaling (or disable SW scaling ?!) ?

Do i have misunderstood something ? Am i being dumb ?
Tell if i should shut up - i'm just a bit enthusiastic about
your work :D


Greetings,
ghans
• Don't like the board ? Missing features ? Change to the prosilver theme ! You can find it in your settings.
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org
Posts: 4612
Joined: Mon Dec 12, 2011 8:30 pm
Location: Germany
by Vanfanel » Sun Dec 16, 2012 3:33 pm
@ghans: I don't think libSDL people would be interested in my humble work,as they are about to release SDL 2.0 wich has a GLES and (hopefully) can simulate blitting by using hardware blending thechniques.
Anyway, I saw there was need for accelerated scaling in current SDL 1.2.X since I was ashamed when looking at youtube videos showing the lovely Rpi running games and emulators on poor, small screen areas, and since most apps/games DO use SDL 1.2 for now.
So right now I'm learning GLES2 so I can bring accelerated blits to the Pi in current SDL 1.2.X.

When SDL 2.0 is released, however, I'm almost sure they'll use X11 GLES, meaning awful X (wich is a plague): that will be a good time to add support for dispmanx via EGL (remember OpenGL is windowing system-agnostic).

On the other hand, last time I asked for help in the SDL channel at freenode, I got insulted because I didn't know how to align memory to a given size, so I'm not really interested in asking that people for anything.

And I really like people passionate about the things they like, so don't worry and ask or say what you want! :D
Posts: 268
Joined: Sat Aug 18, 2012 5:58 pm
by jamesh » Sun Dec 16, 2012 5:18 pm
Vanfanel wrote:On the other hand, last time I asked for help in the SDL channel at freenode, I got insulted because I didn't know how to align memory to a given size, so I'm not really interested in asking that people for anything.


There really are some stupid people on this planet, and people like you encountered on the SDL channel are in that group. Morons.
Soon to be employed engineer - Hurrah! Volunteer at the Raspberry Pi Foundation, helper at PiAcademy September 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11926
Joined: Sat Jul 30, 2011 7:41 pm
by mongrol » Mon Dec 17, 2012 4:13 am
I tried this with advmame and witnessed no change, no autoscaling or anything. How can I test if it's getting invoked or not?
Posts: 76
Joined: Wed Aug 01, 2012 2:43 am
by GuardianBob » Thu Feb 07, 2013 6:16 pm
So best I can tell this doesn't work properly with the 8 bit resolution.

The pixel format VC_IMAGE_8BPP appears to be CYMK not RGB.
Posts: 15
Joined: Mon Feb 04, 2013 1:41 pm
by mongrol » Fri Feb 08, 2013 1:54 am
Would that affect advmame?
Posts: 76
Joined: Wed Aug 01, 2012 2:43 am
by GuardianBob » Fri Feb 08, 2013 7:17 pm
mongrol wrote:Would that affect advmame?

It could in some corner cases.

The bigger issues I found were some API calls would cause problems, such as SDL_VideoModeOK (appeared to always return false) and SDL_SetGammaRamp (crashed the running program).

Debugging is made harder as the console output is ignored once EnterGraphicsMode is called. Redirection seems to work around this issue.
Posts: 15
Joined: Mon Feb 04, 2013 1:41 pm
by kalehrl » Wed Feb 13, 2013 4:40 pm
Thank you Vanfanel for your dispmanx backend.
I installed it and I get as much as 25% speed improvement in some games such as Time Pilot using advmame. All advmame games work fine and produce sound.
However, some games which worked fine before now play with no sound.
Quake3 and games using dgen emulator are silent.
When I run quake3, I see that it's using dispmanx and it seems to be much quicker than before but the sound is missing. The same goes for games run using dgen.
Does this mean that I need to recompile quake3 and dgen?
Posts: 343
Joined: Tue Jul 24, 2012 10:49 am
by Vanfanel » Wed Feb 13, 2013 9:16 pm
@kalehlr: I have teste the dispmanx backend with dgen several times in the past, since the autor reported framerate halving with it when he was using it with dgen, and it sounded. Well, as good as it can sound, at least :D
The backend shouldn't cause any audio problems: it's a video backend and SDL audio relies on ALSA, not related to dispmanx.
Recompiling is not needed: any SDL app linked against the default libSDL 1.2 dynamic libraries should be 100% compatible with the dispmanx backend without further modifications (unless you have to manually disable software scaling in the game's source...but then again, it's not an audio problem :)).
Posts: 268
Joined: Sat Aug 18, 2012 5:58 pm
by kalehrl » Wed Feb 13, 2013 11:00 pm
At first it didn't compile because of changed file location of vchost_config.h.
I solved it by using:
Code: Select all
export CFLAGS="-I/opt/vc/include/interface/vmcs_host/linux"

and running the ./MAC_ConfigureDISPMANX.sh again.
Maybe it messed something up with compilation but I doubt it.
After it finished, sudo make install.
Have you tested it with the latest firmware and kernel?
Posts: 343
Joined: Tue Jul 24, 2012 10:49 am
by kalehrl » Thu Feb 14, 2013 9:40 am
I got the sound but I had to run autogen.sh before MAC_ConfigureDISPMANX.sh.
Now the sound works fine!
Posts: 343
Joined: Tue Jul 24, 2012 10:49 am
by welshy » Tue Feb 19, 2013 12:13 am
Vanfanel wrote:you can boot your Pi in a 4:3 mode and disable 16:9 stretching on your monitor.


Having problems with Aspect Ratio, how exactly do you alter the Config to achive this? (I'm using HDMI)
Posts: 1371
Joined: Mon Oct 29, 2012 2:07 pm
by recliq » Wed Feb 20, 2013 6:35 pm
I patched this project to keep aspect ratio some time ago, it's probably a dirty hack (I'm not really a programmer) but I works for me.
I hope this helps or at least gets you in the right direction.

Note: This patch will only handle horizontal padding adding bars to left/right, it was intended to display 4:3 content aspect correct on 16:10 monitor.

Code: Select all
diff --git a/src/video/dispmanx/SDL_fbvideo.c b/src/video/dispmanx/SDL_fbvideo.c
index d43b882..8d60d84 100644
--- a/src/video/dispmanx/SDL_fbvideo.c
+++ b/src/video/dispmanx/SDL_fbvideo.c
@@ -368,14 +368,23 @@ static SDL_Surface *DISPMANX_SetVideoMode(_THIS, SDL_Surface *current,
        //this->offset_x = (dispvars->amode.width - width)/2;
        //this->offset_y = (dispvars->amode.height - height)/2;

-       printf ("\nUsing internal program mode: width=%d height=%d\n",
-               width, height);
+       float aspect = (float)width / (float)height;
+       printf ("\nUsing internal program mode: width=%d height=%d aspect=%.3f\n",
+               width, height, aspect);
+
+

        //MAC Por ahora en DISPMANX usamos el mismo modo q ya está establecido
        printf ("\nUsing physical mode: %d x %d %d bpp\n",
                dispvars->amode.width, dispvars->amode.height,
                dispvars->bits_per_pixel);

+       int disp_width = dispvars->amode.height * aspect;
+       int offset = (dispvars->amode.width - disp_width) / 2;
+       if (offset < 0)
+               offset = 0;
+       printf ("Using display size: %d x %d  offset: %d\n", disp_width, dispvars->amode.height, offset);
+
        //MAC Establecemos el pitch en fn del bpp deseado
        //Lo alineamos a 32 porque es el aligment interno de dispmanx(en ejemp)
        dispvars->pitch = ( ALIGN_UP( width, 16 ) * (bpp/8) );
@@ -388,9 +397,12 @@ static SDL_Surface *DISPMANX_SetVideoMode(_THIS, SDL_Surface *current,

        vc_dispmanx_rect_set (&(dispvars->src_rect), 0, 0,
           width << 16, height << 16);
-
+/*
        vc_dispmanx_rect_set( &(dispvars->dst_rect), 0, 0,
           dispvars->amode.width , dispvars->amode.height );
+*/
+       vc_dispmanx_rect_set( &(dispvars->dst_rect), offset, 0,
+      disp_width, dispvars->amode.height );

        //MAC Establecemos alpha. Para transparencia descomentar flags con or.
        VC_DISPMANX_ALPHA_T layerAlpha;
@@ -474,7 +486,7 @@ static SDL_Surface *DISPMANX_SetVideoMode(_THIS, SDL_Surface *current,
        /* We're done */
        //MAC Disable graphics 1
        // Set the terminal into graphics mode
-        printf ("\nDISPMANX_SetVideoMode activating keyboard and exiting");
+        printf ("\nDISPMANX_SetVideoMode activating keyboard and exiting\n");
        if ( DISPMANX_EnterGraphicsMode(this) < 0 )
                return(NULL);



The elegant solution would be to implement vertical padding as well and enable it by some environment variable I guess...
Posts: 38
Joined: Wed Jun 13, 2012 4:56 pm
by BBUK » Thu Feb 21, 2013 9:05 am
Has anyone noticed that the latest raspbian apt-get upgrade appears to break this dispmanx/SDL installation (even after reinstalling dispmanx/SDL after the upgrade)?

My symptoms are that SDL applications (advmame in particular) fail to initialise, complaining about a missing .so). I have not investigated this thus far (a simple symlink could solve the issue).

Apt-get install --reinstall libsdl1.2debian enables the application to run but obviously without the benefit of the dispmanx backend.

BBUK
Posts: 99
Joined: Tue Dec 18, 2012 10:34 am
by recliq » Thu Feb 21, 2013 9:14 am
Have you tried recompiling advmame against this SDL version?
Posts: 38
Joined: Wed Jun 13, 2012 4:56 pm
by BBUK » Thu Feb 21, 2013 10:06 am
Thanks recliq.

I didn't think that would make a difference - I thought the new backend would kick in automatically, hence from the application's perspective it is just making ordinary library calls. It is that backend that does the scaling. What I am working on worked perfectly on Tuesday and the apt-get upgrade (which I did not take a great deal of notice of but included some libc files) is the only changed condition between Tuesday and Wednesday.

I much admit, however, that I compile advmame before the new SDL/dispmanx backend but no problem to switch this around. I will test this (but I will first check for compilation errors in the new backend (and the location of the missing file) and see if patch the issue away).

Can anyone else who uses this backend confirm it still works after an attempt to reinstall the backend after an apt-get upgrade (latest Wheezy)?

Rgds
Posts: 99
Joined: Tue Dec 18, 2012 10:34 am
by kalehrl » Thu Feb 21, 2013 10:18 am
This morning I did update and upgrade and, as you say, it pulled some libc and libc-dev files.
After this, I'm no longer able to start emulationstation which may be connected with what you've been experiencing with advmame.
The error I get is 'error while loading shared libraries: libbcm_host.so: can't open shared object file: no such file or directory'.
Posts: 343
Joined: Tue Jul 24, 2012 10:49 am
by kalehrl » Thu Feb 21, 2013 10:59 am
Also, snes9x no longer works.
It reports libGLESv2.so missing but this file is present in /opt/vc/lib!
Since it is an .so file, it's rights should be 755 not 644!
The update must have been a real cock-up!
Posts: 343
Joined: Tue Jul 24, 2012 10:49 am