Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 48
  1. #31
    EmuTalk Member
    Join Date
    Jan 2013
    Posts
    7
    Mentioned
    0 Post(s)
    Thanks for the patch, looks perfect now

    On the subject of GPU vs CPU just wondering -is it possible/beneficial to use the GPU/OpenGL shaders to do the VI filters? Maintain per-pixel accuracy with a mostly software RDP but a healthy speedup overall?


  2. #32
    EmuTalk Member Iconoclast's Avatar
    Join Date
    Aug 2006
    Posts
    900
    Mentioned
    1 Post(s)
    That probably is possible. For the VI DAC filters, some of us have talked about using OpenGL hardware features to handle them instead of doing them all on the CPU. RetroArch has the best feature of investigating into that, I believe. The reasons why I do not invest in it are:

    • lack of GLSL or other forms of modern OpenGL knowledge as well as any interest in having it, along with any of other of Khronos' illogical choices of function replacement and/or deprecation
    • the fact that they can just be bypassed in the plugin settings--No filters emulation is even faster than OpenGL-accelerated emulation of them.
    • fundamental portability: OpenGL is intended to be cross-platform because it is an open specification, but systems are free to decline implementing OpenGL. In this case, doing the VI filters on the CPU as standard C code is more portable than using OpenGL 2.0+ or GLSL to do it.


    However, it is an interesting idea anyway, just one that I prefer not to transfer my time into. Probably the mupen64plus-libretro core usable in the RA frontend may be able to offer it sometime, though for the time being I prefer to keep my application of OpenGL down to just the portable (which is already very hard, when you're working with OpenGL) necessities needed to put an image out to the screen.

  3. #33
    EmuTalk Member
    Join Date
    Jan 2013
    Posts
    7
    Mentioned
    0 Post(s)
    Interesting...as you say, need the speed so I turn the filters off but then there are games like Beetle Rally that need them on -would a neater solution be to run them on separate CPU thread(s)?

    On a separate note unfortunately still looks like RDP bugs are still there, think I missed it first time I retested sorry -still getting pixel crawl++ in SM64 :-(
    Last edited by fla56; April 30th, 2015 at 03:18.

  4. #34
    EmuTalk Member Iconoclast's Avatar
    Join Date
    Aug 2006
    Posts
    900
    Mentioned
    1 Post(s)
    Quote Originally Posted by fla56 View Post
    Interesting...as you say, need the speed so I turn the filters off but then there are games like Beetle Rally that need them on -would a neater solution be to run them on separate CPU thread(s)?
    In what way does Beetle Rally need them on? Does it just look too ugly with them off?

    Re: run VI/RDP on multi CPU threads, I would rather not because I'm not a multi-threading guy. The simplest and purest pieces of software engineering are written for one thread.

    Quote Originally Posted by fla56 View Post
    On a separate note unfortunately still looks like RDP bugs are still there, think I missed it first time I retested sorry -still getting pixel crawl++ in SM64 :-(
    Hm, what RDP bugs in SM64?

    Could you perhaps post a jumbled up link (http : // www . blah blah) to a screenshot showing this, in case EmuTalk tries to filter out links in posts from new users?

    Also, if it's a RDP bug, then you'll see the glitchy graphics with VI filters turned off, not just on. I would turn them off so that the filtering doesn't intervene with the raw RDP frame buffer output for a sharper image to study the bug more clearly. However, with that said, I am confident that there are no RDP bugs at all with this release.

  5. #35
    EmuTalk Member
    Join Date
    Jan 2013
    Posts
    7
    Mentioned
    0 Post(s)
    Quote Originally Posted by Iconoclast View Post
    In what way does Beetle Rally need them on? Does it just look too ugly with them off?

    Hm, what RDP bugs in SM64?

    Could you perhaps post a jumbled up link (http : // www . blah blah) to a screenshot showing this, in case EmuTalk tries to filter out links in posts from new users?

    Also, if it's a RDP bug, then you'll see the glitchy graphics with VI filters turned off, not just on. I would turn them off so that the filtering doesn't intervene with the raw RDP frame buffer output for a sharper image to study the bug more clearly. However, with that said, I am confident that there are no RDP bugs at all with this release.
    Hi -Beetle Racing has a VI-driven sliding film effect in the menus but have jst tested and it seems to work with the option on or off 'oops/great!' -take it VI filters separate from other parts of the VI (apparently some football games do similar things too)

    Re: RDP -think I'm getting my phrasiology wrong -by 'RDP' think I really mean 'RDP plugin' -as you suggest the errors only occur with VI filters on therefore if there is a bug it's in the VI part of the RDP plugin code...

    Will post screenshots to the old PJ64 forum
    Last edited by fla56; April 30th, 2015 at 13:29.

  6. #36
    EmuTalk Member
    Join Date
    Feb 2007
    Posts
    10
    Mentioned
    0 Post(s)

    wrong aspect ratio

    If I use pal games then the picture is stretched vertically while the ntsc (us) version has the rigth aspect ratio.
    You can easily verify this with zelda oot Eur version vs. US.

    PS.
    This doesn't happen with the previous version of the plugin (angrylion's RDP with OpenGL 1.2) from the pj64-emu.com thread.
    RSP is always the static interpreter.
    Attached Images Attached Images  
    Last edited by elchhome; May 5th, 2015 at 11:32. Reason: update information

  7. #37
    EmuTalk Member Iconoclast's Avatar
    Join Date
    Aug 2006
    Posts
    900
    Mentioned
    1 Post(s)
    I've been working on an update to fix 64-bit Linux run-time collisions (never had problems with 32-bit Mupen64 0.5 on Linux). I was able to test the build in Mupen64Plus 1.5 x64 but unable to get any video frames to send through the VI because Mupen64Plus 1.5 keeps failing to update VI_V_SYNC_REG causing a constantly negative number of active video lines--therefore, there is no way that this plugin can be ported to Mupen64Plus 1.5+ without fixing the regression in their core. Maybe I will look into trying plain 64-bit build of Hacktarux's interpreter in Mupen64 0.5, as the performance gains here with the RCP outweigh whether the CPU is being re-compiled or interpreted anyway.

    Sorry about delays by the way. It's fun when you can contribute to a bunch of projects besides just your own.

    Quote Originally Posted by elchhome
    If I use pal games then the picture is stretched vertically while the ntsc (us) version has the rigth aspect ratio.
    You can easily verify this with zelda oot Eur version vs. US.

    PS.
    This doesn't happen with the previous version of the plugin (angrylion's RDP with OpenGL 1.2) from the pj64-emu.com thread.
    Yes elchhome, thanks for mentioning it. This experiment of mine is something I've spent the past few days wondering about, what I should do with it.

    It was for games that draw NTSC-proportionate frame buffers, like 40 Winks, that would look squished if you had a 640x480 window instead of a 640x576 window. (There are 576 lines based on VI_V_SYNC_REG when PAL mode is detected.) You can get a pretty good comparison if you turn VI filters off.

    OOT PAL forced to 480 lines, VI filters off:


    OOT PAL at 576 lines, VI filters off:


    The same can be observed with angrylion's unmodified plugin, except that due to the VI filters always being emulated, this kind of discrepancy isn't so noticeable. Therefore it's not a bug, but I do wonder about whether I should change to a 640x576 window automatically. Care to help me decide? You should be able to configure the graphics DLL to set a "User-defined" resolution, and enter 640x480 to the right to force the NTSC window size for OOT PAL and other games. Which do you think looks better, with or without filters?

  8. #38
    EmuTalk Member Iconoclast's Avatar
    Join Date
    Aug 2006
    Posts
    900
    Mentioned
    1 Post(s)
    Changes since the last attachment to the thread. --updated 2015.06.13 --

    • renamed extension-loaded OpenGL functions to fix Mupen64Plus collisions
    • exporting non-zilmar-spec `ReadScreen' to fix SIGSEGV's on Mupen64Plus 1.5
    • removed the automatic window size adjustment for PAL images to 640x576
    • fixed premature blanking of the rainbow colored bars boot screen
    • added some more forced OpenGL state configuration commands
    • fixed leftover VI garbage seen for an instant when switching between ROMs
    • staticized texture coverage LOD fraction calculations
    • optimized filling large buffers of memory with a single byte
    • merged r84 from upstream angrylions-stuff/mylittle-nocomment
    • many optimizations to YUV texture element fetching and YUV-RGB conversion
    • merged r85 from upstream angrylions-stuff/mylittle-nocomment
    • improved 16-bit R5G5B5 frame buffer reads with dynamic branch weighing
    • optimized coverage buffer allocation and YUV texture LUT decoding
    • merged r86 from upstream angrylions-stuff/mylittle-nocomment
    • folded RGB comparisons for dithering
    • merged most of r87 from upstream angrylions-stuff/mylittle-nocomment
    • improved combiner equation performance with dynamic branch prediction
    • removed the 3-bit restriction on color dither randomization masks
    • supports newly discovered VI pixel destruction on clamped hres or h_start
    • merged r88 from upstream angrylions-stuff/mylittle-nocomment
    • statically preserving x_start initial value in case of RCP timing issues
    • some finalized corrections to horizontal pass max-clamping
    • merged r89 from upstream angrylions-stuff/mylittle-nocomment
    • guaranteeing sufficient VI divot and aliasing buffer sizes
    • passes some more technical RCP hardware tests involving x line caching


    It works in Mupen64Plus 1.5 32-bit and earlier versions, but 64-bit Mupen64 needs to be compiled differently due to corrupt allocation of the RCP registers (most easily ignored as a result of routinely practicing HLE of most components).
    Last edited by Iconoclast; June 14th, 2015 at 05:01.

  9. #39
    EmuTalk Member
    Join Date
    Aug 2015
    Posts
    1
    Mentioned
    0 Post(s)
    Wow! What a truly impressive plugin! If it's all right to make a suggestion, I think that a scanline feature would be awesome for this. It's just a thought though. I look forward to seeing more of this promising plugin.

  10. #40
    EmuTalk Member Iconoclast's Avatar
    Join Date
    Aug 2006
    Posts
    900
    Mentioned
    1 Post(s)
    I had thought about it a year ago, but, being unfamiliar with the way things like that work, I was puzzled on a few issues.

    • how the scanlines should originate...alternating even or odd lines starting from the top or the bottom
    • how OpenGL should "render" the scanlines
    • various feedback from people preferring 50% scanlines, 25 or 75% or different concentrations


    I haven't tried to implement them, but there could be a way to minimize their weight against performance, in the event that most people would prefer to play games without them.

    Have had a number of interesting projects intercepting here and there, though, but I still mean to get back to this one as well.

Page 4 of 5 FirstFirst ... 2345 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •