Next Generation Emulation banner
1 - 20 of 59 Posts

· Registered
Joined
·
128 Posts
Discussion Starter · #1 · (Edited)
PGXP (Parallel/Precision Geometry Transform Pipeline) is an enhancement for PlayStation emulation that produces high precision fully 3D geometry data that was not available on the original console hardware.

It is currently integrated with PCSX-Reloaded via Pete's OpenGL v1.78 plugin and Tapeq's Tweak extension to Pete's OpenGL v2.9 plugin.

Note: This project is still very much a work in progress.

Features
  • High Precision Vertex Data (more stable geometry)
  • Reduced Triangle Culling (more detailed models)
  • Perspective Correct Texture Mapping (reduced texture distortion)

Chrono Cross: Distortion of model geometry is significantly reduced, especially at a distance.


Ridge Racer Type 4: Higher precision culling calculations mean that small triangles are no longer culled


Tomb Raider: 3D vertex coordinates mean affine texture mapping can be replaced by perspective correct mapping

Setup Instructions
Download the required files (links to these can be found below):
  • A WIP build of PCSXR-PGXP
  • A complete install of PCSX-Reloaded
  • Pete's OpenGL2 PSX GPU Plugin v2.9
Copy the PCSXR-PGXP.exe file from the WIP build to the root folder of the PCSX-Reloaded (the one with the PCSXR.exe file in it). Then copy the gpuPeopsOpenGL.dll and gpuPeteOpenGL2Tweak.dll files to the "Plugins" folder.

If you don't already have it copy the "gpuPeteOpenGL2.dll" file to the Plugins folder too (this is required for the Tweak plugin to work).

Note: If the plugins fail to appear in the "Graphics" menu of the "Plugins & Bios..." window then you may need to install the Visual C++ Redistributable 2015 (x86).

Debug Visualisations
Various shading modes are available by pressing F11 when using the OpenGL 1.78 plugin each of which show different information regarding vertices. There are currently three such modes that can be cycled through, the first shows the different states of each vertex:
  • Blue: Successfully tracked from transformation on the GTE to the GPU.
  • Cyan: Tracked but has lost its 'w' component.
  • Yellow: The vertices belong to a 2D sprite element.
  • Red: No valid value was found so it falls back on the native low precision values.
  • Green: A suitable high precision value has been found in the cache
  • Magenta: Multiple high precision values were found at the same position of the cache, making the result ambiguous, so the low precision value is used.
The other two modes display depth values as a spectrum through blue, green and red. The second mode being the 'w' components of the vertices (in older versions this was grey scale).

The last shows depth information taken from the Ordering Table used by the PlayStation to sort primitives so they can be rendered from furthest to nearest.

Links
Most Recent Builds:
WIP_PGXP_build_19_03_02.zip


Source Code:
PCSXR-PGXP: https://github.com/iCatButler/pcsxr
Tapeq's OpenGL Tweak Plugin with PGXP: https://github.com/iCatButler/PeteOpenGL2Tweak

Additional Links:
Official PCSX-Reloaded Home Page: https://pcsxr.codeplex.com/
Pete's OpenGL2 PSX GPU Plugin: http://www.pbernert.com/html/gpu.htm#OGL2
Visual C++ Redistributable 2015: https://www.microsoft.com/en-us/download/details.aspx?id=48145
Visual C++ Redistributable 2010 (may be needed for other plugins): https://www.microsoft.com/en-gb/download/details.aspx?id=5555
Tapeq's Tweak Plugin Thread: http://ngemu.com/threads/peteopengl2tweak-tweaker-for-peteopengl2-plugin-w-gte-accuracy-hack.160319/

Previous Builds:
WIP_PGXP_build_18_12_16.zip

WIP_PGXP_build_17_04_25.zip
WIP_PGXP_build_17_03_19.zip
WIP_PGXP_build_16_08_01.zip
WIP_PGXP_build_16_08_31.zip
WIP_PGXP_build_17_03_17.zip


Thanks to:
Tapeq
Pete Bernert
Edgbla
Simias
The PCSX-R team
And everyone who has provided feedback.
 

· Registered
Joined
·
128 Posts
Discussion Starter · #11 ·
@SolisX Hi! Good idea, I've put a few comparisons in the first post to illustrate the differences. I'll probably put together a video at some point as the difference in motion is even more stark. I've included a couple more images that I put together.

This one shows just how distorted some models can get, the vertices effectively snapping to a square grid.

The distortion effect on faces is also pretty striking.
@gamax92 I suspect Hydro Thunder is writing individual bytes, PGXP currently only tracks 16 and 32-bit reads and writes because vertex coordinates are stored as two 16-bit values.

What's happening when the cache is enabled looks like random false positives. There are vertices being transformed and added to the cache but not at their final screen space positions, so when GPU plugin does a lookup it's sometimes finding a value but probably not the right one.

@otherman good point about the VC++ redistributable, I've added it in now. The 64-bit dynarec is only used in the linux and MacOS versions, the Windows solution only includes the x86 version, I updated it to help CarterLi on GitHub build for Mac.
I did get it working for Windows locally, with a lot of hacking about, but there seemed little point to releasing that version as most of plugins available are only compiled for 32-bit.

@TheDimensioner I've noticed those holes in Crash 3, unlike other cases I can't seem to influence those by modifying NCLIP, although the game does seem to use it for back face culling. I can only assume those gaps are either in the original mesh or being created as part of the tessellation/LoD system before the vertices are transformed.
 

· Registered
Joined
·
128 Posts
Discussion Starter · #15 · (Edited)
Is it possible to call the "Reduced Triangle Culling" feature in some sense an analogue of the tessellation? After all, judging by the screenshots, the final result is similar to tessellation - the models are more detailed.
The default behaviour of the PlayStation is a sort of reverse tessellation, or implicit mesh simplification. This image illustrates what's happening quite well.
All the triangles are being transformed but the low precision results in many vertices of small triangles getting the same position. This causes those triangles to collapse into lines or points, becoming degenerate, with an area of zero.
You can see this happening in the image where groups of small triangles form simple squares, two or three triangles stretch as their vertices snap to the same few points while other triangles disappear altogether.

The PlayStation's GTE has a function to cull these degenerate triangles called NCLIP which also removes triangles that are facing away from the viewer (back-face culling). As PGXP calculates and stores vertices in high precision the implicit simplification doesn't happen but the default NCLIP behaviour still results in small triangles, that would have become degenerate, being culled. This is because the emulated game expects a low precision integer value which will be truncated to 0 for many small triangles.

To solve this PGXP calculates its own NCLIP result in high precision and then intentionally skews the results so that values that would become 0 are now rounded up to 1 or -1 before passing it back to the emulator. So technically, rather than creating more triangles from a mesh, it is preserving existing triangles that would otherwise be simplified out.
 

· Registered
Joined
·
128 Posts
Discussion Starter · #39 · (Edited)
I think the z-buffer is to prevent any z fighting on the water mesh. There's a lot of overlapping waves with transparency. Without a z-buffer, the ps1 doesn't know in what order front-to-back to show the polygons. So you would get a lot of flickering and flashing.

It's amazing the way Naughty Dog could levearage the Hardware potential of the ps1. Also, it looks good with pgxp.
A z-buffer won't actually tell the system the order in which to show polygons, it just stores the depth of the last pixel rendered at any position, it's not actually very useful for layered alpha transparencies at all. When depth testing is enabled for opaque geometry it's generally used to reject a new pixel if it is further from the viewer than the one already in the buffer, meaning rendering can be order independent.

The PS1 does actually have a feature called the "ordering table" to help games render primitives in order from furthest to nearest. It's basically a series of linked list nodes in an array which can be indexed using a very low precision depth value, the game generates one of these values for each triangle and then pushes the triangle into the table at that point. When it renders the scene it then iterates through the primitives in the reverse order they appear in the table.

I've been experimenting with this a little because while the values are very low precision, they are coherent unlike the w coordinates produced by the GTE.


I've changed depth value display to a spectrum from blue to red because it's easier to see small differences.

