Emulation [RELEASE] Cemu - Wii U emulator

  • Thread starter Exzap
  • Start date
  • Views 7,162,855
  • Replies 21,659
  • Likes 283

myowfriend

Active Member
Newcomer
Joined
Dec 12, 2015
Messages
35
Trophies
0
Age
34
XP
87
Country
United States
Not sure if somebody said this but wouldn't it be easier if we could just use multiples?

Like instead of

Code:
[TextureRedefine]
width = 1280
height = 720
overwriteWidth = 3840
overwriteHeight = 2160

it could be

Code:
[TextureRedefine] # zoomed in
width = 1280
height = 720
multiplyBy = 3

It could even be a global rule and all other rules just list exceptions to the rule.

The global rule could technically just be added to the UI instead of being put in rule files. Then there wouldn't need to be separate files for 1080p, 1440p, 2160p, etc.

Just set 2x, 3x, 4x, etc. in the UI and the rule files will take care of what NOT to scale.


Does anybody whose been working on the graphics packs a lot see many downsides to this idea? If not then maybe we can work on an alternative way to write rules that we can suggest to Exzap. It seems like the "muliplyBy" property alone would cut down on some of the work making rule files. Not sure if the idea of a global scaling thing with rules for exceptions would increase or decrease the size of the files but I think it would be worth implementing for testing purposes especially if it means scaling can be moved to the UI since there wouldn't have to be separate packs for different resolutions.
 
Last edited by myowfriend,
  • Like
Reactions: ned

ned

Well-Known Member
Member
Joined
Dec 21, 2014
Messages
591
Trophies
0
Age
38
XP
221
Country
Does anybody whose been working on the graphics packs a lot see many downsides to this idea? If not then maybe we can work on an alternative way to write rules that we can suggest to Exzap. It seems like the "muliplyBy" property alone would cut down on some of the work making rule files. Not sure if the idea of a global scaling thing with rules for exceptions would increase or decrease the size of the files but I think it would be worth implementing for testing purposes especially if it means scaling can be moved to the UI since there wouldn't have to be separate packs for different resolutions.

I think the graphic pack on/off option should be added to the gameprofile also so you have to fiddle with the option when changing games.
Not only this but a interlaced rendering mode option like seen in the new resident evil 7 would look better than 360 and 540p whilst halfing frames rates and 720i with bicubic filtering isn't too shabby whilst 360p looks like aliased turd.
 

myowfriend

Active Member
Newcomer
Joined
Dec 12, 2015
Messages
35
Trophies
0
Age
34
XP
87
Country
United States
I think the graphic pack on/off option should be added to the gameprofile also so you have to fiddle with the option when changing games.
Not only this but a interlaced rendering mode option like seen in the new resident evil 7 would look better than 360 and 540p whilst halfing frames rates and 720i with bicubic filtering isn't too shabby whilst 360p looks like aliased turd.

Wait? Why are we going back to interlaced rendering? That's literally something people were trying to get rid of for years and now games are using it? Bu if you really want interlacing, that might be doable with a shaders but only with 60fps games. You can fake 60i/30fps with 60p but a 30p game can only become 30i/15fps.

Anyway, a graphic pack on/off option seems like an alright and relatively simple suggestion, that's literally just an if statement for Exzap.

Any thoughts on the other stuff I said though?
 

Darkemaste

Well-Known Member
Member
Joined
Mar 31, 2016
Messages
525
Trophies
0
Location
Local Disk (C:)
XP
397
Country
Mexico
Does anybody whose been working on the graphics packs a lot see many downsides to this idea? If not then maybe we can work on an alternative way to write rules that we can suggest to Exzap. It seems like the "muliplyBy" property alone would cut down on some of the work making rule files. Not sure if the idea of a global scaling thing with rules for exceptions would increase or decrease the size of the files but I think it would be worth implementing for testing purposes especially if it means scaling can be moved to the UI since there wouldn't have to be separate packs for different resolutions.
It's.... not that simple. Everything has to multiplied/scaled/divided by different values, it may work for very basic resolutions/graphic packs (ie~ those that only touch a single TV/gamepad resolution and nothing else) but it wouldn't work too well with any title that using half/quarter res alpha, multiple resolutions/camera views, and could potentially result in conflicting rules such as a quarter res alpha inadvertently being scaled up to an incorrect value automatically because the output resolution happens to match the base resolution of a half res alpha rule. (which would break games in itself)

Tbh I don't think most people need to be concerned about actually making graphic packs themselves as the community graphics pack repo already has graphic packs for a variety of titles with an even wider variety of resolutions ranging from 360p to a whopping 10K, and will only continue to grow and support more titles/more resolutions for currently supported titles.
 

