Re: [Bug-freedink] Screen or Sprites Flickering

[beuc]

Hi,

Let me know if the patch works for you.

Cheers!
Sylvain

On Thu, Mar 16, 2017 at 11:50:15PM +0100, address@hidden wrote:
> Hi,
> 
> On Thu, Mar 16, 2017 at 01:03:56PM -0700, Eric Duhamel wrote:
> > Thank you for following up. I did not get anywhere with compiling
> > from the repository; seems I'd need to patch SDL2 and I'm not sure
> > where to start with that.
> 
> AFAICS the required patches I had submitted are now available in the
> latest SDL2 releases, abeilt not in Debian Jessie (which is too old).
> Recompiling SDL2_* should be enough.
> 
> 
> > On March 16, 2017 12:44:33 PM PDT, address@hidden wrote:
> > >OK so I reflashed my RPI with its stock Raspbian Wheezy.
> > >
> > >I think I had already witnessed this issue and at the time I figured
> > >there was nothing to do, since the framebuffer backend had never
> > >really worked for me in my previous setups.
> > >
> > >Indeed FreeDink/SDL requests a hardware-accelerated surface with
> > >double-buffering, and according to freedink --debug, it gets it.
> > >
> > >However it does not fulfill the contract, it seems we get a
> > >single-buffer surface, which causes the flickering.
> > >(incidentally you were right, this is flickering and not tearing)
> > 
> > If I'm not mistaken, this sounds like a bug in whatever GPU blob is 
> > included in Raspbian.
> 
> Well, anywhere in SDL backend > framebuffer > kernel > driver, my
> mileage with the framebuffer never was very good in other setups.
> 
> 
> > >Technical note: I should be possible to write a local patch to the
> > >flip_it() function so as to introduce an extra buffer.  That would
> > >hurt performances in general, but would fix the flickering on
> > >RPI/framebuffer.  Of course the other option is to run FreeDink under
> > >X11 where it works.  Would either be an option for you?
> > 
> > I'm currently collecting games for a Retropie-like system
> > incorporating libre games instead. The setup tends to run without
> > using X, but I suppose a "startx -- /usr/games/freedink" wouldn't be
> > out of the question if it just works.
> 
> It runs fine for a while on X11:
> http://www.dinknetwork.com/forum.cgi?MID=185679
> Ooh, almost 3 years ago already.
> Just re-tested (on wheezy), just a tad slow (due to CPU at 100%).
> 
> 
> > But I'd be more interested in a local patch to flip-it(), if one
> > were available. If I compile a slightly patched version of legacy
> > Freedink for this purpose I would maintain the fork on Gitlab and
> > packages on Archive.org so others would have access to it. Hoping
> > performance wouldn't take *too* much of a hit.
> 
> Attached is a patch.
> I wrote it in one go and surprisingly everything compiled fine... on my PC.
> Then on the RPI I spent an hour trying to figure out the obnoxious
> /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/libSDL.so: 
> undefined reference to `vc_dispmanx_resource_set_palette'
> error which comes after 3mn of ./configure, and decided that it was
> enough time spent on this.
> So... hope it works for you :)
> 
> 
> > >With SDL2 I believe the framebuffer is not directly supported anymore,
> > >(http://forums.libsdl.org/viewtopic.php?t=9661)
> > >it will be either X11/software, or OpenGL.  Does the RPI still require
> > >proprietary drivers (cf. /opt/vc/) for OpenGL, or did the situation
> > >improve?
> > 
> > I don't think it has. At least I haven't heard anything. Would this
> > mean future SDL2-based releases of Freedink are unlikely to work on
> > the Pi?
> 
> So far the latest codebase has a software mode and an OpenGL mode.
> 
> (I admit I'm tempted to ditch the software mode to reduce the number
> of configurations to test, and avoid having to double-implement all
> future improvements in the graphics primitives.  In which case,
> without 3D card, one would fall back to Mesa 3D software
> implementation.  Which on basic desktop is OK, but possibly too
> demanding for RPI 1.)
> 
> Anyway, for now it's there and working, it can stay.
> 
> Cheers!
> Sylvain

> diff --git a/src/gfx.c b/src/gfx.c
> index 3787451..9cd455a 100644
> --- a/src/gfx.c
> +++ b/src/gfx.c
> @@ -60,6 +60,7 @@ int truecolor = 0;
>  // LPDIRECTDRAWSURFACE     lpDDSTrick2 = NULL;       // Offscreen surface 2
>  
>  
> +SDL_Surface* rpihack = NULL;
>  SDL_Surface *GFX_lpDDSBack = NULL; /* Backbuffer and link to physical
>                                     screen*/
>  
> @@ -307,6 +308,11 @@ int gfx_init(enum gfx_windowed_state windowed, char* 
> splash_path)
>    GFX_lpDDSTrick  = SDL_DisplayFormat(GFX_lpDDSBack);
>    GFX_lpDDSTrick2 = SDL_DisplayFormat(GFX_lpDDSBack);
>  
> +  {
> +    SDL_Surface* t = SDL_DisplayFormat(GFX_lpDDSBack);
> +    rpihack = GFX_lpDDSBack;
> +    GFX_lpDDSBack = t;
> +  }
>  
>    /* Display splash picture, as early as possible */
>    {
> @@ -652,7 +658,8 @@ void flip_it(void)
>    if (truecolor_fade_brightness < 256)
>      gfx_fade_apply(truecolor_fade_brightness);
>  
> -  SDL_Flip(GFX_lpDDSBack);
> +  SDL_BlitSurface(GFX_lpDDSBack, NULL, rpihack, NULL);
> +  SDL_Flip(rpihack);
>  }
>  
>  /* Like SDL_WM_ToggleFullScreen(), except that it works under more