The Z components generated by the GTE are high precision and calculated per-vertex but different objects are processed at different scales making the z data incoherent.

The Ordering Table positions are coherent across the whole screen but are stored per-face and at a low resolution, making it unfit for creating a depth buffer...
I think the z-buffer described might actually be used to display the waterline on the player character.
There are various techniques used to display half submerged objects in the jetski levels. Crates are rendered as two meshes, half above and half below the water line. Mines, buoys and ramps appear to have animated textures with baked in water lines.

The player character has a small rectangle blended over it with what appears to be a single bit depth buffer to remove pixels that would be obscured by the part of the character above the water. I think I read something about Crash 2 using a similar technique for still water. I'd probably need to use a VRAM debugger to confirm it though (the one in the Software plugin doesn't work for me).
Edit: Actually... it looks like the jetski mesh changes shape in the lower pictures. I guess that means it's using the same method as the crates, rendering the below water part, then the water, then the above part... :oops:

In that case I'm not sure where the z-buffer is being used in that level. I can find references to it on Wikipedia but they all cite an issue of Game Informer that I can't find online.

Maybe something got lost in translation and they confused software clipping plane with z-buffer. :p
 

· Registered
Joined
·
128 Posts
Discussion Starter · #46 ·
I'm sorry if this was answered earlier, but this is is still non-functioning with Windows 10, yes? The same issue with the standard PCSXR? It demands a netplay plugin and Win10 doesn't appear to be compatible with them.
I'm using Windows 10 on my main computer, so it does work.

Some of the older plugins require the 32-bit (x86) Visual C++ 2010 redistributable to be installed. It doesn't seem to be included in the Windows 10 install by default.

https://www.microsoft.com/en-gb/download/details.aspx?id=5555

I believe Tapeq has recompiled these with VC++ 2015 (the same as my plugins) so you could alternatively download his build of PCSXR to use as a base (a link to his thread is in the first post).
 

· Registered
Joined
·
128 Posts
Discussion Starter · #53 ·
The original implementation of the Wipeout memory hack was enabled by default, I later reintegrated it with changes from Tapeq's build so that it's disabled by default.

With it enabled the Chrono Cross underwater scene worked but played out differently. On reflection I think this was just changed tick costs influencing the random number generator and thus which of several camera splines were chosen. On a real console various factors could result in a different outcome each time, but on an emulator that starts from an identical state only changes to the code would influence it.

As my changes were frequently breaking vertex transforms I couldn't tell if the altered camera was a similar bug so decided to revert it while I investigated further.
 

· Registered
Joined
·
128 Posts
Discussion Starter · #65 · (Edited)
Can someone tell me the differences between epsxe and PCSX-Reloaded, and why PCSX-Reloaded is better? I use this plugin since tapeq created it "I´ve been updating every time that iCatButler improves it" and i can´t see a reason to change to PCSX-Reloaded.
With regards to PGXP, the reason for using PCSX-R over other emulators is that it's currently the only emulator in which it is implemented :D

Many features of Tapeq's Tweak plugin will work with both ePSXe and PCSX-R because they implement all the API calls it requires to work, PGXP adds a lot of extra features that require a special build of both the emulator and plugin to work. The main features are listed in the first post on this thread, namely more accurate and stable vertex positions, more accurate culling to prevent gaps and perspective correct textures that don't stretch and warp.

There is a feature of Tapeq's plugin and others called "GTE Accuracy" which was originally created by Edgbla and goes some way to improving vertex accuracy and stability, although it isn't as effective as PGXP in many cases, it doesn't support perspective correct textures or improved culling. It works by caching high precision values and then trying to retrieve them using the native low precision data, this can cause multiple vertices to all associate with a single point, you can see this where UI elements or 2D backgrounds distort when they are close to animating 3D objects.

This video from an early prototype shows the differences between native PSX geometry, GTE Accuracy and full floating point data.
Beyond PGXP I'm sure there are various other differences but I don't have much recent experience with ePSXe.

Edit:
Are games like THPS1 still wobbly as heck? I noticed that no matter what mode I use,the floor still gets quite distorted at times.
There are still games that are wobbly for a number of reasons, it really depends on how the developers processed the vertices.