CustomEyeBrows

Well-Known Member
Member
Joined
Apr 8, 2015
Messages
128
Trophies
0
Age
36
XP
143
Country
New Zealand
When you start a new game there's a video. You should be able to hear it. There's no fix to the static green video there yet. You just have to wait until that video is over. After that, everything should work fine.

Awesome. Thanks.

Why 'nevermind'? I tried it now and it does actually get rid of the multiple bloom instances issue.
However, if I see correctly the only thing you changed was get rid of those q-res values. And I guess I know what they are for because the DoF effect looks shitty with your bloom-fixing-version :/
So I guess that's what Darkemaste meant when he said fixing one issue creates another.

Yeah, i wanted to see how much I could remove from the rules.txt while keeping visuals as stable as possible.

My line of thinking is that id rather have 2 things look the same in cemu as they are on wiiu instead of having 1 thing look amazing and the other thing glitching out. It didnt work out like that coz as Darkemaste and yourself pointed out, it seems that fixing one thing leads to breaking another. May as well just turn one feature off and make do until an actual fix can be found instead of trying to fix something, then fix the broken thing that the last fix broke.

For me, i find the best trade off right now in SMW3D, is using Slashsiees/Darkemastes rules.txt with the h/q-res alpha lines removed to keep the bloom intact in-conjunction with the NoDof mod.

For CTTT, you either fix the bloom or break the dof and cause really bad aliasing. So the rules.txt by either Slash or Dark is the best way to go imo.

When i get a chance im going to dig around properly with the NSight and actually learn what does what rather than just hacking .txts together.

--------------------- MERGED ---------------------------

It seems I was correct about my previous post regarding SM3DW noting that the scaled bloom issue couldn't be fixed without editing shaders. Rather than disabling bloom altogether, I had reduced it to what would be considered appropriate levels using the shader @masterotaku had provided.

SM3DW using a 5K res graphic pack w/ every rule in place + my reduced bloom shader edit -

For those curious, my 5K+ graphic packs I've been teasing about are currently pending to be merged. :P

Thanks for these, dude. https://github.com/slashiee/cemu_graphic_packs/tree/master/Enthusiast Graphic Packs[/URL


Also, this maybe of use for those downloading the shader modified files such as the no Dof or Bloom mods: http://kinolien.github.io/gitzip/

It allows you to download the whole folder of contents in a github repo in one go instead of needing to open the txt file in the browser and then copy and past the contents into a txt file on your pc.
 
Last edited by CustomEyeBrows,
  • Like
Reactions: StripTheSoul

ned

Well-Known Member
Member
Joined
Dec 21, 2014
Messages
591
Trophies
0
Age
38
XP
221
Country
The problem is the internal resolution isn't yet changed, all graphic packs do is change the resolution of the applied textures to stop them looking less aliased when stretched out to 4k, you can upload as many 4k videos to youtube as you want but their still rendered in 720/1080p it's the gpu and monitor that's scaling it to 4k.
Think of it this way if I apply a 2d 4k fullscreen texture it's still going to get downscaled to 720 or 1080p native resolution there's currently no point redefining the texture resolution past 1080p on 2d planes as you'll get no benefit, the only benefit you get is on 3d models where the texture is mapped accross multiple 2d viewpoints.
The graphic packs are no different to likes of xbrz texture filtering in epsxe or ppsspp at native res.
 
Last edited by ned,

myowfriend

Active Member
Newcomer
Joined
Dec 12, 2015
Messages
35
Trophies
0
Age
34
XP
87
Country
United States
It's.... not that simple. Everything has to multiplied/scaled/divided by different values, it may work for very basic resolutions/graphic packs (ie~ those that only touch a single TV/gamepad resolution and nothing else) but it wouldn't work too well with any title that using half/quarter res alpha, multiple resolutions/camera views, and could potentially result in conflicting rules such as a quarter res alpha inadvertently being scaled up to an incorrect value automatically

Why would that happen? Look at this example from the Super Mario 3D World + Captain Toad: Treasure Tracker 4k pack.

Code:
[TextureRedefine] # tv
width = 1280
height = 720
formatsExcluded = 0x008,0x41A,0x034,0x035 # exclude obvious textures
overwriteWidth = 3840 #3x original
overwriteHeight = 2160 #3x original

So pretty obvious here. 720p to 2160p is a 9x difference cause by rendering 3 times as many pixels in both width and height.

Code:
[TextureRedefine] # half-res alpha
width = 640
height = 360
formatsExcluded = 0x41A # exclude obvious textures
overwriteWidth = 1920 #3x original
overwriteHeight = 1080 #3x original

Here we have exactly what you talked about. If we divide 1920 by 640 we get 3 again, that's because this pack is just scaling things so that they're the same ratio to everything they were before and that can be observed in the whole pack.

Code:
[Definition]
titleIds = 0005000010145d00,0005000010145c00,0005000010106100,0005000010180600,0005000010180700,0005000010180500
name = "Super Mario 3D World + Captain Toad: Treasure Tracker - 2160p (4K)"

[TextureRedefine] # tv
width = 1280
height = 720
formatsExcluded = 0x008,0x41A,0x034,0x035 # exclude obvious textures
overwriteWidth = 3840 #3x original
overwriteHeight = 2160 #3x original

[TextureRedefine] # zoomed in
width = 1128
height = 720
overwriteWidth = 3384 #3x original
overwriteHeight = 2160 #3x original

[TextureRedefine] # zoom transition
width = 1000
height = 600
overwriteWidth = 3000 #3x original
overwriteHeight = 1800 #3x original

[TextureRedefine] # zoom transition 2
width = 1000
height = 720
overwriteWidth = 3000 #3x original
overwriteHeight = 2160 #3x original

[TextureRedefine] # half-res alpha
width = 640
height = 360
formatsExcluded = 0x41A # exclude obvious textures
overwriteWidth = 1920 #3x original
overwriteHeight = 1080 #3x original

[TextureRedefine] # half-res (zoomed in)
width = 564
height = 360
overwriteWidth = 1692 #3x original
overwriteHeight = 1080 #3x original

[TextureRedefine] # half-res (zoom transition)
width = 500
height = 300
overwriteWidth = 1500 #3x original
overwriteHeight = 900 #3x original

[TextureRedefine] # half-res (zoom transition 2)
width = 500
height = 360
overwriteWidth = 1500 #3x original
overwriteHeight = 1080 #3x original

[TextureRedefine] # quarter-res alpha
width = 320
height = 180
formatsExcluded = 0x41A # exclude obvious textures
overwriteWidth = 960 #3x original
overwriteHeight = 540 #3x original

[TextureRedefine] # q-res (zoomed in)
width = 282
height = 180
overwriteWidth = 846 #3x original
overwriteHeight = 540 #3x original

[TextureRedefine] # q-res (zoom transition)
width = 250
height = 150
overwriteWidth = 750 #3x original
overwriteHeight = 450 #3x original

[TextureRedefine] # q-res (zoom transition 2)
width = 250
height = 180
overwriteWidth = 750 #3x original
overwriteHeight = 540 #3x original

By having a scaleBy attribute, it can look like this

Code:
[Definition]
titleIds = 0005000010145d00,0005000010145c00,0005000010106100,0005000010180600,0005000010180700,0005000010180500
name = "Super Mario 3D World + Captain Toad: Treasure Tracker - 2160p (4K)"

[TextureRedefine] # tv
width = 1280
height = 720
formatsExcluded = 0x008,0x41A,0x034,0x035 # exclude obvious textures
scaleBy = 3

[TextureRedefine] # zoomed in
width = 1128
height = 720
scaleBy = 3

[TextureRedefine] # zoom transition
width = 1000
height = 600
scaleBy = 3

[TextureRedefine] # zoom transition 2
width = 1000
height = 720
scaleBy = 3

[TextureRedefine] # half-res alpha
width = 640
height = 360
formatsExcluded = 0x41A # exclude obvious textures
scaleBy = 3

[TextureRedefine] # half-res (zoomed in)
width = 564
height = 360
scaleBy = 3

[TextureRedefine] # half-res (zoom transition)
width = 500
height = 300
scaleBy = 3

[TextureRedefine] # half-res (zoom transition 2)
width = 500
height = 360
scaleBy = 3

[TextureRedefine] # quarter-res alpha
width = 320
height = 180
formatsExcluded = 0x41A # exclude obvious textures
scaleBy = 3

[TextureRedefine] # q-res (zoomed in)
width = 282
height = 180
scaleBy = 3

[TextureRedefine] # q-res (zoom transition)
width = 250
height = 150
scaleBy = 3

[TextureRedefine] # q-res (zoom transition 2)
width = 250
height = 180
scaleBy = 3

This is also a little less prone to user error because somebody can't accidentally have the redefined resolution change it's aspect ratio.
Of course, if the scaling was done in the UI it would get rid of more of that code as well as the redundant packs for different resolutions. But for the examples sake, lets act like a global scaling could be set in graphics pack. It might look like this.

Code:
[Definition]
titleIds = 0005000010145d00,0005000010145c00,0005000010106100,0005000010180600,0005000010180700,0005000010180500
name = "Super Mario 3D World + Captain Toad: Treasure Tracker - 2160p (4K)"

[Global] [TexureRedefine]
scaleBy = 3

[TextureRedefine] # tv
width = 1280
height = 720
formatsExcluded = 0x008,0x41A,0x034,0x035 # exclude obvious textures

[TextureRedefine] # half-res alpha
width = 640
height = 360
formatsExcluded = 0x41A # exclude obvious textures

[TextureRedefine] # quarter-res alpha
width = 320
height = 180
formatsExcluded = 0x41A # exclude obvious textures

Or maybe even this assuming the comment for formatsExcluded is accurately stating what's happening there.

Code:
[Definition]
titleIds = 0005000010145d00,0005000010145c00,0005000010106100,0005000010180600,0005000010180700,0005000010180500
name = "Super Mario 3D World + Captain Toad: Treasure Tracker - 2160p (4K)"

[Global] [TexureRedefine]
scaleBy = 3
formatsExcluded = 0x008,0x41A,0x034,0x035 # exclude obvious textures

because the output resolution happens to match the base resolution of a half res alpha rule. (which would break games in itself)

Why would anything be fed the post-scaled resolution? If that was a thing that would happen, it would happen with the current method as well. Also, aren't these all only targeting uncompressed texture formats AKA render targets?

Tbh I don't think most people need to be concerned about actually making graphic packs themselves as the community graphics pack repo already has graphic packs for a variety of titles with an even wider variety of resolutions ranging from 360p to a whopping 10K, and will only continue to grow and support more titles/more resolutions for currently supported titles.

If what I suggested works than it would be of benefit to the community as it would require a little less work on their part and make the UI a little more straight forward. For example, what happens right now when you have a 1080p and 2160p texture checked on at the same time for the same game? If the texture packs didn't have to have things statically defined, there would only have to be one for that game.

The problem is the internal resolution isn't yet changed, all graphic packs do is change the resolution of the applied textures to stop them looking less aliased when stretched out to 4k, you can upload as many 4k videos to youtube as you want but their still rendered in 720/1080p it's the gpu and monitor that's scaling it to 4k.
Think of it this way if I apply a 2d 4k fullscreen texture it's still going to get downscaled to 720 or 1080p native resolution there's currently no point redefining the texture resolution past 1080p on 2d planes as you'll get no benefit, the only benefit you get is on 3d models where the texture is mapped accross multiple 2d viewpoints.
The graphic packs are no different to likes of xbrz texture filtering in epsxe or ppsspp at native res.

If internal resolution isn't being changed yet then why are the 360p pack called "Performance packs". If the internal resolution is the same than the same amount of shader processing is happening with the 360p pack as having no pack in all. In fact it would be slightly worse because you're forcing it to rescale things.

I assumed all these rules were made to catch calls to render to textures of certain resolutions and changing those functions input resolution.

If it was just texture filtering than shouldn't it get pretty comparable results just scaling the finalized image. Why put all the effort of targeting specific render textures just to scale the same? Also, Xenoblade Chronicle's X's grass would look like ass if it was just upscaling stuff. And if upscaling really had results that looked this clean without increasing internal resolution, you would see video game developers using this all the time.
 
Last edited by myowfriend,

ned

Well-Known Member
Member
Joined
Dec 21, 2014
Messages
591
Trophies
0
Age
38
XP
221
Country
Why would that happen? Look at this example from the Super Mario 3D World + Captain Toad: Treasure Tracker 4k pack.

Code:
[TextureRedefine] # tv
width = 1280
height = 720
formatsExcluded = 0x008,0x41A,0x034,0x035 # exclude obvious textures
overwriteWidth = 3840 #3x original
overwriteHeight = 2160 #3x original

So pretty obvious here. 720p to 2160p is a 9x difference cause by rendering 3 times as many pixels in both width and height.

Code:
[TextureRedefine] # half-res alpha
width = 640
height = 360
formatsExcluded = 0x41A # exclude obvious textures
overwriteWidth = 1920 #3x original
overwriteHeight = 1080 #3x original

Here we have exactly what you talked about. If we divide 1920 by 640 we get 3 again, that's because this pack is just scaling things so that they're the same ratio to everything they were before and that can be observed in the whole pack.

Code:
[Definition]
titleIds = 0005000010145d00,0005000010145c00,0005000010106100,0005000010180600,0005000010180700,0005000010180500
name = "Super Mario 3D World + Captain Toad: Treasure Tracker - 2160p (4K)"

[TextureRedefine] # tv
width = 1280
height = 720
formatsExcluded = 0x008,0x41A,0x034,0x035 # exclude obvious textures
overwriteWidth = 3840 #3x original
overwriteHeight = 2160 #3x original

