The main advantage of switching to glad from glLoadGen is that, apart
from being actively maintained, it supports a customizable entrypoint
loader function, which makes it possible to also support OpenGL ES.
If an OpenGL object is created, bound to a binding using the state
tracker, and then destroyed, a newly created object can be assigned the
same numeric handle by OpenGL. However, even though it is a new object,
and thus needs to be bound to the binding again, the state tracker
compared the current and previous handles and concluded that no change
needed to be made, leading to failure to bind objects in certain cases.
This manifested as broken text in VVVVVV, which this commit fixes along
with similar texturing problems in other games.
In OpenGL 3, texturing is always enabled, and this call is invalid.
While it produced no effect in the rest of the execution, it wouldn't
have the intended effect of disabling texturing for that unit. Instead
bind a null texture to the unit.
This is exposed in the GUI as a new "CiTrace Recording" widget.
Playback is implemented by a standalone 3DS homebrew application (which only runs reliably within Citra currently; on an actual 3DS it will often crash still).
memory.cpp/h contains definitions related to acessing memory and
configuring the address space
mem_map.cpp/h contains higher-level definitions related to configuring
the address space accoording to the kernel and allocating memory.
Involves making asserts use printf instead of the log functions (log functions are asynchronous and, as such, the log won't be printed in time)
As such, the log type argument was removed (printf obviously can't use it, and it's made obsolete by the file and line printing)
Also removed some GEKKO cruft.
Hardware testing determined that the GSP processes shared memory
framebuffer update info even when no memory transfer or filling GX
commands are used. They are now updated on every interrupt, which isn't
confirmed correct but matches hardware behaviour more closely.
This also reverts the hack introduced in #404. It made a few games
behave better, but I believe it's incorrect and also breaks other games.
The view is scaled to be as large as possible, without changing the aspect, within the bounds of the window.
On "retina" displays, or other displays where window units != pixels, the view should no longer draw incorrectly.
This prevents a crash when the buffer size returned by the driver is 0,
in which case no space is allocated to store even the NULL byte and
glGetShaderInfoLog errors out.
Thanks to @Relys for the bug report.
The OpenGL renderer has been revised, with the following changes:
- Initialization and rendering have been refactored to reduce the number of
redundant objects used.
- Framebuffer rotation is now done directly, using texture mapping.
- Vertex coordinates are now given in pixels, and the projection matrix
isn't hardcoded anymore.
This should fix the GL loading errors that occur in some drivers due to
the use of deprecated functions by GLEW. Side benefits are more accurate
auto-completion (deprecated function and symbols don't exist) and faster
pointer loading (less entrypoints to load). In addition it removes an
external library depency, simplifying the build system a bit and
eliminating one set of binary libraries for Windows.
Screen contents are now displayed using textured quads. This can be updated to expose an FBO once an OpenGL backend for when Pica rendering is being worked on. That FBO's texture can then be applied to the quads.
Previously, FBO blitting was used in order to display screen contents, which did not work on OS X. The new textured quad approach is less of a compatibility risk.
This cleans up the mess that address reading/writing had become and makes the code a *lot* more sensible.
This adds a physical<->virtual address converter to mem_map.h. For further accuracy, we will want to properly extend this to support a wider range of address regions. For now, this makes simply homebrew applications work in a good manner though.
While it was some nice and fancy template usage, it ultimately had many practical issues regarding length of involved expressions under regular usage as well as common code completion tools not being able to handle the structures.
Instead, we now use a more conventional approach which is a lot more clean to use.