In the simplest cases like Crash Bandicoot or Threads of Fate the data is animated with good precision, transformed on the GTE (where PGXP starts tracking values) and then copied straight to the GPU. Others like Time Crisis or Chrono Cross have low precision animation, meaning values are already poor when PGXP gets them, while Spyro and Grandia have a lot of processing on the CPU between transformation and the GPU receiving data.

In the case of THPS1 there are two problems:
The first is that the developers have packed additional information into the top 4 bits of some vertices, Pete's plugins strip that out but I hadn't implemented it yet. This stopped the polygons appearing correctly in "Memory + CPU" mode.
Second is the LoD system, which aims to reduce wobbling and texture distortion on original hardware by increasing the polycount, does so by gradually sliding more detailed patches across the floor. It looks like an interesting solution but it can lead to noticeable wobble with PGXP because it's done before transformation.

I've fixed the first problem locally and will try to provide an update soon. I've also found that some games like Hydro Thunder and Alundra 2 pass multiple primitives to the GPU in a single block, PGXP only currently expects one and I'm looking for a way to process this in the Tweak plugin.
 

· Registered
Joined
·
128 Posts
Discussion Starter · #67 ·
To get PGXP features to work, yes. The WIP builds of PCSXR-PGXP all come with both a modified PCSX-R executable and versions of the base 1.78 OpenGL plugin and Tapeq's Tweak 2.4 plugin.

There's a link to the most current build in the first post of this thread along with instructions on how to set it up.
 

· Registered
Joined
·
128 Posts
Discussion Starter · #70 ·
Err... this is embarrassing, but i don´t know how to compile the source code from the first post... Can someone share his modified PCSX-R?

Sorry for the inconvenience.
The most recent build is under the "Links" section of the first post, sorry if it wasn't clear, I'll repost it here for you: WIP_PGXP_build_16_08_01.zip

It contains compiled binaries of the pcsxr-pgxp.exe and the two plugins. You'll need an existing install of PCSXR to add them to, there's a link to the PCSX-reloaded homepage or you can use Tapeq's build from his thread. The exe goes in the same folder as pcsxr.exe and the plugin dlls go in the plugins folder.
 

· Registered
Joined
·
128 Posts
Discussion Starter · #78 ·
Sure is nice having my question about THPS1 ignored. But hey, I guess it's natural for questions to get buried on a thread like this.
As psxhd said, I replied to your query in this post. It was appended as an edit though, to avoid double posting, so I can appreciate that you might not have noticed it.

I've uploaded a build which fixes the first problem described but further improvement will require changes to start processing values earlier. I'll let you know if I see any drastic improvements with later builds.
WIP_PGXP_build_16_08_31.zip

How do I bring up the debug interface that shows everything color-coded according to whether it's hi-res or lo-res? And can you explain the colors etc. again? I think this info was in the old thread but I can't find it now.

Is culling automatically enabled with PGXP? I don't see any options related to culling.

What does caching vertices do?
The debug visualisations are available by pressing F11 when using the OpenGL 1.78 plugin (there are two supported plugins 1.78 and the Tweak 2.4 that requires the 2.9 plugin).
There are currently three modes that can be cycled through, the first shows the different states of each vertex:
  • Blue: Successfully tracked from transformation on the GTE to the GPU.
  • Cyan: Tracked but has lost its 'w' component (new to this version)
  • Yellow: The vertices belong to a 2D sprite element.
  • Red: No valid value was found so it falls back on the native low precision values.
  • Green: A suitable high precision value has been found in the cache
  • Magenta: Multiple high precision values were found at the same position of the cache, making the result ambiguous, so the low precision value is used.
The other two modes (in this version) display depth values as a spectrum from blue to red. The second mode being the 'w' components of the vertices (previously this was grey scale). The last shows depth information taken from the Ordering Table used by the PlayStation to sort primitives.

Improved culling is automatically enabled, turning it off would perhaps fix a few logic bugs in games like Ridge Racer but would leave distracting holes in most geometry.