[TextureRedefine] # zoomed in
width = 1128
height = 720
overwriteWidth = 3384 #3x original
overwriteHeight = 2160 #3x original

[TextureRedefine] # zoom transition
width = 1000
height = 600
overwriteWidth = 3000 #3x original
overwriteHeight = 1800 #3x original

[TextureRedefine] # zoom transition 2
width = 1000
height = 720
overwriteWidth = 3000 #3x original
overwriteHeight = 2160 #3x original

[TextureRedefine] # half-res alpha
width = 640
height = 360
formatsExcluded = 0x41A # exclude obvious textures
overwriteWidth = 1920 #3x original
overwriteHeight = 1080 #3x original

[TextureRedefine] # half-res (zoomed in)
width = 564
height = 360
overwriteWidth = 1692 #3x original
overwriteHeight = 1080 #3x original

[TextureRedefine] # half-res (zoom transition)
width = 500
height = 300
overwriteWidth = 1500 #3x original
overwriteHeight = 900 #3x original

[TextureRedefine] # half-res (zoom transition 2)
width = 500
height = 360
overwriteWidth = 1500 #3x original
overwriteHeight = 1080 #3x original

[TextureRedefine] # quarter-res alpha
width = 320
height = 180
formatsExcluded = 0x41A # exclude obvious textures
overwriteWidth = 960 #3x original
overwriteHeight = 540 #3x original

[TextureRedefine] # q-res (zoomed in)
width = 282
height = 180
overwriteWidth = 846 #3x original
overwriteHeight = 540 #3x original

[TextureRedefine] # q-res (zoom transition)
width = 250
height = 150
overwriteWidth = 750 #3x original
overwriteHeight = 450 #3x original

[TextureRedefine] # q-res (zoom transition 2)
width = 250
height = 180
overwriteWidth = 750 #3x original
overwriteHeight = 540 #3x original

By having a scaleBy attribute, it can look like this

Code:
[Definition]
titleIds = 0005000010145d00,0005000010145c00,0005000010106100,0005000010180600,0005000010180700,0005000010180500
name = "Super Mario 3D World + Captain Toad: Treasure Tracker - 2160p (4K)"

[TextureRedefine] # tv
width = 1280
height = 720
formatsExcluded = 0x008,0x41A,0x034,0x035 # exclude obvious textures
scaleBy = 3

[TextureRedefine] # zoomed in
width = 1128
height = 720
scaleBy = 3

[TextureRedefine] # zoom transition
width = 1000
height = 600
scaleBy = 3

[TextureRedefine] # zoom transition 2
width = 1000
height = 720
scaleBy = 3

[TextureRedefine] # half-res alpha
width = 640
height = 360
formatsExcluded = 0x41A # exclude obvious textures
scaleBy = 3

[TextureRedefine] # half-res (zoomed in)
width = 564
height = 360
scaleBy = 3

[TextureRedefine] # half-res (zoom transition)
width = 500
height = 300
scaleBy = 3

[TextureRedefine] # half-res (zoom transition 2)
width = 500
height = 360
scaleBy = 3

[TextureRedefine] # quarter-res alpha
width = 320
height = 180
formatsExcluded = 0x41A # exclude obvious textures
scaleBy = 3

[TextureRedefine] # q-res (zoomed in)
width = 282
height = 180
scaleBy = 3

[TextureRedefine] # q-res (zoom transition)
width = 250
height = 150
scaleBy = 3

[TextureRedefine] # q-res (zoom transition 2)
width = 250
height = 180
scaleBy = 3

This is also a little less prone to user error because somebody can't accidentally have the redefined resolution change it's aspect ratio.
Of course, if the scaling was done in the UI it would get rid of more of that code as well as the redundant packs for different resolutions. But for the examples sake, lets act like a global scaling could be set in graphics pack. It might look like this.

Code:
[Definition]
titleIds = 0005000010145d00,0005000010145c00,0005000010106100,0005000010180600,0005000010180700,0005000010180500
name = "Super Mario 3D World + Captain Toad: Treasure Tracker - 2160p (4K)"

[Global] [TexureRedefine]
scaleBy = 3

[TextureRedefine] # tv
width = 1280
height = 720
formatsExcluded = 0x008,0x41A,0x034,0x035 # exclude obvious textures

[TextureRedefine] # half-res alpha
width = 640
height = 360
formatsExcluded = 0x41A # exclude obvious textures

[TextureRedefine] # quarter-res alpha
width = 320
height = 180
formatsExcluded = 0x41A # exclude obvious textures

Or maybe even this assuming the comment for formatsExcluded is accurately stating what's happening there.

