PCSXR-PGXP

Discussion in 'PCSX Discussion' started by iCatButler, Aug 8, 2016.

  1. otherman

    otherman New Member

    Messages:
    93
    Likes Received:
    9
    Nope, latest nightlies has it back to opengl3.
  2. Reventon2010

    Reventon2010 New Member

    Messages:
    65
    Likes Received:
    7
    Pretty strange. I downloaded the latest nightly just 2 days ago. I have all 3 BIOS with correct MD5 checksum. All cue files are correct. But it crashes with no error as soon as you pick a game. There's even no visible errors in the log.

    What version do you have? x86 or x64? I chose x64.
  3. superjupi

    superjupi New Member

    Messages:
    114
    Likes Received:
    15
    Cores will crash on game load if the cores are configured to use a different draw method (ddraw, OGL, Vulkan, etc) than RetroArch's UI, I know that much. I also used to have a crash on game load if I had any shaders at all applied, even simple 2x, on a PSX or N64 core, no exceptions, on my old video card.
  4. Reventon2010

    Reventon2010 New Member

    Messages:
    65
    Likes Received:
    7
    Could it be that the Core is defaulted to Vulkan by mistake? I'll check the cfg for it when I'm back on my PC.
  5. the_randomizer

    the_randomizer Fluffy Animal Admirer

    Messages:
    3,390
    Likes Received:
    39
    I can't even get the core to use hardware acceleration, much less PGXP >.>
  6. superjupi

    superjupi New Member

    Messages:
    114
    Likes Received:
    15
    Yeah, you could kinda stand to use a GPU upgrade @the_randomizer :(

    I was forced into an upgrade recently, so I know the feels.

    Edit: 660 isn't as old as I thought it was. I was sure it was six years old by now. Nevermind me, I'm senile.
    Last edited: Dec 15, 2016
  7. VibbyVibbs

    VibbyVibbs New Member

    Messages:
    11
    Likes Received:
    0
    That's a whole lot of red...

    Trying out PGXP's debug mode in Chrono Cross. Red isn't good, is it?

    Attached Files:

  8. iCatButler

    iCatButler New Member

    Messages:
    102
    Likes Received:
    179
    There are a number of modes, the first one shows how vertices are being processed (red = unprocessed, blue = processed, green = cached etc.). There's more information in "Debug Visualisations" section of the first post.

    That image looks like one of the latter 2 modes which show depth information from either the GTE or Ordering Table (from nearest in blue to furthest in red). In which case that image looks really good :D
  9. VibbyVibbs

    VibbyVibbs New Member

    Messages:
    11
    Likes Received:
    0
    If I recall, this is actually the second debug mode (Out of all three in total), being quote for quote, "display depth values as a spectrum through blue, green and red. The second mode being the 'w' components of the vertices." In which case, how good is this looking?
  10. iCatButler

    iCatButler New Member

    Messages:
    102
    Likes Received:
    179
    For PGXP's purposes the 'w' component is the depth information generated by the GTE when it transforms vertices into screen space. It's used for perspective correct texturing as it can tell the GPU the relative depth of all the vertices in a polygon.

    The values in that image are about the best you can expect. It's clear the further points are toward the red end of the spectrum and nearer ones blue, with a smooth gradient in between. This means that there should be no problems with texturing and the values could even be used for to create a proper z-buffer (possibly at some point in the future).

    Most games produce 'w' components that are suitable for perspective correct texturing. All that this requires is that for any given polygon the further vertices have a greater depth than those nearer. The most notable exception is Gran Turismo 2, which stitches the environment together from patches of geometry that have different depth information. This results in some border triangles having depth values that stretch from the furthest limit to the nearest in the wrong direction resulting in incorrect texturing.
    Show Spoiler

    As you can see some triangles are shaded from red/yellow to blue in the wrong direction, resulting in oddly stretched textures.
    [​IMG]
    [​IMG]

    More commonly the games will process elements at different scales but won't stitch them together like this. The result is that textures appear correct but any attempt to build a Z-buffer from the values would be incorrect.
    Show Spoiler
    As you can see, while the main level geometry appears correct, the sky and repeating or dynamic objects appear out of order in terms of depth.
    [​IMG]
  11. Reventon2010

    Reventon2010 New Member

    Messages:
    65
    Likes Received:
    7
    How is the current compatibility/useability of Retroarch PGXP compared to Pcsxr?
    I can try it myself once they've added compatibility back in for OGL 3.3.
  12. VibbyVibbs

    VibbyVibbs New Member

    Messages:
    11
    Likes Received:
    0
    Ahh, understood then. Seems like PGXP is doing its job very well in Chrono Cross then. Very good too, as Chrono Cross is a BEAUTIFUL game for the Playstation, the very best actually!
    (Heck, if you overclock an emulator, you can actually get a full unlocked 60 FPS in CC!)

    As for the Z-buffer, i'm really hoping this can become reality, as another plugin has already attempted a Z-buffer, GPUbladesoft.
    A Z-buffer would be nice, as much like the Super Nintendo's Super FX games, and whatever 3D games came around that same time, you tend to have plenty of bugs without a Z-buffer.
    The most common Z-buffer issue in Chrono Cross tends to be with the main protagonist, Serge, during battles. Take a look at his right hand.

    Serge's right hand is supposed to be in front of the grip of his swallow, not behind it. Yet, it'll "correct" itself as the camera continues to pan around him and put the swallow's grip behind his hand...? (Also, random polys on his model tend to "flash" as the game struggles without a Z-buffer.)

    Yeah, a Z-buffer would be awesome.

    Attached Files:

  13. superjupi

    superjupi New Member

    Messages:
    114
    Likes Received:
    15
    edgbla's BladeSoft was one of the forebearers of increased GTE accuracy, and the forebearer of perspective correct textures. It never actually implemented a Z-buffer, though. To truly get a Z-buffer method in place for every PlayStation game would include an immense number of game-by-game optimizations with not many generalized implementations. There are a tremendous number of ways the myriad of developers attempted to mitigate seams, jitters, and distortions in their own way that there is no cut and dry method, as much as Sony prodded developers to adhere to a standard convention. As long as it ran on hardware and looked good, all was fair.

    I'm deeply impressed by iCatButler's work with PGXP, though it's a fair argument that just intercepting Z data before it gets discarded isn't a catch all solution. Some games play really nice, many others do not. That PGXP has come this far is nothing short of astonishing and admirable.
  14. VibbyVibbs

    VibbyVibbs New Member

    Messages:
    11
    Likes Received:
    0
    PGXP as a whole to me is a very great and welcome addition to PSX emulation, and i'm wondering how much further it can go. How much more polygon jittering can we reduce? How much more can we prevent texture distortion? Will a Z-buffer happen with enough built up dedication from the community? I dunno, only time can tell.

    The next thing I would be able to think of is being able to overclock the PSX without audio glitches and such, so that we can experience true 60 FPS for any game that would allow it.
    To me, the best bet is Mednafen PSX's Vulkan renderer. Even the GL renderer on Mednafen PSX alone, when combined with PGXP, actually seems to have even less polygon jittering than PCSXR, which is awesome!
  15. Reventon2010

    Reventon2010 New Member

    Messages:
    65
    Likes Received:
    7
    If we could unlock the fps just like in n64 emulators, that would be amazing. Then perhaps texture filtering without the visible seems between each texture.

    But it is still amazing how far emulation has come. The sheer dedication that has been put in by many people over the years is incredible.
  16. VibbyVibbs

    VibbyVibbs New Member

    Messages:
    11
    Likes Received:
    0
    I think it'd be kinda tricky to find out how to make such a texture filtering method to work with all the games in the PSX library.
    However, unlocked FPS might be easier than expected; Chrono Cross for example can already run at an unlocked FPS on Mednafen PSX w/ CPU Overclock toggle turned on!
    It's not a stable 60 FPS, the game runs around 30 FPS or 20 FPS most of the time (Rare drops to 15 FPS), but it's still doable, AND it doesn't ruin ingame audio!

    Attached Files:

  17. fischkopf

    fischkopf Member

    Messages:
    191
    Likes Received:
    12
    Most PS1 games have an internal frame limit of 30 so you won't get 60 fps in non-60fps games, even if you overclock. All it does is getting the game closer to the maximum possible frame rate, which the game would not reach without the overclock, most of the time. Silent Hill for instance has a lot of frame drops at standard clock, and runs at a smooth 30fps with a 1.5 overclock, although people have reported it breaks some puzzles. For that reason, I would like a 1.25 overclock feature to see if it improves things.
  18. VibbyVibbs

    VibbyVibbs New Member

    Messages:
    11
    Likes Received:
    0
    1.25 Overclock would be a nice feature, thinking of it as just a minor overclock, just enough so that it boosts your games a bit, with minimal issues.
    I'd still expect slightly sped up audio in some games, but it would be nice, regardless.

    As for games being capped at a certain framerate, well... some, "funky" things can happen if you overclock aggressively. 2.0x and above can actually cause considerable issues. I.E: Final Fantasy IX will have a 60 FPS cap on the overworlds instead of 30 FPS, which doesn't smoothen the game, but speeds it up outright, even in battles.

    Chrono Cross has some issues when overclocking aggressively as well. 3.0x makes overworlds run at a silky smooth 60 FPS without speeding up the game, BUT, the catch is, some cutscenes will softlock trying to play certain character animations, though in New Game+, you can usually correct the glitch by playing around with the Time Shifter (L/R buttons to speed up and slow down the game) until the cutscene continues on properly.

    One thing that CAN'T be avoided however, is that some things in-battle will cause undesired effects. If you use the "Uplift" element in-battle while the game is running a full 60 FPS without dropping, the game will strangely enough, reset itself on the "Published by Square Electronic Arts L.L.C" screen as if you resetted the emulator.

    I'm sure some issues can be avoided by making cheats/patches that put a proper FPS cap on games, but more-less, having a 1.25 overclock would be more effective.
  19. TheDimensioner

    TheDimensioner New Member

    Messages:
    242
    Likes Received:
    60
    Hey, it's been a long time without me flooding this thread XD. I've messed up recently, breaking my monitor trying to remove a flying ant that crawled behind the screen, but to compensate, I've got a cheap CRT 17" (actually 15.5") monitor, and it's amazing how this thing improves upon everything a LCD can't do (besides the low resolution, which is actually 1280x960, and no widescreen, but oh well). This monitor got high refresh rate (up to 140Hz on 640x480) a "true" natural colors filter, kind of built in to it through the simple color options, and natural scanlines, which make emulated games played on their native settings look like, well, "native".

    But enough about the monitor. Since there's talk about overclock, I think it would be better to have a CPU clock slider, instead of fixed values, much like PCSX2 or Dolphin. Maybe if overclock speeds up gameplay or messes audio, what about underclocking? I mean, for some reason, underclocking the CPU on both those emulators makes games run at a full 60 VI/s, and the "fake" FPS the game might have (30 or 60), since the PC architecture CPU is emulating a less powerful console CPU. It does make some games slower when it actually needs the full power of the emulated CPU under the emulators code structure, but the effects also vary by game. I can't test it on PSX emulation on PCSX2, because I could never get it to work, but maybe there's something to it XD.

    But a better overclocking solution, might be the way to go. The most weird game with overclock, in my testings, has been Nedd for Speed: Porsche Unleashed. It just never runs smoothly on PCSX-R(PGXP), and overclock seems just to unlock the framerate as well. I've made a small video on my "new" setup, just to show the effects. Sorry about the quality, I had to upscale to 720p@60 for 60 FPS on Youtube, at a low bitrate so it could upload fast enough on my bandwidth.
    Show Spoiler
    I've recorded it at 640x480, ResHack 5/4, no xBRZ/2xSaI, just simple texture filtering. Also, no natural colors, because it looks too saturated on this monitor :p. The game does run very smoothly on ePSXe using the same settings as PCSX-R (although no PGXP), and Mednafen (both "vanilla" and Retroarch core). It took a long time for it to boot on ePSXe though, I remember I only got it to work on version 1.9.0 or so.

    CPU overclock makes the game run wild sometimes, breaking physics and also the CPU AI. There are portions of some levels where the FPS counter reaches 60 FPS, and the game does seem to run at it, but in other sections, it just doubles the speed. When in first person view, the game runs even faster, I guess because it actually de-renders (culls?) the player's car. Music runs slower, and sound effects try to keep up with the FPS, like the narrator and cars engines. But at least it's fun playing like that XD.

    Maybe if a GPU overclock was done instead, or in conjunction with the CPU overclock, would games have less issues? I got that idea from the recent rumors about the Nintendo Switch, saying that docked or undocked, CPU clock is unchanging since console games are practically bound to it for logic processing, while the GPU and memory are the ones that overclock/underclock. Is it possible to change the "virtual" GPU of an emulator?
  20. the_randomizer

    the_randomizer Fluffy Animal Admirer

    Messages:
    3,390
    Likes Received:
    39
    Give me money and I will, but until my financial situation improves, no dice.

Share This Page