TheSpydog
297f234957
continuous-integration/drone/push Build is passing
Details
**Breaking API Changes** * Removed `REFRESH_SAMPLECOUNT_16/32/64`, since hardware support for these sample counts is generally poor (and completely non-existent with MoltenVK and certain consoles). * Removed unused `sampleCount` parameter from `Refresh_TextureCreateInfo`. * Removed `sampleCount` parameter from `Refresh_ColorAttachmentDescription`. The existence of this parameter meant you had to sync up three different sample count values (render pass, pipeline, and color attachment description) whenever you wanted to use multisampling. However, Vulkan requires that all color attachments in a given pipeline _must_ match the pipeline's sample count anyway, so we can assume all color attachments will use the pipeline's sample count. * Removed the `renderArea` parameter from `Refresh_BeginRenderPass()` since it didn't serve much practical purpose and slightly complicated things on the MoonWorks managed side. **Behavior Changes** * When creating a render pass or graphics pipeline, the requested multisample count will be converted into a sample count that's actually supported by the GPU. For example, if you request 8x MSAA on a device that only supports up to 4x MSAA, it will silently fall back to 4x MSAA. * All color attachments are now forced to have an internal store op of `STORE`, even if `REFRESH_STORE_OP_DONTCARE` is specified. The one exception is internal multisample textures -- if `DONTCARE` is used, those textures will be discarded to save on bandwidth. (Their resolve textures will still be stored.) * The RenderPass hashing logic was updated so that it would still work correctly with the removal of `Refresh_ColorAttachmentDescription.sampleCount`. **Bug Fixes** * Fixed bugs where multisampling logic wasn't kicking in for certain sample counts due to incorrect enum comparisons. Co-authored-by: Caleb Cornett <caleb.cornett@outlook.com> Reviewed-on: #26 Co-authored-by: TheSpydog <thespydog@noreply.example.org> Co-committed-by: TheSpydog <thespydog@noreply.example.org> |
||
|---|---|---|
| Vulkan-Headers@1d99b835ec | ||
| include | ||
| src | ||
| visualc | ||
| .drone.yml | ||
| .editorconfig | ||
| .gitignore | ||
| .gitmodules | ||
| CMakeLists.txt | ||
| LICENSE | ||
| README.md | ||
README.md
This is Refresh, an XNA-inspired 3D graphics library with modern capabilities.
License
Refresh is licensed under the zlib license. See LICENSE for details.
About Refresh
Refresh is directly inspired by FNA3D and intended to be a replacement for XNA's Graphics namespace. XNA 4.0 is a powerful API, but its shader system is outdated and certain restrictions are awkward to handle in a modern context. In the way that XNA was "one step above" DX9, Refresh intends to be "one step above" Vulkan. It should map nicely to modern graphics APIs. Refresh will initially have a Vulkan runtime implementation. Support for other APIs like DX12 may come later. For shaders, we consume SPIR-V bytecode.
Dependencies
Refresh depends on SDL2 for portability. Refresh never explicitly uses the C runtime.
Building Refresh
For *nix platforms, use CMake:
$ mkdir build/
$ cd build/
$ cmake ../
$ make
For Windows, use the Refresh.sln in the "visualc" folder.
Want to contribute?
Issues can be reported and patches contributed via Github: