ARM only at the moment. Could potentially support x86 and MIPS if necessary.
Capable of parsing the manufacturer codes and part IDs of some (but not all part numbers). If anyone knows of part numbers that aren't in the list, please report them.
- Spaces -> Tabs | Consistency
- Javadoc everything that was added and not documented.
- Remove duplicated code regarding the adapter that used to reside in DolphinInfoFragment.java. Now it resides in AboutActivity.java without a second duplication of it.
- Properly retrieve all of the contexts in the EGL initialization in EGLHelper.java.
- Remove the attribute EGL_RENDERABLE_TYPE from the pbuffersurface attributes in EGLHelper.java. With this present, the EGL context will always fail to reinitialize if destroyed and attempted to be recreated.
- Break the inner class Limit within GLES2InfoFragment.java, GLES3InfoFragment.java, and GLInfoFragment.java into its own single class. Greatly reduces code duplication.
- Introduce a Type enum into Limit.java (one of the wildly rare cases in Java where an enum is actually an OK solution). Removes duplicated constants from the Java files stated in the previous bullet note.
- Add a copyright comment to the top of EGLHelper.java. Forgot to do this initially, my bad.
- Add some missing override annotations to GLES2InfoFragment.java, GLES3InfoFragment.java, and GLInfoFragment.java.
- Use StringBuilders in the previously mentioned three Java files. This is better than using a String in this instance, as the String object won't have to be recreated multiple times (ala concatenation).
- Fix some constant accessors in the previously mentioned three Java files.
- Added the 'final' modifier to the above three classes and to Limit.java. These classes serve a single purpose only, and are not intended to be inherited.
There is a /lot/ of information in these tabs, we may have to think about changing how the information looks
OpenGL isn't done yet since there are a million limits on desktop GL, may just show a few things and extensions there.
Some information on this bug since this isn't quite true.
Seemingly with the v53 driver, Qualcomm has actually fixed this bug. So we can dynamically access UBO array members.
The issue that is cropping up is actually converting our attribute 'fposmtx' to an integer.
int posmtx = int(fpostmtx);
This line causes some seemingly garbage values to enter in to the posmtx variable.
Not sure exactly why it is failing, probably them just not actually converting the float to an integer and just handling the float directly as a integer.
So the bug is going to stay active with Qualcomm devices until we convert this vertex attribute from a float to a integer.
Let's talk a bit about this bug. 12nd oldest bug not fixed in Dolphin, it was a
lot of fun to debug and it kept me busy for a while :)
Shoutout to Nintendo for framework.map, without which this could have taken a
lot longer.
Basic debugging using apitrace shows that the heat effect is rendered in an
interesting way:
* An EFB copy texture is created, using the hardware scaler to divide the
texture resolution by two and that way create the blur effect.
* This texture is then warped using indirect texturing: a deformation map is
used to "move" the texture coordinates used to sample the framebuffer copy.
Pixel shader: http://pastie.org/private/25oe1pqn6s0h5yieks1jfw
Interestingly, when looking at apitrace, the deformation texture was only 4x4
pixels... weird. It also does not have any feature that you would expect from a
deformation map. Seeing how the heat effect glitches, this deformation texture
being wrong looks like a good candidate for the problem. Let's see how it's
loaded!
By NOPing random calls to GXSetTevIndirect, we find a call that when removed
breaks the effect completely. The parameters used for this call come from the
results of methods of JPAExTexShapeArc objects. 3 different objects go through
this code path, by breaking each one we can notice that the one "controlling"
the heat effect is the one at 0x81575b98.
Following the path of this object a bit more, we can see that it has a method
called "getIndTexId". When this is called, the returned texture ID is used to
index a map and get a JPATextureArc object stored at 0x81577bec.
Nice feature of JPATextureArc: they have a getName method. For this object, it
returns "AK_kagerouInd01". We can probably use that to see how this texture
should look like, by loading it "manually" from the Wind Waker DVD.
Unfortunately I don't know how to do that. Fortunately @Abahbob got me the
texture I wanted in less than 10min after I asked him on Twitter.
AK_kagerouInd01 is a 32x32 texture that really looks like a deformation map:
http://i.imgur.com/0TfZEVj.png . Fun fact: "kagerou" means "heat haze" in JP.
So apparently we're not using the right texture object when rendering! The
GXTexObj that maps to the JPATextureArc is at offset 0x81577bf0 and points to
data at 0x80ed0460, but we're loading texture data from 0x0039d860 instead.
I started to suspect the BP write that loads the texture parameters "did not
work" somehow. Logged that and yes: nothing gets loaded to texture stage 1! ...
but it turns out this is normal, the deformation map is loaded to texture stage
5 (hardcoded in the DOL). Wait, why is the TextureCache trying to load from
texture stage 1 then?!
Because someone sucked at hex.
Fixes issue 2338.
At the moment, custom textures with:
- invalid mipmap size
- invalid aspect ratio
- non-fractional scaling factors
are allowed. But they can't be loaded fine by the backend, so generate a warning if someone trys to load them.
fixes issue 6898
OpenGL defaults are GL_REPEAT, which is even more unlikely than GL_CLAMP_TO_EDGE.
As I can't test the behavoir of the real hardware, I changed it to how it works before,
but I guess just clip the texture makes more sense.
Some settings that bootmanger reads from game ini can be changed while a game is running, so we don't have to revert these back to what they were when starting the game, unless they were actually changed by the game ini.
Fix signed/unsigned warnings that pauldacheez pointed out.
Lioncash
