Next Generation Emulation banner
81 - 100 of 1133 Posts

· Registered
Joined
·
30 Posts
I downloaded your latest version and copied the plugins over again - and you are correct all is working now :) F11 works as well.

BTW my overall impression is that Vagrant Story benefits from this a lot. One question: is the end goal to have the entire game as 'blue' in the debug view? Or is it inevitable that some parts of games will be red? Should we report parts of games that are red?
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
·
106 Posts
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!
 

· Registered
Joined
·
308 Posts
@iCatButler Yout never fail to impress me! Alundra 2 is practically "fixed" (the quotes are because PSX wasn't meant to be like that XD). Some of the performance issues I had with "Mem + CPU Logic" also seems to be improved. Soul Reaver is also "fixed" with this WIP, no gaps on "Mem + CPU".

Although, other games I've tested still seem to have "false positives" using "Mem + CPU" mode, like the Duke Nukem and Bugs Bunny games. GTA 2 still doesn't get any PGXP "recognition", the windows in the buildings are unaligned and the floor is wobbly, and on PGXP debug mode everything is red. "Mem + CPU" mode causes texture stretching.

Alundra 2 intro, WIP_PGXP_build_16_08_31, OpenGL 1.78, "Mem + CPU Logic" mode + PGXP debug. The slowdowns can be fixed using x1.5 CPU overclock, but not while recording XD
GTA 2, WIP_PGXP_build_16_08_31, OpenGL 1.78, "Memory only" mode.
GTA 2 in "Mem + CPU Logic" mode
Transport Line Architecture Wood Roof
Mode of transport Tree Roof Plant Home
Green Blue Text Line Turquoise
 

· Registered
Joined
·
88 Posts
Ok, after many tests with the PCSXR-PGXP, i can say that is a great emulator (I used the latest build available in emucr) but i see two problems:

1- Need a widescreen patch (Epsxe comes by default with it)
2- CD images in .bin format show a error message when you load it "But it works"

Otherwise, the PGXP is a wonderful thing :D, no more trembling textures at last.
 

· Registered
Joined
·
308 Posts
@LuismaSp89 In the main screen, under "Configuration...", click on "CPU...". In the window that appears, check "Widescreen (GTE Hack)" and widescreen will be enabled. Keep in mind that the hack works only for full 3D games, with 2D games or 3D games with 2D backgrounds (Final Fantasy series, Resident Evil series, etc), 2D elements will get stretched, and 3D characters will be misplaced over the background.

I always make sure I have the .cue sheets with my bins, I always had errors when launching only .bin images, even on ePSXe.
 

· Registered
Joined
·
88 Posts
@LuismaSp89 In the main screen, under "Configuration...", click on "CPU...". In the window that appears, check "Widescreen (GTE Hack)" and widescreen will be enabled. Keep in mind that the hack works only for full 3D games, with 2D games or 3D games with 2D backgrounds (Final Fantasy series, Resident Evil series, etc), 2D elements will get stretched, and 3D characters will be misplaced over the background.

I always make sure I have the .cue sheets with my bins, I always had errors when launching only .bin images, even on ePSXe.
...Ok, i´m blind... thanks xD

Ok, i found the problem, the .cue i have was corrupted. Thanks again : )
 

· Registered
Joined
·
13 Posts
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.
 

· Registered
Joined
·
49 Posts
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.
I decided to quickly test out FF IX and I don't seem to have any issue with xBRZ enabled for this game, I only tested really quickly, right up to when you meet Vivi, but that takes two cutscenes and neither of them made a static white screen appear for me.... I imagine something is wrong on your and not entirely the programs fault with this problem. I had xBRZ at 3x for my testing, but I don't think that'll matter.
 

· Registered
Joined
·
13 Posts
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
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?
 

· 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
·
13 Posts
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.

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?

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.
By running out of memory do you mean that I should adjust the batch size in the ini?

Also, I decided to reset the ini (by deleting it and then running the emulator) and it worked, so it definitely had to do with something I had changed.

Thanks for your help.
 

· Registered
Joined
·
10 Posts
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.
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.
 

· Registered
Joined
·
106 Posts
Is not possible use ordering table with per-vertex values?
I think of check compatibility between per-vertex high precision data and the ordering table: if they are in check then per-vertex is used ad it is, if they are not then ordering table is used to make a "center" position and per-vertex is used relatively to that position. From my undestanding, if possible, that would be not a perfect depth buffer, but a good enough for effects and shader in post.

Edit: This is the same idea @Quaoar here, posted while I was whriting this stuff, and his exposition is better than mine... I hate you, Quaoar! (Just kidding :p)

In my unreasonable opinion, with the preatty hacky nature of pgxp, a "per game hack" of sort is inevitable. I think about "ishiiruka" Dolphin approach: there is some options working with some games, and other options for other games, and it deals with the problem with per-game ini file.
While the psx library is huge, the games that deserve (for popularity and goodness) some heavy eye-candy is not so much: they are basically Crash, Spyro, Tekken, Residenti Evil, Final Fantasy, and a bunch of single title. With a "patreon" in mind, they are the targets for trick and wizardy.
I think that a psx emulator with jittery-free for all games and advanced effects for some games is a good enogh destination, not evil at all.

I insist 'couse your work deserve to be rewarned. The idea is around litteraly for decades, but you are the first make it works, and open source, in a scene relatively dead and/or closed source. You are the most active devoloper on this scene at the moment, or so it seams at least, and you have not even a donation link! You are like a hero.
 

· Registered
Joined
·
88 Posts
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.
You can try with the 4gb patch "http://www.ntcore.com/4gb_patch.php" and use it in your .exe, i hope it helps : )

By the way, anyone can tell me why my PCSX-R sounds like crap? I used all the sound plugins available "P.E.Op.S (all of its variants) Eternal, eternal lite, with many configs and for example, in the main menu of tomb raider I, there´s a choppy music. This doesn´t happen with the same plugins, and the same config in epsxe. The eternal plugin is the less chopy sound of all, but not perfect :(

Thanks for the help.
 
81 - 100 of 1133 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