SDL 1.2 with dispmanx backend

[Vanfanel]

Hello there,

I've just published my SDL dispmanx backend, wich is included in the libSDL sources I've put in this repository:

https://github.com/vanfanel/SDL12-kms-dispmanx

The idea behind this backend is to have dispmanx scale the games/apps to native fullscreen resolution, so you *MUST* disable all software scaling inside the games: in other words, 320x240 games must be run in 320x240 and dispmanx will scale them to the native fullscreen resolution without using any cpu.

Just download, run the MAC_ConfigureDISPMANX.sh script and then "make && sudo make install".
WARNING: It will replace Raspbian's default SDL wich only has SLOOOOOW X11 backend and broken fbcon backend (tearing all the way because it uses a broken ioctl() to wait for vsync), so I'm not responsible if it leaves your Raspbian broken. Just re-install default libsdl1.2 and everything should be back to normal, I guess

[obcd]

Thanks for this.
Do you think that an OpenVG implementation of SDL could even more improve it's speed?
Maybe, blitting could be done by the GPU? It's just a thought. I haven't looked much deeper into it. (And I assume you have)

[Narishma]

dispmanx already does the scaling on the GPU. No need for OpenVG.

[obcd]

I understand the scaling part.
On windows, sdl can use hardware accelerated directx. On pc linux, it can use opengl mesa.
On the Pi, it uses directFB which means it get's the base adress of the video memory frame buffer.
I was wondering if it's speed could be improved by using OpenVG or OpenGL ES calls which are also handeled by the GPU. The Pi is supposed to have performant graphics, but nothing seems to use them. It's like having a pc video card without the drivers.
Small correction, omxplayer and xbmc are using it for video playback.

[jamesh]

Dispmanx is the best approach here - it's a HW accelerated system specifically designed of this sort of thing.

[jamesh]

I understand the scaling part.
On windows, sdl can use hardware accelerated directx. On pc linux, it can use opengl mesa.
On the Pi, it uses directFB which means it get's the base adress of the video memory frame buffer.
I was wondering if it's speed could be improved by using OpenVG or OpenGL ES calls which are also handeled by the GPU. The Pi is supposed to have performant graphics, but nothing seems to use them. It's like having a pc video card without the drivers.
Small correction, omxplayer and xbmc are using it for video playback.

XBMC also uses dispmanx for UI acceleration.

Anyone can write stuff that uses the OpenXX drivers and will get acceleration. Quake for example.

[Mequa]

I seem to get an error (in Spanish!) when trying this with my SDL app:

dispmanx: Abriendo display[0]...
El modo de vídeo actual es 1360 x 768
Añadiendo modo 1360 x 768 - 8 bpp
Añadiendo modo 1360 x 768 - 16 bpp
Añadiendo modo 1360 x 768 - 24 bpp
Añadiendo modo 1360 x 768 - 32 bpp

Borrando elementos de dispmanx;

Google translate gives this as follows:

dispmanx: Opening display [0] ...
The current video mode is 1360 x 768
Adding 1360 x 768 mode - 8 bpp
Adding mode 1360 x 768 - 16 bpp
Adding mode 1360 x 768 - 24 bpp
Adding mode 1360 x 768 - 32 bpp

Deleting dispmanx elements;

At which point the program quits.

[Vanfanel]

@Mequa: sorry about that, I've translated initialization messages to english now.
Can you pastebin your program's SDL graphics initialization code? If it's an available program I can test it myself.
Are you trying to use it under X? It won't work, I believe. I don't have/want any X enviroment on the Pi.

[Mequa]

@Mequa: sorry about that, I've translated initialization messages to english now.
Can you pastebin your program's SDL graphics initialization code? If it's an available program I can test it myself.
Are you trying to use it under X? It won't work, I believe. I don't have/want any X enviroment on the Pi.

I'm sure the program's initialisation routines will need some modification to work without X.

The program is XAMOS. It already builds on Raspbian with the standard Linux Makefile provided, but runs horrendously slow with the standard SDL in an X window.

The interpreter (for non-graphical work) has tested to run exceptionally well on Raspbian ARMHF, so it looks promising if a faster graphical engine than unaccelerated X could be provided.

How do the SDL initialisation methods (in GameEngineWrapper.cpp) need to be altered? Here's the current initialization code:

Code: Select all

	// Initialize all SDL subsystems:
	if (SDL_Init(SDL_INIT_EVERYTHING) < 0)
	{
		cout << "Error initialising SDL!" << endl;
		return false;
	}

	// Added - SDL_ttf:
	if (TTF_Init() == -1) 
	{
		cout << "Unable to initialize SDL_ttf: " << TTF_GetError() << endl;
		//exit(1); // return true;
	}
	font = TTF_OpenFont("resources/Default.ttf", 28);

	screen = SDL_SetVideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_BPP, SDL_SWSURFACE); // | SDL_RESIZABLE);

	// If there was an error in setting up the screen:
	if ((screen == NULL) || (font == NULL))
		return false;

