disponibile la 1.7.5 barbon version
Novità sulla 1.7.6 d iCEMU in arrivo a maggio appena pubblicate:
Apr 30 at 10:22pm
Here is a preview of what to expect in Cemu 1.7.6. Keep in mind that development just started a week ago and everything mentioned in this post is subject to change. There is currently no set release date but we plan to spent about 3-4 weeks working on this release.
General plans
For 1.7.6 we will be looking into the following:
Separable shaders (details below)
Graphic fixes
Performance improvements
Fixing remaining rare FPU emulation related gameplay bugs (e.g. Splatoon)
And as usual, other various bugs and minor problems
If time permits we will also look into audio and compatibility improvements.
Separable shaders
This part will be quite technical and if you just want to read a summary of what to expect from this change, you can scroll to the end.
Let's start with a bit of background knowledge. Here is an image of a modern render pipeline: Image (Taken from the Khronos OpenGL wiki) The image depicts the steps on the GPU to go from some input geometry data to a pixel on the screen. For the purposes of this post we don't have to worry about all the steps and we can boil it down to only these shader stages:
Vertex shader
Geometry shader (Optional)
Pixel shader (Optional) Also called fragment shader
The above applies to OpenGL, DirectX, Vulkan or any other rendering API on PC. For Wii U it's not exactly identical, but similar enough that we don't need to dive into details.
The problem
For historical reasons Cemu always looked at the entire shader pipeline as a whole and shaders were generated in sets. That means that for each possible configuration of shader types, Cemu would generate a new shader set upon first use. This set would contain a copy of the vertex shader, the geometry and pixel shader. If individual shaders were reused but other stages differed, Cemu would create a new set regardless.
It's easier to explain this with an example:
Assume we have 2 vertex shaders (vsA, vsB), 3 pixel shaders (psA, psB, psC) and no geometry shaders.
The game does the following draw operations:
Draw 1: vsA + psA
Draw 2: vsA + psB
Draw 3: vsA + psC
Draw 4: vsB + psA
Draw 5: vsB + psB
Draw 6: vsB + psC
Question: How many shader sets do we need to create?
The correct answer is 6. Each of the draw operations uses a unique configuration of shader types.
This is where we start to see the inefficiency emerge: There are only 5 shaders (2 vertex + 3 pixel), but Cemu generates 6 sets. With only a small numbers of shaders this isn't that big of a deal, but since most games actually ship with hundreds of shaders the number of possible permutations is huge. Even worse, each shader set contains a copy of both the vertex and the pixel shader. So in total we are generating 12 shaders from only 5 shaders as input.
The obvious but difficult solution
Naturally, we should try to avoid creating shaders whenever possible. In theory the solution is easy: Scrap the concept of shader sets and handle shaders individually. Modern OpenGL allows us to do that, so why not make use of it.
However, this is easier said than done. There are a few problems that need to be solved: Not all shaders translate well and sometimes the pixel shader affects the vertex shader and vice versa. In such a case we are forced to create and use those shaders in a set because they cannot exist independently. Another problem is that the current render state can affect the generated shaders. For example, if alpha transparency is enabled it modifies the pixel shader that Cemu generates. Meaning we are forced to generate one pixel shader without alpha transparency and one with it.
But ultimately we try to strive for perfection. Thus, for 1.7.6 we decided to scrap the shader set system in it's entirety and replace it with a solution that can handle individual shaders. The idea is that the new solution is as adaptive as possible. Ideally, it should be able handle shaders individually but also be able to deal with cross-shader dependencies.
The only downside:
The massive change in how we handle shaders in Cemu will break compatibility with already existing shader caches and graphic packs (if they use custom shaders).
Separable shaders (summary)
Cemu 1.7.6 will handle vertex, pixel and geometry shaders individually instead of pairing them up into sets. This allows individual shader types to be reused.
The pros:
Faster shader compilation overall
Less RAM usage by shaders
Better performance
It's too early to give exact numbers yet.
The cons:
Breaks compatibility with shader caches from 1.7.5 or below
Breaks compatibility with graphic packs if they use custom shaders
Apr 30 at 10:22pm
Here is a preview of what to expect in Cemu 1.7.6. Keep in mind that development just started a week ago and everything mentioned in this post is subject to change. There is currently no set release date but we plan to spent about 3-4 weeks working on this release.
General plans
For 1.7.6 we will be looking into the following:
Separable shaders (details below)
Graphic fixes
Performance improvements
Fixing remaining rare FPU emulation related gameplay bugs (e.g. Splatoon)
And as usual, other various bugs and minor problems
If time permits we will also look into audio and compatibility improvements.
Separable shaders
This part will be quite technical and if you just want to read a summary of what to expect from this change, you can scroll to the end.
Let's start with a bit of background knowledge. Here is an image of a modern render pipeline: Image (Taken from the Khronos OpenGL wiki) The image depicts the steps on the GPU to go from some input geometry data to a pixel on the screen. For the purposes of this post we don't have to worry about all the steps and we can boil it down to only these shader stages:
Vertex shader
Geometry shader (Optional)
Pixel shader (Optional) Also called fragment shader
The above applies to OpenGL, DirectX, Vulkan or any other rendering API on PC. For Wii U it's not exactly identical, but similar enough that we don't need to dive into details.
The problem
For historical reasons Cemu always looked at the entire shader pipeline as a whole and shaders were generated in sets. That means that for each possible configuration of shader types, Cemu would generate a new shader set upon first use. This set would contain a copy of the vertex shader, the geometry and pixel shader. If individual shaders were reused but other stages differed, Cemu would create a new set regardless.
It's easier to explain this with an example:
Assume we have 2 vertex shaders (vsA, vsB), 3 pixel shaders (psA, psB, psC) and no geometry shaders.
The game does the following draw operations:
Draw 1: vsA + psA
Draw 2: vsA + psB
Draw 3: vsA + psC
Draw 4: vsB + psA
Draw 5: vsB + psB
Draw 6: vsB + psC
Question: How many shader sets do we need to create?
The correct answer is 6. Each of the draw operations uses a unique configuration of shader types.
This is where we start to see the inefficiency emerge: There are only 5 shaders (2 vertex + 3 pixel), but Cemu generates 6 sets. With only a small numbers of shaders this isn't that big of a deal, but since most games actually ship with hundreds of shaders the number of possible permutations is huge. Even worse, each shader set contains a copy of both the vertex and the pixel shader. So in total we are generating 12 shaders from only 5 shaders as input.
The obvious but difficult solution
Naturally, we should try to avoid creating shaders whenever possible. In theory the solution is easy: Scrap the concept of shader sets and handle shaders individually. Modern OpenGL allows us to do that, so why not make use of it.
However, this is easier said than done. There are a few problems that need to be solved: Not all shaders translate well and sometimes the pixel shader affects the vertex shader and vice versa. In such a case we are forced to create and use those shaders in a set because they cannot exist independently. Another problem is that the current render state can affect the generated shaders. For example, if alpha transparency is enabled it modifies the pixel shader that Cemu generates. Meaning we are forced to generate one pixel shader without alpha transparency and one with it.
But ultimately we try to strive for perfection. Thus, for 1.7.6 we decided to scrap the shader set system in it's entirety and replace it with a solution that can handle individual shaders. The idea is that the new solution is as adaptive as possible. Ideally, it should be able handle shaders individually but also be able to deal with cross-shader dependencies.
The only downside:
The massive change in how we handle shaders in Cemu will break compatibility with already existing shader caches and graphic packs (if they use custom shaders).
Separable shaders (summary)
Cemu 1.7.6 will handle vertex, pixel and geometry shaders individually instead of pairing them up into sets. This allows individual shader types to be reused.
The pros:
Faster shader compilation overall
Less RAM usage by shaders
Better performance
It's too early to give exact numbers yet.
The cons:
Breaks compatibility with shader caches from 1.7.5 or below
Breaks compatibility with graphic packs if they use custom shaders
Occhio al disclaimer 
Ecco, adesso arriveranno gli swat a casa di Tuco e domani mattina sarà a raccogliere saponette a Guantanamo.
Goodnight sweet prince.
Goodnight sweet prince.
la CEMU police!
Hai ragione, sono stato uno sconsiderato.
Ora lo rimuovo dal quote.
ot ma non troppo: è stato annunciato il primo dlc per zelda botw http://zelda.com/breath-of-the-wild/news/expansion-pass-dlc-pack-1-detailed/
a me pare na sola
il secondo uscirà verso natale
a me pare na sola
il secondo uscirà verso natale
Ma come i DLC anche su zelda ora?
Ma sbaglio o è il primo della serie ad avere DLC?
Ma sbaglio o è il primo della serie ad avere DLC?
Siamo anche nel 2017 e i DLC sono parecchio remunerativi per essere ignorati.
Sono la prassi per i giochi un minimo grossi.
Sembra veramente monnezza.
Più che un DLC sembra una patch, a parte "trial of the sword" non mi pare ci sia alcun contenuto nuovo
Una patch che si paga però
3 immagini scarse di nuova ambientazione e 5 di costumi
A quanto potrebbero vendere il dlc? 9.90? 19.90? 29.90?
edit:
La varietà dei mostri presenti si sapeva, ma porca puttana
Considerato che un pezzo di plastica con una usb e una hdmi costa 90 euro, direi che 5 costumi e altre due cazzate fanno 44,99. Che faccio lascio?
Ma lo schermo di plastica è più semplice da sostituire 
no di piú l'hard mode permette praticamente di riocarlo da zero, é come regalarti un nuovo gioco
98,99€
Poi di sicuro dentro la patch ci sarà qualche anti-CEMU
Ma poi l'idea del regen per l'hard mode a me sembra anche un'idea di merda.
Almeno fare il minimo sforzo di inventarsi due/tre creature nuove che menano duro e inserirle in zone critiche della mappa, si poteva prendere due piccioni con una fava, fava piuttosto cara peraltro.
Almeno fare il minimo sforzo di inventarsi due/tre creature nuove che menano duro e inserirle in zone critiche della mappa, si poteva prendere due piccioni con una fava, fava piuttosto cara peraltro.