1. myowfriend

    myowfriend Member
    Newcomer

    Joined:
    Dec 12, 2015
    Messages:
    35
    Country:
    United States

    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, Jan 21, 2017
    ned likes this.
  2. ned

    ned GBAtemp Advanced Fan
    Member

    Joined:
    Dec 21, 2014
    Messages:
    591
    Country:
    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.
     
  3. myowfriend

    myowfriend Member
    Newcomer

    Joined:
    Dec 12, 2015
    Messages:
    35
    Country:
    United States
    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?
     
  4. CustomEyeBrows

    CustomEyeBrows GBAtemp Regular
    Member

    Joined:
    Apr 8, 2015
    Messages:
    128
    Country:
    New Zealand
    double post. sorry.
     
  5. Darkemaste

    Darkemaste GBAtemp Advanced Fan
    Member

    Joined:
    Mar 31, 2016
    Messages:
    525
    Country:
    Mexico
    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.
     
  6. CustomEyeBrows

    CustomEyeBrows GBAtemp Regular
    Member

    Joined:
    Apr 8, 2015
    Messages:
    128
    Country:
    New Zealand
    Awesome. Thanks.

    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.

    — Posts automatically merged - Please don't double post! —

    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, Jan 21, 2017
    StripTheSoul likes this.
  7. ned

    ned GBAtemp Advanced Fan
    Member

    Joined:
    Dec 21, 2014
    Messages:
    591
    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, Jan 21, 2017
  8. myowfriend

    myowfriend Member
    Newcomer

    Joined:
    Dec 12, 2015
    Messages:
    35
    Country:
    United States
    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.
     
    Last edited by myowfriend, Jan 21, 2017
  9. ned

    ned GBAtemp Advanced Fan
    Member

    Joined:
    Dec 21, 2014
    Messages:
    591
    Country:
    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, Jan 21, 2017
  10. myowfriend

    myowfriend Member
    Newcomer

    Joined:
    Dec 12, 2015
    Messages:
    35
    Country:
    United States
    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.
     
  11. Darkemaste

    Darkemaste GBAtemp Advanced Fan
    Member

    Joined:
    Mar 31, 2016
    Messages:
    525
    Country:
    Mexico
    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, Jan 21, 2017
  12. ned

    ned GBAtemp Advanced Fan
    Member

    Joined:
    Dec 21, 2014
    Messages:
    591
    Country:
    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.
     
  13. myowfriend

    myowfriend Member
    Newcomer

    Joined:
    Dec 12, 2015
    Messages:
    35
    Country:
    United States
    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.

    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.

    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, Jan 21, 2017
  14. alucard_xs

    alucard_xs GBAtemp Advanced Fan
    Member

    Joined:
    Oct 31, 2012
    Messages:
    646
    Country:
    Canada
    is mario kart 8 US version working ? It launches now but craches once the logo appears.
     
  15. StripTheSoul

    StripTheSoul GBAtemp Fan
    Member

    Joined:
    Apr 3, 2016
    Messages:
    400
    Country:
    Gambia, The
    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).
     
  16. ned

    ned GBAtemp Advanced Fan
    Member

    Joined:
    Dec 21, 2014
    Messages:
    591
    Country:
    What are you talking about? it's the textures that are being scaled not the final rendered frame.
     
    Last edited by ned, Jan 21, 2017
  17. myowfriend

    myowfriend Member
    Newcomer

    Joined:
    Dec 12, 2015
    Messages:
    35
    Country:
    United States
    I'm aware. But what your describing would just as effective as that.

    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.
     
  18. ned

    ned GBAtemp Advanced Fan
    Member

    Joined:
    Dec 21, 2014
    Messages:
    591
    Country:
    So it overwrites the texture map resolution?
     
  19. myowfriend

    myowfriend Member
    Newcomer

    Joined:
    Dec 12, 2015
    Messages:
    35
    Country:
    United States
    Right. Here's an example of what a G-buffer looks like as an example.

    [​IMG]

    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.
     
  20. JaceCearK1

    JaceCearK1 GBAtemp Advanced Fan
    Member

    Joined:
    May 18, 2015
    Messages:
    540
    Country:
    Gambia, The
    Maybe you just got a bad dump. You might wanna retry using another tool! :P
     
Draft saved Draft deleted
Loading...

Hide similar threads Similar threads with keywords - [RELEASE], emulator,