I have yet to add a key to quit (I may add ESC and/or CTRL+C to quit in the next build).

[Vanfanel]

@Mequa: If I understood you well, you're trying to make it work from an X console, right?
If that's the case, it won't work. Could you test it without X, please?

[Mequa]

@Mequa: If I understood you well, you're trying to make it work from an X console, right?
If that's the case, it won't work. Could you test it without X, please?

Sure, would you mind modifying the above to work correctly without X?

[Vanfanel]

Ok, Mequa, this is how I would initialize the audio & video systems (I believe using EVERYTHING was causing the early exit error):

Code: Select all

#define SCREEN_HEIGHT  200
#define SCREEN_BPP 0

int main (void){

   TTF_Font *font;
   // Initialize all SDL subsystems:
   if (SDL_Init(SDL_INIT_VIDEO | SDL_INIT_AUDIO) < 0)
   {
     printf ("\nError init SDL\n");
     return 0;
   }

   // Added - SDL_ttf:
   if (TTF_Init() == -1)
   {
      printf ("\nUnable to initialize SDL_ttf: \n");
      //exit(1); // return true;
   }
   font = TTF_OpenFont("resources/Default.ttf", 28);

   SDL_Surface *screen = SDL_SetVideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_BPP, SDL_HWSURFACE | SDL_DOUBLEBUF | SDL_FULLSCREEN);
   if ((screen == NULL) || (font == NULL))
      printf ("\nERROR setting videomde!\n");


   SDL_Quit();
}

I hope it helps. Take into account that WITDTH and HEIGHT should be the NATIVE application resolution, not an scaled resolution! The Pi doesn't have the horsepower for software scaling (nor does it need to have, thanks to dispmanx).

[Mequa]

I'm wondering if dispmanx could be used with ScummVM on Raspbian to scale games at resolutions such as 320x200, 640x400 and 640x480 to whatever native screen resolution is used. (Perhaps DOSBox too, but ScummVM definitely performs better!)

[mongrol]

Anyone tried this with AdvMame yet? Seems like a great idea to squeeze some better performance out it.

[Mequa]

Great, XAMOS now gives 30fps on the Raspberry Pi with the default "Eater" demo (and a bit slower with the Breakout-like demo). Not quite fullspeed 60fps, but getting there.

Using OpenGL ES to draw directly (mapping textures to quads) would be faster though, compared with using a SDL soft-renderer and hard-scaling the output.

I'll release an updated version once I also add a key to quit. It won't run from X, only from fullscreen console.

BTW, a RISC OS port of XAMOS is also in progress.

[Vanfanel]

@Mequa: This dispmanx backend has a blocking SDL_Flip() implementation, so if your application is waiting in each frame to keep a given speed, then you would be losing frames because you would be issuing buffer swap (in the SDL_Flip() function) too late, and changes won't take place until the next vsync arrives... Maybe that's why you're losing frames with this backend.

In the other hand, I don't think GLES is faster for 2D stuff. But please prove me wrong

[Mequa]

A problem I've found - when using this version of SDL running from the console, all SDL apps I've tested (including my project) won't shut down correctly and freeze the Pi when trying to close them.

[Vanfanel]

I'm trying to build this XAMOS, but I get

GameEngineWrapper.h:31:35: fatal error: boost/unordered_map.hpp: No such file or directory

What lib do I have to apt-get in raspbian? There seems to be a lot of this boost lib stuff.

[Mequa]

You don't need Boost to build XAMOS (it's optional), change the Makefile (based on Linux default) as follows:

On the CFLAGS line, remove "-D USEBOOST", and replace with "-Wno-deprecated".

Alternatively, something like this will install all Boost libraries (and will take a long time):
sudo apt-get install libboost1.50*

[ghans]

I'm not sure what you actually have done , but couldn't you
contact asb or plugwash to have this included in Raspbian or
the Raspbian repos ?
It sounds very useful for me , and i believe lots of projects
would benefit from it.


ghans

[Mequa]

I'm trying to build this XAMOS

XAMOS has now been updated to version 0.29, try building the updated version from XAMOS.zip:
http://sourceforge.net/projects/xamos/files/

A binary for Raspbian (XAMOS_raspbian_armhf.tar.gz) is now available which works fullscreen (with ESC or CTRL+C to quit), with both standard SDL and this experimental dispmanx backend.
With the standard SDL build this will need to be run from an X terminal; when using the experimental dispmanx SDL build this needs to be run from a fullscreen console (without X).


