[Plugin N64] angrylion’s Per-Pixel RDP with OpenGL (2015/04/24)

Posté le 25/04/2015 à 13:15 par Jets

Il s’agit de la suite du plugin vidéo de Angrylion destiné aux émulateurs de N64 permettant à ceux-ci de proposer une image extrêmement proche de la Nintendo 64 originelle

Now that I’m able to give posting here another chance, I decided that it seemed easier on everybody to have the rest of the development downloadable via the forum here. I’m sorry that it was inconveniencing people in so many issues when I was trying to make it work with the PJ forum. For those who haven’t known, a group of developers after the MAME N64 drivers started to do more reverse-engineering of the RDP after ziggy released his nice, accelerated OpenGL fork of MESS RDP at his z64gl thread. Since then, angrylion has done several hardware tests and reversing to verify his maintained C implementation of various informative sources. (I have also done a few tests myself to confirm 100% bit-by-bit graphical accuracy, with help from dsx and ExtremeDude2 who were able to capture pixel-by-pixel real N64 screenshots, both with and without the video DAC filtering.)

So what about my own fork of it here? Well, only 2 reasons really drove me to do my own fork. In the end, the biggest reason is that angrylion’s original plugin uses Microsoft DirectDraw, which of course on Windows has excellent blitting acceleration support but also is constricted to a couple unfortunate circumstances of GPU-defined graphical behavior with their closed specifications. I was happy to practice some basic, primitive OpenGL code to rewrite the plugin to force visual correctness, eventually having Linux releases (starting now). The other reason is that, from time to time, I like to staticize the C code (which includes but is not limited to SIMD vectorization, for example MMX ).

In an older generation of working on the plugin, performance and getting the plugin to work at full speed was the top priority. I hope that with this release, I have focused on enough portability, standards-compliance, compatibility etc. issues that I can look at making the plugin faster again. Not much in the way of speed has changed since the last download, except that my OpenGL blitting code is much faster now (GL 1.5 buffer mapping extensions to VRAM, if your hardware supports it), but if everyone is happy otherwise I can start to look at speed again finally.

The `/bin` folder has 32- and 64-bit Windows and Linux releases, but I only advise installing the 32-bit Windows plugin until we are able to test out a working 64-bit version of zilmar’s plugin specifications. If you’re on Linux, it’s even better to try just executing `./make.sh` in the source folder instead of using my pre-compiled binary release.

Voici les changements:

    – sharper OpenGL rendering quality on the visual screen (NN and bi-linear)
    – better compatibility with older OpenGL implementations
    – OpenGL 1.5 extensions for hardware-accelerated rasterization of the VI
      image as two triangles, rather than pixel data sent through the CPU bus
    – compatible with OpenGL ES 1.x specifications
    – now fully ported to compile outside of Windows
    – able to maintain 64-bit and 32-bit Windows and GNU builds
    – renamed build files from « mylittle-nocomment » to « vigl »
    – no more VS2013 files, just vigl.vcproj and .vcxproj for VS2005 and VS2010
    – repaired old VI origin scanline regression when in 480i interlaced mode
    – rewrote RDP tex_rect and tex_rect_flip commands (fixed GE 007 menus)
    – up-to-date with latest revisions upstream on Google Code as of r83
    – more changes to the DLL configuration GUI by RPGMaster
    – changed some confusing, maybe misleading elements to the Win32 GUI
    – new GUI option to export 4, 8, or 16 MB RDRAM to a binary output image
    – changed screen captures to check old file names to prevent overwriting
    – changed screen captures to write shots thru DAC if not DP FB res. formula
    – screen clearing to black background color, not gray or magenta
    – some scattered improvements to vectorizing some more of the RDP in places
    – no longer any CRT dependencies, either dynamically or statically linked
      (no more msvcr*.dll requirement on Windows, uses plain kernel32)
    – I can’t remember. Too many more commits to read to name other changes.