Apparently the path was changed from using "/thump.png" to using
"/gameId-#.png". We will always use the first screenshot for the game
broswer wich will be "/gameId-1.png"
Saving screenshot was not working due to 2 problems. The first one is that
the view id of the save screenshot in the Android TV fragment doesnt match
the one declared inside the menu_emulation. Second Problem will be fixed
in another commit.
This commit chnage the code to not depend on reusing the ids of the menu
everywhere in the emulator inorder for the onMenuItemClicked to work.
Instead you need to call EmulationActivity.handleMenuAction passing
the action to handle regardless of the ids you are using in the view.
Dolphin assumes that content 0 is opening.bnr, without checking
whether content 0 exists or if it is even supposed to be there (it's
only there for channels). This results in sometimes reading garbage.
This adds a check to only try to read names from content 0's header
if the title is a channel (channel, system channel or game channel).
Trying to return to the Wii Menu from a game is the easiest
way to trigger this error. Just saying 0000000100000002
when that happens doesn't mean much to most users.
The FrameBufferManager::CreateTexture (from the OpenGL backend) method introduced by commit 69cedf41 incorrectly compares the texture variable (which contains a name provided by glGenTextures) against GL_TEXTURE_2D_MULTISAMPLE_ARRAY and GL_TEXTURE_2D_MULTISAMPLE.
It should instead use the texture_type variable for this (as done in the first branch of the if).
Places all of the SI code under the SerialInterface namespace instead of
only the main source file. This keeps all SI code under a common name,
as well as out of the global namespace
This commit should have zero performance effect if SSBOs are supported.
If they aren't (e.g. on all Macs), this commit alters FramebufferManager
to attach a new stencil buffer and VertexManager to draw to it when
bounding box is active. `BBoxRead` gets the pixel data from the buffer
and dumbly loops through it to find the bounding box.
This patch can run Paper Mario: The Thousand-Year Door at almost full
speed (50–60 FPS) without Dual-Core enabled for all common bounding
box-using actions I tested (going through pipes, Plane Mode, Paper
Mode, Prof. Frankly's gate, combat, walking around the overworld, etc.)
on my computer (macOS 10.12.3, 2.8 GHz Intel Core i7, 16 GB 1600 MHz
DDR3, and Intel Iris 1536 MB).
A few more demanding scenes (e.g. the self-building bridge on the way
to Petalburg) slow to ~15% of their speed without this patch (though
they don't run quite at full speed even on master). The slowdown is
caused almost solely by `glReadPixels` in `OGL::BoundingBox::Get`.
Other implementation ideas:
- Use a stencil buffer that's separate from the depth buffer. This would
require ARB_texture_stencil8 / OpenGL 4.4, which isn't available on
macOS.
- Use `glGetTexImage` instead of `glReadPixels`. This is ~5 FPS slower
on my computer, presumably because it has to transfer the entire
combined depth-stencil buffer instead of only the stencil data.
Getting only stencil data from `glGetTexImage` requires
ARB_texture_stencil8 / OpenGL 4.4, which (again) is not available on
macOS.
- Don't use a PBO, and use `glReadPixels` synchronously. This has no
visible performance effect on my computer, and is theoretically
slower.
GCMemcard.h has quite a bit of different classes implemented within it
that could likely be split up into other files to make it a little
easier to read. However, they should be moved into their own folder
first so that they don't clutter up the base HW directory.
Anthony