Vertex caching is an implementation of Edgbla's GTE accuracy technique, instead of tracking vertices as they're moved through the PSX's memory and registers, it uses the native low precision positions as a lookup to store and retrieve high precision values from a cache. While there are a number of problems with this approach, because of the low precision of the lookup values, it can be useful to improve coverage in games that don't work well with PGXP.

@gamax92 this new build should smooth vertices in Hydro Thunder, although the 'w' components come through badly so you might want to disable perspective correct texturing for now.

@TheDimensioner Alundra 2 had the same behaviour as Hydro Thunder so should also work now, in this case I think the 'w' values are pretty good.
 

· Registered
Joined
·
128 Posts
Discussion Starter · #80 ·
It sounds like you're not using the version of the 1.78 plugin from the WIP build, maybe it didn't copy across properly. While it requires special versions of both executable and plugins for all the features to work it won't completely fail if they're mixed with normal versions.

Can you try copying the new version into the plugins folder and making sure the configuration is pointing to the right folder.
 

· Registered
Joined
·
128 Posts
Discussion Starter · #82 ·
There might be some elements that always come through as red, or at least don't benefit that much from PGXP because of the way they're calculated. There are a number of goals for the project at the moment:
  • Improving coverage for games that have limited support (reduce red vertices)
  • Improved CPU calculations for vertices that are handled but either glitch or are still low precision
  • Support for more GTE functions and for earlier processing to smooth out animations
  • Optimisations or multi-threading to improve performance
  • Integration with other emulators like Libretro-Mednafen
It may not be possible to completely smooth all games because there are so many different ways the vertices can be processed, there's a definite tension between games that benefit from looser calculations and others which rely on quirks of the original fixed point math.

If there are games that are not supported in some way it's always useful to know. Vagrant Story does look great and I think it could be improved further by processing the animations at a higher precision, although I'm making no promises :p
 

· Registered
Joined
·
128 Posts
Discussion Starter · #93 ·
I think your priority would be find at least an other good coder to make a team (if you think you need a team), make ssao works to make some nice video with vagrant story and other games where dof is right allready, set a patreon and makes some money to buy you time, or good pizza and beer at least!
I don't think I'd be much good at managing a team, I've a hard enough time organising myself! :p

I actually spent quite a lot of time trying to get good depth values out of games recently, the reason I didn't list it as an objective right now is I'm still not convinced it's possible to implement without game specific hacks.

At the moment I can extract per-vertex depth values from the GTE, but in most games those are not in the same space for all objects in a scene and some, like sky boxes or UI elements, have no depth at all. I can also get the position of whole primitives from within the ordering table which are all in the same space but have very low precision.

The per-vertex values are fine for perspective correct texturing because all the vertices in any single primitive are transformed in the same space (except for some patch edges in GT2). This gives OpenGL the gradient it needs to scale texture coordinates on a per-pixel basis. When they're used within a scene for depth testing then the different spaces being layered up clip into one another incorrectly.

I've tried enabling depth testing with these values and in most games elements like sky boxes or background sprites will draw over everything unless disabled, which then often disables UI elements too. I managed to get Vagrant Story displaying like this (with text breaking) but a lot of the lighting and shadows used by the game involve rendering meshes multiple times with offsets which lead to z-fighting.

In most cases I know the game will be scaling and averaging all the per-vertex depth values to find the correct entry in the OT and then to sort them within that entry (bucket sorting). It's just that PGXP isn't currently smart enough to find the those values before they're discarded and associate them with the relevant primitive or vertex. I'm not even sure all games do these calculations as some, like Crash Bandicoot, have precompiled ordering tables.

I'm not going to rule it out completely but at the moment I don't have a clear idea of what would be needed to implement depth buffering and thus techniques like SSAO, it's something I'm definitely keeping in mind as I improve other aspects of PGXP though.

Well, this is my first post here and it's going to be about a bug.

