This only moves the issue, as PerformanceEventBuffer::add_process can't
fail yet, but this will allow us to remove the non-failable
Custody::absolute_path API.
ProjectBuilder takes care of building and running the current project
from Hack Studio.
The existing functionality of building javascript and Makefile projects
remains, and in addition to it the ability to build standalone serenity
components is added.
If the Hack Studio project is the serenity repository itself,
ProjectBuilder will attempt building the component that the currently
active file belongs to.
It does so by creating a new CMake file which adds the component as a
build subdirectory.
It also parses all CMake files in the serenity repository to gather all
available libraries. It declares the libraries and their dependencies in
this CMake file.
It then uses the HACKSTUDIO_BUILD CMake option to direct the build
system to use this CMake file instead of doing a full system build.
If this option is set, we will not build all components.
Instead, we include an external CMake file passed in via a variable
named HACKSTUDIO_BUILD_CMAKE_FILE.
This will be used to build serenity components from Hack Studio.
Previously, Core::command only returned a String which contained the
data from stdout.
The CommandResult struct contains the exit code as well as the data
from stdout and stderr.
According to the OpenGL spec, invoking functions without an active
context results in undefined behavior. Since ScummVM seems to be the
only port having issues with our behavior, patch their code instead.
We don't mutate the pointed-to memory, so let's be const correct.
Fixes building the `mimalloc` library that's optionally used by the mold
linker (note that it isn't enabled yet as I haven't tested it).
Although we handle it in the linker spec file, gcc will actually reject
this argument unless it's also enabled in the option file.
CMake adds this flag if the minimum required version is 3.3 or less (see
CMP0065), so old projects would fail to compile because of this
unrecognized option.
This function is an extended version of `chmod(2)` that lets one control
whether to dereference symlinks, and specify a file descriptor to a
directory that will be used as the base for relative paths.
When deleting an entire AddressSpace, we don't need to do TLB flushes
at all (since the entire page directory is going away anyway).
We also don't need to deallocate VM ranges one by one, since the entire
VM range allocator will be deleted anyway.
If there's less than 3 vertices, we cannot do triangle strip otherwise
we will go out-of-bounds of the vertices vector.
Required for Half-Life, which sometimes submits 0 vertices for triangle
strip when drawing the electric disks around the pillars in Xen.
This was currently only set in the OpenGL context, as the previous
architecture did all of the transformation in LibGL before passing the
transformed triangles onto the rasterizer. As this has now changed, and
we require the vertex data to be in eye-space before we can apply
lighting, we need to pass this flag along as well via the GPU options.
Most of the T&L stuff is, like on an actual GPU, now done inside of
LibSoftGPU. As such, it no longer makes sense to have specific values
like the scene ambient color inside of LibGL as part of the GL context.
These have now been moved into LibSoftGPU and use the same pattern as
the render options to set/get.
These two functions have been turned from stubs into actually doing
something. They now set the correspondingmaterial data member based on
the value passed into the `pname`argument.
Co-authored-by: Stephan Unverwerth <s.unverwerth@serenityos.org>
This implements the `glLightf{v}` family of functions used to set
lighting parameters per light in the GL. It also fixes an incorrect
prototype for the user exposed version of `glLightf{v}` in which
`params` was not marked as `const`.
This is required to allow lighting to work properly in the GL. We
currently have the maximum number of lights in the software GL context
set to 8, as this is the minimum that OpenGL mandates according to the
spec.
We can use `StringView::for_each_split_view` here to avoid the potential
allocation of `Vector<StringView>` elements we would get from the normal
Split view functions.
StringView::for_each_split_view allows you to process the splits in a
StringView without needing to allocate a Vector<StringView> to store
each of the parts.
Since we migrated the implementation from the normal split_view path, we
can also re-implement split_view in terms of for_each_split_view.
