mirror of
https://github.com/baldurk/renderdoc.git
synced 2026-08-25 16:06:31 +00:00
Remove links to deleted wiki pages, and planned/roadmap features doc
This commit is contained in:
baldurk
@@ -14,7 +14,7 @@ To install on windows run the appropriate installer for your OS ([64-bit](https:
|
||||
* **Documentation**: [HTML online](https://renderdoc.org/docs), [CHM in builds](https://renderdoc.org/docs/renderdoc.chm), [Videos](https://www.youtube.com/user/baldurkarlsson)
|
||||
* **Contact**: [baldurk@baldurk.org](mailto:baldurk@baldurk.org), [#renderdoc on OFTC IRC](https://kiwiirc.com/nextclient/irc.oftc.net/#renderdoc), [Discord server](https://discord.gg/ahq6yRB)
|
||||
* **Code of Conduct**: [Contributor Covenant](docs/CODE_OF_CONDUCT.md)
|
||||
* **Information for contributors**: [All contribution information](docs/CONTRIBUTING.md), [Compilation instructions](docs/CONTRIBUTING/Compiling.md), [Roadmap](https://github.com/baldurk/renderdoc/wiki/Roadmap)
|
||||
* **Information for contributors**: [All contribution information](docs/CONTRIBUTING.md), [Compilation instructions](docs/CONTRIBUTING/Compiling.md)
|
||||
* **Community extensions**: [Extensions repository](https://github.com/baldurk/renderdoc-contrib)
|
||||
|
||||
Screenshots
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Code Explanation
|
||||
|
||||
There are [several pages](https://github.com/baldurk/renderdoc/wiki/Code-Dives) on the wiki explaining different aspects of how the code fits together - like how the capture-side works vs replay-side, how shader debugging works, etc.
|
||||
This is a rough 'table of contents' overview of how the main code components are organised:
|
||||
|
||||
renderdoc/
|
||||
CMakeLists.txt ; The cmake file, will recurse into subdirectories to build them
|
||||
|
||||
@@ -9,6 +9,9 @@ The coding style is primarily enforced by clang-format for things that can be ea
|
||||
For things that clang-format can't cover, there are a few guidelines below but the golden rule is to try and match the surrounding code as much as possible. The code isn't perfectly consistent so you might see varying naming conventions, avoid adding code that is significantly different to the context.
|
||||
|
||||
* `auto` is only allowed for types that are prohibitive: STL iterators and lambdas. Everywhere else you should use the explicit type.
|
||||
* Use `NULL` rather than `nullptr`.
|
||||
* If an `if` or `else` requires braces, add braces to all cases, rather than leaving one 'bare' without braces and another with braces.
|
||||
* Strings are always UTF-8, everywhere, unless they are wide strings which are only used for windows compatibility. Plain `char*` byte strings should be used everywhere in non-OS specific code, and are always treated as UTF-8 (never assume a string will be plain ASCII).
|
||||
* Limit STL use to a minimum. Allowed uses are `std::map`, `std::function`, `std::set`, algorithms like `std::sort` and `std::lower_bound`, and type-traits type checks like `std::is_same`. Use `rdcarray` instead of `std::vector` and `rdcstr` instead of `std::string`.
|
||||
* Don't use hungarian notation aside from `m_` for members. Some existing names will use `p` prefixes for pointers but it should be phased out in new code. The exception is when working with hooked functions where the official parameter names have hungarian notation.
|
||||
|
||||
@@ -24,7 +27,7 @@ Aim to merge your work to the main line in reasonably sized chunks. How big is a
|
||||
|
||||
# Where to Start
|
||||
|
||||
There are always plenty of things to do, if you'd like to chip in! Check out the [Roadmap](https://github.com/baldurk/renderdoc/wiki/Roadmap) page in the wiki for future tasks to tackle, or have a look at the [issues](https://github.com/baldurk/renderdoc/issues) for outstanding bugs. I'll try and tag things that seem like small changes that would be a good way for someone to get started with.
|
||||
There are always plenty of things to do, if you'd like to chip in! Check out the [issues](https://github.com/baldurk/renderdoc/issues) for outstanding feature requests.
|
||||
|
||||
If you have a change you'd like to see make it into mainline, create a fork of renderdoc, make your changes to a branch, and open a pull request on github. You can look around for instructions on that - it's pretty simple.
|
||||
|
||||
|
||||
@@ -4,7 +4,6 @@ Behind the scenes
|
||||
.. toctree::
|
||||
|
||||
analytics
|
||||
planned_features
|
||||
how_works
|
||||
opengl_support
|
||||
vulkan_support
|
||||
|
||||
@@ -3,8 +3,6 @@ OpenGL & OpenGL ES Support
|
||||
|
||||
This page documents the support of OpenGL & OpenGL ES in RenderDoc. This gives an overview of what RenderDoc is capable of, and primarily lists information that is relevant. You might also be interested in the :doc:`full list of features <../getting_started/features>`.
|
||||
|
||||
The latest information and up-to-date support is always available on the `GitHub wiki <https://github.com/baldurk/renderdoc/wiki/OpenGL>`_.
|
||||
|
||||
Capture requirements
|
||||
--------------------
|
||||
|
||||
|
||||
@@ -1,21 +0,0 @@
|
||||
Planned future features
|
||||
=======================
|
||||
|
||||
This is a list of features that are planned to be added at some point. Probably none of them have timelines or estimates yet, and they are in no particular order. I just would like to add them eventually. It's mostly here for interest, and for reference if you have a new feature request - it might be on here already!
|
||||
|
||||
For more detail and a more up to date list, check the `GitHub wiki <https://github.com/baldurk/renderdoc/wiki/Roadmap>`_.
|
||||
|
||||
Also note that none of these features are guaranteed. In an ideal world they would all happen but since work hasn't started on any of them some may turn out to be impractical or delayed indefinitely.
|
||||
|
||||
Planned features
|
||||
----------------
|
||||
|
||||
* Debugging of all shader stages.
|
||||
* Mesh display after hull shader stage.
|
||||
* Diffing events in a given frame.
|
||||
* Modifying the pipeline on the fly to change state.
|
||||
* Highlighting redundant state-setting.
|
||||
* Tracking the dependencies or dependants of a given action.
|
||||
* Exposing an API to applications so they can give more details or annotation, more tightly integrating with the app itself.
|
||||
* A low-resource mode so RenderDoc can be left on by default whenever running an app, so it's always available if a bug appears.
|
||||
* Attaching to an already-running application
|
||||
@@ -19,7 +19,7 @@ How do I do some particular task?
|
||||
|
||||
Many specific tasks or functions are detailed in the :doc:`"How Do I... ?" <../how/index>` sections. These sections each take a feature or element of a workflow and explain how it fits into the program as a whole as well as any details of how it works.
|
||||
|
||||
If the task you have in mind isn't listed there you might find something similar, or you might find a related feature which can be used to do what you want. If the feature you want doesn't seem to exist at all you might want to check the :doc:`../behind_scenes/planned_features` to see if it's coming soon - if it's not on that list please feel free to `contact me <mailto:baldurk@baldurk.org?subject=RenderDoc%20request>`__ and request it! It has often been that simple features are very quick to implement and the prioritisation and scheduling of features is fairly fluid depending on user needs.
|
||||
If the task you have in mind isn't listed there you might find something similar, or you might find a related feature which can be used to do what you want. If you have a workflow which isn't supported at all, feel free to open an issue on github to request a new feature. Make sure to describe clearly what you are trying to do and what workflow you want to support, not just the specific feature you want. That way the problem can be better understood.
|
||||
|
||||
Why did you make RenderDoc?
|
||||
---------------------------
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
Features
|
||||
========
|
||||
|
||||
This page documents the current feature set of RenderDoc. This gives an overview of what RenderDoc is capable of, and where it is in its development. You might also be interested in the :doc:`../behind_scenes/planned_features`.
|
||||
This page documents the current feature set of RenderDoc. This gives an overview of what RenderDoc is capable of, and where it is in its development.
|
||||
|
||||
Currently RenderDoc supports Vulkan, D3D11, D3D12, OpenGL, and OpenGL ES on Windows, Linux, Android, Stadia, and Nintendo Switch :sup:`TM`. The UI runs in Qt and will work on any desktop platform.
|
||||
|
||||
@@ -98,7 +98,3 @@ OpenGL & OpenGL ES
|
||||
* Support for OpenGL ES 2.0 - 3.2 on Linux, Windows, and Android.
|
||||
* Tree hierarchy of events defined by any of the standard or vendor-specific extensions, and ``KHR_debug`` object labels used for object naming.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
* :doc:`../behind_scenes/planned_features`
|
||||
|
||||
@@ -251,10 +251,6 @@
|
||||
<param name="Keyword" value="Pixel Picking">
|
||||
<param name="Local" value="how/how_inspect_pixel.html">
|
||||
</OBJECT>
|
||||
<LI> <OBJECT type="text/sitemap">
|
||||
<param name="Keyword" value="Planned Features">
|
||||
<param name="Local" value="behind_scenes/planned_features.html">
|
||||
</OBJECT>
|
||||
<LI> <OBJECT type="text/sitemap">
|
||||
<param name="Keyword" value="Preferences">
|
||||
<param name="Local" value="window/settings_window.html">
|
||||
|
||||
Reference in New Issue
Block a user