I've been testing PCSX-R PGXP with FF IX (PAL Spanish version) and I have found out that setting xBRZ higher than x1 messes up cutscenes, it just turns them into a static white screen. Not only that, but when the cutscene ends it stays white. I think this is exclusive to Final Fantasy IX because it didn't happen with FF VII. Also, the higher you set the value, the faster it screws up.
This sounds like you might be running out of memory for upscaled textures as it is possibly generating a new texture for each frame of the cutscene, I don't know if the plugin avoids doing this. Does it happen with normal PCSXR and the version of the Tweak plugin from Tapeq's thread?

Nice! I'm really looking forward Libretro-Mednafen integration. Btw, do you think it's possible for PGXP to work with the software-only mode of Mednafen?
It should be possible but it depends on how the software renderer is designed as to how easy it would be. I'd expect perspective correct texturing would require substantial changes to implement in software.
 

· Registered
Joined
·
128 Posts
Discussion Starter · #131 · (Edited)
Is it possible to use ordering table to calculate offsets for corresponding Z-values? If it is, you can take it and apply through formula to each primitive so they will have correct position in depth space.
I did try something along these lines:
  1. Calculate the distance in Z between each vertex and the centre of the primitive (average of all vertex Z values)
  2. Convert this distance to a fraction of the whole Z range (far - near)
  3. Multiply that by the number of Ordering table entries, so it should now be in OT space
  4. Add this offset to the primitive's position in the ordering table (OT-Z)
Unfortunately it didn't really work for most games (though it did for Threads of Fate in most cases), a number of problems became apparent that make this approach unlikely to work:
  • No Z-plane is specified on the PSX (online documents suggest 0xFFFF) so scaling appears to be different in each game
  • Primitives are often grouped and share a single OT value (the background and floor in Tekken 3 appear to do this)
  • Crash Bandicoot's precompiled ordering tables don't always show sequential values along the Z-axis
  • Some games like Spyro don't appear to use an OT at all (at least not one I can get values for)
I even considered looking for grouped primitives by tagging those that use the same transforms, until I discovered Tekken 3 was passing individual vertex positions as the translation part of the transform... :(

Edit: Just remembered I did try defining the range as between the near plane and the average Z too, that worked on a wider range of games but still gave some pretty odd results for the other reasons mentioned (and low precision in the OT).

@otherman I'm trying to avoid game specific hacks as much as possible, and hacky special case code in general, not to mention everyone has their own favourites they'd like to see supported ;)
I suspect a lot of people who understood where the original hardware's inaccuracy comes from have thought about implementing floating point alternatives in some way or other, for the most part concerns about performance or potential errors probably put them off attempting it (I honestly expected Memory+CPU mode to be unplayable :p). Perspective correct texturing in particular might also have been hampered by the common misconception that it requires proper Z values or a Z-buffer which are considerably harder to generate.

I have a question... I see that the GTE Accuracy can essentially be set in two places... in the Configuration > PGXP > "Enable PGXP GTE Vertex Creation", and in the gpuPeteOpenGL2Tweak.ini under the "GTEAccuracy" option of course.
What's the difference here? Just different methods?
Is one better than the other?
Do they work at the same time, or together? Like do the both do something if they're both one, or does one override the other?.
"GTE Accuracy" refers to the older technique for vertex accuracy developed by Edgbla and used in PCSX-R and ePSXe. It's currently removed from PCSXR-PGXP, so those options won't do anything, but it's functionally very similar to the Vertex Caching option which is based on that technique. Caching can be used as a fallback option when the main PGXP method fails but otherwise it produces less accurate results.

I haven't removed the GUI/ini code for it yet because I'm still considering whether to reinstate the original technique should anyone wish to use it, maybe sharing plugins with a copy of the original PCSX-R that doesn't support the newer version. Sorry for any confusion.

I have the pal version, and like i thought, the problem is with the emulator. I have the Psx system type option in "Autodetect" (Enabled by default) the problem is that this option is not working properly, if i set "PAL" manually in that section, the game´s sound works perfect. No matters if i select PAL or NTSC in the P.E.Op.S Audio plugin.
Just to rule out any changes I've made, does this occur with the normal build of PCSXR too? It seems unlikely but the overclocking/savestate code might cause such a bug.

The autodetect feature in PCSX-R uses the games id to determine the region of a game, it expects the third character to be 'E' as PAL releases should typically start with SLES or SCES. It also checks for a limited number of other strings that might be specific PSP re-releases, I assume ePSXe uses a more robust method (it seems to hava database to identify multi-disc releases too). Does this only occur with a specific game or one that has been modified and might have a different code?
 

· Registered
Joined
·
128 Posts
Discussion Starter · #133 ·
That does appear to be the case, although the PGXP build does have added code for overclocking that might interact with it (the CPU code uses region type to determine how many cycles are allowed per frame), I thought it was worth ruling that out in case I'd broken something.

As mentioned in my previous post, the autodetect is a pretty simple test of the "CDROM ID", a string within the image file rather than the image filename. This should correspond to the game's product code, which for PAL releases should begin SCES or SLES, with PCSX-R looking for the 'E'. If this code is at fault then I'm guessing that ePSXe either uses a different method, knows about more string variations or has a more robust way of finding the string.
 

· Registered
Joined
·
128 Posts
Discussion Starter · #155 ·
How are the Spyro games working on PCSXR-PGXP?

I've encountered a problem with games on the emulator in general. Sometimes, when pressing Esc to pause the game, when going back into the game, the screen shows nothing but grey (the sounds go on, and you can actually still control your character).
Sorry for not giving you an answer sooner.

I believe the remaining low precision vertices in Spyro require additional GTE functions to be implemented, I think they're used to interpolate some of the nearer positions to subdivide triangles. There are also some issues with the portal geometry too as zackboy mentioned, I think those are related to CPU accuracy problems.

With regards to the grey screens, is this only using the Tweak plugin? It enables and disables hooks into OpenGL each time the window is opened and closed, so maybe something is failing there. Is there a way to reliable replicate it or is it just a case of dropping in and out of the emulator?
@iCatButler When you said it seemed like the emulator was running out of memory did you mean RAM or would it be fixed by adjusting another setting in the ini?
It was more of a general observation, video sequences would in theory result in a lot of unique textures, sorry I don't have any deeper insights.
xBRZ is one of the features that Tapeq implemented into the Tweak plugin, I only modified it to work with PGXP, so you might be better asking about this in his thread: http://ngemu.com/threads/peteopengl2tweak-tweaker-for-peteopengl2-plugin-w-gte-accuracy-hack.160319/
@iCatButler, I think is a good idea to pay attention to development of this.
Thanks for the heads up! :D

As @otherman said, it's very easy for people working on similar things to miss one another, just because you post the information in public doesn't mean everyone who might be interested can find it. There are just so many different channels for groups to communicate through.

Regarding licences I don't think there should be a problem at the moment, the core parts of PGXP are 100% my work, as I understand it I should be able to release it under different licences as necessary. If others contribute work to any particular version then that would need to remain under the existing licence unless they agree to a change.
Just wanted to hop and say thank you iCatButler, today I beat Xenogears and PGXP made the game look unbelievably amazing. Fantastic game rendered beautifully.
You are most welcome! :D
I do love what PGXP does right now, I just don't want that in the future, it becomes unplayable for me because of features that any device I have won't support. And it's not that easy to buy new devices...
I wouldn't worry about PGXP becoming incompatible in future, the core features probably wouldn't benefit from hardware acceleration. Someone could build a more advanced renderer on top of it but advances to PGXP itself should continue to work with the current plugins.
 

· Registered
Joined
·
128 Posts
Discussion Starter · #174 · (Edited)
How do you turn off the 2D filters (xBRZ), without turning off the entire PGXP, with the 3D upscaling?

Better put: I would like to only use PGXP for 3D games (because of compatibility issues with many games), and use only the tweaks to remove wobbliness and upscale.
Wait, does PGXP even upscale 3D graphics? What exactly changes with the emu for 3D? Remove wobbliness, and?
There are various enhancements and features provided by different projects, each built upon the other, most of them can be enabled/disabled independently, although some clash.

