Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 48
  1. #21
    EmuTalk Member Iconoclast's Avatar
    Join Date
    Aug 2006
    Posts
    900
    Mentioned
    1 Post(s)
    https://github.com/cxd4/rsp

    That is if you are talking about the 32-/64-bit RSP code I was just talking about.

    For the present time, I'm still not interested in discussing the pixel-accurate RDP with GitHub. The RSP is on GitHub.

    As far as building on Windows, the RSP plugin compiles fastest if you have MinGW installed to C:\MinGW and simply double-click the batch file `make_w32.cmd'. A 64-bit Windows build is slightly harder...I think you either need to install MinGW-64 or MSYS2 with 64-bit in it and change the %MinGW% batch variable in my command script to refer to that to get it to compile the 64-bit DLL. I will have to confirm which method is best by the time I do a release of that plugin here as well.



    Either way, the latest RSP recompiler plugin for Project64 current versions still seems faster than my interpreter. I thought for sure I did see a couple cases where I had a SSSE3 build going that was faster than the recompiler plugin in a game I tried, but in general as long as you simply need full speed the re-compiler plugin seems best.

  2. #22
    Texture Pack Invader NES_player4LIFE's Avatar
    Join Date
    Nov 2005
    Location
    Earth
    Posts
    2,173
    Mentioned
    20 Post(s)
    Thread Stuck!
    -NES
    We are in the process of archiving all qualifying texture packs!
    Contact me via PM to have your N64 texture pack hosted on Emulation64.com!
    Having a hard time loading Large packs? Be sure to patch your emulator.
    Can't load .DAT or .HTC archives? Look no further then this shiny Tutorial, Android users may use this Tutorial.

      Spoiler:

  3. #23
    EmuTalk Member
    Join Date
    Jan 2013
    Posts
    7
    Mentioned
    0 Post(s)

    N64

    Hi. Thanks for this but something seems to have changed drastically for me with the VI filters on SuperMario -getting all kinds of weird jaggy pixel crawl that wasn't there in 1.2, esp obvious on 'Mario head' screen (on GTX970, OGL4.5)

    -doesn't seem to make any difference with/without nearest neighbour or screen res settings in case that helps...(can't seem to post screenshots either)

  4. #24
    EmuTalk Member
    Join Date
    May 2013
    Posts
    99
    Mentioned
    5 Post(s)
    Thanks for the help guys.
    I get no crash with your static interpreter plugin.

  5. #25
    EmuTalk Member Iconoclast's Avatar
    Join Date
    Aug 2006
    Posts
    900
    Mentioned
    1 Post(s)
    Quote Originally Posted by fla56 View Post
    Hi. Thanks for this but something seems to have changed drastically for me with the VI filters on SuperMario -getting all kinds of weird jaggy pixel crawl that wasn't there in 1.2, esp obvious on 'Mario head' screen (on GTX970, OGL4.5)

    -doesn't seem to make any difference with/without nearest neighbour or screen res settings in case that helps...(can't seem to post screenshots either)
    I have attached a new release to the original post of the thread which addresses this, along with a few minor changes.

    Thanks for bringing this difficult-to-confirm VI divot filtering discrepancy to my attention. It was a problem with the MinGW/GCC build; prior to the creation of this thread here on EmuTalk, I was always using MSVC 2013 to do the binary releases. However, on July 24th, 2014, it seems I made quite a significant typo which affected non-Visual-Studio builds of the plugin (which, back then, was all that was possible).

    Code:
    #ifdef _MSC_VER
    #define ZERO_MSB(word)    ((unsigned)(word) >> (8*sizeof(word) - 1))
    #define SIGN_MSB(word)    ((signed)(word) >> (8*sizeof(word) - 1))
    #define FULL_MSB(word)    SIGN_MSB(word)
    #else
    #define ZERO_MSB(word)    ((word < 0) ? +1 :  0)
    #define SIGN_MSB(word)    ((word < 0) ? -0 :  0)
    #define FULL_MSB(word)    ((word < 0) ? ~0 :  0)
    #endif
    I'd intended these macros for portability of the RDP outside of a 2's complement CPU, but I seem to have overlooked typing what I actually meant: -1, not -0.

    I also changed the #ifdef _MSC_VER to #if defined(USE_SSE_SUPPORT), as SSE2 is necessarily bound by the Intel CPU architecture fixations. Therefore, divot filtering should be optimized on MinGW/GCC and Linux builds, not just Windows MSVC builds.

    Quote Originally Posted by mendus View Post
    Thanks for the help guys.
    I get no crash with your static interpreter plugin.
    Then it was another problem with the RSP re-compiler.


    By the way folks, yesterday I've already modified post #3 of this thread to include my PixD utility attached to the post, near the bottom with the instructions on using the "Write DRAM" button in the configuration UI. It is a ZIP archive of Windows-only binary release. The Linux binary can be obtained by making sure you have the freeglut headers and libraries installed, then executing ./make.sh to build it ourselves. As for building it on Windows, it uses Mark Kilgard's non-free glut32 library instead of freeglut, which you could officially obtain from the latest NVIDIA SDK.

  6. #26
    EmuTalk Member
    Join Date
    Apr 2015
    Location
    Sofia, Bulgaria
    Posts
    2
    Mentioned
    0 Post(s)
    Hello,

    I'm getting an 'unidentified microcode' error whatever I try to do.
    Could anyone help?

    PJ:2.2
    OS: Win 7
    GFXCard: ASUS GTX970

  7. #27
    EmuTalk Member Ambient_Malice's Avatar
    Join Date
    Feb 2015
    Posts
    11
    Mentioned
    0 Post(s)
    Quote Originally Posted by neverwind View Post
    Hello,

    I'm getting an 'unidentified microcode' error whatever I try to do.
    Could anyone help?

    PJ:2.2
    OS: Win 7
    GFXCard: ASUS GTX970
    Disable High Level graphics emulation?

  8. #28
    EmuTalk Member
    Join Date
    Apr 2015
    Location
    Sofia, Bulgaria
    Posts
    2
    Mentioned
    0 Post(s)
    Quote Originally Posted by Ambient_Malice View Post
    Disable High Level graphics emulation?
    Hey, thanks, that worked!

    I've tried WWF - No Mercy - at first it was awfully slow. After enabling the RSP plugin, it's now a lot better but still it has some slowdowns.
    However, I noticed my Video Card's clocks stay the same as if it is in idle mode all the time? Could this be the reason for the slowdowns?

  9. #29
    EmuTalk Member
    Join Date
    Apr 2015
    Posts
    1
    Mentioned
    0 Post(s)
    Just installed it on 2.2 (it's not working ot 2.1 though)
    It works, but so hard
    PJ64 2.2 is slow by itself (slower than 1.6)
    with this plugin I'm only getting 15-20fps
    Audio is stuttering
    Is there a way to make SkipFrame option?

  10. #30
    EmuTalk Member Iconoclast's Avatar
    Join Date
    Aug 2006
    Posts
    900
    Mentioned
    1 Post(s)
    Quote Originally Posted by neverwind View Post
    However, I noticed my Video Card's clocks stay the same as if it is in idle mode all the time? Could this be the reason for the slowdowns?
    It's faster to use the CPU, than it is to use the video card, just to specify one pixel at a time.
    So I think the reason for what you said is that the video card is mostly used to draw the final screen as a texture, but not to emulate the RDP itself.

    Otherwise, it would not be a per-pixel plugin. Really, video cards are proficient at handling vectors, floating-point, things like that. Just forcing pixel-exact correctness is more of a scalar operation. It always is conceivable for some video driver/implementation, somewhere, to have some way to use hardware-accelerated OpenGL to do pixel-accurate emulation of the RDP. That would not work on every implementation, though--it would be pixel-accurate, hardware-accelerated rendering on some video hardware but most likely none of our own. ziggy did seem pretty interested in giving it a shot before he left, though. His hardware-accelerated plugin was a fantastic attempt, but it seems to have started too early in time, back when MAME implementation and some reversing of the RDP hardware was still too incomplete.

    From time to time, I do think about the idea, but I think gaining more practical experience with the RDP triangle spans rendering and working on simplifying more deadwood for speed first would help that idea more if it came before rather than after.

    Quote Originally Posted by Alex Cherkasoff View Post
    Just installed it on 2.2 (it's not working ot 2.1 though)
    Update Project64.rdb, if you want to test on 2.1.

    Virtually all of the "best" RDB settings for Project64 1.6 were tested with HLE plugins. When you use LLE, some extra stuff gets executed, so it's more prone to the effects of bad re-compiler settings in the Project64 CPU and the like.

    Quote Originally Posted by Alex Cherkasoff View Post
    PJ64 2.2 is slow by itself (slower than 1.6)
    with this plugin I'm only getting 15-20fps
    Audio is stuttering
    All three of those things coincide. If audio, graphics, RSP, the core, or any other component to emulation slows down the overall emulation, then audio with most plugins will also slow down and "stutter". I'm quite used to it by now. Actually, haven't yet found a audio plugin that doesn't stutter if emulation isn't at full speed.

    Quote Originally Posted by Alex Cherkasoff View Post
    Is there a way to make SkipFrame option?
    It's documented in post #3: You can skip every few N triangles or every few N vertical refreshes of the screen.

    The speed gain from skipping every N refreshes is less observable, of course, if you just bypass the DAC filters, which also is faster.

Page 3 of 5 FirstFirst 12345 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
  •