This function initially returned a ByteBuffer, so `return {}` was fine.
It was then changed to return Optional<ByteBuffer>, so we accidentally
started returning an empty Optional instead. Explicitly specify the
constructor name to fix this.
Thanks to DexesTTP for catching this!
This is a simple implementation of SubtleCrypto.digest() using LibCrypto
under the hood, so it supports all the required hash functions:
SHA-1, SHA-256, SHA-384, SHA-512.
Two FIXMEs remain: doing the hashing "in parallel", and supporting an
object argument instead of a plain string.
Just some boilerplate code to get started :^)
This adds both the SubtleCrypto constructor to the window object, as
well as the crypto.subtle instance attribute.
Similar to commit 2a7f36b392, this change moves the generated
CalendarSymbol enumeration to the public LibUnicode/NumberFormat.h
header with a pre-defined set of symbols that we need. This is to
prepare for uniquely generating the CalendarSymbols structure.
This file refers to the controlling terminal associated with the current
process. It's specified by POSIX, and is used by ports like openssh to
interface with the terminal even if the standard input/output is
redirected to somewhere else.
Our implementation leverages ProcFS's existing facilities to create
process-specific symbolic links. In our setup, `/dev/tty` is a symbolic
link to `/proc/self/tty`, which itself is a symlink to the appropriate
`/dev/pts` entry. If no TTY is attached, `/dev/tty` is left dangling.
If an unsupported drawing mode was configured, `glEnd` would not reach
the line where `m_in_draw_state` was set to `false`. This caused all
subsequent invocations to `glBegin` to fail.
Most resources seem to suggest that points on the clip planes are also
inside the frustum, e.g.: https://www.cubic.org/docs/3dclip.htm
This seems to resolve some rendering issues in Grim Fandango in OpenGL
mode where the screen remained black. This was because of quads being
drawn with their vertex positions exactly on the clip planes.
In its current state, ScummVM seems to invoke these methods just after
destroying the current GL context. According to the OpenGL spec:
"Issuing GL commands when the program does not have a current
context results in undefined behavior, up to and including program
termination."
Our old behavior was to deref a `nullptr`, which isn't that great. For
now, protect these two methods. If other ports seem to misbehave as
well, we can always expand the check to other methods.
The `glGet*` family of functions requires that all parameters of
different types are transparently converted into each other. For
example, you can request a boolean parameter as a float or a list of
double values as an integer. It might be considered bad practice to
request parameters through the wrongly-typed function, but to be spec-
compliant we need to implement this.
Introduce a new `::get_context_parameter()` to obtain a parameter
value, which is then converted to the right type by the respective
`::gl_get_*()` functions.
GLES 2.0 is a subset of OpenGL, so we allow applications to compile
against LibGL as if it fully supports GLES 2.0.
Additionally, we set the definitions to an integer value of `1` so
applications that check for availability like this...
int main() { return GL_ES_VERSION_2_0; }
...can actually compile. At least ScummVM uses this, and Mesa defines
their constants in the same way:
44b9e11ddb/include/GL/gl.h (L105)