Code:
[Definition]
titleIds = 0005000010145d00,0005000010145c00,0005000010106100,0005000010180600,0005000010180700,0005000010180500
name = "Super Mario 3D World + Captain Toad: Treasure Tracker - 2160p (4K)"

[Global] [TexureRedefine]
scaleBy = 3
formatsExcluded = 0x008,0x41A,0x034,0x035 # exclude obvious textures



Why would anything be fed the post-scaled resolution? If that was a thing that would happen, it would happen with the current method as well. Also, aren't these all only targeting uncompressed texture formats AKA render targets?



If what I suggested works than it would be of benefit to the community as it would require a little less work on their part and make the UI a little more straight forward. For example, what happens right now when you have a 1080p and 2160p texture checked on at the same time for the same game? If the texture packs didn't have to have things statically defined, there would only have to be one for that game.



If internal resolution isn't being changed yet then why are the 360p pack called "Performance packs". If the internal resolution is the same than the same amount of shader processing is happening with the 360p pack as having no pack in all. In fact it would be slightly worse because you're forcing it to rescale things.

I assumed all these rules were made to catch calls to render to textures of certain resolutions and changing those functions input resolution.

If it was just texture filtering than shouldn't it get pretty comparable results just scaling the finalized image. Why put all the effort of targeting specific render textures just to scale the same? Also, Xenoblade Chronicle's X's grass would look like ass if it was just upscaling stuff. And if upscaling really had results that looked this clean without increasing internal resolution, you would see video game developers using this all the time.

They probably would if they weren't bound to likes of console ram limits not mention it takes alot more processing power to filter every single and if enough ram is their already they'd draw the textures at a higher res anyway.
 
Last edited by ned,

myowfriend

Active Member
Newcomer
Joined
Dec 12, 2015
Messages
35
Trophies
0
Age
34
XP
87
Country
United States
They probably would if they weren't bound to likes of console ram limits not mention it takes alot more processing power to filter every single and if enough ram is their already they'd draw the textures at a higher res anyway.

The issue with current console isn't how much memory they have. If what you're talking about was at all possible and as good as it looks in CEMU and requires no increase in internal resolution than there would be no PS4 Pro game that isn't hitting 4k because they would be able to keep internal resolution at 1080p and rescale to 4k and that's not happening.

Plus what you're describing still wouldn't make those 360p graphics pack increase performance at all, they would decrease performance.

CEMU is not just using advanced filtering, it's increasing/decreasing internal resolution.
 

Darkemaste

Well-Known Member
Member
Joined
Mar 31, 2016
Messages
525
Trophies
0
Location
Local Disk (C:)
XP
397
Country
Mexico
Why would anything be fed the post-scaled resolution? If that was a thing that would happen, it would happen with the current method as well. Also, aren't these all only targeting uncompressed texture formats AKA render targets?
This is what already happens, it's a pain for several resolutions and a pain for the gamepad in general for other resolutions. As an example of what could go wrong should a certain output resolution match a previous resolution in another rule, it had caused Xeno to lose 3/4th of it's visible screen with an effect similar to Nvidia acid sky in MK8.
I'm not sure if you've also been paying attention to the discussion of SM3DW in the past few pages or how shaders/bloom can be tied to half/quarter-res rules (they can't be excluded by formats) but if the resolution used by ANY shaders end up getting indirectly scaled it can result in corruption far worse than the pre-shader edit SM3DW screenshots posted by others. (ie~ Immediately seeing a solid-white screen in Xenoblade after exiting a Skell's cockpit view)

Tbh it seems to me you want a more universal approach similar to Dolphin, but Exzap has previously commented on why Dolphin's approach wouldn't work in Cemu well before graphic packs were introduced.... which has only seemed to be further confirmed on my end.
 
Last edited by Darkemaste,

ned

Well-Known Member
Member
Joined
Dec 21, 2014
Messages
591
Trophies
0
Age
38
XP
221
Country
The issue with current console isn't how much memory they have. If what you're talking about was at all possible and as good as it looks in CEMU and requires no increase in internal resolution than there would be no PS4 Pro game that isn't hitting 4k because they would be able to keep internal resolution at 1080p and rescale to 4k and that's not happening.

Plus what you're describing still wouldn't make those 360p graphics pack increase performance at all, they would decrease performance.

CEMU is not just using advanced filtering, it's increasing/decreasing internal resolution.

It performs faster because it's reducing the amount of utilised vram because the textures have been down sized, you can have billions worth of vram but if the clock speed isn't increased to match the load it'll lag like hell this is why vram usage needs to still be decreased further in cemu.
 

myowfriend

