Re: [Bug-freedink] Screen or Sprites Flickering

[Eric Duhamel]

On March 19, 2017 3:49:45 PM PDT, address@hidden wrote:
>Hi,
>
>Let me know if the patch works for you.
>

Thank you for taking the time to write a patch. I apologize for the delay.

The changes compiled flawlessly --I applied them to release 108.4-- and the 
flicker is now gone in framebuffer on my Raspberry Pi. I'm surprised it did 
work at all, since you said you had trouble with it on your Pi.

However, everything is now in psychedelic colors. There must have been a 
graphics mode problem somewhere in the fix?

I wonder if I made a mistake applying the patch. In fact, I had some trouble 
doing it and just typed in the changes by hand. The changes were so simple 
though I can hardly imagine that's it.

>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


--
Eric Duhamel
http://www.noxbanners.net/