2. Update video extension API version to 3.0.0
- add extra 0 to CoreVideo_SetVideoMode() call, to signify that this plugin does not support a resizable window
3. Update video plugin API version to 2.2.0, add ResizeVideoOutput() function which doesn't do anything
The Glitch64 library is now part of glide64mk2 and it doesn't need to check the
symbols of an external library. Therefore, no wxDynamicLibrary is needed.
Some systems don't have the required boost support and would not be able to
compile glide64 without adding a lot of new dependencies to their build
environment.
GCC produces warnings when the statement is to confusing for the reader and
misinterpretations could happen. These can be avoided by adding parentheses to
clarify the statement.
Glitch64 uses fragment shaders extensively to emulate combiners. These also
affect external parts in other components of the emulator. Disabling them
before returning to the emulator should fix for example the OSD.
The user cache path for mupen64plus is something different compared to the user
data path. On Unix systems it is stored in $HOME/.cache/mupen64plus/ and all
non-cache/non-config data is stored in $HOME/.local/share/mupen64plus.
The Windows+single user centric view of the original GlideHQ made it store its
cache in the local plugins directory in a special folder called "cache". This
is not available anymore and therefore the user cache directory is used
instead. A subfolder called "glidehq" is used to avoid collisions with non
GlideHQ compatible data.
The original Rice CRC algorithm always assumes an image size of at least 4
bytes per image. This is not a valid assumption and causes invalid memory
access when the byte width of an image is smaller. Avoiding the calculation of
the CRC in this situation seems to be a better choice.
The glide64 plugin for mupen64plus is available at the same time as the
glide64mk2 video plugin. Both support different features and use different
configuration options. A clear distinction is necessary to avoid confusion by
the users.
The status updates are limited by the amount of frames which can be rendered.
Showing a status update for each hires texture limits also the loading of them.
This gets even more problematic when vsync is enabled.
Now only every 0.25 seconds a status update is made. This is enough to keep the
user a feeling what is happening and still utilize the CPU and the I/O enough.
The support for TEXTURE_FILTER is the start to get GlideHQ working. Remaining
work items are:
* Setting the correct path for HighRes textures
* Config support for ghq_fltr
* Config support for ghq_cmpr
* Config support for ghq_enht
* Config support for ghq_hirs
* Fixing random crashes