Pete's OpenGL2 PSX GPU plugin (can be used with either PCSXR(-PGXP) or ePSXe) uses GPU plugin menu to configure:
  • Higher resolution
  • Texture filtering
  • 2xSai texture upscaling
  • Full screen shader effects
Tapeq's Tweaker for Pete's plugin (different builds can be used with either PCSXR(-PGXP) or ePSXe) uses .ini file to configure:
  • Res-hack internal resolution multiplier (replaces and can go higher than Pete's)
  • xBRz texture upscaling (does not work with 2xSai upscaling)
  • Edgbla's GTE Accuracy, stabilises some geometry wobble (does not work with PGXP)
PGXP (only works with PCSXR-PGXP and modified Tweak/Opengl 1.78 plugins) uses PGXP menu to configure:
  • Stable High Precision Vertex Data and operations (memory only or with CPU)
  • Reduced Triangle Culling (always used with high precision PGXP data)
  • Perspective Correct Texture Mapping (reduced texture distortion)
  • Vertex Caching (equivalent to Edgbla's GTE Accuracy)
You mix and match settings as you like, so you could use PGXP to stabilise vertices and textures at native resolution with default textures or disable PGXP, use Sai upscaled textures and Reshack.

Edit: If you want to use the Tweak plugin without xBRz upscaling set the scale factor to 0, this should allow you to use Pete's scaler instead or none at all.

I've probably missed a few features (especially of the GPU plugin) but I think this gives you an idea of what features each project adds and where they can be configured.
 

· Registered
Joined
·
128 Posts
Discussion Starter · #190 ·
"FastFMV" - yuck, better I will someday write proper TextureWindow emulation, but currently I have some health problems, so do not expect this soon :(
I'm really sorry to hear that, I hope you get better soon.

I had wondered if it would be possible to upscale textures on the GPU using pixel shaders. Effectively load the source image into a temporary texture, bind the destination in an FBO and then render a quad into it using a pixel shader to handle the scaling. Obviously there are some algorithms that wouldn't work well as a pixel shader, they might need to use compute or maintain a CPU path.
I'd also thought about the possibility of asynchronous or late upscaling, effectively using a basic nearest-neighbour or bilinear technique to produce a higher resolution place holder and then attempting to swap it out for the final version once the xBRz filtering is done. For textures involving FMVs and FBEs these would probably be obsolete so you'd never see the full upscaling effect. That would probably be harder as you'd need to know if the area of VRAM was still being used for that texture before writing the final data.

I've not looked into the implementation details of either case though, so they may not be viable.
 

· Registered
Joined
·
128 Posts
Discussion Starter · #194 ·
It's PGXP, but not quite the same... :p
It was pretty interesting to see the differences between Mednafen and PCSX-R, especially in regards to the way transferring data to the GPU is handled. Pretty much all of the GPU side stuff had to be simplified right down and the "smart" caching stuff needed to be ripped out because it seems to model some level of concurrency between the GTE and GPU.

Needless to say this is even more "work in progress" than the PCSX-R build, with plenty of crashes that need fixing.
 

· Registered
Joined
·
128 Posts
Discussion Starter · #198 ·
@TheDimensioner it's currently only working in the hardware renderer. It would be awesome to get it working with software rasterisation but I suspect it would be pretty difficult, especially perspective correct texturing (it currently just crashes if software is enabled :p).

@jjjfloyd it hasn't made its way into the main libretro-mednafen repo yet, I'm not sure what the plans are regarding that. If we can get it to a point where it doesn't crash too often then I'll put a build up for people to try out. The codes there if anyone wants to build it though.

Just for information PCSX2 is adding PSX support.


It would be interessting to see if PGXP would also work there.
But it is now a good opportunity to enhance the PS1 part in GSDX with OpenGL functions.
Then we would have an updated open source opgengl graphics plugin, which could also be benificial for the pcsx project.

The last remaining plugin which needs an update would be audio.
That's pretty impressive.

I think it should work, Mednafen integration wasn't too difficult to achieve. A quick look at the source suggests it's using function tables similar to the PCSX-R interpreter, possibly some shared legacy, so integration might be very simple at that end.
 
1 - 20 of 59 Posts
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top