Active Member
Newcomer
Joined
Dec 12, 2015
Messages
35
Trophies
0
Age
34
XP
87
Country
United States
This is what already happens, it's a pain for several resolutions and a pain for the gamepad in general for other resolutions. As an example of what could go wrong should a certain output resolution match a previous resolution in another rule, it had caused Xeno to lose 3/4th of it's visible screen with an effect similar to Nvidia acid sky in MK8.
I'm not sure if you've also been paying attention to the discussion of SM3DW in the past few pages or how shaders/bloom can be tied to half/quarter-res rules (they can't be excluded by formats) but if the resolution used by ANY shaders end up getting indirectly scaled it can result in corruption far worse than the pre-shader edit SM3DW screenshots posted by others. (ie~ Immediately seeing a solid-white screen in Xenoblade after exiting a Skell's cockpit view)

What you're describing sounds like cascading to me.

Like I'm trying to figure out logistically what might be going on behind the scenes for something like that to happen. I would assume that any time the API creates a new render target and a graphics pack is enabled, CEMU checks the graphics pack to see if any rules match the input resolution of that API call. If it finds a matching condition for a rule, it swaps in the new resolution. Then it should leave it alone. It shouldn't evaluate that call again. The only way I can think of it doing that is if the rules cascade in way they weren't intended to. Like imagine this:

Code:
[TextureRedefine]
width = 1024
height = 1024
overwriteWidth = 2048
overwriteHeight = 2048

[TextureRedefine]
width = 2048
height = 2048
overwriteWidth = 4096
overwriteHeight = 4096

[CODE]
[TextureRedefine]
width = 1024
height = 1024
overwriteWidth = 3072
overwriteHeight = 3072

CEMU might have been set up to have cascading rules so you don't have to get rid of previous rules just to test new ones. This example would be somebody trying out a rule that scales 1024x1024 texture to 3072x3072. If CEMU doesn't cascade it's rules than it should detects the game wants to create a render target of 1024x1024 than go through the graphics pack, see the first rule that applies to 1024x1024 textures, change the render target resolution to 2048x2048, then stop there. If if does cascade through rules then it would go through all the rules until it reaches the end of the file and each rule for 1024x1024 textures will overwrite the previous. But if the code was accidentally made to start comparing by the RTs NEW resolution instead of it's original resolution, than it would hit the first rule, scale it to 2048x2048, then run the second rule, scale it to 4096x4096 instead, and then skip the third rule. If that's the case than swapping the orders of the rules from higher-resolution to lower-resolution would fix that.

Code:
[TextureRedefine]
width = 2048
height = 2048
overwriteWidth = 4096
overwriteHeight = 4096

[TextureRedefine]
width = 1024
height = 1024
overwriteWidth = 2048
overwriteHeight = 2048

In this case, it would reach that same call to set up a 1024x1024 RT but this time it'll pass by the first rule and only apply the second. This should only be done in graphics packs that increase resolution though. Basically, you'd have to look at rules as an order of operations. Again, this assuming that that's the problem. It's an easy fix for Exzap if it is.

It seems to me you want a more universal approach similar to Dolphin, but Exzap has previously commented on why Dolphin's approach wouldn't work in Cemu well before graphic packs were introduced, which has only seemed to be further confirmed on my end having to deal with 9 different resolutions for each title (while including the gamepad) rather than just the 1-2 most tend to look at. (while typically ignoring the gamepad)

I'm just suggesting anything that will reduce the redundancy of things. Like is there anything I suggested that really creates more problems than are already present? I'm aware that things can't be done in a completely automated way but there can at least be some kind of UI fed variables and a scaleBy property.

A scaleBy property would be welcome since you wouldn't want to change the aspect ratio of the texture and it would scale the texture in both dimensions equally by 1.5, 2, 3, or 4 or even lower numbers.

And a scale variable being fed to the rules via the UI can work like this.

Code:
[Definition]
titleIds = 0005000010145d00,0005000010145c00,0005000010106100
name = "Super Mario 3D World + Captain Toad: Treasure Tracker - 2160p (4K)"

[TextureRedefine] # tv
width = 1280
height = 720
formatsExcluded = 0x008,0x41A,0x034,0x035 # exclude obvious textures
scaleBy = SCALE

[TextureRedefine] # Shadows
width = 1024
height = 1024
formatsExcluded = 0x008,0x41A,0x033,0x034,0x035,0x431,0x235,0x433 # exclude everything but shadowmap
scaleBy = SCALE

[TextureRedefine] # half-res alpha
width = 640
height = 360
formatsExcluded = 0x41A # exclude obvious textures
scaleBy = SCALE

[TextureRedefine] # half-res (zoomed in)
width = 564
height = 360
scaleBy = SCALE

[TextureRedefine] # half-res (zoom transition)
width = 500
height = 300
scaleBy = SCALE

[TextureRedefine] # half-res (zoom transition 2)
width = 500
height = 360
scaleBy = SCALE

This at least gets rid of having multiple packs and if a certain texture is causing problems when scaled, you can choose to put in a custom resolution for that texture or maybe apply some math like SCALE / 2.

Each pack could also specify the games default resolution so that the UI can instead list 360p, 480p, 720p, 1080p, 1440p, and 2160p. The user can than choose the resolution and CEMU will check the default that's listed in the graphics pack and figure out what the value of SCALE should be.

It performs faster because it's reducing the amount of utilised vram because the textures have been down sized, you can have billions worth of vram but if the clock speed isn't increased to match the load it'll lag like hell this is why vram usage needs to still be decreased further in cemu.

So you're not talking about the amount of VRAM, you're talking about VRAM bandwidth and even so, that doesn't make sense.

If the internal resolution isn't being changed than a 1280x720p image is still being rendering off screen then it's scaled down to a lower resolution, than scaled up to the monitors resolution.

You would still be running fragment shaders for 921,600 pixels which uses for more memory bandwidth than sending the finished frame to the monitor. Resizing it would just be ADDING a small bit of work. By comparison, natively rendering at 640x360 would only require fragment shaders to be run on 230,400 pixels (1/4th the amount) which WOULD increase performance.
 
Last edited by myowfriend,

StripTheSoul

Well-Known Member
Member
Joined
Apr 3, 2016
Messages
400
Trophies
0
Age
40
XP
259
Country
Gambia, The
For CTTT, you either fix the bloom or break the dof and cause really bad aliasing. So the rules.txt by either Slash or Dark is the best way to go imo.

Hm, actually, in CTTT I cannot see the drawbacks you're talking about with your bloom fix. Where's the bad aliasing? And I don't see more DoF when using the SM3DW pack (without bloom fix).
 

ned

Well-Known Member
Member
Joined
Dec 21, 2014
Messages
591
Trophies
0
Age
38
XP
221
Country
So you're not talking about the amount of VRAM, you're talking about VRAM bandwidth and even so, that doesn't make sense.

If the internal resolution isn't being changed than a 1280x720p image is still being rendering off screen then it's scaled down to a lower resolution, than scaled up to the monitors resolution.

You would still be running fragment shaders for 921,600 pixels which uses for more memory bandwidth than sending the finished frame to the monitor. Resizing it would just be ADDING a small bit of work. By comparison, natively rendering at 640x360 would only require fragment shaders to be run on 230,400 pixels (1/4th the amount) which WOULD increase performance.

What are you talking about? it's the textures that are being scaled not the final rendered frame.
 
Last edited by ned,

myowfriend

Active Member
Newcomer
Joined
Dec 12, 2015
Messages
35
Trophies
0
Age
34
XP
87
Country
United States
What are you talking about? it's the textures that are being scaled not the final rendered frame.
I'm aware. But what your describing would just as effective as that.

The problem is the internal resolution isn't yet changed, all graphic packs do is change the resolution of the applied textures to stop them looking less aliased when stretched out to 4k, you can upload as many 4k videos to youtube as you want but their still rendered in 720/1080p it's the gpu and monitor that's scaling it to 4k.
.. The graphic packs are no different to likes of xbrz texture filtering in epsxe or ppsspp at native res.

That's not what the graphics packs are doing. The graphics packs are increasing the rendered resolution of the image. It's not rendering at 720p or 1080p and then being stretched or interpolated to 4k. All these texture defined rules are overwriting the target resolution that different render targets render at. So when a rule is changing the resolution of something that is 1280x720, that's meant to target and change the resolution that the color buffer, z-buffer, and normal buffer are rendered at.
 

myowfriend

Active Member
Newcomer
Joined
Dec 12, 2015
Messages
35
Trophies
0
Age
34
XP
87
Country
United States
So it overwrites the texture map resolution?
Right. Here's an example of what a G-buffer looks like as an example.

G-Buffer.jpg

The geometry gets rendered and stored as different buffers which are stored as textures. Shaders then use the information in these buffers to do things like lighting, fog, normal-mapping, etc and make the finalized image. Shadow maps are created in the same way that each of the buffers would be made except the game renders the scene from the perspective of a light and only render a silhouette of the objects that will cast a shadow from the light. The resulting shadow map is then project into the image. Shadow maps are really never the same resolution as the g-buffer so the same rules that tell CEMU to render g-buffers at higher resolution wouldn't apply to a shadow map.
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
    SylverReZ @ SylverReZ: @salazarcosplay, Morning