Next Generation Emulation banner
661 - 680 of 1,036 Posts
Hyllian,

My codes skills are amateurish at best, so I may be way off base here. I'm guessing your code works as some sort of two step process where it:

1. First uses an algorithm to detect which areas of the screen are 3D renders.
2. Then applies a filter to anything that returns a value of "false." I.E. 2D.

I'm curious if the first step could be applied to something like opengl2tweak, something along the lines of a "No 3D shade" option. Something that could then send that data to the user selected shader in Pete's Opengl2. That way the user could choose any shader he/she wants for step 2 instead of you porting a whole bunch of different shaders to use this process.
 
Hyllian,

My codes skills are amateurish at best, so I may be way off base here. I'm guessing your code works as some sort of two step process where it:

1. First uses an algorithm to detect which areas of the screen are 3D renders.
2. Then applies a filter to anything that returns a value of "false." I.E. 2D.
It's almost what you described. It doesn't detect 3D renders. Actually, it detects pixels in high res. So, when you increase internal res, all 3D models are rendered in high res and the 2d sprites stay at low res. So you have small and big pixels in the same framebuffer. My detection is done by sampling a region (the size of a single low res pixel) to 'see' if all high res pixels inside it have the same color (which tells me I'm looking at a low res region). So, if it is low res, it gets filtered, otherwise, nothing is done.

I'm curious if the first step could be applied to something like opengl2tweak, something along the lines of a "No 3D shade" option. Something that could then send that data to the user selected shader in Pete's Opengl2. That way the user could choose any shader he/she wants for step 2 instead of you porting a whole bunch of different shaders to use this process.
It would be possible in a multipass shader framework (like in Retroarch). So the first pass shader would just mark pixels with some flag saying it is low or high res region.

In ePSXe I don't know how this info could be passed to shaders in a uniform var.
 
It's almost what you described. It doesn't detect 3D renders. Actually, it detects pixels in high res. So, when you increase internal res, all 3D models are rendered in high res and the 2d sprites stay at low res. So you have small and big pixels in the same framebuffer. My detection is done by sampling a region (the size of a single low res pixel) to 'see' if all high res pixels inside it have the same color (which tells me I'm looking at a low res region). So, if it is low res, it gets filtered, otherwise, nothing is done.



It would be possible in a multipass shader framework (like in Retroarch). So the first pass shader would just mark pixels with some flag saying it is low or high res region.

In ePSXe I don't know how this info could be passed to shaders in a uniform var.
Genius, you've solved a conundrum many in the community have faced trying to play mixed 2D/3D games. Seriously, bravo!

I'm curious how "portable" your code is, in the sense that do you have to make modifications to your secondary engine (such as XBR) or do you literally just run your script and then drop the secondary code in?

I'm two weeks into coding school, a total noob at this kind of thing, but between that and your explanation, and your excellent comments in the shader file, I can sort tell what's going on here.

If it's indeed portable, I thought I might try to implement a bash script, where someone could put a shader in a folder, run the script, and your code would be inserted (with credit to you, of course).
 
I don't think you can automatize it. Each shader has a different treatment, I have noticed. Now I'm working into making super-xbr compatible with it and the approach will be different from all others I already made. I don't use any scripts, the idea is hacked inside each shader manually.

The idea to compare pixels size to detect high res one is good, but it relies in fragile premises. And you'll see many games that'll break them easily. One of the premises is that the pixels should be squared and positioned in the low res grid (almost all N64 cores break this in RA). The other is that the rule of sampling a small region to compare small pixels inside it isn't perfect and can not be 100% effective. So many games will present small glitches here and there.
 
I don't think you can automatize it. Each shader has a different treatment, I have noticed. Now I'm working into making super-xbr compatible with it and the approach will be different from all others I already made. I don't use any scripts, the idea is hacked inside each shader manually.

The idea to compare pixels size to detect high res one is good, but it relies in fragile premises. And you'll see many games that'll break them easily. One of the premises is that the pixels should be squared and positioned in the low res grid (almost all N64 cores break this in RA). The other is that the rule of sampling a small region to compare small pixels inside it isn't perfect and can not be 100% effective. So many games will present small glitches here and there.
Well for now then I'll leave this at: Thanks for the explanation! And thanks even more for taking all this time to create these fantastic shaders! I've been working on a pretty comprehensive guide to the best settings for Chrono Cross, as this game can be finicky and gets a lot of questions in the forum. I'm happy to say your work has forced me to update pieces of my guide.
 
@Hyllian
I'm super sorry for interrupting the thread with an off topic subject, but I really need this shader converted for FF7 PC (to be precisely the '98 version of the game). We have a new OpenGL 2.0 driver and the author said
It's also not very difficult to adapt shaders made for Pete's PSX GPU plugins
But after some research I found out why I failed so horrible to implement it into the openGL driver
"They can work, but you need to make some changes to the code. Only GLSL shaders will work and you need to have some experience with the language to make the necessary changes."
I don't how to work on these stuff, so I ask you if you could spend some time to adapt your shader to the PC version of FF7.

Here is the OpenGL custom driver I speak of:
http://forums.qhimm.com/index.php?topic=14922.0

Thank you for reading and sorry for the interruption
 
Using the latest xBR from the post above, I''ve managed to insert the 3D code from the old one (the slower one) and now it runs at 60fps on my humble PC!! It's running perfectly on games with 2D with 3D elements!









You can get it attached! You need to increase Internal Resolution (I use number 2) to see the effects!

Now I think it's the full fledged version!

I use this config to test this shader:
Hyllian, is there any way you can add some scale-able 3D AA and some colour saturation controls to this shader? I really like the way this shader looks but but I also like a little anti-aliasing on the 3D models.

As it stands now I'm using ReShade to do some SMAA anti-aliasing and tweak the colour a bit. I would prefer not having to use ReShade unless I have to. Nothing wrong with ReShade but I prefer to keep things simple.
 
@Hyllian
I'm super sorry for interrupting the thread with an off topic subject, but I really need this shader converted for FF7 PC (to be precisely the '98 version of the game). We have a new OpenGL 2.0 driver and the author said

But after some research I found out why I failed so horrible to implement it into the openGL driver


I don't how to work on these stuff, so I ask you if you could spend some time to adapt your shader to the PC version of FF7.

Here is the OpenGL custom driver I speak of:
http://forums.qhimm.com/index.php?topic=14922.0

Thank you for reading and sorry for the interruption
Do you have a shader for that system working so that I can look and ser if it's only glsl? (I port shaders only for systems that have its shaders specs available or if they have other working shaders so that I can figure out how they work.
 
Hyllian, is there any way you can add some scale-able 3D AA and some colour saturation controls to this shader? I really like the way this shader looks but but I also like a little anti-aliasing on the 3D models.

As it stands now I'm using ReShade to do some SMAA anti-aliasing and tweak the colour a bit. I would prefer not having to use ReShade unless I have to. Nothing wrong with ReShade but I prefer to keep things simple.
What you mean? Aren't 3D AA applied by your GPU?
The color saturation you're talking is The natural Vision one?
 
661 - 680 of 1,036 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