[buggs]

Originally Posted by matthey

The DISPLAY=PIP with or without FULLPIP is still only showing a grey render area with your test version. I see now that the window mode DISPLAY=PIP is also likely a YUV mode even though it is on a 16 bit BGR workbench screen. The interface seems backward to me as DISPLAY=PIP gives a window while other options open a screen (but with FULLPIP it is like opening a screen). I'm surprised there is no non-PIP window mode too. The PIP window mode is friendly and can be moved around like any other intuition window with less than 1 fps difference in performance. Would it be possible to add a non-PIP window setting?

Please see my previous post. PIP support was inoperable when not used in conjunction with the PIVPLANARASSIST option.

Originally Posted by matthey

While testing I discovered another problem with RIVA v0.50 which is still present in the new version. Sometimes the rendered screen shows a garbled screen of diagonal banding with DISPLAY=HICOLOR. I looked at the screen modes being used.
320x256x16PC screen mode to display a 352x256 mpeg (not working)
320x240x16PC screen mode to display a 352x240 mpeg (not working)
320x240x16PC screen mode to display a 320x240 mpeg (working)

This is actually a curious bug. (Told you there were real bugs in RiVA to be found, no pun intended ). It works with UAEGFX, it works on my A4k but it doesn't work on Apollo when using TrueColor (and your setup). I ported my cropping/centering code from SAGA YUV to the other P96 modes. This way, no video beyond the displayed area is rendered and sizes/offsets are implicitly corrected.

Originally Posted by matthey

It may be worthwhile to look into the choice of best mode id and have centering or scaling if the video is narrower than the display (or clipping if the video resolution is larger than the display resolution). A non-PIP window mode and the ability to force a screen mode id and/or resolution could be helpful here for testing even though the switches may have to be changed.

Best Mode ID choice is actually a sad topic with P96. Instead of returning a screenmode that fits the requested dimensions, you get a screen that is quite often smaller than what you asked for. A workaround would be to enumerate all screen modes and re-implement the BestModeID in a custom routine (on the TODO list without "urgency" marker).

Originally Posted by matthey

The performance advantage of MOVE16 depends greatly on whether the 16 byte block should be in the DCache afterward or not. If the block is going to be used from the DCache soon then there is little advantage to using MOVE16 as writes from it bypasses the DCache. On the other hand, it could be useful for large and/or streaming data which would otherwise flush the DCache.

True. In this particular case, the data is of the forgetful kind. As there is no way to fit a video frame into the DCache of available 68k CPUs, Move16 really helps a little with performance.

It must be pointed out, however that the loop in question is the "best case" scenario where previous blocks are just cloned for picture areas where nothing changed between frames. Tech side note: MPEG-1 and -2 don't have the inherent "Macroblock skip" abilities of later standards. Current encoders emulate the skip mode by ending a slice when a number of skip Macroblock candidates are present and continue with the next "coded" Macroblock after the skipped blocks by starting a new bitstream fragment.

Updated 68k binary that should hopefully fix a number of the reported issues: http://bax.comlab.uni-rostock.de/fil...A-0.53a0-m68k3