Re: [Bug-freedink] Screen or Sprites Flickering

[beuc]

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

rpihack.patch
Description: Text Data