Using this dispmanx backend however, XAMOS freezes on quit. I noticed however that this also happens with other SDL applications (Quake 3, ScummVM, etc.) when using this version of SDL. In my tests the Pi freezes up when trying to quit an application/game when using this SDL build from a console.

[Shawty]

Just to let people know, even simple SDL based apps are freezing on quit with this addition.

The following code:

Code: Select all

#include <stdio.h>
#include "bcm_host.h"
#include <SDL/SDL.h>

void exitfunc()
{
  SDL_Quit();
  bcm_host_deinit();
}

int main( int argc, char* args[] )
{
  bcm_host_init();
  atexit(exitfunc);

  SDL_Surface* screen = NULL;

  if( SDL_Init( SDL_INIT_VIDEO) < 0 )
  {
    printf("Unable to init SDL: %s\n", SDL_GetError());
    exit(EXIT_FAILURE);
  }

  const SDL_VideoInfo* videoInfo = SDL_GetVideoInfo ();

  int systemX = videoInfo->current_w ;
  int systemY = videoInfo->current_h ;
  Uint8 bpp = videoInfo->vfmt->BitsPerPixel ;

  screen = SDL_SetVideoMode( systemX, systemY, bpp, SDL_SWSURFACE );
  if (!screen)
  {
    printf("SDL_SetVideoMode failed\n");
    return 0;
  }

  printf("The current video surface bits per pixel is %d\n", screen->format->BitsPerPixel);

  SDL_Rect r = {0,0,320,240};
  SDL_FillRect(screen,&r, SDL_MapRGB(screen->format, 200,200,0) );

  SDL_Flip( screen );

  SDL_Delay( 2000 );

  SDL_Quit();

  return 0;
}

Fails with the same set of "screen mode messages" as reported previously, and it does this reliably every time, from console via frame buffer and from XWindows.

More so, if I'm running this code at the Pi's actual terminal and looking at it's output from an SSH session on another machine, I can't even use kill to end the task, I have no choice but to reboot the Pi in order to get it out of memory. From my limitied investigations, it looks like a thread handler is not exiting somewhere and thus forcing the program to not exit and keeps the image in memory.

If I revert back to the default SDL install then all seems to work ok without a problem.

[Mequa]

I'm trying to build this XAMOS

XAMOS has now been updated to version 0.29, try building the updated version from XAMOS.zip:
http://sourceforge.net/projects/xamos/files/

Just to add - I have added an extra Makefile for Raspbian - please copy src/Makefile_raspbian over src/Makefile before building. (This is necessary to work with this dispmanx backend; the default Makefile or Makefile_unix assumes an X window.)

On the CFLAGS line, remove "-D USEBOOST", and replace with "-Wno-deprecated".

As before, use the edit above to build without using Boost.

[Vanfanel]

@Mequa: The Raspbian makefile has a missing library route. Complete LDFLAGS line would be:

Code: Select all

LDFLAGS=-L/opt/vc/lib -lSDLmain -lSDL -lSDL_image -lSDL_mixer -lSDL_gfx -lSDL_ttf -lEGL -lGLESv2

Without the additional -L/opt/vc/lib, it would compile but linker couldn't find the EGL and GLES libs.
Runs fine here with dispmanx backend. I tried several examples from different categories without any problems. However, they seem to be a bit slow. 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().

@Shawty: I've just updated the backend so your example works. It was my fault as I didn't initialize current video mode variables, so SDL_GetVideoInfo() didn't return the expected results.
Note that you shouldn't be including "bcm_host.h" in an SDL program, nor should you be calling bcm_host_init() or bcm_host_deinit() from it! Those are lower-level functions and the dispmanx backend takes care of that kind of stuff. So please remove those.
Also, in your code you call SDL_Quit() at the end of the main function, but you previously did atexit(exitfunc). Since exitfunc contains an SDL_Quit() call itself, you're calling it twice.
After correcting these minor errors (on both sides), that simple program runs as expected.

I couldn't find ANY program to lock up the Pi or show a black screen on exit. I should make clear that I have no X on the Pi, nor am I interested on testing of fixing anything related to that bloatware, so please run the tests withoun an X server running. Can you guys please test the new version and point me to any fullscreen programs with bad behavior?

[Shawty]

@Vanfanel - I certainly will give it a try.

Tks for the heads up on the bcm_host stuff, I'm beginning to wonder if that's the reason behind the behaviour I'm seeing in my "Pi Graphical Oddities" post.

Since I posted that one, Iv'e removed the bcm_host stuff (on a plain SDL install, not your dispmanx ver) and it's made things a little better but I'm still seeing some strangeness.

I'll not get into that here though, it's a different subject

Same process as in the first post to build your fixed version right?

Cheers

Shawty.