jessydl / paradigm Goto Github PK
View Code? Open in Web Editor NEWC++20 Vulkan and GLes rendering engine
Home Page: https://paradigmengine.dev
C++20 Vulkan and GLes rendering engine
Home Page: https://paradigmengine.dev
Look into tracking bulk erase operations, and compact after the erasions have been completed (lowering the amount of moving memory significantly)
To complete #64 first step we should implement a container type that can do most of the functionality staged_sparse_array
can do, with exclusion of dealing with non-trivial types (i.e. types that don't satisfy std::is_trivial
).
Following are a list of features that should be investigated or added to the ECS implementation:
Extra:
core::ecs::components::transform
issue in internal docs)Severity: High (causes non-fatal issue, and recovers next frame)
Issue:
GPU memory can get trashed when realloc happens in a buffer when, in a single frame, range A moves, followed by range B reallocs onto the old range A location. This results in a frame where the affected commands interacting with that region of memory can get incorrect results (f.e. in the case of rendering geometry, usually a "jitter" is observed). This recovers the next frame as the correct offsets are recorded.
Possible resolution:
Implement a mechanism to mark regions of memory as locked
while they are in flight, deferring their dealloc. Let these locks be attached to preferably a user controllable solution, so that we can solve this using fences for this instance, and potentially barriers/others in case of other user defined use cases.
The stringifying of typenames cannot deal with templated types correctly cross platform (issue related to NTTP & defaulted template args). Either we reject NTTPs (would require considerable parsing), and figure out a solution to sidestep defaulted template args (MSVC differs from GCC/CLang), or reject all templated names for the time being.
Currently the psl::serialization
system requires a serialization_name
to be present in the serialization supported objects. This currently is a const char[]
where users need to explicitly write the size of the buffer. Modify this so the user either doesn't need it (unlikely), or where the size of this is known automatically.
As PR #101, apply this to details::staged_sparse_array.
Investigate an alternative approach, and then wholesale replace the existing resource loading system.
The alternative will have these constraints and goals:
* immutable authoritive source seems to be impossible without large efforts in architecture as when f.e. a buffer is loaded we obviously need to be able to write to it if it's used for those purposes.
The current approach selects the "last loaded" to be the authoritive source of what is the disk based assets (for the find
method), but allows load to be called N times and get a fresh version as if just loaded from disk
As the system has been implemented using coroutines, you can simply use co_await
in the construct
method and await for you relevant signal to fire, or to switch to other threads.
All resources are always tracked by default. This isn't toggleable for now (this is to satisfy the safe resource destruction requirement). However, you can control when resources get destroyed if it's safe to do so (i.e. the last references are held by the cache, and the caller). The try_destroy
method will verify if it's safe, and will destroy the resource within the given scope.
Alternatively, the unsafe_destroy
will forcibly destroy the resource. This functionality is hidden behind the RESOURCE_ALLOW_UNSAFE
define.
consider renaming construct
to co_construct
/s
Currently the underlying storage knows about the type. This allows us to handle non-trivial types, but disallows us from trivially deserializing these types without knowing the type up front. Ideally we solve this by making the underlying storage itself generic allowing the sidestepping of this problem, and not with type registration patterns.
This issue interacts with #63 and #65 , particularly dealing with complexer types such as reference tracked handles should be considered when solving this problem.
psl::ecs::details::component_info
to utilize this. Preferably figure out a correct way of dealing with flag types that don't incur overhead. Fetching data from this new type should be type-safe (i.e. upper types shouldn't be the one dealing with type safety concerns).Note: we could consider a hybrid system where any serializable component has to use the untyped storage, while serializable components can have non-trivial types.
Currently no method of automated builds for Android exist, resolve this.
What is expected:
Currently filters use the component key, and do a lookup just when the filtering operation is done. This could be improved by having the component container be used instead (when available), and fall back to the key behaviour.
PR #78 introduced stage_t
and stage_range_t
, we should use these in all user facing layers in favour of the hard-coded numeric values.
The feature introduced in PR #51 currently lacks an implementation on CLang 14 and earlier. When std::source_location
becomes available, remove the wrapper code, and clean up the printer.
App currently doesn't recover from going to sleep/background on the Android platform.
goal: app gracefully can go to background for any time, any duration, and either reboots, or continues execution.
Documentation should be generated through the CI every PR merge (or every commit to develop
)
Ideally the documentation would be accessible online versioned. This could be achieved by having versioned folders based on tag on gh-pages
branch i.e.:
root
0.1.0/**
0.1.1/**
all_files_current_develop
psl::serialization
needs some additional work to allow for polymorphic serialization irrespective of the used encoder/decoder.
Current codepath for vulkan texture loading doesn't check for supported formats. Resolve this and gracefully handle, or error out.
When storing a type that has been aligned using alignas
GCC will generate faulty code when fetching the data from a component pack.
example:
struct alignas(16) foo {
float data[4];
};
state_t state{};
state.create<foo>(1);
state.declare([](info_t& info, pack<foo> pack){
for(auto [value] : pack) {
volatile auto copy = value; // <- segfault
}
});
state.tick(std::chrono::duration<float>(1.0f));
Add missing CI workflow for Ubuntu GLES combination
Currently the MaterialData
binding's backing storage is "set once, change never". This can work for toy examples but is bad for actual production.
Proposed changes (choose one):
Advantage:
Cons:
Implementing this in bundles has the distinct advantage that materials already store their instance data there
Pros:
Cons:
Implement material data handling in either bundles/material (prefer bundles), defer to a global buffer unless size exceeds N bytes, or global buffer runs out of size. When global buffer runs out of size, either allocate 2nd global buffer or do smaller self managed allocations.
Pros:
Cons:
The ECS state should be fully de/serializable, this includes all the components, and the to-be-processed state. Potentially we serialize the filters as well, but these are less important as that's internal optimization.
Registered systems are not to be serialized.
Note that support for deserializing into an already modified ECS state is considered an "extra" and not necessary.
The way the packs are handled internally in the ecs state results in some copying; as the indirect packs are managing their own memory (the indices only), this results in some overhead for copying. If we make the indirect packs as lightweight as the direct packs (by using the state's internal cache), then we can remove quite a bit from this overhead.
Support basic animated models using skeletal animation keyframes. Dealing with import is left for the assembler
project.
Preferably the implementation is done through compute shaders for the transformations, but is not a requirement. If not implemented through compute, it is considered a defect that has to be resolved before 1.0.0
Compute shaders can already be loaded, but have some edge cases in resource handling and dependency tracking.
Finalize *::computepass
and *::computecall
to offer the full functionality set as is expected.
At the end we should be able to effortlessly load a "compute" material that outputs to a texture (or other resource), which is then consumed by another "draw" or "compute" material. Preferably this has almost no user interactions needed (i.e. no code to map to one another if everything is described in data files).
This means finding a solution for reference tracked resources (f.e. core::resource::handle), and resources that contain indirections (f.e. std::string). This likely means these resources would need to persist elsewhere in the ecs::state rather than the typical component storage structure, and the storage structure holding indirections to.
Currently we ignore this constraint resulting in being allowed to use these non-conforming elements, and thanks to the way the internal memory storage is handled this is still valid. But as we need to support std::is_trivial
in the future for other ECS features, this should be handled first before proceeding.
Due to the requirements of std::is_trivially_constructible
we cannot have constructors with side effects for serializable types. Add the ability to have a "prototype" function of some sort allowing the user to specify a "good default value" for a new instance.
This works as the only time new objects get created is either from a known position (from the type system's perspective), or from known data (deserialization and internal stack).
Currently there is no iwgpu layer implementation for pipelines, or pipeline caching. These are required for the agnostic abstraction layer, and as well for the convenience when targeting just the webgpu backend.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.