Pandora improved SDL for pandora

[mcobit]

I once had a problem like this. Do you setup the stuff with setenv in the code or with the startupscript?


If you use the startupscript, try the other method.

 

[Magic Sam]

Hi,


Thank you very much Notaz for your hard work on SDL


@ Pickle: do you plan to update Giana's Return with this library ?


Bye, Magic Sam

 

[captain_coconut]

With just these videos if I use -vo omapfb I see evenly spaced horizontal lines in the video that are off in color. I don't see this if I play with -vo xv or in other media players.

that omapfb code uses some NEON color space converter, maybe it has some bug. Can you make a small video sample that demonstrates the problem? I don't have any DVDs here.

Sorry about the slow reply. I have been looking into this further and yes, it does appear to be a bug in the neon color space converter code. I'm not sure how to fix the bug in the existing NEON code, but I did manage to fix the bug basing the color space conversion on code from xf86-video-omap.


Here is a 10 second video illustrating the problem. The horizontal lines are very apparent on the orange tshirt. They appear to happen every 2 out of 3 frames, if you advance frame by frame with pressing . (period)


https://docs.google....jNlNmZkNTM1NTNm


mencoder command line for above video:

/usr/bin/mencoder "dvd://5" -o "omapfb_problem.avi" -endpos 10 -dvd-device THE_BIG_BANG_THEORY_SEASON1_D2 -nosub -ofps 24000/1001 -vf softskip,scale=624:352:0,harddup -sws 10 -aid 128 -oac mp3lame -lameopts abr:br=140:aq=4:vol=2.2:mode=1 -ovc xvid -xvidencopts bitrate=1200:threads=2:me_quality=6:vhq=3:max_bframes=2:bvhq=1:trellis:chroma_me:chroma_opt:hq_ac:nolumi_mask:closed_gop:noqpel:nogmc:nopacked:rc_reaction_delay_factor=0:rc_averaging_period=100:autoaspect:nointerlacing

Here is a patch where I used a modified function from the xf86-video-omap to do the color space conversion.


https://docs.google....TQ1MmE3MGJkMTRl

 

[notaz]

Here is a patch where I used a modified function from the xf86-video-omap to do the color space conversion.


https://docs.google....TQ1MmE3MGJkMTRl

Hm, I wonder what effect on performance this has, the old asm seems to be making better use of NEON..

 

[captain_coconut]

Here is a patch where I used a modified function from the xf86-video-omap to do the color space conversion.


https://docs.google....TQ1MmE3MGJkMTRl

Hm, I wonder what effect on performance this has, the old asm seems to be making better use of NEON..

I'm not sure the difference offhand, and its perhaps best to fix the original code, however I got stuck. If I set a breakpoint in draw_slice() and repeatedly hit continue, I was unable to reproduce the horizontal line problem, which makes me wonder if there is some sort of timing issue.


Update:


Not sure if this is meaningful regarding performance:


Original code:

time ./mplayer-old -fs -endpos 60 -vo omapfb /media/mmcblk1p1/movies/bbt-d2-4.avi

real 1m0.972s

user 0m19.445s

sys 0m0.695s

With patch I sent:

time ./mplayer -fs -endpos 60 -vo omapfb /media/mmcblk1p1/movies/bbt-d2-4.avi

real 1m1.016s

user 0m19.188s

sys 0m0.766s

 

[StreaK]

just for the record:


Adding Notaz SDL libs to fheroes2 , causes heavy flickering in the game [on all Notaz SDL configs] and renders game unplayable.

 

[notaz]

just for the record:


Adding Notaz SDL libs to fheroes2 , causes heavy flickering in the game [on all Notaz SDL configs] and renders game unplayable.

You do use the latest binary right?


It has been silently updated several times.

 

[mcobit]

Also, if there is the sdl_doublebuff flag in sdlinit, remove it!

 

[StreaK]

just for the record:


Adding Notaz SDL libs to fheroes2 , causes heavy flickering in the game [on all Notaz SDL configs] and renders game unplayable.

You do use the latest binary right?


It has been silently updated several times.

Yes, of course. I pulled it from git few days [maybe 4 days] ago.

 

[john4p]

With this new SDL lib there's now tearing in UAE4All. Looks like doublebuffering is broken.


With the November 2010 version of your lib there was no tearing at all.


Could you please look into this problem?


Here's the zipped uae4all-folder containing the binaries and your latest SDL lib:


http://www.mediafire.com/?g8106xjf3wsoe9p


You just need to add a 512k 1.3 kickstart image named kick.rom into the dir and then execute runme.sh to start the emu. The tearing is already noticeable in the GUI. In sidescrolling games it's very heavy.


I hope with this you can debug your SDL and solve the issue.

 

[notaz]

Do you set SDL_DOUBLEBUF on SDL_SetVideoMode()?


Previously this used to be force-enabled but it broke games that don't fully redraw, so you have to specify it explicitly now.

 

[john4p]

Yes, I set it with every call. With this version I only do the following call (which is called everytime when the environment variables are changed):


prSDLScreen = SDL_SetVideoMode(320, 270, 16, SDL_SWSURFACE|SDL_FULLSCREEN|SDL_DOUBLEBUF);


I've also tried to set the respective environment variable for forced doublebuffering prior to starting the emulator which didn't make a difference.

 

[Wally]

I can confirm this helps Basilisk 2 and the touch screen works great now (except for the grabbing issue but I think thats in the code itself)

 

[john4p]

I've now built your previous SDL versions and tested them with UAE4All.


This is the one which brought the tearing:


http://notaz.gp2x.de...26066658e313065


It's the release where you changed oshide.c/.h into xenv.c/.h.


If you can't solve the doublebuffering issue in the current version could you maybe release a version that uses the old oshide-stuff but has your new feature "Add support for border removal" from the Nov. 23rd version?


I've tried to merge the new feature into the Sep 16th release and could build the lib - but although uae4all starts with it (no tearing) it crashes with a segfault as soon as the bordercut-feature is utilized.


edit: After reverting the changes done to fbdev.c/.h, osdl_video.c and sdlif.c in the 1st "tearing-release" to their versions from a non-tearing version the resulting lib still caused tearing. So it's safe to assume the problem lies in xenv.c.

 

[notaz]

I'm quite sure it's not xenv.c, in osdl_video.c, try changing last argument to vout_fbdev_init() from 2 to 3, and osdl_setup_omapfb() last argument from ... * 2 to ... * 3.

 

[john4p]

Yes - that was it! Tearing is gone.


Thanks a bunch!

 

[john4p]

Adding Notaz SDL libs to fheroes2 , causes heavy flickering in the game [on all Notaz SDL configs] and renders game unplayable.

Here's the modified SDL lib which solved the tearing issue with UAE4All:


http://www.mediafire.com/?28xlnhkxmtxdi78


Maybe Heroes2 works fine with it, too.

 

[notaz]

ok a new build available at the usual location:


http://notaz.gp2x.de...psdl_latest.zip


Changes:

• deal with different DSS2 (OMAP display driver) versions better
  
• use tripple buffering when enough memory is available for reduced chance of tearing (app must still set SDL_DOUBLEBUF or SDL_OMAP_FORCE_DOUBLEBUF env variable), fall back to doublebuffering if not (print a warning)
  
• support external mice, nubs in mouse mode
  

With these john4p's build should no longer be needed.


If there are no issues reported in a few days, I'll queue this for next firmware update.

 

[milkshake]

woop

 

[Linux-SWAT]

Cool !


Nice to see mouse support.