Compare commits

..

146 Commits

Author SHA1 Message Date
67aefff940 windows mono_time hotfix 2024-01-09 15:37:02 +01:00
74129cabef fix url open with unsanitized strings 2024-01-09 02:26:50 +01:00
be8ceb861c 1 sec cooldown for reduced fps mode 2024-01-07 22:20:40 +01:00
da0f59a3f5 try fix plugin rendering 2024-01-07 19:37:05 +01:00
000254320e add ubuntu linux to cd 2024-01-07 18:54:18 +01:00
2fac7206d2 pull windows fixes 2024-01-07 18:05:36 +01:00
e8234f2a4a properly seperate tick and render 2024-01-07 16:33:08 +01:00
a0ba0b39d8 add fps reduced mode 2024-01-06 18:23:06 +01:00
845967cf12 more main loop fiddling 2024-01-06 16:45:08 +01:00
92b58cbfa9 faster wakeup 2024-01-06 15:13:45 +01:00
5a0651eaf0 wip low fps mode for hidden states and powersave modes.
dont use yet, as all compute is still done in the render method
2024-01-06 14:38:21 +01:00
14fcaf1d7e why is windows so bad 2024-01-05 16:32:37 +01:00
5a0252d8d0 start screen refactor 2024-01-05 14:47:08 +01:00
9c0ffd38ce last update fixes 2023-12-27 12:49:52 +01:00
ae1fb0fde3 Merge commit 'b2ae9530a405e02a50476c04fc7196c5e9863ad6' 2023-12-27 12:37:22 +01:00
b2ae9530a4 Squashed 'external/toxcore/c-toxcore/' changes from e29e185c03..f1df709b87
f1df709b87 feat: add ngc events
1b6c907235 refactor: Make event dispatch ordered by receive time.
b7f9367f6f test: Upgrade cppcheck, fix some warnings.
766e62bc89 chore: Use `pkg_search_module` directly in cmake.
00ff078f91 cleanup: Use target_link_libraries directly in cmake.
c58928cc89 chore: Add `IMPORTED_TARGET` to pkg-config packages.
895a6af122 cleanup: Remove NaCl support.
41dfb1c1c0 fix: unpack enum function names in event impl generator
447666d1a1 chore: Disable targets for cross-compilation.
572924e924 chore: Build a docker image with coverage info in it.
415cb78f5e cleanup: Some portability/warning fixes for Windows builds.
425216d9ec fix: Correct a use-after-free and fix some memory leaks.
4b1cfa3e08 refactor: Change all enum-like `#define` sequences into enums.
d3c2704fa9 chore: Fix make_single_file to support core-only.
0ce46b644e refactor: Change the `TCP_PACKET_*` defines into an enum.
22cd38ad50 adopt event impl generation tool to #2392
f31ea1088a add the event impl generation tool
4e603bb613 refactor: Use `enum-from-int` rule from tokstyle.
19d8f180d6 chore: Update github actions `uses`.
6a895be0c7 test: Make esp32 build actually try to instantiate tox.
65d09c9bfb cleanup: Remove test net support.
REVERT: e29e185c03 feat: add ngc events

git-subtree-dir: external/toxcore/c-toxcore
git-subtree-split: f1df709b8792da4c0e946d826b11df77d565064d
2023-12-27 12:37:22 +01:00
35ebbbef93 prep for new toxcore events 2023-12-27 12:36:38 +01:00
83e200df43 Squashed 'external/toxcore/c-toxcore/' changes from adbd5b32d8..e29e185c03
e29e185c03 feat: add ngc events
2b0dc0f46b add ngc related unpack functions
b2315c50e0 Add groupchat API function that returns an IP address string for a peer
5f863a5492 feat: Add `to_string` functions for all public enums.
0c998a7598 add real timeout test
68c827609a chore: Move s390x build to post-merge.
028b017d79 perf: Slightly reduce bandwidth usage when there are few nodes.
90f7496819 feat: Enable ubsan on bootstrap nodes.
89b6450d66 test: Add check-c run to bazel build.
REVERT: adbd5b32d8 feat: add ngc events

git-subtree-dir: external/toxcore/c-toxcore
git-subtree-split: e29e185c03fea7337036e5ef4d1d9080a6cee721
2023-12-24 12:21:34 +01:00
260d3b7818 Merge commit '83e200df43eb790719c40103099c8d70e37c0477' 2023-12-24 12:21:34 +01:00
4ebffd8c63 switch to cerr in test to restore log order 2023-12-22 12:07:43 +01:00
8923e09b36 add asan option and enable for msvc ci/cd 2023-12-22 11:44:59 +01:00
ec4195f18a add linux to test 2023-12-19 01:56:35 +01:00
062ad7ae80 fix mac 2023-12-19 01:47:50 +01:00
aad07611c7 ci/cd blancing 2023-12-19 01:26:56 +01:00
0dcb66f143 add temp test 2023-12-19 00:29:27 +01:00
331c25b0e6 switch to debug 2023-12-19 00:22:23 +01:00
e50844be06 switch to release with debug info 2023-12-19 00:07:47 +01:00
4dd7c98c1a change to 2019 2023-12-18 23:58:15 +01:00
63bad2e99a add deterrent 2023-12-18 22:58:23 +01:00
9ddeea3d06 Squashed 'external/toxcore/c-toxcore/' changes from d4b06edc2a..adbd5b32d8
adbd5b32d8 feat: add ngc events
15ee46d431 add simple test for max sized lossy custom group packet
01e7950c67 increase lossy custom packet size in ngc to the toxcore common max of 1373
9b3c1089f1 Make group saving/loading more forgiving with data errors
55a76003b0 Replace memset(int32_t*, -1, _) with a for-loop
66453439ac fix: also Install header for private/experimental API functions with autotools
3983369103 fix: Enable debug flag for ubsan.
4d1db21102 Update tox-boostrapd hash
e700c31b70 Fix memory leak in group connection
2994441d9c Fix memory leak in save-generator
d0400df13d Fix memory leak in tox-bootstrapd
7a6d50ebe3 Install header for private/experimental API functions
d89677fb5f Remove defunct IRC channel from README.md
26d41fc604 Replace DEFAULT_TCP_RELAY_PORTS_COUNT with a compile-time calculation
63fb2941ca Clarify disabling of static assert checks
65b3375b98 refactor: Use Bin_Pack for packing Node_format.
84ba154f6a group connection queries now return our own connection type
a4df2862ed Replace tabs with spaces
1b6dee7594 Update tox-bootstrapd's base Docker images
a030cdee5c Fix Docker tox-bootstrapd hash update failing when using BuildKit
7cfe35dff2 cleanup: Remove explicit layering_check feature.
d390947245 chore: Upgrade sonar-scan jvm to java 17.
d1e850c56c fix: Add missing `htons` call when adding configured TCP relay.
814090f2b8 chore: Cancel old PR builds on docker and sonar-scan workflows.
83efb17367 perf: Add a KVM FreeBSD build on cirrus ci.
a927183233 test: Add a test for encrypting 100MB of data.
28f39049f6 chore: Retry freebsd tests 2 times.
47e77d1bb0 chore: Use C99 on MSVC instead of C11.
7155f7f60e test: Add an s390x build (on alpine) for CI.
6c35cef63f chore: Add a compcert docker run script.
41e6ea865e cleanup: Use tcc docker image for CI.
e726b197b0 refactor: Store time in Mono_Time in milliseconds.
REVERT: d4b06edc2a feat: add ngc events

git-subtree-dir: external/toxcore/c-toxcore
git-subtree-split: adbd5b32d85d9c13800f5ece17c0a9dce99faacd
2023-12-15 15:21:40 +01:00
b95f0498b6 Merge commit '9ddeea3d06045c8ae38cd2d6eed0fc2891c6e146' 2023-12-15 15:21:40 +01:00
7495a50723 add hack to copy the ngc chat id 2023-12-13 14:02:31 +01:00
1cdde5170b update subs 2023-12-12 16:52:52 +01:00
4248d1d9ab disable annoying debug message 2023-11-28 13:19:00 +01:00
4f02c2b55b Squashed 'external/toxcore/c-toxcore/' changes from 75f3c33943..d4b06edc2a
d4b06edc2a feat: add ngc events
cd34b60f0f feat: allow for larger incoming NGC packets
94cf9d1f36 fix: Fix memory leak in the error path of loading savedata.
fc623a5281 tox_new() should return null when savedata loading fails
06d949a701 fix: always respond to version packets with toxcore version
REVERT: 75f3c33943 adopt to #2415 changes
REVERT: 38e4c82fe0 feat: add ngc events

git-subtree-dir: external/toxcore/c-toxcore
git-subtree-split: d4b06edc2a35bad51b0f0950d74f61c8c70630ab
2023-11-17 16:01:52 +01:00
05d1648209 Merge commit '4f02c2b55b1eb57f39d69fe7f4319b4cbb50240e' 2023-11-17 16:01:52 +01:00
fd9d14d00c tox private impl + dht caps histo 2023-11-13 16:23:49 +01:00
4e4f62dd20 provide ToxPrivateI 2023-11-13 15:14:30 +01:00
cdc4284cb5 Squashed 'external/toxcore/c-toxcore/' changes from 38e4c82fe0..75f3c33943
75f3c33943 adopt to #2415 changes

git-subtree-dir: external/toxcore/c-toxcore
git-subtree-split: 75f3c33943cd3e249cfab3dab122aa4bbb9eec9a
2023-11-13 15:03:22 +01:00
bedbacddde Merge commit 'cdc4284cb50041b5bf7d476561085d629292e456' 2023-11-13 15:03:22 +01:00
32a8dba185 Squashed 'external/toxcore/c-toxcore/' changes from 82460b2124..38e4c82fe0
38e4c82fe0 feat: add ngc events
8099d82397 diagnostic: get the number of close dht nodes with announce/store support
d01c116764 cleanup: make it more clear that assert and uint32_t increment both only exist if NDEBUG is not defined
58fac53429 refactor: Add a `bin_unpack_bin_max` for max-length arrays.
6be29f01e5 chore: Add more logging to loading conferences from savedata.
1195271b7f Fix inversed return values
82276ef5ac cleanup: Fix GCC compatibility.
REVERT: 82460b2124 feat: add ngc events

git-subtree-dir: external/toxcore/c-toxcore
git-subtree-split: 38e4c82fe0fc373b9d43ee9ad2b8fe5fd1d26810
2023-11-13 14:02:43 +01:00
d6e5051b15 Merge commit '32a8dba185482fe1a89037bce2a5b0c5e76d4127' 2023-11-13 14:02:43 +01:00
780a67a40d update for toxcore changes 2023-11-13 13:25:41 +01:00
0c7fff3029 update for id comp 2023-11-03 14:41:38 +01:00
e7db39d20a small debuggabilty improvements (scouting for an avatar bug) 2023-10-21 18:07:06 +02:00
869edb8d84 add hacky tox add by id + use ips instead of dns names for bsnodes and relays 2023-10-20 21:40:45 +02:00
dce42b866a hack in extra decimal for progressbars 2023-10-20 02:39:13 +02:00
da19b0ac31 basic settings ui for cats 2023-10-19 23:52:11 +02:00
bc090bdaa8 make main window injectable + start settings window 2023-10-19 17:21:45 +02:00
2a5937652e add file dropping support 2023-10-18 14:24:46 +02:00
b9d4f594ce fix missing include 2023-10-14 16:25:01 +02:00
c79068c561 add tox avatar handling + prio png for paste + other fixes and updates 2023-10-14 15:59:32 +02:00
e7095a1849 forgot to close popup (oops) 2023-10-12 01:10:38 +02:00
3f78e17888 small refactor for pasting img + allow specifying mime type on paste 2023-10-11 21:57:36 +02:00
897253e1d6 toxcore api changes 2023-10-11 03:03:28 +02:00
cd28b26761 fix cmake for toxcore 2023-10-10 20:29:29 +02:00
a3126d581b Squashed 'external/toxcore/c-toxcore/' changes from 67badf694..82460b212
82460b212 feat: add ngc events
24b54722a fix: Ensure we have allocators available for the error paths.
48dbcfebc cleanup: Remove redundant `-DSODIUM_EXPORT` from definitions.
0cef46ee9 cleanup: Fix a few more clang-tidy warnings.
0c5b918e9 cleanup: Fix a few more clang-tidy warnings.
4d3c97f49 cleanup: Enforce stricter identifier naming using clang-tidy.
a549807df refactor: Add `mem` module to allow tests to override allocators.
6133fb153 chore: Add devcontainer setup for codespaces.
620e07ecd chore: Set a timeout for tests started using Conan
c0ec33b16 chore: Migrate Windows CI from Appveyor to Azure DevOps
8ed47f3ef fix incorrect documentation
a1e245841 docs: Fix doxygen config and remove some redundant comments.
b0f633185 chore: Fix the Android CI job
7469a529b fix: Add missing `#include <array>`.
2b1a6b0d2 add missing ngc constants getter declarations and definitions
2e02d5637 chore: Add missing module dependencies.
REVERT: 67badf694 feat: add ngc events

git-subtree-dir: external/toxcore/c-toxcore
git-subtree-split: 82460b2124216af1ac9d63060de310a682a2fd15
2023-10-10 19:37:39 +02:00
1da4a12104 Merge commit 'a3126d581b6a872f0b8d5641f199fb233306e181' 2023-10-10 19:37:39 +02:00
8725bafbdb hide pw in memory 2023-10-10 18:17:27 +02:00
c24dc45e93 hack in compressor types for sip + a bunch of refactoring and fixes 2023-10-09 21:17:00 +02:00
62b00a4bd6 add stb png and jpg encoders, untested 2023-10-06 13:16:45 +02:00
f1f67fe1ba extract webp image encoder 2023-10-06 02:01:31 +02:00
621327bf55 rework the crop buttons 2023-10-05 23:44:18 +02:00
9dabdd32fa add gh sp profile 2023-10-05 19:03:04 +02:00
b479db4989 color anim + fix crop w/h sanitization + hack to determine if png 2023-10-05 18:26:35 +02:00
8633c5eafd crop lr works too 2023-10-05 16:24:51 +02:00
440489f228 sanitize crop 2023-10-05 14:54:42 +02:00
bb824a9fb7 cropping ui partly done (upper left cropper works) 2023-10-05 14:23:39 +02:00
c98dd8a584 try to fix funky timing hanging animation loops 2023-10-04 22:49:33 +02:00
e12d7b1458 add compress to sip (hack webp only) + crop code but not in ui 2023-10-04 20:17:53 +02:00
58edc97787 change cd artifact name 2023-10-04 16:03:29 +02:00
ca6853e2c0 missing include 2023-10-04 02:19:03 +02:00
fc90106d83 openurl file + starting with sending image file and pasting 2023-10-04 02:11:06 +02:00
89bc11eca7 update tox sub with fix 2023-10-02 19:15:03 +02:00
5c4c397f6c update plug and add chat debugging 2023-10-02 17:03:00 +02:00
da774e10e8 update to entt 3.12.2 2023-10-02 15:40:32 +02:00
2f8eca71a4 update subtree entt Merge commit '90ce4bda4e1dc23508bbd6b6923156cd5a370c18' 2023-10-02 15:30:10 +02:00
90ce4bda4e Squashed 'external/entt/entt/' changes from fef921132..344e03ac6
344e03ac6 update single include file to v3.12.2
da56665b0 registry: make ::valid backward compatible
f6f01ef1b snapshot: avoid warnings due to deprecated functions
0ed514628 now working on v3.12.2
a41421d86 update single include file to v3.12.1
c1f6b11f7 snapshot: reintroduce support to storage listeners
b2233064a now working on version v3.12.1
cb974bf56 adjacency_matrix: fix in_edges() is off by 1 in some cases (close #1019)
7b7d82e6f doc: snapshot (close #984)
05c6898fc test: self-fixing archive example for snapshot classes
7ffa459a6 snapshot: drop ::get member template parameter
93e8e94e6 test: basic continuous loader
c4e241662 snapshot: review basic_continuous_loader (and drop shrink)
9c25419b9 test: more on basic_snapshot_loader
1879830df snapshot: drop pointless assert
29298c0eb test: guarantee code coverage, we'll update the test later on
247abef1d test: rollback for code coverage purposes on the snapshot class
6994d98d2 test: typo
9a600ece2 test: snapshot
f91226ef4 snapshot: share ::orphans implementation (to deprecate in future though)
e366ffbd3 doc: snapshot
63b300d39 snapshot: again, dense_map::contains is a thing
afb70d157 test: avoid warnings due to unused variables
49534eec0 snapshot: dense_map::contains is a thing fortunately
3f1277f7b snapshot: use the right allocator for the remote-local mapping
26fad4c38 test: basic snapshot loader
25b3afacf test: basic snapshot
2d25bbb09 snapshot: check registry type
0eb834582 snapshot: small cleanup
124a44052 test: use the new snapshot get functions in the test suite
5c704636e test: use the new snapshot get functions in the test suite
31fd94cc3 snapshot: cleanup to get ready to drop an internal function
573e43272 snapshot: reduce storage lookups
1d8943481 snapshot: drop useless function
e0a1ef7c1 snapshot: check on member type class
48ac0e0eb snapshot: add basic_continuous_loader::get, deprecate ::entities and ::component
bcb6234d9 snapshot: add basic_snapshot_loader::get, deprecate ::entities and ::component
f96796326 snapshot: reject entity type in the range-get (now get instead of get_sparse)
b22c55dd2 doc: typo
4ff5a536c snapshot: add basic_snapshot::get, deprecate ::entities and ::component
fff5f578a test: avoid using deprecated functions in an example
0f44c8c92 doc: reflect recent changes
0b6ad0315 snapshot: * single element only archive functions required * avoid iterating elements more than once
2450b0bc6 test: minor changes (waiting for a rework)
fc8eebf36 snapshot: use component_traits instead of is_empty_v
e4f51f2b7 snapshot: avoid multiple lookups of the same storage
2c2216a89 doc: typo
cafe85180 snapshot: deprecate multi-type component loading function
35e338cc9 snapshot: deprecate multi-type component loading function
8feeaaef7 doc: minor changes
e7a3c4e37 snapshot: add missing [[deprecate(...)]]
ea5c558bd snapshot: cleanup (waiting for further improvements)
94f0ed179 snapshot: deprecate multi-type component loading function
244c35949 snapshot: deprecate multi-type component loading function
1f24fea21 type_traits: formatting
8deaa09b2 test: perform static checks at compile-time
85bffb714 type_traits: std::tuple traits specialization for entt::type_list and entt::value_list (#1011)
325ca310d view: updated ::refresh
d903e268f snapshot: minor changes
f4b26756c snapshot: improved basic_snapshot::component
fb3a34ee9 *: updated TODO
6902bb6c4 doc: typo
379819b2b test: cleanup
59abfbfb5 meta: refine policy check on value types for non-member data
6e2d87184 registry: avoid casting return types directly to better support empty storage
57ec3c85c registry: erase_if (close #977)
4afdf287f doc: minor changes
2810ac7cb registry: suppress a warning on msvc
e0d27f9bf *: updated TODO
de303c999 test: reverse-each for storage entity
1619e780f test: reverse each for plain storage classes
a1e37eca6 storage: reverse-each
c345e7456 doc: note on reverse iterations
d166c026f snapshot: minor changes
5e639996d doc: minor changes
dac2ef5a9 doc: typo
71d7888e8 snapshot: drop redundant check
84a4df9c4 doc: exclude-only views
95bc20319 doc: entity lifecycle
5a9f6d211 doc: cleanup
a29302faa test: more on entity signals
75efa72c6 registry: cleanup ::erase
58a84665b registry: cleanup ::remove
a5263384d doc: drop redundant comments
c0e6759c6 doc: cleanup a little further
d754f7431 doc: cleanup
1df539943 doc: drop pointless tags
c284e6fee doc: minor changes
500239758 test: typo
319ecd808 organizer: fix organizer::vertex::prepare not creating component pools (#1014)
d7891fabc doc: mention named pools support when registering listeners
e287dd041 helper: minor changes
4dee9dde1 registry: named pools support for on_construct/on_update/on_destroy
9bae6e67b doc: update connection helper doc
aa7a7ce25 doc: minor changes
a969468c5 registry: de-deprecate :) on_construct/on_update/on_destroy
a1e76fc63 doc: more about entity storage
d8ed4ca35 registry: refine how entity storage is used internally
3248e3f91 helper: make sigh_helper work with named pools
f00687e6f doc: updated registry documentation
5240c6b60 registry: deprecate on_construct/on_update/on_destroy
67604a88e natvis: update registry snippet
4242dfb8b registry: use entity storage directly as much as possible
f96d8ee83 registry: prepare to split component storage and entity storage
c147ec37c test: try to make gcc happy again
094ddbba3 meta: avoid shadow warnings
634630ca2 test: add missing template keywords (thanks msvc for ignoring them)
d78c26f26 *: updated TODO
fabc6c9bd test: full cross-registry entity-copy example with meta (not strictly required)
b6e8ddd2a meta: fight against the small nuances of the language :)
cf2bbae6e mixin: make it simpler to modify the underlying type
08799616d *: updated TODO
58bebf78d meta: reduce symbols and their sizes if possible
d534fad3e doc: more about views
871dc7a40 doc: drop references to storage placeholders
1fe7c78f7 test: minor changes
22a65f80f test: cleanup
756ea8a38 *: updated TODO
12186cb40 registry: drop internal static storage variables from ::assure
aa9ffb9ee registry: const ::storage<T>(...) returns a pointer to possibly null storage
dcb5aed90 registry: lazily/partially initialize views in the ::view const function
34f6a747a registry: add support for non-existent pools to try_get
912cb2ad5 snapshot: constness review
885488b3d registry: any_of supports non-existing pools now
3d3d3ef2d registry: all_of supports non-existing pools now
a7120b340 registry: coding style
51915205b test: cover stable multi-type model
4a3ee042e view: refine ::storage function
88a1b8d0d view: stable multi-type view ::each(cb) function
7e18a0f96 view: update ::use function
c367082dd view: unchecked_refresh function
9f94b5306 view: double check on none_of
44ed10c50 view: stable multi type view ::find/::back/::front functions
1b2280941 view: stable multi type view ::begin/::end functions
bdabbaa63 view: stable multi type view ::contains function
c79c109b7 view: stable multi type view ::size_hint function
f1a213382 registry: prepare to remove static storage from const assure
17dc06149 view: stable single type view ::each(cb) function
3b8d82330 view: drop unused return
a20829e70 view: ::handle returns a pointer rather than a reference
5be2fdc15 view: stable single type view ::each() function
873b107e6 -: updated TODO
356bbbe53 view: stable single type view ::find function
e3ce4e156 view: stable single type view ::front/::back functions
e02050c51 view: stable single type view ::rbegin/::rend functions
26930633f view: stable single type view ::begin/::end functions
b7a485767 view: stable single type view ::contains function
f54cdccd4 view: stable single type view ::empty function
41c9a32f3 view: stable single type view ::size function
736ef3580 view: make operator bool work properly with partially initialized views
0128cbb4f test: minor changes
ff0a40715 test: prepare test suite for safe invalid views
34f440386 view: avoid using storage, further prepare for empty safe views
b1c78efb6 nativs: updated signal file
28f03ff9c meta: add missing checks on factory<...>::data
a5fe61adb *: minor changes
457f5e59e view: rollback handle() usage and prepare to safe empty views
422fd284e group: refine group ::find function
6f3222573 view: refine single type view ::find function
366bbceb0 doc: use doxygen-awesome-css
7b7f81e08 doc: update reference.md
cfe955f97 doc: update links.md
684ddc9de doc: minor changes
f5d38a9ae doc: drop redundant doxy variable
447e3693f doc: updated doxy file (doxygen 1.9.6)
909490bf6 view: try to make g++ happy again
d90363e4a view: make view pack also work with empty views
ee5de744c view: add missing [[nodiscard]]
d401c88a0 view: assert on null handles
80563b955 view: allow swapping storage elements of a view
c74900057 sigh_mixin: avoid shadow warnings
78867d5c9 group: make msvc happy with constness on virtual functions
d435fc779 basic_entt_traits: suppress a warning by gcc
e6f76e0f9 view: try to make VS happy again :)
1c6b53360 test: minor changes
5c3d8360c view: turn ::use into a self-contained, non-const function
3882c7d9a view: turn ::refresh into a self contained, non-const function
15726218b view: doc
869bfc82c test: minor changes
0eb3d54b2 group: change signature of ::storage to return a (maybe null) pointer rather than a reference
f83290f76 view: change signature of ::storage to return a (maybe null) pointer rather than a reference
686a3b9d7 registry: make storage_for_type available to the final user
4d57d5c32 registry: make ::storage<T> return type explicit
36c21cf7f registry: drop redundant traits usage
7ab10e193 test: minor changes
41467d35a -: updated TODO
d351252a1 doc: entity storage
c6cd4f701 doc: refine storage section
65889cca4 doc: brief mention of void storage
f1914fd94 doc: rearrange a few things
e53af7bef registry: minor changes
b910cd261 *: updated TODO
58d331ca0 registry: minor changes
17f5b0a33 registry: avoid bumping version on destroy if not requested
de386292b registry: deprecate ::each
88bf26a2f registry: deprecate ::assign
3caad4100 mixin: common internal owner_or_assert function
916203a24 test: stress assert on entity limit
62f1971f7 test: minor changes
4fde96357 natvis: updated registry snippet
c3730b65f group: * unified model * drop group handler's size function (no longer required)
1ea072cd3 group: back to the unified model for group handlers
bbe4582ee meta: minor changes
89ab5c328 meta: operator==/!= for meta_func
3a4672793 meta: operator==/!= for meta_prop
0a0446f35 meta: operator==/!= for meta_data (close #1002)
fc58ff74b meta: operator==/!= for meta_handle (see #1002)
fed6831cd locator: support to opaque structures (close #956)
1605c8d9d natvis: updated entity file
d6641c7d8 -: updated TODO file
5079f38e9 storage: allow on_update signals on entity storage
1eab2a4a8 meta: fix constness detection for static functions in meta_type::invoke
c33110765 test: cleanup
117b0bd67 test: more about storage<...>::patch
9b4a6f877 storage: use allocator_traits::destroy rather than destroy_at
f4e6f2b37 group: suppress shadow warning
5971fb7aa -: updated TODO
10dfe7e93 sigh: allow disconnecting listeners during iterations (close #986)
a9208a956 doc: fixed typo
1cc5b32ca test: cleanup
f8a972a3c signal: drop sink::before
5b7cc2002 group: rollback some (no longer required) changes to the owning_group_descriptor
bd34e7f2c group: drop nested groups support, prepare to the large group review and multi storage support
46fe29c3f group: make matching functions virtual for owning groups
c50e2815c group: make owning_group_descriptor depend on the storage base type
fbfee632d group: minor changes
77c59aabf group: group_handler::size function for owning groups
ebb1e8a72 group: single check function for group handlers
1646217f0 group: make types explicit for the next/prev functions
645edfb2b group: decouple constructing and setting prev/next links
61f28298c group/registry: minor changes
d19f97bf2 group: use ::handle() if possible
70c611a84 group: cleanup
286428c19 group: make common_type base of non-owning group handlers
6ec719bcf group: reduce the footprint of non-owning group handlers
11f9bb2d7 registry: use shared_ptr<void> for non-owning groups (prepare to drop the basic handler dependency)
5a1ba5ad7 regisrtry: decouple container types for groups
cf094e7ef registry: finally split owning and non-owning groups as it ought to be
31808bd9a sigh: flip the last commit on its head and drop redundant functions rather than merging them
61a5173a7 sigh: merge a couple of functions
ed6fe9e65 sigh/sink: refine internal definition
e30fa8520 doc: cleanup
ca1069e18 snapshot: avoid allocations if possible
70f73a094 snapshot: drop pointless checks
710fff0e3 entity: make get_t, exclude_t and owned_t constexpr constructible
660bc5843 entity: turn get_t, exclude_t and owned_t into proper classes (close #998)
13295a14e type_traits: v141 toolset workaround for value_list_diff
9ce07ff61 type_traits: value_list_diff[_t]
b272e04ba type_traits: value_list_contains[_v]
28b11912a test: cleanup
b9f096d12 type_traits: value_list_unique[_t]
8c60faa1d type_traits: value_list_index[_v]
1f93ea4ee snapshot: avoid unnecessary lookups
7ca77e53f snapshot: avoid unnecessary lookups
69397f365 snapshot: avoid unnecessary lookups
f907bc066 snapshot: drop redundant checks and avoid unnecessary lookups
bda52701f snapshot: avoid unnecessary lookups
d26f7684c snapshot: minor changes
63d6c2bff snapshot: avoid unnecessary lookups
cc45e7341 snapshot: also avoid using views if not required
5d092bcb1 snapshot: avoid unnecessary lookups
295c68841 snapshot: review ::orphans functions
2664b5255 observer: allocator support
dd3632833 observer: configurable mask type
c8c929e4a group: use type members properly
d1ef7bf15 view: use type members properly
1ab23f17d group: early exit on signal races
a72eb4693 group: minor changes
67579d062 -: updated TODO
766a233f3 view: base_type -> common_type
905671c23 runtime_view: base_type -> common_type
27c1383e4 group: base_type -> common_type
029ccc8f7 registry: base_type -> common_type
cde40d586 group: drop unused using decl
6a16a8a20 group: auto init for owning groups
1a12dede6 group: auto init for non-owning groups
35a78b65e group: cleanup
ada19432f group: support for index based sort
4998e9087 doc: minor changes
471c11c6d sparse_set: respect -> sort_as (naming is hard, you know)
3e13e0b59 group: sort/respect -> sort_as (also decoupled from group types)
53cd105f2 group: reuse pools as much as possible
24b31c379 group: reuse pools as much as possible
def82b534 group: index based get
a424f4ebf view: review get
b8f0a8d8e doc: a couple of interesting articles/series (close #994)
7941226ef group: try to reuse pools when sorting and also please all compilers out there at the same time (aka me figthing ICEs again)
86bbb2f6b group: reuse pools when sorting
3c176f725 test: suppress warnings due to unused variables
3642c8a78 registry: drop [[nodiscard]] from ::group (close #991)
0e80d90a7 group: use storage<idx> as much as possible
4fdf2dccd group: update doc
f8a997e6c group: minor changes
40f676ed1 test: drop unused include
5e346748e test: code coverage for groups and registry
3ef61fe01 meta: support meta member functions on primitive types
3885d280d test: cleanup
f41b91419 meta: allow updating values on meta properties
e0684f634 registry: cleanup/minor changes
fb980a78c registry: further refine the group function(s)
c2430ab48 doc: minor changes
d36d9cb39 registry: further cleanup group functions
0017c08bb group: get pools from handlers
e737ff747 group: get filter from handlers
945dc4093 group: split group handler functions
7ef008511 registry: drop group_data
d2fa68813 registry/group: prepare to get rid of group_data
f22a09a9a group: in-between change to simplify dropping group_data
b0aba79a5 snapshot: minor changes
7c23e4a2f registry: minor changes
7fe035ce4 group: move group size from registry group_data to basic_group_handler
3e7160eda group: minor changes
aaeb686ec group: common base class for group handlers
3fdf4884d group: prepare for group handler common base class
1b23ff4b9 registry: use common group handler types as keys for the group set
88dac318e group: wrap the len of owning groups to avoid changing it by mistake
520c2e660 group: make group handlers work with multiple storage of the same type
f5d0d451b group: split pools and filter in the group handlers
8af6fc0cc group: use ::handle internally if possible
c04b97a31 group: add ::handle function to all group types
1d85414dc doc: drop refs to registry::version (close #992)
c6533827f group: fight with clang format from time to time :)
b5803451b group: make owning groups work with their handlers
3417d66b2 group: make non-owning groups work with their handlers
1e61204e8 registry: deduce group handler type from group type
19c4857ef group: cleanup
66ea94898 registry/group: move group handler to group file as it ought to be
ced6d21c3 registry: break dependency between registry and group handlers
429c7c45c registry: further cleanup things
c03b1111a registry: small cleanup
ebd7d3acd registry: storage based model with pools for groups
5aeec60cf registry: prepare to switch to storage based group handlers
620b4f751 registry: pass handlers to group callbacks
6d58004c1 registry: minor changes to simplify the implementation slightly
df6d926de registry: prepare for a storage based group handler
e63af24cb registry: turn the non-owning group handler in a storage
068d9f8ae registry: discard unused arguments from listeners if possible
c19c848c4 test: suppress warnings due to unused variables
0bf0a0a8f doc: delegate
743e8678e delegate: also support functions that skip first elements (on second attempt only)
a7ad1c06f delegate: prepare to support filtering on both sides
b1af70e70 registry: avoid checking pools in the group handler if possible
c87c3533e registry: avoid checking pools in the group handler if possible
4839a0ee6 registry: cleanup
a0f0c44e6 registry: minor changes
74691dc1d group: just use meaningful names :)
e4957badb registry: split group handler to further refine group management
46791c4c3 registry: turn group handler functions into static ones
56c391784 registry: prepare to rework groups
1fb13d3e9 doc: minor changes
535beb4e2 storage: drop unnecessary use of integral_constant
2d318b88c -: updated TODO
b7f0b76ce entity/mixin: add missing include
d30312f51 entity/helper: add missing include, drop unnecessary traits calls
30772848e meta: avoid unnecessary calls to std::move
eca01a397 doc: add vcpkg badge and vcpkg.link (#985)
35ef0b7ac core: reduces the number of instantiations a bit
19ccba3a6 meta: reduces the number of instantiations a bit
207b7674a doc: fix typo
631c55ba9 storage: minor changes/tests
e7b30fd36 storage: return iterator to elements rather than entities and only if it makes sense
3e959007b storage: ::insert returns an iterator to the range of inserted entities
07ec4ca23 -: updated TODO
6e4946b68 storage: uniform interface to simplify mixin implementation
47ea16f17 test: signals on entity creation/destruction
722857fc0 test: get rid of pointless template parameters
2125b3838 test: minor changes
289de7d57 test: exclude only views
25ecd8e79 test: minor changes
319dfdb07 test: filtered registry view
9dbbcac01 -: updated TODO
f545c8e05 registry: deprecate ::release
c68fa6a65 registry: make ::destroy work without ::release (the latter to be deprecated)
d288ecd70 registry: make ::release use ::bump return value
312d3aba8 sparse_set: bump returns the version in use (for convenience)
4d2b2c6de registry: use traits_type::next if possible
80d55a226 test: increase code coverage
d86a53935 test: suppress warnings due to unused variables
0f7098d0e -: updated TODO
8c96be1e9 registry: deprecate a bunch of functions because of the entity storage
37f396bfe registry: make entity storage storage as any other
75894dc40 storage: update traits_type for entity storage
cdee000ce any: rollback a change that turns vs toolset v141 crazy
54ca62600 dispatcher: refine aggregate check
6f4280ed5 any: refine aggregate check
ddf56b78c storage: backward compatibility on component requirements
53a854f54 any: just cleanup the code to make it easier to work with
4896acac7 storage: typo
e3defeba2 test: suppress warnings due to unused variables
62079908c storage: use proper value type for entity storage
e65a8f2e5 doc: add link to koala engine :)
9f27fb1e5 registry: further prepare to turn the entity storage into a plain pool
04d734e76 registry: prepare to turn the entity pool in a plain storage
df50fa1b5 natvis: cleanup
051872b8c natvis: update registry definition
57ab9e7be registry: avoid using assure if not required
69d95ba75 test: more bench to stress a little an upcoming feature
9caf66d7c test: cleanup
74cb0d40c test: internal rework
deac7f34b dispatcher: refine aggregate support
a9883f27c storage: refine transparent aggregate support
85b1e57d8 sparse_set: drop fast_compact, expect full clear
b7d8e0186 storage: make the entity storage perform a full clear rather than a fake one (still viable via erase)
390a56176 -: updated TODO file
a1b888cce natvis: add optiona storage length item for entity storage
2107dd689 natvis: fix already existing errors due to renaming or design changes
1fca56afe storage: make it easier to refine the natvis file
c0762a6a5 storage: add get/get_as_tuple to entity storage to make it suitable for use with views
f48de1bac test: stress get/get_as_tuple for empty types
c7dfce89e sigh_mixin: refine pop_all
822fafcd4 view: uniform implementation to simplify upcoming changes
1476d4ea9 sparse_set: refine ::respect
c1c63777e -: updated TODO
2fab25ae8 registry: refine internal check
75d449152 -: updated TODO
c7866fb21 storage: use entt traits next function if possible
87987bacd entity: added basic_entt_traits::next (with tests)
bde0219fe snapshot: review basic_continuous_loader::entities
ad64c849b storage: suppress warnings
b808bb83b test: suppress warnings
d0090d35f snapshot: try to make sizes an opaque value to the caller
7a1a06a24 sigh_mixin: avoid shadow warnings
000b17881 -: updated TODO
068b6ed49 registry: first (almost) backward compatible version with opaque hidden entity storage
0187fb48a test: sigh mixin for entity storage types
35a2b3844 sigh_mixin: also support entity storage types
4747c9a4c registry: extended checks to support swap-only entity storage types
7be8d8327 registry: make a couple of conditions opaque
a5d6757d6 registry: prepare to get rid of the vector of entities
3f09d47c8 storage: remove redundant typename keyword
9c06d6ba0 registry: use type member names
b7c819bf4 test: entity storage
9f31803ba storage: swap-only entity storage
1e7deff9c test: drop redundant checks
04ac15d8d test: minor changes
376218991 sigh_mixin: make pop_all use narrow view iterators if any
18d6e466d -: [[nodiscard]]  as appropriate
095ecf314 group: extended_group_iterator::base to return the underlying iterator
433ed863e view: extended_view_iterator::base to return the underlying iterator
0dba68e75 storage: coding style/minor changes
1ab281582 storage: extended_storage_iterator::base to return the underlying iterator
2af5a725e doc: * updated copyright * udpated TODO list
a86bf1332 test: try to make lcov happy
831054bff test: share as much as possible
f94de1c06 test: rework lib stuff to share common files
a3d9503a1 test: try to make lcov happy
3f2b15f9f test: try to make lcov happy
e48817d51 test: try to make lcov happy
d11cebe30 view: uniform design to also help natvis without having to poke into stl internals
77a5efb32 natvis: updated to_entity intrinsic
851006efe -: updated TODO
6fc6b2fb3 sigh_mixin: further improve ::pop_all
ed17a2c48 sparse_set: ::contiguous function
bd00e797a sparse_set: further refine pop_all to make it even faster
e645c4928 -: updated TODO
a425878e8 sparse_set/storage: clear is backward compatible now
f3cd9d374 storage: fixed clear_all counter
b3e93b084 registry: naming convention
314c189c4 test: minor changes
2bb2c5566 build: try to make lcov happy again
d13c126e9 view: avoid name clashes
9b54ee37a flow: propagate allocator to generated graph + internal rework
e1ead9d3e build: update coverage workflow
cf61068dc mixin: suppress a warning with gcc11
82863f829 test: code coverage for range functionalities
e4de59827 test: try to make lcov happy
ccea4c920 memory: code coverage
89166f0e4 build: refine analyzer workflow
7a05a16c5 registry: slightly better destroy (yet not quite there though)
d0854646c test: yet another test to stress the upcoming changes
1e9c9fe5f registry: better, faster range-remove + refine range-erase
80fac8d8e test: minor changes
c774b9838 -: updated TODO
3fd0403cc registry: faster, better range-erase
6eb3347a3 test: a couple of extra functions to stress the upcoming changes
89bceaff7 -: updated TODO
dc25c9c1a sparse_set: invoke release_sparse_pages before clearing the sparse array
e68ba5870 sigh_mixin: add a missing include
c68cb3375 entity: make deletion_policy publicly available via fwd.hpp
59f807fd0 sparse_set: suppress warnings due to unused expressions
232ffebc1 sparse_set: internal clear_all function
3cea845a0 sparse_set: sparse_set_iterator::data function
295f3b32e registry: a couple of extra move calls here and there
254da2c3c sparse_set: better, faster range remove
ecd3b8d93 sparse_set: prevent rework errors as much as possible
c673b9b17 sigh_mixin: slightly improved pop + review insert
cd28de0d6 test: clear-stable bench
672f6a711 test: minor changes
3b50672b7 storage: restore storage_for/storage_type duality, it turned out to be very useful in practice
f0613b1c6 sparse_set/storage: minor changes to reuse type members
2197e160e -: drop file pushed by mistake :)
2dccd9016 handle: discard entity on destruction
2f873f2dd -: storage_mixin.hpp -> mixin.hpp (non-storage mixins are also a thing)
fde1a524e sparse_set: ::get -> ::value (to avoid hiding from derived classes)
055801047 doc: drop references to docsforge + minor changes
79a054a52 sigh_mixin: scope base_type properly
d94e443a1 doc: drop outdated section
3862184e8 sigh_mixin: support self managed storage classes
f40fa3c2f test: * use range destroy * avoid compiler optimizations
01bc93459 test (bench): the new entity storage enables the fast path in all cases
151bd0739 sparse_set: revert optmized range push, it prevents self-managed storage classes
935393aae sparse_set: better, faster range push
fbfde4347 snapshot: avoid unused variable warnings
2ffbe115b component_traits: revert entity customization support
645973eb7 sparse_set: insert -> push
133230797 sparse_set: emplace -> push
b700f5eb5 doc: typo
e60dbdc52 sparse_set/storage: * rename swap_at in swap_or_move to capture the real purpose * define swap_at as a protected function to allow swapping from above
c66623b33 sigh_mixin: avoid hiding basic_iterator type meber
62246d879 storage: avoid hiding basic_iterator type meber
b35f13130 sparse_set: support swap-only mixins
3dd82633a -: drop storage_mixin.cpp, I forgot to do it a couple of commits ago :)
00231bf8a storage: make swap_at non-final to support checks on derived classes
58d392e81 -: minor changes
1d4d99d09 mixin: sigh_storage_mixin -> sigh_mixin
fe3edf2c8 -: minor changes
0864ba042 -: drop useless typename
3a9698001 build: minor changes
423f7a555 is_equality_comparable: detect C-style arrays directly
5db8ad53a build: update gh workflow
c2ab35780 view: make also VS toolset v141 happy
4fb558f14 view: further reduce instantiations
5762a8a08 view: reuse internal functions if possible
ed4c67521 sparse_set/storage: drop move_element
f15789846 config: ENTT_FAIL(msg) -> ENTT_ASSERT(false, msg)
6d20709e0 storage: minor changes
a9a9853c0 sigh_storage_mixin: use entity_type from Type
af14aa4c9 doc: more about signals (sigh_storage_mixin)
24d6b9881 test: minor changes
899f4baa6 storage: * drop storage_for]_t] * make storage_type[_t] deal with constness
c1ab7ba02 sigh_storage_mixin: make all virtual member functions final
9d38f6020 registry: thanks MSVC for accepting invalid C++ code
0efa25cf6 sigh: cool, I keep doing the same error again and again apparently :)
6316b6045 registry: make it work with storage<void> also in C++17
f268fb60a entity: avoid breaking changes due to type members renaming
3520d6915 entity: add base_type
4da7a8451 entity: make checks work with 64b identifiers :)
382dfc3bb entity: strict check on entity/version masks
b6dcdc816 entity: * also expose entity_mask and version mask to the final user * avoid default args with entt_traits::construct for backward compatibility
c9d544089 doc: review/cleanup entity.md a bit (done)
3eb5faeed doc: review/cleanup entity.md a bit (work in progress)
7a328c7ed doc: updated links
6567aa195 doc: a note about listeners disconnection (close #958)
92319f011 entt_traits: split basic impl, simplify def
782d86b6e entt_traits: value_type -> type (cuz it's not a value type after all)
c2cae37c1 entity_traits: make page_size type explicit
1026d26ec entt_traits: drop reserved value
7156803db test: local non-static constexpr variables
f54ed5424 helper: local non-static constexpr variables
f30b50195 algorithm: local non-static constexpr variables
c90ab9aff sparse_set: * break dependency on traits_type::reserved * use a tombstone if all I need is a tombstone
c2f6ca43f doc: graph (close #957)
3e5e41d88 test: cover some corner cases of the flow class
9eafc0431 flow: minor changes
0a82b777b component_traits: support specializations based on entity type
32bcc01a4 component: * make component_traits treat void properly * drop ignore_as_empty_v
9c3fe3546 nativs: entity module
83f8aed58 helper: use traits_type from storage class directly
2fd660274 snapshot: use public registry traits_type member type
a554d406e registry: * public traits_type member type * break dependency on component_traits * use public storage traits_type member type
5f12f872e test: minor changes
be4eb68a3 helper: * break dependency on component_traits * use public storage traits_type member type
df5284d9e view: * break dependency on component_traits * use public storage traits_type member type
0e27d33e7 storage: public traits_type member type
fe6e6ae73 sparse_set: public traits_type member type
9d29713ea entity: naming convention
270d0277d group: cleanup
0bd06c8d5 hashed_string: naming convention
733f215cc storage: break dependency between component_traits and storage_iterator
ad01a69fe *: renaming/coding style
dd9c1dade sparse_set: no need to differentiate template args for sparse_set_iterator
b8f70519f doc: fixed typo
9b9d212dd *: coding style
3fe15969d doc: cleanup
ec4bf222c meta: avoid the +1u trick for 0-sized arrays
1173908ee meta: avoid rebinding when forwarding requests
2595b8a92 doc: sigh_helper
f4e2a8c76 sigh_builder: add all missing .template that msvc kindly accepted anyway
66e1a0565 entity: sigh_helper utility with tests (close #928)
87283dc41 storage: simplified impl in order to introduce multi-type storage more easily
a802ebffe storage: * move storage_type[_t] and storage_for[_t] to fwd.hpp * no need to include storage.hpp when forward defining views
b84b09421 doc: add Arch ECS to references.md (#954)
940fd0939 todo: add a note for a (soon to be released) change
920338be5 doc: add ecsact to links.md (thanks @zaucy for pointing this out)
bcd1155b7 gh: add more gcc and clang versions
1dc88109e gh: update workflows
262c1f53c cmake: only enable -Wdocumentation for clang-cl
4af0a3a0d doc: cleanup
be1641828 doc: cleanup
b54a52fbf doc: fixed typo
ae8815995 doc: fixed typo
62c764f68 doc: fixed typo
2c48cc10a cmake: enable documentation diagnostic for clang
82f286678 sigh: drop redundant function
d56e5a269 registry: propagate allocator to context
1517b2951 doc: document delegate raw access
bea7b43a1 delegate: target member function
2f878f8b5 sigh: refine ::collect
fc68c1b29 view/group: cleanup
9081c185d meta: minor changes
7c4493f23 group: make filter storage available
da4e73ab8 view: make filter storage available
f3e7f98b4 registry: extra check when moving a registry
3925fc612 emitter: extra allocator check when moving
c639130c1 dispatcher: extra allocator check when moving
75c311600 registry: cleanup
e9e14eb49 meta: [[nodiscard]]
d1558304f any: [[nodiscard]]
0531b530b snapshot: minor changes
f9d0178dd workflow: bump iwyu version
b66b8d37e test: suppress warning
05ef4c29d storage: minor changes
9c3d75669 test: cleanup include directives
93651e46f registry: drop [[deprecated]] functions
ea901cbfa test: code coverage
d5dc4f43e doc: meta.md
498e02f15 doc: core.md
d0ea8f4f9 cmake: suppress some warnings for clang-cl, it goes a little wrong otherwise
dec3b7bb3 test: suppress warnings
10bc8b05a test: use /W1 with VS (but for toolset v141, too bugged for that)
ad77b54dc cmake: bump version to get some cool feature/update
b6724b028 group: pass filter storage to groups (in-between change for full storage access)
54270b103 group: make them easily copyable/movable
31dc732a7 doc: graph.md
f0e02d6d3 doc: container.md
156d6e4ea doc: poly.md
4375c1c3d doc: lib.md
24a9cd67e scheduler: forgot to add the fwd file to the previous commit :)
ba8d522c1 doc: add the worst engine (love the name) to the list of links
3ae46214a doc: review process.md
5119fe8d7 scheduler: basic type model with default for common cases
ed0319cdd view: avoid shadow warnings
bc50da6a7 storage: suppress warnings with non copyable nor default constructible types
52b3b4c24 group: suppress warnings for unused variables in case of empty types
74bab529d test: minor changes
b1b143917 meta: [[maybe_unused]] variable to avoid warnings with corner cases
7beb4c85c test: suppress a few warnings (entity)
f3beb5670 test: suppress a few warnings (container)
446c67b69 test: suppress a few warnings (resource)
c4507bd17 test: suppress a few warnings (poly)
61e872bb4 test: suppress a few warnings (meta)
9f22a3e23 test: suppress a few warnings (memory)
653dd5cd4 test: suppress a few warnings (tuple)
bc53ed3be test: suppress a few warnings (flow)
f935bbcce dense_set: suppress warnings due to possible narrowing conversions
c7d505353 dense_map: suppress warnings due to possible narrowing conversions
ea78f1d97 now working on version 3.12
REVERT: fef921132 update single include file
REVERT: e52a93f8a ready to cut v3.11.1
REVERT: cd541f335 storage: * move storage_type[_t] and storage_for[_t] to fwd.hpp * no need to include storage.hpp when forward defining views
REVERT: 255b8be8c view: avoid shadow warnings
REVERT: 8cd7f064a storage: suppress warnings with non copyable nor default constructible types
REVERT: 58ae4117c group: suppress warnings for unused variables in case of empty types
REVERT: cfa1e805b meta: [[maybe_unused]] variable to avoid warnings with corner cases
REVERT: ccedacec8 dense_set: suppress warnings due to possible narrowing conversions
REVERT: 17578dc8c dense_map: suppress warnings due to possible narrowing conversions

git-subtree-dir: external/entt/entt
git-subtree-split: 344e03ac64a1f78424ab1150e2d4778e8df8431d
2023-10-02 15:30:10 +02:00
4afe39dacc unread message status + fade in ui 2023-09-29 18:15:18 +02:00
dd316d2589 update sdl Merge commit '644725478f4de0f074a6834e8423ac36dce3974f' 2023-09-23 18:53:38 +02:00
12e8b5d6c4 windows -> linux ln fixes 2023-09-23 18:45:03 +02:00
f5c7261805 update nix flake to support more platforms 2023-09-16 23:54:51 +02:00
73ee0f905b added nix flake (hacky, shipping sdl was a mistake) 2023-09-15 20:06:37 +02:00
0b46b891c2 add simple quote message context menu 2023-09-01 21:13:36 +02:00
d131b5a02f add hacky way to load encrypted tox saves 2023-08-28 15:33:36 +02:00
9d9a486537 limit fps to 60 and disable imgui demo window 2023-08-28 14:06:27 +02:00
610ed10011 scope plugin paths 2023-08-20 12:50:58 +02:00
4edab11616 update deps and dont try to load files >50mib as images 2023-08-19 21:42:47 +02:00
6df0417667 update sdl Merge commit '4d48f9d23713d94b861da7b5d41baf2a41334994' 2023-08-12 20:17:29 +02:00
bd9bbf67d4 small fixes 2023-08-11 12:18:50 +02:00
8cab1307ab update sub 2023-08-09 11:18:41 +02:00
5bfc429450 small ui refactor + forwarding files 2023-08-06 16:07:50 +02:00
7a7b55bebf make tox save file selectable (hacky) 2023-08-03 15:03:12 +02:00
b4eda033c6 update plugin version 2023-08-03 13:11:59 +02:00
c9672bf352 add debug start screen ui + can load plugins 2023-08-03 13:05:19 +02:00
5547ff6d2b also scen media on message creation 2023-08-02 20:58:16 +02:00
ea8cc85c61 update subs for tox reconnection bug fixes 2023-08-02 20:21:06 +02:00
5ecec26731 image inlining working 2023-08-02 19:24:51 +02:00
01fddd19cd message texture cache + message image loader (no inline images yet) 2023-08-02 16:36:34 +02:00
e362af8271 cleanup texures on cache destruction 2023-08-02 15:37:37 +02:00
2dba4f8fbb add webp support 2023-08-02 15:06:19 +02:00
bdfe44399a Merge commit '67653bbe50841153bfeaebcc5792bd8464da9880' as 'external/libwebp/libwebp' 2023-08-02 14:57:22 +02:00
67653bbe50 Squashed 'external/libwebp/libwebp/' content from commit dd7364c3c
git-subtree-dir: external/libwebp/libwebp
git-subtree-split: dd7364c3cefe0f5c0b3c18c3b1887d353f90fc1f
2023-08-02 14:57:22 +02:00
a144459e8d add stb image loader (avatar png support) 2023-08-01 20:17:38 +02:00
d725ed8cd0 add stb 2023-08-01 20:13:38 +02:00
87d7eb69af Merge commit '3cd551098b8dc5a2b55d45a2a63bb9a219d31f2e' as 'external/stb/stb' 2023-08-01 20:11:22 +02:00
3cd551098b Squashed 'external/stb/stb/' content from commit c39c7023e
git-subtree-dir: external/stb/stb
git-subtree-split: c39c7023ebb833ce099750fe35509aca5662695e
2023-08-01 20:11:22 +02:00
95b77cb696 add avatar texture handling 2023-08-01 18:25:56 +02:00
2e28ad7bb9 fix missing include 2023-08-01 14:28:28 +02:00
75f78f8c7f load tox identicons 2023-08-01 13:21:16 +02:00
ef59386e5c start texture cache for contacts (avatars) 2023-07-31 20:47:22 +02:00
c0b57c30bd add sdl bmp image loader 2023-07-30 16:00:55 +02:00
42b3866753 start thinking about pasting files 2023-07-30 15:10:26 +02:00
aff239377d add README.md 2023-07-29 22:50:15 +02:00
3aaa1b0350 try satisfy macintosh 2023-07-29 22:30:36 +02:00
823a4ae189 missing include 2023-07-29 21:51:24 +02:00
40cd04f9dd fix cross platform file paths to string 2023-07-29 21:25:25 +02:00
6a979d31a0 fix missing includes 2023-07-29 20:58:29 +02:00
56f7db9ae6 msg sorting 2023-07-29 20:51:32 +02:00
d5e2dd2e1f add auto dirty (save toxfile) + minor stuff 2023-07-29 20:39:31 +02:00
93e5bb867b invites 2023-07-29 20:07:59 +02:00
4cd295065b add chat gui, probably works 2023-07-28 18:03:45 +02:00
5a9aacc603 add file selector with sorting 2023-07-27 19:34:47 +02:00
082c4febdf more setup 2023-07-26 20:09:57 +02:00
a848a01527 add tox client and more setup 2023-07-26 12:55:50 +02:00
3a1c15f313 screen concept 2023-07-26 12:24:18 +02:00
e92c7cbfa0 add exe icon 2023-07-26 02:02:06 +02:00
4d09e1fd4a gh windows cd 2023-07-26 01:13:54 +02:00
07765b4ad7 wire up imgui 2023-07-26 01:11:17 +02:00
f66b8d3ea2 Merge commit '88f609166511499341dde3b5a6191e34641d2eeb' as 'external/imgui/imgui' 2023-07-26 00:23:40 +02:00
88f6091665 Squashed 'external/imgui/imgui/' content from commit d4ddc46e7
git-subtree-dir: external/imgui/imgui
git-subtree-split: d4ddc46e7773e9a9b68f965d007968f35ca4e09a
2023-07-26 00:23:40 +02:00
a0122d38f2 minimal sdl app 2023-07-25 23:59:35 +02:00
e4d2987c54 add sdl 2023-07-25 22:47:22 +02:00
b8e444eaa8 Merge commit 'dec0d4ec4153bf9fc2b78ae6c2df45b6ea8dde7a' as 'external/sdl/SDL' 2023-07-25 22:27:55 +02:00
b38ea75e56 updat sol toxcore 2023-07-25 22:08:02 +02:00
8613511928 more fixing 2023-07-25 16:22:35 +02:00
7650d0ff23 update plugin sub 2023-07-25 15:38:14 +02:00
4ec6a26d91 start with gh ci 2023-07-25 15:10:52 +02:00
efa781e9ba empty main 2023-07-25 14:56:22 +02:00
41d0fc02c3 should compile 2023-07-25 14:35:57 +02:00
227425b90e Squashed 'external/toxcore/c-toxcore/' content from commit 67badf69
git-subtree-dir: external/toxcore/c-toxcore
git-subtree-split: 67badf69416a74e74f6d7eb51dd96f37282b8455
2023-07-25 11:53:09 +02:00
5568b70d31 Merge commit '227425b90e9a671118026689dd30967e127a1090' as 'external/toxcore/c-toxcore' 2023-07-25 11:53:09 +02:00
5c7231b7a3 Squashed 'external/entt/entt/' content from commit fef92113
git-subtree-dir: external/entt/entt
git-subtree-split: fef921132cae7588213d0f9bcd2fb9c8ffd8b7fc
2023-07-25 11:29:51 +02:00
310a099f14 Merge commit '5c7231b7a33124aeadedbd8c7579376494a05a56' as 'external/entt/entt' 2023-07-25 11:29:51 +02:00
df9fc529e2 add gitignore 2023-07-25 11:29:43 +02:00
f077a29cf0 partial setup 2023-07-25 01:11:30 +02:00
3549 changed files with 631041 additions and 59011 deletions

1
.github/FUNDING.yml vendored Normal file
View File

@ -0,0 +1 @@
github: Green-Sky

113
.github/workflows/cd.yml vendored Normal file
View File

@ -0,0 +1,113 @@
name: ContinuousDelivery
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
env:
BUILD_TYPE: Release
jobs:
linux-ubuntu:
timeout-minutes: 10
runs-on: ubuntu-20.04
steps:
- uses: actions/checkout@v3
with:
submodules: recursive
- name: Install Dependencies
run: sudo apt update && sudo apt -y install libsodium-dev
- name: Configure CMake
run: cmake -B ${{github.workspace}}/build -DCMAKE_BUILD_TYPE=${{env.BUILD_TYPE}}
- name: Build
run: cmake --build ${{github.workspace}}/build --config ${{env.BUILD_TYPE}} -j 4
- name: temp test
run: ${{github.workspace}}/build/bin/mono_time_test
- uses: actions/upload-artifact@v3
with:
name: ${{ github.event.repository.name }}-ubuntu20.04-x86_64
# TODO: do propper packing
path: |
${{github.workspace}}/build/bin/
windows:
timeout-minutes: 15
runs-on: windows-2019
steps:
- uses: actions/checkout@v3
with:
submodules: recursive
- name: Install Dependencies
run: vcpkg install libsodium:x64-windows-static pthreads:x64-windows-static
# setup vs env
- uses: ilammy/msvc-dev-cmd@v1
with:
arch: amd64
- name: Configure CMake
run: cmake -G Ninja -B ${{github.workspace}}/build -DCMAKE_BUILD_TYPE=${{env.BUILD_TYPE}} -DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake -DVCPKG_TARGET_TRIPLET=x64-windows-static
- name: Build
run: cmake --build ${{github.workspace}}/build --config ${{env.BUILD_TYPE}} -j 4
- name: temp test
run: ${{github.workspace}}/build/bin/mono_time_test.exe
- uses: actions/upload-artifact@v3
if: success() || failure()
with:
name: ${{ github.event.repository.name }}-windows-msvc-x86_64
# TODO: do propper packing
path: |
${{github.workspace}}/build/bin/
windows-asan:
timeout-minutes: 15
runs-on: windows-2019
steps:
- uses: actions/checkout@v3
with:
submodules: recursive
- name: Install Dependencies
run: vcpkg install libsodium:x64-windows-static pthreads:x64-windows-static
# setup vs env
- uses: ilammy/msvc-dev-cmd@v1
with:
arch: amd64
- name: Configure CMake
run: cmake -G Ninja -B ${{github.workspace}}/build -DCMAKE_BUILD_TYPE=${{env.BUILD_TYPE}} -DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake -DVCPKG_TARGET_TRIPLET=x64-windows-static -DTOMATO_ASAN=ON -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded
- name: Build
run: cmake --build ${{github.workspace}}/build --config ${{env.BUILD_TYPE}} -j 4
- name: temp test
run: ${{github.workspace}}/build/bin/mono_time_test.exe
- uses: actions/upload-artifact@v3
if: success() || failure()
with:
name: ${{ github.event.repository.name }}-windows-msvc-asan-x86_64
# TODO: do propper packing
# TODO: also switch to asan dlls
path: |
${{github.workspace}}/build/bin/

80
.github/workflows/ci.yml vendored Normal file
View File

@ -0,0 +1,80 @@
name: ContinuousIntegration
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
env:
BUILD_TYPE: Debug
jobs:
linux:
timeout-minutes: 10
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
with:
submodules: recursive
- name: Install Dependencies
run: sudo apt update && sudo apt -y install libsodium-dev
- name: Configure CMake
run: cmake -B ${{github.workspace}}/build -DCMAKE_BUILD_TYPE=${{env.BUILD_TYPE}}
- name: Build
run: cmake --build ${{github.workspace}}/build --config ${{env.BUILD_TYPE}} -j 4
- name: temp test
run: ${{github.workspace}}/build/bin/mono_time_test
macos:
timeout-minutes: 10
runs-on: macos-latest
steps:
- uses: actions/checkout@v3
with:
submodules: recursive
- name: Install Dependencies
run: brew install libsodium
- name: Configure CMake
run: cmake -B ${{github.workspace}}/build -DCMAKE_BUILD_TYPE=${{env.BUILD_TYPE}}
- name: Build
run: cmake --build ${{github.workspace}}/build --config ${{env.BUILD_TYPE}} -j 4
windows:
timeout-minutes: 10
runs-on: windows-latest
steps:
- uses: actions/checkout@v3
with:
submodules: recursive
- name: Install Dependencies
run: vcpkg install libsodium:x64-windows-static pthreads:x64-windows-static
# setup vs env
- uses: ilammy/msvc-dev-cmd@v1
with:
arch: amd64
- name: Configure CMake
run: cmake -G Ninja -B ${{github.workspace}}/build -DCMAKE_BUILD_TYPE=${{env.BUILD_TYPE}} -DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake -DVCPKG_TARGET_TRIPLET=x64-windows-static
- name: Build
run: cmake --build ${{github.workspace}}/build --config ${{env.BUILD_TYPE}} -j 4
- name: temp test
run: ${{github.workspace}}/build/bin/mono_time_test.exe

View File

@ -1,56 +0,0 @@
name: Build (C/P Actions)
on: [push, pull_request]
concurrency:
group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.run_id }}
cancel-in-progress: true
jobs:
freebsd:
runs-on: ubuntu-latest
name: '${{ matrix.platform.name }} ${{ matrix.platform.os-version }}'
timeout-minutes: 30
strategy:
fail-fast: false
matrix:
platform:
- { name: FreeBSD, os: freebsd, os-version: 13.2, os-arch: x86-64, artifact: SDL-freebsd-x64,
sdl-cmake-configure-arguments: '-DSDL_CHECK_REQUIRED_INCLUDES="/usr/local/include" -DSDL_CHECK_REQUIRED_LINK_OPTIONS="-L/usr/local/lib"',
setup-cmd: 'sudo pkg update',
install-cmd: 'sudo pkg install -y cmake ninja pkgconf libXcursor libXext libXinerama libXi libXfixes libXrandr libXScrnSaver libXxf86vm wayland wayland-protocols libxkbcommon mesa-libs libglvnd evdev-proto libinotify alsa-lib jackit pipewire pulseaudio sndio dbus zh-fcitx ibus libudev-devd',
}
- { name: NetBSD, os: netbsd, os-version: 9.3, os-arch: x86-64, artifact: SDL-netbsd-x64,
sdl-cmake-configure-arguments: '',
setup-cmd: 'export PATH="/usr/pkg/sbin:/usr/pkg/bin:/sbin:$PATH";export PKG_CONFIG_PATH="/usr/pkg/lib/pkgconfig";export PKG_PATH="https://cdn.netBSD.org/pub/pkgsrc/packages/NetBSD/$(uname -p)/$(uname -r|cut -f "1 2" -d.)/All/";echo "PKG_PATH=$PKG_PATH";echo "uname -a -> \"$(uname -a)\"";sudo -E sysctl -w security.pax.aslr.enabled=0;sudo -E sysctl -w security.pax.aslr.global=0;sudo -E pkgin clean;sudo -E pkgin update',
install-cmd: 'sudo -E pkgin -y install cmake dbus pkgconf ninja-build pulseaudio libxkbcommon wayland wayland-protocols libinotify libusb1',
}
steps:
- uses: actions/checkout@v3
- name: Build
uses: cross-platform-actions/action@v0.21.1
with:
operating_system: ${{ matrix.platform.os }}
architecture: ${{ matrix.platform.os-arch }}
version: ${{ matrix.platform.os-version }}
run: |
${{ matrix.platform.setup-cmd }}
${{ matrix.platform.install-cmd }}
cmake -S . -B build -GNinja \
-Wdeprecated -Wdev -Werror \
-DCMAKE_BUILD_TYPE=Release \
-DSDL_WERROR=ON \
${{ matrix.platform.sdl-cmake-configure-arguments }}
cmake --build build/ --config Release --verbose
cmake --build build/ --config Release --target package
cmake --build build/ --config Release --target clean
rm -rf build/dist/_CPack_Packages
rm -rf build/CMakeFiles
rm -rf build/docs
- uses: actions/upload-artifact@v3
with:
if-no-files-found: error
name: ${{ matrix.platform.artifact }}
path: build/dist/SDL3*

174
.gitignore vendored
View File

@ -1,160 +1,26 @@
build/ .vs/
build-*/
!build-scripts/
buildbot/
/VERSION.txt
__pycache__
*.so
*.so.*
*.dll
*.exe
*.o *.o
*.obj
*.res
*.lib
*.a
*.la
*.dSYM
*,e1f
*,ff8
*.lnk
*.err
*.exp
*.map
*.orig
*~
*.swp *.swp
*.tmp ~*
*.rej *~
.idea/
cmake-build-debug/
cmake-build-debugandtest/
cmake-build-release/
*.stackdump
*.coredump
compile_commands.json
/build*
/result*
.clangd
.cache
# for CMake
CMakeFiles/
CMakeCache.txt
cmake_install.cmake
cmake_uninstall.cmake
SDL3ConfigVersion.cmake
.ninja_*
*.ninja
# for CLion
.idea
cmake-build-*
# for Xcode
*.mode1*
*.perspective*
*.pbxuser
(^|/)build($|/)
.DS_Store .DS_Store
xcuserdata .AppleDouble
*.xcworkspace .LSOverride
# for Visual Studio Code CMakeLists.txt.user*
.vscode/ CMakeCache.txt
# for Visual C++ *.tox
.vs imgui.ini
Debug
Release
*.user
*.ncb
*.suo
*.sdf
VisualC/tests/gamepadmap/axis.bmp
VisualC/tests/gamepadmap/button.bmp
VisualC/tests/gamepadmap/gamepadmap.bmp
VisualC/tests/gamepadmap/gamepadmap_back.bmp
VisualC/tests/loopwave/sample.wav
VisualC/tests/testautomation/*.bmp
VisualC/tests/testgamepad/axis.bmp
VisualC/tests/testgamepad/button.bmp
VisualC/tests/testgamepad/gamepadmap.bmp
VisualC/tests/testgamepad/gamepadmap_back.bmp
VisualC/tests/testoverlay/moose.dat
VisualC/tests/testrendertarget/icon.bmp
VisualC/tests/testrendertarget/sample.bmp
VisualC/tests/testscale/icon.bmp
VisualC/tests/testscale/sample.bmp
VisualC/tests/testsprite/icon.bmp
VisualC/tests/testyuv/testyuv.bmp
VisualC-GDK/**/Layout
VisualC-GDK/shaders/*.h
# for Android
android-project/local.properties
android-project/.gradle/
test/checkkeys
test/checkkeysthreads
test/gamepadmap
test/loopwave
test/loopwavequeue
test/testatomic
test/testaudiocapture
test/testaudiohotplug
test/testaudioinfo
test/testautomation
test/testbounds
test/testcustomcursor
test/testdisplayinfo
test/testdraw
test/testdrawchessboard
test/testdropfile
test/testerror
test/testevdev
test/testfile
test/testfilesystem
test/testgamepad
test/testgeometry
test/testgesture
test/testgl
test/testgles
test/testgles2
test/testhaptic
test/testhittesting
test/testhotplug
test/testiconv
test/testime
test/testintersections
test/testjoystick
test/testkeys
test/testloadso
test/testlocale
test/testlock
test/testmessage
test/testmouse
test/testmultiaudio
test/testnative
test/testoverlay
test/testplatform
test/testpower
test/testqsort
test/testrelative
test/testrendercopyex
test/testrendertarget
test/testresample
test/testrumble
test/testscale
test/testsem
test/testsensor
test/testshader
test/testshape
test/testsprite
test/testspriteminimal
test/teststreaming
test/testsurround
test/testthread
test/testtimer
test/testurl
test/testver
test/testviewport
test/testvulkan
test/testwm
test/testyuv
test/torturethread
# for Doxygen
docs/output
SDL.tag
doxygen_warn.txt

22
.gitmodules vendored Normal file
View File

@ -0,0 +1,22 @@
[submodule "external/toxcore/c-toxcore/third_party/cmp"]
path = external/toxcore/c-toxcore/third_party/cmp
url = https://github.com/camgunz/cmp.git
shallow = true
[submodule "external/solanaceae_toxcore"]
path = external/solanaceae_toxcore
url = https://github.com/Green-Sky/solanaceae_toxcore.git
[submodule "external/solanaceae_util"]
path = external/solanaceae_util
url = https://github.com/Green-Sky/solanaceae_util.git
[submodule "external/solanaceae_contact"]
path = external/solanaceae_contact
url = https://github.com/Green-Sky/solanaceae_contact.git
[submodule "external/solanaceae_message3"]
path = external/solanaceae_message3
url = https://github.com/Green-Sky/solanaceae_message3.git
[submodule "external/solanaceae_tox"]
path = external/solanaceae_tox
url = https://github.com/Green-Sky/solanaceae_tox.git
[submodule "external/solanaceae_plugin"]
path = external/solanaceae_plugin
url = https://github.com/Green-Sky/solanaceae_plugin.git

File diff suppressed because it is too large Load Diff

View File

@ -1,34 +0,0 @@
# Simple DirectMedia Layer CREDITS
Thanks to everyone who made this possible, including:
- Cliff Matthews, for giving me a reason to start this project. :) -- Executor rocks! *grin*
- Ryan Gordon for helping everybody out and keeping the dream alive. :)
- Gabriel Jacobo for his work on the Android port and generally helping out all around.
- Philipp Wiesemann for his attention to detail reviewing the entire SDL code base and proposes patches.
- Andreas Schiffler for his dedication to unit tests, Visual Studio projects, and managing the Google Summer of Code.
- Mike Sartain for incorporating SDL into Team Fortress 2 and cheering me on at Valve.
- Alfred Reynolds for the game controller API and general (in)sanity
- Jørgen Tjernø¸ for numerous magical macOS fixes.
- Pierre-Loup Griffais for his deep knowledge of OpenGL drivers.
- Julian Winter for the SDL 2.0 website.
- Sheena Smith for many months of great work on the SDL wiki creating the API documentation and style guides.
- Paul Hunkin for his port of SDL to Android during the Google Summer of Code 2010.
- Eli Gottlieb for his work on shaped windows during the Google Summer of Code 2010.
- Jim Grandpre for his work on multi-touch and gesture recognition during
the Google Summer of Code 2010.
- Edgar "bobbens" Simo for his force feedback API development during the
Google Summer of Code 2008.
- Aaron Wishnick for his work on audio resampling and pitch shifting during
the Google Summer of Code 2008.
- Holmes Futrell for his port of SDL to the iPhone and iPod Touch during the
Google Summer of Code 2008.
- Jon Atkins for SDL_image, SDL_mixer and SDL_net documentation.
- Everybody at Loki Software, Inc. for their great contributions!
And a big hand to everyone else who has contributed over the years.
THANKS! :)
-- Sam Lantinga <slouken@libsdl.org>

View File

@ -1,64 +0,0 @@
# To compile and install SDL:
## Windows with Visual Studio:
Read ./docs/README-visualc.md
## Windows building with mingw-w64 for x86:
Run: `cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=build-scripts/cmake-toolchain-mingw64-i686.cmake && cmake --build build && cmake --install build`
## Windows building with mingw-w64 for x64:
Run: `cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=build-scripts/cmake-toolchain-mingw64-x86_64.cmake && cmake --build build && cmake --install build`
## macOS with Xcode:
Read docs/README-macos.md
## macOS from the command line:
Run: `cmake -S . -B build && cmake --build build && cmake --install build`
## Linux and other UNIX systems:
Run: `cmake -S . -B build && cmake --build build && cmake --install build`
## Android:
Read docs/README-android.md
## iOS:
Read docs/README-ios.md
## Using CMake:
Read docs/README-cmake.md
# Example code
Look at the example programs in ./test, and check out the online
documentation at https://wiki.libsdl.org/SDL3/
# Discussion
## Forums/mailing lists
Join the SDL developer discussions, sign up on
https://discourse.libsdl.org/
and go to the development forum
https://discourse.libsdl.org/c/sdl-development/6
Once you sign up, you can use the forum through the website, or as a mailing
list from your email client.
## Announcement list
Sign up for the announcement list through the web interface:
https://www.libsdl.org/mailing-list.php

View File

@ -1,18 +1,4 @@
# Tomato
# Simple DirectMedia Layer (SDL) Version 3.0 ![tomato](res/icon/tomato_v1_256.png)
https://www.libsdl.org/
Simple DirectMedia Layer is a cross-platform development library designed
to provide low level access to audio, keyboard, mouse, joystick, and graphics
hardware via OpenGL and Direct3D. It is used by video playback software,
emulators, and popular games including Valve's award winning catalog
and many Humble Bundle games.
More extensive documentation is available in the docs directory, starting
with [README.md](docs/README.md). If you are migrating to SDL 3.0 from SDL 2.0,
the changes are extensively documented in [README-migration.md](docs/README-migration.md).
Enjoy!
Sam Lantinga (slouken@libsdl.org)

View File

@ -1,436 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<ClCompile Include="..\..\src\core\gdk\SDL_gdk.cpp" />
<ClCompile Include="..\..\src\core\windows\pch.c" />
<ClCompile Include="..\..\src\core\windows\pch_cpp.cpp" />
<ClCompile Include="..\..\src\render\direct3d12\SDL_render_d3d12_xbox.cpp" />
<ClCompile Include="..\..\src\render\direct3d12\SDL_shaders_d3d12_xboxone.cpp" />
<ClCompile Include="..\..\src\render\direct3d12\SDL_shaders_d3d12_xboxseries.cpp" />
<ClCompile Include="..\..\src\main\generic\SDL_sysmain_callbacks.c" />
<ClCompile Include="..\..\src\main\SDL_main_callbacks.c" />
<ClCompile Include="..\..\src\SDL_guid.c" />
<ClCompile Include="..\..\src\atomic\SDL_atomic.c" />
<ClCompile Include="..\..\src\atomic\SDL_spinlock.c" />
<ClCompile Include="..\..\src\audio\directsound\SDL_directsound.c" />
<ClCompile Include="..\..\src\audio\disk\SDL_diskaudio.c" />
<ClCompile Include="..\..\src\audio\dummy\SDL_dummyaudio.c" />
<ClCompile Include="..\..\src\audio\SDL_audio.c" />
<ClCompile Include="..\..\src\audio\SDL_audiocvt.c" />
<ClCompile Include="..\..\src\audio\SDL_audiodev.c" />
<ClCompile Include="..\..\src\audio\SDL_audiotypecvt.c" />
<ClCompile Include="..\..\src\audio\SDL_audioqueue.c" />
<ClCompile Include="..\..\src\audio\SDL_audioresample.c" />
<ClCompile Include="..\..\src\audio\SDL_mixer.c" />
<ClCompile Include="..\..\src\audio\SDL_wave.c" />
<ClCompile Include="..\..\src\audio\wasapi\SDL_wasapi.c" />
<ClCompile Include="..\..\src\audio\wasapi\SDL_wasapi_win32.c" />
<ClCompile Include="..\..\src\core\SDL_core_unsupported.c" />
<ClCompile Include="..\..\src\core\SDL_runapp.c" />
<ClCompile Include="..\..\src\core\windows\SDL_hid.c" />
<ClCompile Include="..\..\src\core\windows\SDL_immdevice.c" />
<ClCompile Include="..\..\src\core\windows\SDL_windows.c" />
<ClCompile Include="..\..\src\core\windows\SDL_xinput.c" />
<ClCompile Include="..\..\src\cpuinfo\SDL_cpuinfo.c" />
<ClCompile Include="..\..\src\dynapi\SDL_dynapi.c" />
<ClCompile Include="..\..\src\events\SDL_clipboardevents.c" />
<ClCompile Include="..\..\src\events\SDL_displayevents.c" />
<ClCompile Include="..\..\src\events\SDL_dropevents.c" />
<ClCompile Include="..\..\src\events\SDL_events.c" />
<ClCompile Include="..\..\src\events\SDL_keyboard.c" />
<ClCompile Include="..\..\src\events\SDL_mouse.c" />
<ClCompile Include="..\..\src\events\SDL_pen.c" />
<ClCompile Include="..\..\src\events\SDL_quit.c" />
<ClCompile Include="..\..\src\events\SDL_touch.c" />
<ClCompile Include="..\..\src\events\SDL_windowevents.c" />
<ClCompile Include="..\..\src\file\SDL_rwops.c" />
<ClCompile Include="..\..\src\filesystem\gdk\SDL_sysfilesystem.cpp" />
<ClCompile Include="..\..\src\haptic\dummy\SDL_syshaptic.c" />
<ClCompile Include="..\..\src\haptic\SDL_haptic.c" />
<ClCompile Include="..\..\src\haptic\windows\SDL_dinputhaptic.c" />
<ClCompile Include="..\..\src\haptic\windows\SDL_windowshaptic.c" />
<ClCompile Include="..\..\src\haptic\windows\SDL_xinputhaptic.c" />
<ClCompile Include="..\..\src\hidapi\SDL_hidapi.c" />
<ClCompile Include="..\..\src\joystick\controller_type.c" />
<ClCompile Include="..\..\src\joystick\dummy\SDL_sysjoystick.c" />
<ClCompile Include="..\..\src\joystick\hidapi\SDL_hidapijoystick.c" />
<ClCompile Include="..\..\src\joystick\hidapi\SDL_hidapi_combined.c" />
<ClCompile Include="..\..\src\joystick\hidapi\SDL_hidapi_gamecube.c" />
<ClCompile Include="..\..\src\joystick\hidapi\SDL_hidapi_luna.c" />
<ClCompile Include="..\..\src\joystick\hidapi\SDL_hidapi_ps3.c" />
<ClCompile Include="..\..\src\joystick\hidapi\SDL_hidapi_ps4.c" />
<ClCompile Include="..\..\src\joystick\hidapi\SDL_hidapi_ps5.c" />
<ClCompile Include="..\..\src\joystick\hidapi\SDL_hidapi_rumble.c" />
<ClCompile Include="..\..\src\joystick\hidapi\SDL_hidapi_shield.c" />
<ClCompile Include="..\..\src\joystick\hidapi\SDL_hidapi_stadia.c" />
<ClCompile Include="..\..\src\joystick\hidapi\SDL_hidapi_steam.c" />
<ClCompile Include="..\..\src\joystick\hidapi\SDL_hidapi_steamdeck.c" />
<ClCompile Include="..\..\src\joystick\hidapi\SDL_hidapi_switch.c" />
<ClCompile Include="..\..\src\joystick\hidapi\SDL_hidapi_wii.c" />
<ClCompile Include="..\..\src\joystick\hidapi\SDL_hidapi_xbox360.c" />
<ClCompile Include="..\..\src\joystick\hidapi\SDL_hidapi_xbox360w.c" />
<ClCompile Include="..\..\src\joystick\hidapi\SDL_hidapi_xboxone.c" />
<ClCompile Include="..\..\src\joystick\SDL_gamepad.c" />
<ClCompile Include="..\..\src\joystick\SDL_joystick.c" />
<ClCompile Include="..\..\src\joystick\SDL_steam_virtual_gamepad.c" />
<ClCompile Include="..\..\src\joystick\virtual\SDL_virtualjoystick.c" />
<ClCompile Include="..\..\src\joystick\windows\SDL_dinputjoystick.c" />
<ClCompile Include="..\..\src\joystick\windows\SDL_rawinputjoystick.c" />
<ClCompile Include="..\..\src\joystick\windows\SDL_windowsjoystick.c" />
<ClCompile Include="..\..\src\joystick\windows\SDL_windows_gaming_input.c" />
<ClCompile Include="..\..\src\joystick\windows\SDL_xinputjoystick.c" />
<ClCompile Include="..\..\src\libm\e_atan2.c" />
<ClCompile Include="..\..\src\libm\e_exp.c" />
<ClCompile Include="..\..\src\libm\e_fmod.c" />
<ClCompile Include="..\..\src\libm\e_log.c" />
<ClCompile Include="..\..\src\libm\e_log10.c" />
<ClCompile Include="..\..\src\libm\e_pow.c" />
<ClCompile Include="..\..\src\libm\e_rem_pio2.c" />
<ClCompile Include="..\..\src\libm\e_sqrt.c" />
<ClCompile Include="..\..\src\libm\k_cos.c" />
<ClCompile Include="..\..\src\libm\k_rem_pio2.c" />
<ClCompile Include="..\..\src\libm\k_sin.c" />
<ClCompile Include="..\..\src\libm\k_tan.c" />
<ClCompile Include="..\..\src\libm\s_atan.c" />
<ClCompile Include="..\..\src\libm\s_copysign.c" />
<ClCompile Include="..\..\src\libm\s_cos.c" />
<ClCompile Include="..\..\src\libm\s_fabs.c" />
<ClCompile Include="..\..\src\libm\s_floor.c" />
<ClCompile Include="..\..\src\libm\s_modf.c" />
<ClCompile Include="..\..\src\libm\s_scalbn.c" />
<ClCompile Include="..\..\src\libm\s_sin.c" />
<ClCompile Include="..\..\src\libm\s_tan.c" />
<ClCompile Include="..\..\src\loadso\windows\SDL_sysloadso.c" />
<ClCompile Include="..\..\src\locale\SDL_locale.c" />
<ClCompile Include="..\..\src\locale\windows\SDL_syslocale.c" />
<ClCompile Include="..\..\src\misc\SDL_url.c" />
<ClCompile Include="..\..\src\misc\windows\SDL_sysurl.c" />
<ClCompile Include="..\..\src\power\SDL_power.c" />
<ClCompile Include="..\..\src\power\windows\SDL_syspower.c" />
<ClCompile Include="..\..\src\render\direct3d11\SDL_shaders_d3d11.c" />
<ClCompile Include="..\..\src\render\direct3d12\SDL_render_d3d12.c" />
<ClCompile Include="..\..\src\render\direct3d12\SDL_shaders_d3d12.c" />
<ClCompile Include="..\..\src\render\direct3d\SDL_render_d3d.c" />
<ClCompile Include="..\..\src\render\direct3d11\SDL_render_d3d11.c" />
<ClCompile Include="..\..\src\render\direct3d\SDL_shaders_d3d.c" />
<ClCompile Include="..\..\src\render\opengl\SDL_render_gl.c" />
<ClCompile Include="..\..\src\render\opengl\SDL_shaders_gl.c" />
<ClCompile Include="..\..\src\render\opengles2\SDL_render_gles2.c" />
<ClCompile Include="..\..\src\render\opengles2\SDL_shaders_gles2.c" />
<ClCompile Include="..\..\src\render\SDL_d3dmath.c" />
<ClCompile Include="..\..\src\render\SDL_render.c" />
<ClCompile Include="..\..\src\render\SDL_render_unsupported.c" />
<ClCompile Include="..\..\src\render\SDL_yuv_sw.c" />
<ClCompile Include="..\..\src\render\software\SDL_blendfillrect.c" />
<ClCompile Include="..\..\src\render\software\SDL_blendline.c" />
<ClCompile Include="..\..\src\render\software\SDL_blendpoint.c" />
<ClCompile Include="..\..\src\render\software\SDL_drawline.c" />
<ClCompile Include="..\..\src\render\software\SDL_drawpoint.c" />
<ClCompile Include="..\..\src\render\software\SDL_render_sw.c" />
<ClCompile Include="..\..\src\render\software\SDL_rotate.c" />
<ClCompile Include="..\..\src\render\software\SDL_triangle.c" />
<ClCompile Include="..\..\src\SDL.c" />
<ClCompile Include="..\..\src\SDL_assert.c" />
<ClCompile Include="..\..\src\SDL_list.c" />
<ClCompile Include="..\..\src\SDL_error.c" />
<ClCompile Include="..\..\src\SDL_hashtable.c" />
<ClCompile Include="..\..\src\SDL_hints.c" />
<ClCompile Include="..\..\src\SDL_log.c" />
<ClCompile Include="..\..\src\SDL_properties.c" />
<ClCompile Include="..\..\src\SDL_utils.c" />
<ClCompile Include="..\..\src\sensor\dummy\SDL_dummysensor.c" />
<ClCompile Include="..\..\src\sensor\SDL_sensor.c" />
<ClCompile Include="..\..\src\sensor\windows\SDL_windowssensor.c" />
<ClCompile Include="..\..\src\stdlib\SDL_crc16.c" />
<ClCompile Include="..\..\src\stdlib\SDL_crc32.c" />
<ClCompile Include="..\..\src\stdlib\SDL_getenv.c" />
<ClCompile Include="..\..\src\stdlib\SDL_iconv.c" />
<ClCompile Include="..\..\src\stdlib\SDL_malloc.c" />
<ClCompile Include="..\..\src\stdlib\SDL_mslibc.c" />
<ClCompile Include="..\..\src\stdlib\SDL_qsort.c" />
<ClCompile Include="..\..\src\stdlib\SDL_stdlib.c" />
<ClCompile Include="..\..\src\stdlib\SDL_string.c" />
<ClCompile Include="..\..\src\stdlib\SDL_strtokr.c" />
<ClCompile Include="..\..\src\thread\generic\SDL_syscond.c" />
<ClCompile Include="..\..\src\thread\generic\SDL_sysrwlock.c" />
<ClCompile Include="..\..\src\thread\SDL_thread.c" />
<ClCompile Include="..\..\src\thread\windows\SDL_syscond_cv.c" />
<ClCompile Include="..\..\src\thread\windows\SDL_sysmutex.c" />
<ClCompile Include="..\..\src\thread\windows\SDL_sysrwlock_srw.c" />
<ClCompile Include="..\..\src\thread\windows\SDL_syssem.c" />
<ClCompile Include="..\..\src\thread\windows\SDL_systhread.c" />
<ClCompile Include="..\..\src\thread\windows\SDL_systls.c" />
<ClCompile Include="..\..\src\timer\SDL_timer.c" />
<ClCompile Include="..\..\src\timer\windows\SDL_systimer.c" />
<ClCompile Include="..\..\src\video\dummy\SDL_nullevents.c" />
<ClCompile Include="..\..\src\video\dummy\SDL_nullframebuffer.c" />
<ClCompile Include="..\..\src\video\dummy\SDL_nullvideo.c" />
<ClCompile Include="..\..\src\video\gdk\SDL_gdktextinput.cpp" />
<ClCompile Include="..\..\src\video\SDL_blit.c" />
<ClCompile Include="..\..\src\video\SDL_blit_0.c" />
<ClCompile Include="..\..\src\video\SDL_blit_1.c" />
<ClCompile Include="..\..\src\video\SDL_blit_A.c" />
<ClCompile Include="..\..\src\video\SDL_blit_auto.c" />
<ClCompile Include="..\..\src\video\SDL_blit_copy.c" />
<ClCompile Include="..\..\src\video\SDL_blit_N.c" />
<ClCompile Include="..\..\src\video\SDL_blit_slow.c" />
<ClCompile Include="..\..\src\video\SDL_bmp.c" />
<ClCompile Include="..\..\src\video\SDL_clipboard.c" />
<ClCompile Include="..\..\src\video\SDL_egl.c" />
<ClCompile Include="..\..\src\video\SDL_fillrect.c" />
<ClCompile Include="..\..\src\video\SDL_pixels.c" />
<ClCompile Include="..\..\src\video\SDL_rect.c" />
<ClCompile Include="..\..\src\video\SDL_RLEaccel.c" />
<ClCompile Include="..\..\src\video\SDL_stretch.c" />
<ClCompile Include="..\..\src\video\SDL_surface.c" />
<ClCompile Include="..\..\src\video\SDL_video.c" />
<ClCompile Include="..\..\src\video\SDL_video_unsupported.c" />
<ClCompile Include="..\..\src\video\SDL_vulkan_utils.c" />
<ClCompile Include="..\..\src\video\SDL_yuv.c" />
<ClCompile Include="..\..\src\video\windows\SDL_windowsclipboard.c" />
<ClCompile Include="..\..\src\video\windows\SDL_windowsevents.c" />
<ClCompile Include="..\..\src\video\windows\SDL_windowsframebuffer.c" />
<ClCompile Include="..\..\src\video\windows\SDL_windowskeyboard.c" />
<ClCompile Include="..\..\src\video\windows\SDL_windowsmessagebox.c" />
<ClCompile Include="..\..\src\video\windows\SDL_windowsmodes.c" />
<ClCompile Include="..\..\src\video\windows\SDL_windowsmouse.c" />
<ClCompile Include="..\..\src\video\windows\SDL_windowsopengl.c" />
<ClCompile Include="..\..\src\video\windows\SDL_windowsopengles.c" />
<ClCompile Include="..\..\src\video\windows\SDL_windowsvideo.c" />
<ClCompile Include="..\..\src\video\windows\SDL_windowsvulkan.c" />
<ClCompile Include="..\..\src\video\windows\SDL_windowswindow.c" />
<ClCompile Include="..\..\src\video\yuv2rgb\yuv_rgb.c" />
<ClCompile Include="..\..\src\filesystem\windows\SDL_sysfilesystem.c" />
<ClCompile Include="..\..\src\video\SDL_video_capture.c" />
</ItemGroup>
<ItemGroup>
<ClInclude Include="..\..\include\SDL3\SDL_begin_code.h" />
<ClInclude Include="..\..\include\SDL3\SDL_close_code.h" />
<ClInclude Include="..\..\include\SDL3\SDL.h" />
<ClInclude Include="..\..\include\SDL3\SDL_assert.h" />
<ClInclude Include="..\..\include\SDL3\SDL_atomic.h" />
<ClInclude Include="..\..\include\SDL3\SDL_audio.h" />
<ClInclude Include="..\..\include\SDL3\SDL_bits.h" />
<ClInclude Include="..\..\include\SDL3\SDL_blendmode.h" />
<ClInclude Include="..\..\include\SDL3\SDL_clipboard.h" />
<ClInclude Include="..\..\include\SDL3\SDL_copying.h" />
<ClInclude Include="..\..\include\SDL3\SDL_cpuinfo.h" />
<ClInclude Include="..\..\include\SDL3\SDL_egl.h" />
<ClInclude Include="..\..\include\SDL3\SDL_endian.h" />
<ClInclude Include="..\..\include\SDL3\SDL_error.h" />
<ClInclude Include="..\..\include\SDL3\SDL_events.h" />
<ClInclude Include="..\..\include\SDL3\SDL_filesystem.h" />
<ClInclude Include="..\..\include\SDL3\SDL_gamepad.h" />
<ClInclude Include="..\..\include\SDL3\SDL_guid.h" />
<ClInclude Include="..\..\include\SDL3\SDL_haptic.h" />
<ClInclude Include="..\..\include\SDL3\SDL_hints.h" />
<ClInclude Include="..\..\include\SDL3\SDL_hidapi.h" />
<ClInclude Include="..\..\include\SDL3\SDL_joystick.h" />
<ClInclude Include="..\..\include\SDL3\SDL_keyboard.h" />
<ClInclude Include="..\..\include\SDL3\SDL_keycode.h" />
<ClInclude Include="..\..\include\SDL3\SDL_loadso.h" />
<ClInclude Include="..\..\include\SDL3\SDL_locale.h" />
<ClInclude Include="..\..\include\SDL3\SDL_log.h" />
<ClInclude Include="..\..\include\SDL3\SDL_main.h" />
<ClInclude Include="..\..\include\SDL3\SDL_messagebox.h" />
<ClInclude Include="..\..\include\SDL3\SDL_metal.h" />
<ClInclude Include="..\..\include\SDL3\SDL_misc.h" />
<ClInclude Include="..\..\include\SDL3\SDL_mouse.h" />
<ClInclude Include="..\..\include\SDL3\SDL_mutex.h" />
<ClInclude Include="..\..\include\SDL3\SDL_opengl.h" />
<ClInclude Include="..\..\include\SDL3\SDL_opengl_glext.h" />
<ClInclude Include="..\..\include\SDL3\SDL_opengles.h" />
<ClInclude Include="..\..\include\SDL3\SDL_opengles2.h" />
<ClInclude Include="..\..\include\SDL3\SDL_opengles2_gl2.h" />
<ClInclude Include="..\..\include\SDL3\SDL_opengles2_gl2ext.h" />
<ClInclude Include="..\..\include\SDL3\SDL_opengles2_gl2platform.h" />
<ClInclude Include="..\..\include\SDL3\SDL_opengles2_khrplatform.h" />
<ClInclude Include="..\..\include\SDL3\SDL_pen.h" />
<ClInclude Include="..\..\include\SDL3\SDL_pixels.h" />
<ClInclude Include="..\..\include\SDL3\SDL_platform.h" />
<ClInclude Include="..\..\include\SDL3\SDL_platform_defines.h" />
<ClInclude Include="..\..\include\SDL3\SDL_power.h" />
<ClInclude Include="..\..\include\SDL3\SDL_quit.h" />
<ClInclude Include="..\..\include\SDL3\SDL_rect.h" />
<ClInclude Include="..\..\include\SDL3\SDL_render.h" />
<ClInclude Include="..\..\include\SDL3\SDL_revision.h" />
<ClInclude Include="..\..\include\SDL3\SDL_rwops.h" />
<ClInclude Include="..\..\include\SDL3\SDL_scancode.h" />
<ClInclude Include="..\..\include\SDL3\SDL_sensor.h" />
<ClInclude Include="..\..\include\SDL3\SDL_stdinc.h" />
<ClInclude Include="..\..\include\SDL3\SDL_surface.h" />
<ClInclude Include="..\..\include\SDL3\SDL_system.h" />
<ClInclude Include="..\..\include\SDL3\SDL_test.h" />
<ClInclude Include="..\..\include\SDL3\SDL_test_assert.h" />
<ClInclude Include="..\..\include\SDL3\SDL_test_common.h" />
<ClInclude Include="..\..\include\SDL3\SDL_test_compare.h" />
<ClInclude Include="..\..\include\SDL3\SDL_test_crc32.h" />
<ClInclude Include="..\..\include\SDL3\SDL_test_font.h" />
<ClInclude Include="..\..\include\SDL3\SDL_test_fuzzer.h" />
<ClInclude Include="..\..\include\SDL3\SDL_test_harness.h" />
<ClInclude Include="..\..\include\SDL3\SDL_test_log.h" />
<ClInclude Include="..\..\include\SDL3\SDL_test_md5.h" />
<ClInclude Include="..\..\include\SDL3\SDL_test_memory.h" />
<ClInclude Include="..\..\include\SDL3\SDL_test_random.h" />
<ClInclude Include="..\..\include\SDL3\SDL_thread.h" />
<ClInclude Include="..\..\include\SDL3\SDL_timer.h" />
<ClInclude Include="..\..\include\SDL3\SDL_touch.h" />
<ClInclude Include="..\..\include\SDL3\SDL_types.h" />
<ClInclude Include="..\..\include\SDL3\SDL_version.h" />
<ClInclude Include="..\..\include\SDL3\SDL_video.h" />
<ClInclude Include="..\..\include\SDL3\SDL_vulkan.h" />
<ClInclude Include="..\..\src\audio\directsound\SDL_directsound.h" />
<ClInclude Include="..\..\src\audio\disk\SDL_diskaudio.h" />
<ClInclude Include="..\..\src\audio\dummy\SDL_dummyaudio.h" />
<ClInclude Include="..\..\src\audio\SDL_audio_c.h" />
<ClInclude Include="..\..\src\audio\SDL_audiodev_c.h" />
<ClInclude Include="..\..\src\audio\SDL_sysaudio.h" />
<ClInclude Include="..\..\src\audio\SDL_audioqueue.h" />
<ClInclude Include="..\..\src\audio\SDL_audioresample.h" />
<ClInclude Include="..\..\src\audio\SDL_wave.h" />
<ClInclude Include="..\..\src\audio\wasapi\SDL_wasapi.h" />
<ClInclude Include="..\..\src\core\gdk\SDL_gdk.h" />
<ClInclude Include="..\..\src\core\windows\SDL_directx.h" />
<ClInclude Include="..\..\src\core\windows\SDL_hid.h" />
<ClInclude Include="..\..\src\core\windows\SDL_immdevice.h" />
<ClInclude Include="..\..\src\core\windows\SDL_windows.h" />
<ClInclude Include="..\..\src\core\windows\SDL_xinput.h" />
<ClInclude Include="..\..\src\dynapi\SDL_dynapi.h" />
<ClInclude Include="..\..\src\dynapi\SDL_dynapi_overrides.h" />
<ClInclude Include="..\..\src\dynapi\SDL_dynapi_procs.h" />
<ClInclude Include="..\..\src\events\blank_cursor.h" />
<ClInclude Include="..\..\src\events\default_cursor.h" />
<ClInclude Include="..\..\src\events\scancodes_windows.h" />
<ClInclude Include="..\..\src\events\SDL_clipboardevents_c.h" />
<ClInclude Include="..\..\src\events\SDL_displayevents_c.h" />
<ClInclude Include="..\..\src\events\SDL_dropevents_c.h" />
<ClInclude Include="..\..\src\events\SDL_events_c.h" />
<ClInclude Include="..\..\src\events\SDL_keyboard_c.h" />
<ClInclude Include="..\..\src\events\SDL_mouse_c.h" />
<ClInclude Include="..\..\src\events\SDL_touch_c.h" />
<ClInclude Include="..\..\src\events\SDL_windowevents_c.h" />
<ClInclude Include="..\..\src\haptic\SDL_haptic_c.h" />
<ClInclude Include="..\..\src\haptic\SDL_syshaptic.h" />
<ClInclude Include="..\..\src\haptic\windows\SDL_dinputhaptic_c.h" />
<ClInclude Include="..\..\src\haptic\windows\SDL_windowshaptic_c.h" />
<ClInclude Include="..\..\src\haptic\windows\SDL_xinputhaptic_c.h" />
<ClInclude Include="..\..\src\hidapi\hidapi\hidapi.h" />
<ClInclude Include="..\..\src\hidapi\SDL_hidapi_c.h" />
<ClInclude Include="..\..\src\joystick\controller_type.h" />
<ClInclude Include="..\..\src\joystick\hidapi\SDL_hidapijoystick_c.h" />
<ClInclude Include="..\..\src\joystick\hidapi\SDL_hidapi_rumble.h" />
<ClInclude Include="..\..\src\joystick\SDL_gamepad_c.h" />
<ClInclude Include="..\..\src\joystick\SDL_gamepad_db.h" />
<ClInclude Include="..\..\src\joystick\SDL_joystick_c.h" />
<ClInclude Include="..\..\src\joystick\SDL_steam_virtual_gamepad.h" />
<ClInclude Include="..\..\src\joystick\SDL_sysjoystick.h" />
<ClInclude Include="..\..\src\joystick\usb_ids.h" />
<ClInclude Include="..\..\src\joystick\virtual\SDL_virtualjoystick_c.h" />
<ClInclude Include="..\..\src\joystick\windows\SDL_dinputjoystick_c.h" />
<ClInclude Include="..\..\src\joystick\windows\SDL_rawinputjoystick_c.h" />
<ClInclude Include="..\..\src\joystick\windows\SDL_windowsjoystick_c.h" />
<ClInclude Include="..\..\src\joystick\windows\SDL_xinputjoystick_c.h" />
<ClInclude Include="..\..\src\libm\math_libm.h" />
<ClInclude Include="..\..\src\libm\math_private.h" />
<ClInclude Include="..\..\src\locale\SDL_syslocale.h" />
<ClInclude Include="..\..\src\main\SDL_main_callbacks.h" />
<ClInclude Include="..\..\src\misc\SDL_sysurl.h" />
<ClInclude Include="..\..\src\power\SDL_syspower.h" />
<ClInclude Include="..\..\src\render\direct3d11\SDL_shaders_d3d11.h" />
<ClInclude Include="..\..\src\render\direct3d12\SDL_render_d3d12_xbox.h" />
<ClInclude Include="..\..\src\render\direct3d12\SDL_shaders_d3d12.h" />
<ClInclude Include="..\..\src\render\direct3d\SDL_shaders_d3d.h" />
<ClInclude Include="..\..\src\render\opengles2\SDL_gles2funcs.h" />
<ClInclude Include="..\..\src\render\opengles2\SDL_shaders_gles2.h" />
<ClInclude Include="..\..\src\render\opengl\SDL_glfuncs.h" />
<ClInclude Include="..\..\src\render\opengl\SDL_shaders_gl.h" />
<ClInclude Include="..\..\src\render\SDL_d3dmath.h" />
<ClInclude Include="..\..\src\render\SDL_sysrender.h" />
<ClInclude Include="..\..\src\render\SDL_yuv_sw_c.h" />
<ClInclude Include="..\..\src\render\software\SDL_blendfillrect.h" />
<ClInclude Include="..\..\src\render\software\SDL_blendline.h" />
<ClInclude Include="..\..\src\render\software\SDL_blendpoint.h" />
<ClInclude Include="..\..\src\render\software\SDL_draw.h" />
<ClInclude Include="..\..\src\render\software\SDL_drawline.h" />
<ClInclude Include="..\..\src\render\software\SDL_drawpoint.h" />
<ClInclude Include="..\..\src\render\software\SDL_render_sw_c.h" />
<ClInclude Include="..\..\src\render\software\SDL_rotate.h" />
<ClInclude Include="..\..\src\render\software\SDL_triangle.h" />
<ClInclude Include="..\..\src\SDL_assert_c.h" />
<ClInclude Include="..\..\src\SDL_error_c.h" />
<ClInclude Include="..\..\src\SDL_hashtable.h" />
<ClInclude Include="..\..\src\SDL_hints_c.h" />
<ClInclude Include="..\..\src\SDL_internal.h" />
<ClInclude Include="..\..\src\SDL_list.h" />
<ClInclude Include="..\..\src\SDL_log_c.h" />
<ClInclude Include="..\..\src\SDL_properties_c.h" />
<ClInclude Include="..\..\src\sensor\dummy\SDL_dummysensor.h" />
<ClInclude Include="..\..\src\sensor\SDL_sensor_c.h" />
<ClInclude Include="..\..\src\sensor\SDL_syssensor.h" />
<ClInclude Include="..\..\src\sensor\windows\SDL_windowssensor.h" />
<ClInclude Include="..\..\src\thread\generic\SDL_sysrwlock_c.h" />
<ClInclude Include="..\..\src\thread\SDL_systhread.h" />
<ClInclude Include="..\..\src\thread\SDL_thread_c.h" />
<ClInclude Include="..\..\src\thread\generic\SDL_syscond_c.h" />
<ClInclude Include="..\..\src\thread\windows\SDL_sysmutex_c.h" />
<ClInclude Include="..\..\src\thread\windows\SDL_systhread_c.h" />
<ClInclude Include="..\..\src\timer\SDL_timer_c.h" />
<ClInclude Include="..\..\src\video\dummy\SDL_nullevents_c.h" />
<ClInclude Include="..\..\src\video\dummy\SDL_nullframebuffer_c.h" />
<ClInclude Include="..\..\src\video\dummy\SDL_nullvideo.h" />
<ClInclude Include="..\..\src\video\gdk\SDL_gdktextinput.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vk_icd.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vk_layer.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vk_platform.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vk_sdk_platform.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vulkan.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vulkan.hpp" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vulkan_android.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vulkan_beta.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vulkan_core.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vulkan_directfb.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vulkan_fuchsia.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vulkan_ggp.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vulkan_ios.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vulkan_macos.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vulkan_metal.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vulkan_vi.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vulkan_wayland.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vulkan_win32.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vulkan_xcb.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vulkan_xlib.h" />
<ClInclude Include="..\..\src\video\khronos\vulkan\vulkan_xlib_xrandr.h" />
<ClInclude Include="..\..\src\video\SDL_blit.h" />
<ClInclude Include="..\..\src\video\SDL_blit_auto.h" />
<ClInclude Include="..\..\src\video\SDL_blit_copy.h" />
<ClInclude Include="..\..\src\video\SDL_blit_slow.h" />
<ClInclude Include="..\..\src\video\SDL_clipboard_c.h" />
<ClInclude Include="..\..\src\video\SDL_egl_c.h" />
<ClInclude Include="..\..\src\video\SDL_pixels_c.h" />
<ClInclude Include="..\..\src\video\SDL_rect_c.h" />
<ClInclude Include="..\..\src\video\SDL_RLEaccel_c.h" />
<ClInclude Include="..\..\src\video\SDL_sysvideo.h" />
<ClInclude Include="..\..\src\video\SDL_vulkan_internal.h" />
<ClInclude Include="..\..\src\video\SDL_yuv_c.h" />
<ClInclude Include="..\..\src\video\windows\SDL_msctf.h" />
<ClInclude Include="..\..\src\video\windows\SDL_windowsclipboard.h" />
<ClInclude Include="..\..\src\video\windows\SDL_windowsevents.h" />
<ClInclude Include="..\..\src\video\windows\SDL_windowsframebuffer.h" />
<ClInclude Include="..\..\src\video\windows\SDL_windowskeyboard.h" />
<ClInclude Include="..\..\src\video\windows\SDL_windowsmessagebox.h" />
<ClInclude Include="..\..\src\video\windows\SDL_windowsmodes.h" />
<ClInclude Include="..\..\src\video\windows\SDL_windowsmouse.h" />
<ClInclude Include="..\..\src\video\windows\SDL_windowsopengl.h" />
<ClInclude Include="..\..\src\video\windows\SDL_windowsopengles.h" />
<ClInclude Include="..\..\src\video\windows\SDL_windowsvideo.h" />
<ClInclude Include="..\..\src\video\windows\SDL_windowsvulkan.h" />
<ClInclude Include="..\..\src\video\windows\SDL_windowswindow.h" />
<ClInclude Include="..\..\src\video\windows\wmmsg.h" />
<ClInclude Include="..\..\src\video\yuv2rgb\yuv_rgb.h" />
<ClInclude Include="..\..\src\video\yuv2rgb\yuv_rgb_sse_func.h" />
<ClInclude Include="..\..\src\video\yuv2rgb\yuv_rgb_std_func.h" />
</ItemGroup>
<ItemGroup>
<ResourceCompile Include="..\..\src\core\windows\version.rc" />
</ItemGroup>
</Project>

View File

@ -1,19 +0,0 @@
struct PixelShaderInput
{
float4 pos : SV_POSITION;
float2 tex : TEXCOORD0;
float4 color : COLOR0;
};
#define ColorRS \
"RootFlags ( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT |" \
"DENY_DOMAIN_SHADER_ROOT_ACCESS |" \
"DENY_GEOMETRY_SHADER_ROOT_ACCESS |" \
"DENY_HULL_SHADER_ROOT_ACCESS )," \
"RootConstants(num32BitConstants=32, b0)"
[RootSignature(ColorRS)]
float4 main(PixelShaderInput input) : SV_TARGET0
{
return input.color;
}

View File

@ -1,43 +0,0 @@
Texture2D theTextureY : register(t0);
Texture2D theTextureUV : register(t1);
SamplerState theSampler : register(s0);
struct PixelShaderInput
{
float4 pos : SV_POSITION;
float2 tex : TEXCOORD0;
float4 color : COLOR0;
};
#define NVRS \
"RootFlags ( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT |" \
" DENY_DOMAIN_SHADER_ROOT_ACCESS |" \
" DENY_GEOMETRY_SHADER_ROOT_ACCESS |" \
" DENY_HULL_SHADER_ROOT_ACCESS )," \
"RootConstants(num32BitConstants=32, b0),"\
"DescriptorTable ( SRV(t0), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( SRV(t1), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( Sampler(s0), visibility = SHADER_VISIBILITY_PIXEL )"
[RootSignature(NVRS)]
float4 main(PixelShaderInput input) : SV_TARGET
{
const float3 offset = {-0.0627451017, -0.501960814, -0.501960814};
const float3 Rcoeff = {1.1644, 0.0000, 1.5960};
const float3 Gcoeff = {1.1644, -0.3918, -0.8130};
const float3 Bcoeff = {1.1644, 2.0172, 0.0000};
float4 Output;
float3 yuv;
yuv.x = theTextureY.Sample(theSampler, input.tex).r;
yuv.yz = theTextureUV.Sample(theSampler, input.tex).rg;
yuv += offset;
Output.r = dot(yuv, Rcoeff);
Output.g = dot(yuv, Gcoeff);
Output.b = dot(yuv, Bcoeff);
Output.a = 1.0f;
return Output * input.color;
}

View File

@ -1,43 +0,0 @@
Texture2D theTextureY : register(t0);
Texture2D theTextureUV : register(t1);
SamplerState theSampler : register(s0);
struct PixelShaderInput
{
float4 pos : SV_POSITION;
float2 tex : TEXCOORD0;
float4 color : COLOR0;
};
#define NVRS \
"RootFlags ( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT |" \
" DENY_DOMAIN_SHADER_ROOT_ACCESS |" \
" DENY_GEOMETRY_SHADER_ROOT_ACCESS |" \
" DENY_HULL_SHADER_ROOT_ACCESS )," \
"RootConstants(num32BitConstants=32, b0),"\
"DescriptorTable ( SRV(t0), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( SRV(t1), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( Sampler(s0), visibility = SHADER_VISIBILITY_PIXEL )"
[RootSignature(NVRS)]
float4 main(PixelShaderInput input) : SV_TARGET
{
const float3 offset = {-0.0627451017, -0.501960814, -0.501960814};
const float3 Rcoeff = {1.1644, 0.0000, 1.7927};
const float3 Gcoeff = {1.1644, -0.2132, -0.5329};
const float3 Bcoeff = {1.1644, 2.1124, 0.0000};
float4 Output;
float3 yuv;
yuv.x = theTextureY.Sample(theSampler, input.tex).r;
yuv.yz = theTextureUV.Sample(theSampler, input.tex).rg;
yuv += offset;
Output.r = dot(yuv, Rcoeff);
Output.g = dot(yuv, Gcoeff);
Output.b = dot(yuv, Bcoeff);
Output.a = 1.0f;
return Output * input.color;
}

View File

@ -1,43 +0,0 @@
Texture2D theTextureY : register(t0);
Texture2D theTextureUV : register(t1);
SamplerState theSampler : register(s0);
struct PixelShaderInput
{
float4 pos : SV_POSITION;
float2 tex : TEXCOORD0;
float4 color : COLOR0;
};
#define NVRS \
"RootFlags ( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT |" \
" DENY_DOMAIN_SHADER_ROOT_ACCESS |" \
" DENY_GEOMETRY_SHADER_ROOT_ACCESS |" \
" DENY_HULL_SHADER_ROOT_ACCESS )," \
"RootConstants(num32BitConstants=32, b0),"\
"DescriptorTable ( SRV(t0), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( SRV(t1), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( Sampler(s0), visibility = SHADER_VISIBILITY_PIXEL )"
[RootSignature(NVRS)]
float4 main(PixelShaderInput input) : SV_TARGET
{
const float3 offset = {0.0, -0.501960814, -0.501960814};
const float3 Rcoeff = {1.0000, 0.0000, 1.4020};
const float3 Gcoeff = {1.0000, -0.3441, -0.7141};
const float3 Bcoeff = {1.0000, 1.7720, 0.0000};
float4 Output;
float3 yuv;
yuv.x = theTextureY.Sample(theSampler, input.tex).r;
yuv.yz = theTextureUV.Sample(theSampler, input.tex).rg;
yuv += offset;
Output.r = dot(yuv, Rcoeff);
Output.g = dot(yuv, Gcoeff);
Output.b = dot(yuv, Bcoeff);
Output.a = 1.0f;
return Output * input.color;
}

View File

@ -1,43 +0,0 @@
Texture2D theTextureY : register(t0);
Texture2D theTextureUV : register(t1);
SamplerState theSampler : register(s0);
struct PixelShaderInput
{
float4 pos : SV_POSITION;
float2 tex : TEXCOORD0;
float4 color : COLOR0;
};
#define NVRS \
"RootFlags ( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT |" \
" DENY_DOMAIN_SHADER_ROOT_ACCESS |" \
" DENY_GEOMETRY_SHADER_ROOT_ACCESS |" \
" DENY_HULL_SHADER_ROOT_ACCESS )," \
"RootConstants(num32BitConstants=32, b0),"\
"DescriptorTable ( SRV(t0), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( SRV(t1), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( Sampler(s0), visibility = SHADER_VISIBILITY_PIXEL )"
[RootSignature(NVRS)]
float4 main(PixelShaderInput input) : SV_TARGET
{
const float3 offset = {-0.0627451017, -0.501960814, -0.501960814};
const float3 Rcoeff = {1.1644, 0.0000, 1.5960};
const float3 Gcoeff = {1.1644, -0.3918, -0.8130};
const float3 Bcoeff = {1.1644, 2.0172, 0.0000};
float4 Output;
float3 yuv;
yuv.x = theTextureY.Sample(theSampler, input.tex).r;
yuv.yz = theTextureUV.Sample(theSampler, input.tex).gr;
yuv += offset;
Output.r = dot(yuv, Rcoeff);
Output.g = dot(yuv, Gcoeff);
Output.b = dot(yuv, Bcoeff);
Output.a = 1.0f;
return Output * input.color;
}

View File

@ -1,43 +0,0 @@
Texture2D theTextureY : register(t0);
Texture2D theTextureUV : register(t1);
SamplerState theSampler : register(s0);
struct PixelShaderInput
{
float4 pos : SV_POSITION;
float2 tex : TEXCOORD0;
float4 color : COLOR0;
};
#define NVRS \
"RootFlags ( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT |" \
" DENY_DOMAIN_SHADER_ROOT_ACCESS |" \
" DENY_GEOMETRY_SHADER_ROOT_ACCESS |" \
" DENY_HULL_SHADER_ROOT_ACCESS )," \
"RootConstants(num32BitConstants=32, b0),"\
"DescriptorTable ( SRV(t0), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( SRV(t1), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( Sampler(s0), visibility = SHADER_VISIBILITY_PIXEL )"
[RootSignature(NVRS)]
float4 main(PixelShaderInput input) : SV_TARGET
{
const float3 offset = {-0.0627451017, -0.501960814, -0.501960814};
const float3 Rcoeff = {1.1644, 0.0000, 1.7927};
const float3 Gcoeff = {1.1644, -0.2132, -0.5329};
const float3 Bcoeff = {1.1644, 2.1124, 0.0000};
float4 Output;
float3 yuv;
yuv.x = theTextureY.Sample(theSampler, input.tex).r;
yuv.yz = theTextureUV.Sample(theSampler, input.tex).gr;
yuv += offset;
Output.r = dot(yuv, Rcoeff);
Output.g = dot(yuv, Gcoeff);
Output.b = dot(yuv, Bcoeff);
Output.a = 1.0f;
return Output * input.color;
}

View File

@ -1,43 +0,0 @@
Texture2D theTextureY : register(t0);
Texture2D theTextureUV : register(t1);
SamplerState theSampler : register(s0);
struct PixelShaderInput
{
float4 pos : SV_POSITION;
float2 tex : TEXCOORD0;
float4 color : COLOR0;
};
#define NVRS \
"RootFlags ( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT |" \
" DENY_DOMAIN_SHADER_ROOT_ACCESS |" \
" DENY_GEOMETRY_SHADER_ROOT_ACCESS |" \
" DENY_HULL_SHADER_ROOT_ACCESS )," \
"RootConstants(num32BitConstants=32, b0),"\
"DescriptorTable ( SRV(t0), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( SRV(t1), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( Sampler(s0), visibility = SHADER_VISIBILITY_PIXEL )"
[RootSignature(NVRS)]
float4 main(PixelShaderInput input) : SV_TARGET
{
const float3 offset = {0.0, -0.501960814, -0.501960814};
const float3 Rcoeff = {1.0000, 0.0000, 1.4020};
const float3 Gcoeff = {1.0000, -0.3441, -0.7141};
const float3 Bcoeff = {1.0000, 1.7720, 0.0000};
float4 Output;
float3 yuv;
yuv.x = theTextureY.Sample(theSampler, input.tex).r;
yuv.yz = theTextureUV.Sample(theSampler, input.tex).gr;
yuv += offset;
Output.r = dot(yuv, Rcoeff);
Output.g = dot(yuv, Gcoeff);
Output.b = dot(yuv, Bcoeff);
Output.a = 1.0f;
return Output * input.color;
}

View File

@ -1,24 +0,0 @@
Texture2D theTexture : register(t0);
SamplerState theSampler : register(s0);
struct PixelShaderInput
{
float4 pos : SV_POSITION;
float2 tex : TEXCOORD0;
float4 color : COLOR0;
};
#define TextureRS \
"RootFlags ( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT |" \
" DENY_DOMAIN_SHADER_ROOT_ACCESS |" \
" DENY_GEOMETRY_SHADER_ROOT_ACCESS |" \
" DENY_HULL_SHADER_ROOT_ACCESS )," \
"RootConstants(num32BitConstants=32, b0),"\
"DescriptorTable ( SRV(t0), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( Sampler(s0), visibility = SHADER_VISIBILITY_PIXEL )"
[RootSignature(TextureRS)]
float4 main(PixelShaderInput input) : SV_TARGET
{
return theTexture.Sample(theSampler, input.tex) * input.color;
}

View File

@ -1,46 +0,0 @@
Texture2D theTextureY : register(t0);
Texture2D theTextureU : register(t1);
Texture2D theTextureV : register(t2);
SamplerState theSampler : register(s0);
struct PixelShaderInput
{
float4 pos : SV_POSITION;
float2 tex : TEXCOORD0;
float4 color : COLOR0;
};
#define YUVRS \
"RootFlags ( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT |" \
" DENY_DOMAIN_SHADER_ROOT_ACCESS |" \
" DENY_GEOMETRY_SHADER_ROOT_ACCESS |" \
" DENY_HULL_SHADER_ROOT_ACCESS )," \
"RootConstants(num32BitConstants=32, b0),"\
"DescriptorTable ( SRV(t0), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( SRV(t1), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( SRV(t2), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( Sampler(s0), visibility = SHADER_VISIBILITY_PIXEL )"
[RootSignature(YUVRS)]
float4 main(PixelShaderInput input) : SV_TARGET
{
const float3 offset = {-0.0627451017, -0.501960814, -0.501960814};
const float3 Rcoeff = {1.1644, 0.0000, 1.5960};
const float3 Gcoeff = {1.1644, -0.3918, -0.8130};
const float3 Bcoeff = {1.1644, 2.0172, 0.0000};
float4 Output;
float3 yuv;
yuv.x = theTextureY.Sample(theSampler, input.tex).r;
yuv.y = theTextureU.Sample(theSampler, input.tex).r;
yuv.z = theTextureV.Sample(theSampler, input.tex).r;
yuv += offset;
Output.r = dot(yuv, Rcoeff);
Output.g = dot(yuv, Gcoeff);
Output.b = dot(yuv, Bcoeff);
Output.a = 1.0f;
return Output * input.color;
}

View File

@ -1,46 +0,0 @@
Texture2D theTextureY : register(t0);
Texture2D theTextureU : register(t1);
Texture2D theTextureV : register(t2);
SamplerState theSampler : register(s0);
struct PixelShaderInput
{
float4 pos : SV_POSITION;
float2 tex : TEXCOORD0;
float4 color : COLOR0;
};
#define YUVRS \
"RootFlags ( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT |" \
" DENY_DOMAIN_SHADER_ROOT_ACCESS |" \
" DENY_GEOMETRY_SHADER_ROOT_ACCESS |" \
" DENY_HULL_SHADER_ROOT_ACCESS )," \
"RootConstants(num32BitConstants=32, b0),"\
"DescriptorTable ( SRV(t0), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( SRV(t1), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( SRV(t2), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( Sampler(s0), visibility = SHADER_VISIBILITY_PIXEL )"
[RootSignature(YUVRS)]
float4 main(PixelShaderInput input) : SV_TARGET
{
const float3 offset = {-0.0627451017, -0.501960814, -0.501960814};
const float3 Rcoeff = {1.1644, 0.0000, 1.7927};
const float3 Gcoeff = {1.1644, -0.2132, -0.5329};
const float3 Bcoeff = {1.1644, 2.1124, 0.0000};
float4 Output;
float3 yuv;
yuv.x = theTextureY.Sample(theSampler, input.tex).r;
yuv.y = theTextureU.Sample(theSampler, input.tex).r;
yuv.z = theTextureV.Sample(theSampler, input.tex).r;
yuv += offset;
Output.r = dot(yuv, Rcoeff);
Output.g = dot(yuv, Gcoeff);
Output.b = dot(yuv, Bcoeff);
Output.a = 1.0f;
return Output * input.color;
}

View File

@ -1,46 +0,0 @@
Texture2D theTextureY : register(t0);
Texture2D theTextureU : register(t1);
Texture2D theTextureV : register(t2);
SamplerState theSampler : register(s0);
struct PixelShaderInput
{
float4 pos : SV_POSITION;
float2 tex : TEXCOORD0;
float4 color : COLOR0;
};
#define YUVRS \
"RootFlags ( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT |" \
" DENY_DOMAIN_SHADER_ROOT_ACCESS |" \
" DENY_GEOMETRY_SHADER_ROOT_ACCESS |" \
" DENY_HULL_SHADER_ROOT_ACCESS )," \
"RootConstants(num32BitConstants=32, b0),"\
"DescriptorTable ( SRV(t0), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( SRV(t1), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( SRV(t2), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( Sampler(s0), visibility = SHADER_VISIBILITY_PIXEL )"
[RootSignature(YUVRS)]
float4 main(PixelShaderInput input) : SV_TARGET
{
const float3 offset = {0.0, -0.501960814, -0.501960814};
const float3 Rcoeff = {1.0000, 0.0000, 1.4020};
const float3 Gcoeff = {1.0000, -0.3441, -0.7141};
const float3 Bcoeff = {1.0000, 1.7720, 0.0000};
float4 Output;
float3 yuv;
yuv.x = theTextureY.Sample(theSampler, input.tex).r;
yuv.y = theTextureU.Sample(theSampler, input.tex).r;
yuv.z = theTextureV.Sample(theSampler, input.tex).r;
yuv += offset;
Output.r = dot(yuv, Rcoeff);
Output.g = dot(yuv, Gcoeff);
Output.b = dot(yuv, Bcoeff);
Output.a = 1.0f;
return Output * input.color;
}

View File

@ -1,95 +0,0 @@
#pragma pack_matrix( row_major )
struct VertexShaderConstants
{
matrix model;
matrix projectionAndView;
};
ConstantBuffer<VertexShaderConstants> Constants : register(b0);
struct VertexShaderInput
{
float3 pos : POSITION;
float2 tex : TEXCOORD0;
float4 color : COLOR0;
};
struct VertexShaderOutput
{
float4 pos : SV_POSITION;
float2 tex : TEXCOORD0;
float4 color : COLOR0;
};
#define ColorRS \
"RootFlags ( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT |" \
"DENY_DOMAIN_SHADER_ROOT_ACCESS |" \
"DENY_GEOMETRY_SHADER_ROOT_ACCESS |" \
"DENY_HULL_SHADER_ROOT_ACCESS )," \
"RootConstants(num32BitConstants=32, b0)"
#define TextureRS \
"RootFlags ( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT |" \
" DENY_DOMAIN_SHADER_ROOT_ACCESS |" \
" DENY_GEOMETRY_SHADER_ROOT_ACCESS |" \
" DENY_HULL_SHADER_ROOT_ACCESS )," \
"RootConstants(num32BitConstants=32, b0),"\
"DescriptorTable ( SRV(t0), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( Sampler(s0), visibility = SHADER_VISIBILITY_PIXEL )"
#define YUVRS \
"RootFlags ( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT |" \
" DENY_DOMAIN_SHADER_ROOT_ACCESS |" \
" DENY_GEOMETRY_SHADER_ROOT_ACCESS |" \
" DENY_HULL_SHADER_ROOT_ACCESS )," \
"RootConstants(num32BitConstants=32, b0),"\
"DescriptorTable ( SRV(t0), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( SRV(t1), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( SRV(t2), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( Sampler(s0), visibility = SHADER_VISIBILITY_PIXEL )"
#define NVRS \
"RootFlags ( ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT |" \
" DENY_DOMAIN_SHADER_ROOT_ACCESS |" \
" DENY_GEOMETRY_SHADER_ROOT_ACCESS |" \
" DENY_HULL_SHADER_ROOT_ACCESS )," \
"RootConstants(num32BitConstants=32, b0),"\
"DescriptorTable ( SRV(t0), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( SRV(t1), visibility = SHADER_VISIBILITY_PIXEL ),"\
"DescriptorTable ( Sampler(s0), visibility = SHADER_VISIBILITY_PIXEL )"
[RootSignature(ColorRS)]
VertexShaderOutput mainColor(VertexShaderInput input)
{
VertexShaderOutput output;
float4 pos = float4(input.pos, 1.0f);
// Transform the vertex position into projected space.
pos = mul(pos, Constants.model);
pos = mul(pos, Constants.projectionAndView);
output.pos = pos;
// Pass through texture coordinates and color values without transformation
output.tex = input.tex;
output.color = input.color;
return output;
}
[RootSignature(TextureRS)]
VertexShaderOutput mainTexture(VertexShaderInput input)
{
return mainColor(input);
}
[RootSignature(YUVRS)]
VertexShaderOutput mainYUV(VertexShaderInput input)
{
return mainColor(input);
}
[RootSignature(NVRS)]
VertexShaderOutput mainNV(VertexShaderInput input)
{
return mainColor(input);
}

View File

@ -1,35 +0,0 @@
if %2.==one. goto setxboxone
rem Xbox Series compile
set XBOXDXC="%GameDKLatest%\GXDK\bin\Scarlett\DXC.exe"
set SUFFIX=_Series.h
goto startbuild
:setxboxone
set XBOXDXC="%GameDKLatest%\GXDK\bin\XboxOne\DXC.exe"
set SUFFIX=_One.h
:startbuild
echo Building with %XBOXDXC%
cd "%1\shaders"
rem Root Signatures
%XBOXDXC% -E ColorRS -T rootsig_1_1 -rootsig-define ColorRS -Fh D3D12_RootSig_Color%SUFFIX% -Vn D3D12_RootSig_Color D3D12_VertexShader.hlsl
%XBOXDXC% -E TextureRS -T rootsig_1_1 -rootsig-define TextureRS -Fh D3D12_RootSig_Texture%SUFFIX% -Vn D3D12_RootSig_Texture D3D12_VertexShader.hlsl
%XBOXDXC% -E YUVRS -T rootsig_1_1 -rootsig-define YUVRS -Fh D3D12_RootSig_YUV%SUFFIX% -Vn D3D12_RootSig_YUV D3D12_VertexShader.hlsl
%XBOXDXC% -E NVRS -T rootsig_1_1 -rootsig-define NVRS -Fh D3D12_RootSig_NV%SUFFIX% -Vn D3D12_RootSig_NV D3D12_VertexShader.hlsl
rem Vertex Shaders
%XBOXDXC% -E mainColor -T vs_6_0 -Fh D3D12_VertexShader_Color%SUFFIX% -Vn D3D12_VertexShader_Color D3D12_VertexShader.hlsl
%XBOXDXC% -E mainTexture -T vs_6_0 -Fh D3D12_VertexShader_Texture%SUFFIX% -Vn D3D12_VertexShader_Texture D3D12_VertexShader.hlsl
%XBOXDXC% -E mainNV -T vs_6_0 -Fh D3D12_VertexShader_NV%SUFFIX% -Vn D3D12_VertexShader_NV D3D12_VertexShader.hlsl
%XBOXDXC% -E mainYUV -T vs_6_0 -Fh D3D12_VertexShader_YUV%SUFFIX% -Vn D3D12_VertexShader_YUV D3D12_VertexShader.hlsl
rem Pixel Shaders
%XBOXDXC% -E main -T ps_6_0 -Fh D3D12_PixelShader_Colors%SUFFIX% -Vn D3D12_PixelShader_Colors D3D12_PixelShader_Colors.hlsl
%XBOXDXC% -E main -T ps_6_0 -Fh D3D12_PixelShader_NV12_BT601%SUFFIX% -Vn D3D12_PixelShader_NV12_BT601 D3D12_PixelShader_NV12_BT601.hlsl
%XBOXDXC% -E main -T ps_6_0 -Fh D3D12_PixelShader_NV12_BT709%SUFFIX% -Vn D3D12_PixelShader_NV12_BT709 D3D12_PixelShader_NV12_BT709.hlsl
%XBOXDXC% -E main -T ps_6_0 -Fh D3D12_PixelShader_NV12_JPEG%SUFFIX% -Vn D3D12_PixelShader_NV12_JPEG D3D12_PixelShader_NV12_JPEG.hlsl
%XBOXDXC% -E main -T ps_6_0 -Fh D3D12_PixelShader_NV21_BT601%SUFFIX% -Vn D3D12_PixelShader_NV21_BT601 D3D12_PixelShader_NV21_BT601.hlsl
%XBOXDXC% -E main -T ps_6_0 -Fh D3D12_PixelShader_NV21_BT709%SUFFIX% -Vn D3D12_PixelShader_NV21_BT709 D3D12_PixelShader_NV21_BT709.hlsl
%XBOXDXC% -E main -T ps_6_0 -Fh D3D12_PixelShader_NV21_JPEG%SUFFIX% -Vn D3D12_PixelShader_NV21_JPEG D3D12_PixelShader_NV21_JPEG.hlsl
%XBOXDXC% -E main -T ps_6_0 -Fh D3D12_PixelShader_Textures%SUFFIX% -Vn D3D12_PixelShader_Textures D3D12_PixelShader_Textures.hlsl
%XBOXDXC% -E main -T ps_6_0 -Fh D3D12_PixelShader_YUV_BT601%SUFFIX% -Vn D3D12_PixelShader_YUV_BT601 D3D12_PixelShader_YUV_BT601.hlsl
%XBOXDXC% -E main -T ps_6_0 -Fh D3D12_PixelShader_YUV_BT709%SUFFIX% -Vn D3D12_PixelShader_YUV_BT709 D3D12_PixelShader_YUV_BT709.hlsl
%XBOXDXC% -E main -T ps_6_0 -Fh D3D12_PixelShader_YUV_JPEG%SUFFIX% -Vn D3D12_PixelShader_YUV_JPEG D3D12_PixelShader_YUV_JPEG.hlsl

View File

@ -1,204 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup Label="ProjectConfigurations">
<ProjectConfiguration Include="Debug|Win32">
<Configuration>Debug</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Debug|x64">
<Configuration>Debug</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Release|Win32">
<Configuration>Release</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Release|x64">
<Configuration>Release</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
</ItemGroup>
<PropertyGroup Label="Globals">
<ProjectGuid>{C4E04D18-EF76-4B42-B4C2-16A1BACDC1A3}</ProjectGuid>
<RootNamespace>testpower</RootNamespace>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" Label="Configuration">
<ConfigurationType>Application</ConfigurationType>
<PlatformToolset Condition="'$(VisualStudioVersion)' != '10.0'">$(DefaultPlatformToolset)</PlatformToolset>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="Configuration">
<ConfigurationType>Application</ConfigurationType>
<PlatformToolset Condition="'$(VisualStudioVersion)' != '10.0'">$(DefaultPlatformToolset)</PlatformToolset>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
<ConfigurationType>Application</ConfigurationType>
<PlatformToolset Condition="'$(VisualStudioVersion)' != '10.0'">$(DefaultPlatformToolset)</PlatformToolset>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="Configuration">
<ConfigurationType>Application</ConfigurationType>
<PlatformToolset Condition="'$(VisualStudioVersion)' != '10.0'">$(DefaultPlatformToolset)</PlatformToolset>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
<ImportGroup Label="ExtensionSettings">
</ImportGroup>
<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="$(VCTargetsPath)Microsoft.CPP.UpgradeFromVC70.props" />
</ImportGroup>
<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="$(VCTargetsPath)Microsoft.CPP.UpgradeFromVC70.props" />
</ImportGroup>
<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="$(VCTargetsPath)Microsoft.CPP.UpgradeFromVC70.props" />
</ImportGroup>
<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="$(VCTargetsPath)Microsoft.CPP.UpgradeFromVC70.props" />
</ImportGroup>
<PropertyGroup Label="UserMacros" />
<PropertyGroup>
<_ProjectFileVersion>10.0.40219.1</_ProjectFileVersion>
<OutDir Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">$(SolutionDir)$(Platform)\$(Configuration)\</OutDir>
<IntDir Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">$(Platform)\$(Configuration)\</IntDir>
<OutDir Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">$(SolutionDir)$(Platform)\$(Configuration)\</OutDir>
<IntDir Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">$(Platform)\$(Configuration)\</IntDir>
<OutDir Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">$(SolutionDir)$(Platform)\$(Configuration)\</OutDir>
<IntDir Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">$(Platform)\$(Configuration)\</IntDir>
<OutDir Condition="'$(Configuration)|$(Platform)'=='Release|x64'">$(SolutionDir)$(Platform)\$(Configuration)\</OutDir>
<IntDir Condition="'$(Configuration)|$(Platform)'=='Release|x64'">$(Platform)\$(Configuration)\</IntDir>
<CodeAnalysisRuleSet Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">AllRules.ruleset</CodeAnalysisRuleSet>
<CodeAnalysisRules Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" />
<CodeAnalysisRuleAssemblies Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" />
<CodeAnalysisRuleSet Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">AllRules.ruleset</CodeAnalysisRuleSet>
<CodeAnalysisRules Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" />
<CodeAnalysisRuleAssemblies Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" />
<CodeAnalysisRuleSet Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">AllRules.ruleset</CodeAnalysisRuleSet>
<CodeAnalysisRules Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" />
<CodeAnalysisRuleAssemblies Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" />
<CodeAnalysisRuleSet Condition="'$(Configuration)|$(Platform)'=='Release|x64'">AllRules.ruleset</CodeAnalysisRuleSet>
<CodeAnalysisRules Condition="'$(Configuration)|$(Platform)'=='Release|x64'" />
<CodeAnalysisRuleAssemblies Condition="'$(Configuration)|$(Platform)'=='Release|x64'" />
</PropertyGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
<Midl>
<PreprocessorDefinitions>_DEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<MkTypLibCompatible>true</MkTypLibCompatible>
<SuppressStartupBanner>true</SuppressStartupBanner>
<TargetEnvironment>Win32</TargetEnvironment>
<TypeLibraryName>.\Debug/testpower.tlb</TypeLibraryName>
</Midl>
<ClCompile>
<Optimization>Disabled</Optimization>
<AdditionalIncludeDirectories>$(SolutionDir)/../include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
<AdditionalUsingDirectories>%(AdditionalUsingDirectories)</AdditionalUsingDirectories>
<PreprocessorDefinitions>WIN32;_DEBUG;_WINDOWS;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<RuntimeLibrary>MultiThreadedDLL</RuntimeLibrary>
<WarningLevel>Level3</WarningLevel>
<DebugInformationFormat>OldStyle</DebugInformationFormat>
</ClCompile>
<ResourceCompile>
<PreprocessorDefinitions>_DEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<Culture>0x0409</Culture>
</ResourceCompile>
<Link>
<GenerateDebugInformation>true</GenerateDebugInformation>
<SubSystem>Windows</SubSystem>
</Link>
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<Midl>
<PreprocessorDefinitions>_DEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<MkTypLibCompatible>true</MkTypLibCompatible>
<SuppressStartupBanner>true</SuppressStartupBanner>
<TargetEnvironment>X64</TargetEnvironment>
<TypeLibraryName>.\Debug/testpower.tlb</TypeLibraryName>
</Midl>
<ClCompile>
<Optimization>Disabled</Optimization>
<AdditionalIncludeDirectories>$(SolutionDir)/../include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
<AdditionalUsingDirectories>%(AdditionalUsingDirectories)</AdditionalUsingDirectories>
<PreprocessorDefinitions>WIN32;_DEBUG;_WINDOWS;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<RuntimeLibrary>MultiThreadedDebugDLL</RuntimeLibrary>
<WarningLevel>Level3</WarningLevel>
<DebugInformationFormat>OldStyle</DebugInformationFormat>
</ClCompile>
<ResourceCompile>
<PreprocessorDefinitions>_DEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<Culture>0x0409</Culture>
</ResourceCompile>
<Link>
<GenerateDebugInformation>true</GenerateDebugInformation>
<SubSystem>Windows</SubSystem>
</Link>
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
<Midl>
<PreprocessorDefinitions>NDEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<MkTypLibCompatible>true</MkTypLibCompatible>
<SuppressStartupBanner>true</SuppressStartupBanner>
<TargetEnvironment>Win32</TargetEnvironment>
<TypeLibraryName>.\Release/testpower.tlb</TypeLibraryName>
</Midl>
<ClCompile>
<AdditionalIncludeDirectories>$(SolutionDir)/../include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
<AdditionalUsingDirectories>%(AdditionalUsingDirectories)</AdditionalUsingDirectories>
<PreprocessorDefinitions>WIN32;NDEBUG;_WINDOWS;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<RuntimeLibrary>MultiThreadedDLL</RuntimeLibrary>
<WarningLevel>Level3</WarningLevel>
</ClCompile>
<ResourceCompile>
<PreprocessorDefinitions>NDEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<Culture>0x0409</Culture>
</ResourceCompile>
<Link>
<SubSystem>Windows</SubSystem>
</Link>
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<Midl>
<PreprocessorDefinitions>NDEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<MkTypLibCompatible>true</MkTypLibCompatible>
<SuppressStartupBanner>true</SuppressStartupBanner>
<TargetEnvironment>X64</TargetEnvironment>
<TypeLibraryName>.\Release/testpower.tlb</TypeLibraryName>
</Midl>
<ClCompile>
<AdditionalIncludeDirectories>$(SolutionDir)/../include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
<AdditionalUsingDirectories>%(AdditionalUsingDirectories)</AdditionalUsingDirectories>
<PreprocessorDefinitions>WIN32;NDEBUG;_WINDOWS;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<RuntimeLibrary>MultiThreadedDLL</RuntimeLibrary>
<WarningLevel>Level3</WarningLevel>
</ClCompile>
<ResourceCompile>
<PreprocessorDefinitions>NDEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<Culture>0x0409</Culture>
</ResourceCompile>
<Link>
<SubSystem>Windows</SubSystem>
</Link>
</ItemDefinitionGroup>
<ItemGroup>
<ProjectReference Include="..\..\SDL\SDL.vcxproj">
<Project>{81ce8daf-ebb2-4761-8e45-b71abcca8c68}</Project>
<Private>false</Private>
<CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies>
<ReferenceOutputAssembly>true</ReferenceOutputAssembly>
</ProjectReference>
<ProjectReference Include="..\..\SDL_test\SDL_test.vcxproj">
<Project>{da956fd3-e143-46f2-9fe5-c77bebc56b1a}</Project>
<Private>false</Private>
<CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies>
<ReferenceOutputAssembly>true</ReferenceOutputAssembly>
</ProjectReference>
</ItemGroup>
<ItemGroup>
<ClCompile Include="..\..\..\test\testpen.c" />
</ItemGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
<ImportGroup Label="ExtensionTargets">
</ImportGroup>
</Project>

View File

@ -1,62 +0,0 @@
package org.libsdl.app;
import android.content.*;
import android.text.InputType;
import android.view.*;
import android.view.inputmethod.EditorInfo;
import android.view.inputmethod.InputConnection;
/* This is a fake invisible editor view that receives the input and defines the
* pan&scan region
*/
public class SDLDummyEdit extends View implements View.OnKeyListener
{
InputConnection ic;
public SDLDummyEdit(Context context) {
super(context);
setFocusableInTouchMode(true);
setFocusable(true);
setOnKeyListener(this);
}
@Override
public boolean onCheckIsTextEditor() {
return true;
}
@Override
public boolean onKey(View v, int keyCode, KeyEvent event) {
return SDLActivity.handleKeyEvent(v, keyCode, event, ic);
}
//
@Override
public boolean onKeyPreIme (int keyCode, KeyEvent event) {
// As seen on StackOverflow: http://stackoverflow.com/questions/7634346/keyboard-hide-event
// FIXME: Discussion at http://bugzilla.libsdl.org/show_bug.cgi?id=1639
// FIXME: This is not a 100% effective solution to the problem of detecting if the keyboard is showing or not
// FIXME: A more effective solution would be to assume our Layout to be RelativeLayout or LinearLayout
// FIXME: And determine the keyboard presence doing this: http://stackoverflow.com/questions/2150078/how-to-check-visibility-of-software-keyboard-in-android
// FIXME: An even more effective way would be if Android provided this out of the box, but where would the fun be in that :)
if (event.getAction()==KeyEvent.ACTION_UP && keyCode == KeyEvent.KEYCODE_BACK) {
if (SDLActivity.mTextEdit != null && SDLActivity.mTextEdit.getVisibility() == View.VISIBLE) {
SDLActivity.onNativeKeyboardFocusLost();
}
}
return super.onKeyPreIme(keyCode, event);
}
@Override
public InputConnection onCreateInputConnection(EditorInfo outAttrs) {
ic = new SDLInputConnection(this, true);
outAttrs.inputType = InputType.TYPE_CLASS_TEXT |
InputType.TYPE_TEXT_FLAG_MULTI_LINE;
outAttrs.imeOptions = EditorInfo.IME_FLAG_NO_EXTRACT_UI |
EditorInfo.IME_FLAG_NO_FULLSCREEN /* API 11 */;
return ic;
}
}

View File

@ -1,136 +0,0 @@
package org.libsdl.app;
import android.content.*;
import android.os.Build;
import android.text.Editable;
import android.view.*;
import android.view.inputmethod.BaseInputConnection;
import android.widget.EditText;
public class SDLInputConnection extends BaseInputConnection
{
protected EditText mEditText;
protected String mCommittedText = "";
public SDLInputConnection(View targetView, boolean fullEditor) {
super(targetView, fullEditor);
mEditText = new EditText(SDL.getContext());
}
@Override
public Editable getEditable() {
return mEditText.getEditableText();
}
@Override
public boolean sendKeyEvent(KeyEvent event) {
/*
* This used to handle the keycodes from soft keyboard (and IME-translated input from hardkeyboard)
* However, as of Ice Cream Sandwich and later, almost all soft keyboard doesn't generate key presses
* and so we need to generate them ourselves in commitText. To avoid duplicates on the handful of keys
* that still do, we empty this out.
*/
/*
* Return DOES still generate a key event, however. So rather than using it as the 'click a button' key
* as we do with physical keyboards, let's just use it to hide the keyboard.
*/
if (event.getKeyCode() == KeyEvent.KEYCODE_ENTER) {
if (SDLActivity.onNativeSoftReturnKey()) {
return true;
}
}
return super.sendKeyEvent(event);
}
@Override
public boolean commitText(CharSequence text, int newCursorPosition) {
if (!super.commitText(text, newCursorPosition)) {
return false;
}
updateText();
return true;
}
@Override
public boolean setComposingText(CharSequence text, int newCursorPosition) {
if (!super.setComposingText(text, newCursorPosition)) {
return false;
}
updateText();
return true;
}
@Override
public boolean deleteSurroundingText(int beforeLength, int afterLength) {
if (Build.VERSION.SDK_INT <= 29 /* Android 10.0 (Q) */) {
// Workaround to capture backspace key. Ref: http://stackoverflow.com/questions>/14560344/android-backspace-in-webview-baseinputconnection
// and https://bugzilla.libsdl.org/show_bug.cgi?id=2265
if (beforeLength > 0 && afterLength == 0) {
// backspace(s)
while (beforeLength-- > 0) {
nativeGenerateScancodeForUnichar('\b');
}
return true;
}
}
if (!super.deleteSurroundingText(beforeLength, afterLength)) {
return false;
}
updateText();
return true;
}
protected void updateText() {
final Editable content = getEditable();
if (content == null) {
return;
}
String text = content.toString();
int compareLength = Math.min(text.length(), mCommittedText.length());
int matchLength, offset;
/* Backspace over characters that are no longer in the string */
for (matchLength = 0; matchLength < compareLength; ) {
int codePoint = mCommittedText.codePointAt(matchLength);
if (codePoint != text.codePointAt(matchLength)) {
break;
}
matchLength += Character.charCount(codePoint);
}
/* FIXME: This doesn't handle graphemes, like '🌬️' */
for (offset = matchLength; offset < mCommittedText.length(); ) {
int codePoint = mCommittedText.codePointAt(offset);
nativeGenerateScancodeForUnichar('\b');
offset += Character.charCount(codePoint);
}
if (matchLength < text.length()) {
String pendingText = text.subSequence(matchLength, text.length()).toString();
for (offset = 0; offset < pendingText.length(); ) {
int codePoint = pendingText.codePointAt(offset);
if (codePoint == '\n') {
if (SDLActivity.onNativeSoftReturnKey()) {
return;
}
}
/* Higher code points don't generate simulated scancodes */
if (codePoint < 128) {
nativeGenerateScancodeForUnichar((char)codePoint);
}
offset += Character.charCount(codePoint);
}
SDLInputConnection.nativeCommitText(pendingText, 0);
}
mCommittedText = text;
}
public static native void nativeCommitText(String text, int newCursorPosition);
public static native void nativeGenerateScancodeForUnichar(char c);
}

View File

@ -1,138 +0,0 @@
# - Try to find the required ffmpeg components(default: AVFORMAT, AVUTIL, AVCODEC)
#
# Once done this will define
# FFMPEG_FOUND - System has the all required components.
# FFMPEG_LIBRARIES - Link these to use the required ffmpeg components.
#
# For each of the components it will additionally set.
# - AVCODEC
# - AVDEVICE
# - AVFORMAT
# - AVFILTER
# - AVUTIL
# - POSTPROC
# - SWSCALE
# the following target will be defined
# FFmpeg::SDL::<component> - link to this target to
# the following variables will be defined
# FFmpeg_<component>_FOUND - System has <component>
# FFmpeg_<component>_INCLUDE_DIRS - Include directory necessary for using the <component> headers
# FFmpeg_<component>_LIBRARIES - Link these to use <component>
# FFmpeg_<component>_DEFINITIONS - Compiler switches required for using <component>
# FFmpeg_<component>_VERSION - The components version
#
# Copyright (c) 2006, Matthias Kretz, <kretz@kde.org>
# Copyright (c) 2008, Alexander Neundorf, <neundorf@kde.org>
# Copyright (c) 2011, Michael Jansen, <kde@michael-jansen.biz>
# Copyright (c) 2023, Sam lantinga, <slouken@libsdl.org>
#
# Redistribution and use is allowed according to the terms of the BSD license.
# For details see the accompanying COPYING-CMAKE-SCRIPTS file.
include(FindPackageHandleStandardArgs)
include("${CMAKE_CURRENT_LIST_DIR}/PkgConfigHelper.cmake")
# The default components were taken from a survey over other FindFFMPEG.cmake files
if(NOT FFmpeg_FIND_COMPONENTS)
set(FFmpeg_FIND_COMPONENTS AVCODEC AVFORMAT AVUTIL)
foreach(_component IN LISTS FFmpeg_FIND_COMPONENTS)
set(FFmpeg_FIND_REQUIRED_${_component} TRUE)
endforeach()
endif()
find_package(PkgConfig QUIET)
#
### Macro: find_component
#
# Checks for the given component by invoking pkgconfig and then looking up the libraries and
# include directories.
#
macro(find_component _component _pkgconfig _library _header)
# use pkg-config to get the directories and then use these values
# in the FIND_PATH() and FIND_LIBRARY() calls
if(PKG_CONFIG_FOUND)
pkg_check_modules(PC_${_component} QUIET ${_pkgconfig})
endif()
find_path(FFmpeg_${_component}_INCLUDE_DIRS
NAMES ${_header}
HINTS
${PC_${_component}_INCLUDE_DIRS}
PATH_SUFFIXES
ffmpeg
)
find_library(FFmpeg_${_component}_LIBRARY
NAMES ${_library}
HINTS
${PC_${_component}_LIBRARY_DIRS}
)
if(FFmpeg_${_component}_INCLUDE_DIRS AND FFmpeg_${_component}_LIBRARY)
set(FFmpeg_${_component}_FOUND TRUE)
endif()
if(PC_${_component}_FOUND)
get_flags_from_pkg_config("${FFmpeg_${_component}_LIBRARY}" "PC_${_component}" "${_component}")
endif()
set(FFmpeg_${_component}_VERSION "${PC_${_component}_VERSION}")
set(FFmpeg_${_component}_COMPILE_OPTIONS "${${_component}_options}" CACHE STRING "Extra compile options of FFmpeg ${_component}")
set(FFmpeg_${_component}_LIBRARIES "${${_component}_link_libraries}" CACHE STRING "Extra link libraries of FFmpeg ${_component}")
set(FFmpeg_${_component}_LINK_OPTIONS "${${_component}_link_options}" CACHE STRING "Extra link flags of FFmpeg ${_component}")
set(FFmpeg_${_component}_LINK_DIRECTORIES "${${_component}_link_directories}" CACHE PATH "Extra link directories of FFmpeg ${_component}")
mark_as_advanced(
FFmpeg_${_component}_INCLUDE_DIRS
FFmpeg_${_component}_LIBRARY
FFmpeg_${_component}_COMPILE_OPTIONS
FFmpeg_${_component}_LIBRARIES
FFmpeg_${_component}_LINK_OPTIONS
FFmpeg_${_component}_LINK_DIRECTORIES
)
endmacro()
# Check for all possible component.
find_component(AVCODEC libavcodec avcodec libavcodec/avcodec.h)
find_component(AVFORMAT libavformat avformat libavformat/avformat.h)
find_component(AVDEVICE libavdevice avdevice libavdevice/avdevice.h)
find_component(AVUTIL libavutil avutil libavutil/avutil.h)
find_component(AVFILTER libavfilter avfilter libavfilter/avfilter.h)
find_component(SWSCALE libswscale swscale libswscale/swscale.h)
find_component(POSTPROC libpostproc postproc libpostproc/postprocess.h)
find_component(SWRESAMPLE libswresample swresample libswresample/swresample.h)
# Compile the list of required vars
set(_FFmpeg_REQUIRED_VARS)
foreach(_component ${FFmpeg_FIND_COMPONENTS})
list(APPEND _FFmpeg_REQUIRED_VARS FFmpeg_${_component}_INCLUDE_DIRS FFmpeg_${_component}_LIBRARY)
endforeach ()
# Give a nice error message if some of the required vars are missing.
find_package_handle_standard_args(FFmpeg DEFAULT_MSG ${_FFmpeg_REQUIRED_VARS})
set(FFMPEG_LIBRARIES)
if(FFmpeg_FOUND)
foreach(_component IN LISTS FFmpeg_FIND_COMPONENTS)
if(FFmpeg_${_component}_FOUND)
list(APPEND FFMPEG_LIBRARIES FFmpeg::SDL::${_component})
if(NOT TARGET FFmpeg::SDL::${_component})
add_library(FFmpeg::SDL::${_component} UNKNOWN IMPORTED)
set_target_properties(FFmpeg::SDL::${_component} PROPERTIES
IMPORTED_LOCATION "${FFmpeg_${_component}_LIBRARY}"
INTERFACE_INCLUDE_DIRECTORIES "${FFmpeg_${_component}_INCLUDE_DIRS}"
INTERFACE_COMPILE_OPTIONS "${FFmpeg_${_component}_COMPILE_OPTIONS}"
INTERFACE_LINK_LIBRARIES "${FFmpeg_${_component}_LIBRARIES}"
INTERFACE_LINK_OPTIONS "${FFmpeg_${_component}_LINK_OPTIONS}"
INTERFACE_LINK_DIRECTORIES "${FFmpeg_${_component}_LINK_DIRECTORIES}"
)
endif()
endif()
endforeach()
endif()

View File

@ -1,10 +0,0 @@
@PACKAGE_INIT@
set_and_check(SDL3_JAR "@PACKAGE_SDL_INSTALL_JAVADIR@/SDL3/SDL3-@SDL3_VERSION@.jar")
if(NOT TARGET SDL3::Jar)
add_library(SDL3::Jar INTERFACE IMPORTED)
set_property(TARGET SDL3::Jar PROPERTY JAR_FILE "${SDL3_JAR}")
endif()
unset(SDL3_JAR)

View File

@ -1,194 +0,0 @@
# Where an SDL program starts running.
## History
SDL has a long, complicated history with starting a program.
In most of the civilized world, an application starts in a C-callable
function named "main". You probably learned it a long time ago:
```c
int main(int argc, char **argv)
{
printf("Hello world!\n");
return 0;
}
```
But not all platforms work like this. Windows apps might want a different
function named "WinMain", for example, so SDL set out to paper over this
difference.
Generally how this would work is: your app would always use the "standard"
`main(argc, argv)` function as its entry point, and `#include` the proper
SDL header before that, which did some macro magic. On platforms that used
a standard `main`, it would do nothing and what you saw was what you got.
But those other platforms! If they needed something that _wasn't_ `main`,
SDL's macro magic would quietly rename your function to `SDL_main`, and
provide its own entry point that called it. Your app was none the wiser and
your code worked everywhere without changes.
## The main entry point in SDL3
Previous versions of SDL had a static library, SDLmain, that you would link
your app against. SDL3 still has the same macro tricks, but the static library
is gone. Now it's supplied by a "single-header library," which means you
`#include <SDL3/SDL_main.h>` and that header will insert a small amount of
code into the source file that included it, so you no longer have to worry
about linking against an extra library that you might need on some platforms.
You just build your app and it works.
You should _only_ include SDL_main.h from one file (the umbrella header,
SDL.h, does _not_ include it), and know that it will `#define main` to
something else, so if you use this symbol elsewhere as a variable name, etc,
it can cause you unexpected problems.
SDL_main.h will also include platform-specific code (WinMain or whatnot) that
calls your _actual_ main function. This is compiled directly into your
program.
If for some reason you need to include SDL_main.h in a file but also _don't_
want it to generate this platform-specific code, you should define a special
macro before including the header:
```c
#define SDL_MAIN_NOIMPL
```
If you are moving from SDL2, remove any references to the SDLmain static
library from your build system, and you should be done. Things should work as
they always have.
If you have never controlled your process's entry point (you are using SDL
as a module from a general-purpose scripting language interpreter, or you're
using SDL in a plugin for some otherwise-unrelated app), then there is nothing
required of you here; there is no startup code in SDL's entry point code that
is required, so using SDL_main.h is completely optional. Just start using
the SDL API when you are ready.
## Main callbacks in SDL3
There is a second option in SDL3 for how to structure your program. This is
completely optional and you can ignore it if you're happy using a standard
"main" function.
Some platforms would rather your program operate in chunks. Most of the time,
games tend to look like this at the highest level:
```c
int main(int argc, char **argv)
{
initialize();
while (keep_running()) {
handle_new_events();
do_one_frame_of_stuff();
}
deinitialize();
}
```
There are platforms that would rather be in charge of that `while` loop:
iOS would rather you return from main() immediately and then it will let you
know that it's time to update and draw the next frame of video. Emscripten
(programs that run on a web page) absolutely requires this to function at all.
Video targets like Wayland can notify the app when to draw a new frame, to
save battery life and cooperate with the compositor more closely.
In most cases, you can add special-case code to your program to deal with this
on different platforms, but SDL3 offers a system to handle this transparently on
the app's behalf.
To use this, you have to redesign the highest level of your app a little. Once
you do, it'll work on all supported SDL platforms without problems and
`#ifdef`s in your code.
Instead of providing a "main" function, under this system, you would provide
several functions that SDL will call as appropriate.
Using the callback entry points works on every platform, because on platforms
that don't require them, we can fake them with a simple loop in an internal
implementation of the usual SDL_main.
The primary way we expect people to write SDL apps is still with SDL_main, and
this is not intended to replace it. If the app chooses to use this, it just
removes some platform-specific details they might have to otherwise manage,
and maybe removes a barrier to entry on some future platform. And you might
find you enjoy structuring your program like this more!
## How to use main callbacks in SDL3
To enable the callback entry points, you include SDL_main.h with an extra define,
from a single source file in your project:
```c
#define SDL_MAIN_USE_CALLBACKS
#include <SDL3/SDL_main.h>
```
Once you do this, you do not write a "main" function at all (and if you do,
the app will likely fail to link). Instead, you provide the following
functions:
First:
```c
int SDL_AppInit(int argc, char **argv);
```
This will be called _once_ before anything else. argc/argv work like they
always do. If this returns 0, the app runs. If it returns < 0, the app calls
SDL_AppQuit and terminates with an exit code that reports an error to the
platform. If it returns > 0, the app calls SDL_AppQuit and terminates with
an exit code that reports success to the platform. This function should not
go into an infinite mainloop; it should do any one-time startup it requires
and then return.
Then:
```c
int SDL_AppIterate(void);
```
This is called over and over, possibly at the refresh rate of the display or
some other metric that the platform dictates. This is where the heart of your
app runs. It should return as quickly as reasonably possible, but it's not a
"run one memcpy and that's all the time you have" sort of thing. The app
should do any game updates, and render a frame of video. If it returns < 0,
SDL will call SDL_AppQuit and terminate the process with an exit code that
reports an error to the platform. If it returns > 0, the app calls
SDL_AppQuit and terminates with an exit code that reports success to the
platform. If it returns 0, then SDL_AppIterate will be called again at some
regular frequency. The platform may choose to run this more or less (perhaps
less in the background, etc), or it might just call this function in a loop
as fast as possible. You do not check the event queue in this function
(SDL_AppEvent exists for that).
Next:
```c
int SDL_AppEvent(const SDL_Event *event);
```
This will be called whenever an SDL event arrives, on the thread that runs
SDL_AppIterate. Your app should also not call SDL_PollEvent, SDL_PumpEvent,
etc, as SDL will manage all this for you. Return values are the same as from
SDL_AppIterate(), so you can terminate in response to SDL_EVENT_QUIT, etc.
Finally:
```c
void SDL_AppQuit(void);
```
This is called once before terminating the app--assuming the app isn't being
forcibly killed or crashed--as a last chance to clean up. After this returns,
SDL will call SDL_Quit so the app doesn't have to (but it's safe for the app
to call it, too). Process termination proceeds as if the app returned normally
from main(), so atexit handles will run, if your platform supports that.

View File

@ -1,223 +0,0 @@
Wayland
=======
Wayland is a replacement for the X11 window system protocol and architecture and is favored over X11 by default in SDL3
for communicating with desktop compositors. It works well for the majority of applications, however, applications may
encounter limitations or behavior that is different from other windowing systems.
## Common issues:
### Window decorations are missing, or the decorations look strange
- On some desktops (i.e. GNOME), Wayland applications use a library
called [libdecor](https://gitlab.freedesktop.org/libdecor/libdecor) to provide window decorations. If this library is
not installed, the decorations will be missing. This library uses plugins to generate different decoration styles, and
if a plugin to generate native-looking decorations is not installed (i.e. the GTK plugin), the decorations will not
appear to be 'native'.
### Windows do not appear immediately after creation
- Wayland requires that the application initially present a buffer before the window becomes visible. Additionally,
applications _must_ have an event loop and processes messages on a regular basis, or the application can appear
unresponsive to both the user and desktop compositor.
### ```SDL_SetWindowPosition()``` doesn't work on non-popup windows
- Wayland does not allow toplevel windows to position themselves programmatically.
### Retrieving the global mouse cursor position when the cursor is outside a window doesn't work
- Wayland only provides applications with the cursor position within the borders of the application windows. Querying
the global position when an application window does not have mouse focus returns 0,0 as the actual cursor position is
unknown. In most cases, applications don't actually need the global cursor position and should use the window-relative
coordinates as provided by the mouse movement event or from ```SDL_GetMouseState()``` instead.
### Warping the global mouse cursor position via ```SDL_WarpMouseGlobal()``` doesn't work
- For security reasons, Wayland does not allow warping the global mouse cursor position.
### The application icon can't be set via ```SDL_SetWindowIcon()```
- Wayland doesn't support programmatically setting the application icon. To provide a custom icon for your application,
you must create an associated desktop entry file, aka a `.desktop` file, that points to the icon image. Please see the
[Desktop Entry Specification](https://specifications.freedesktop.org/desktop-entry-spec/latest/) for more information
on the format of this file. Note that if your application manually sets the application ID via the `SDL_APP_ID` hint
string, the desktop entry file name should match the application ID. For example, if your application ID is set
to `org.my_org.sdl_app`, the desktop entry file should be named `org.my_org.sdl_app.desktop`.
## Using custom Wayland windowing protocols with SDL windows
Under normal operation, an `SDL_Window` corresponds to an XDG toplevel window, which provides a standard desktop window.
If an application wishes to use a different windowing protocol with an SDL window (e.g. wlr_layer_shell) while still
having SDL handle input and rendering, it needs to create a custom, roleless surface and attach that surface to its own
toplevel window.
This is done by using `SDL_CreateWindowWithProperties()` and setting the
`SDL_PROPERTY_WINDOW_CREATE_WAYLAND_SURFACE_ROLE_CUSTOM_BOOLEAN` property to `SDL_TRUE`. Once the window has been
successfully created, the `wl_display` and `wl_surface` objects can then be retrieved from the
`SDL_PROPERTY_WINDOW_WAYLAND_DISPLAY_POINTER` and `SDL_PROPERTY_WINDOW_WAYLAND_SURFACE_POINTER` properties respectively.
Surfaces don't receive any size change notifications, so if an application changes the window size, it must inform SDL
that the surface size has changed by calling SDL_SetWindowSize() with the new dimensions.
Custom surfaces will automatically handle scaling internally if the window was created with the
`SDL_PROPERTY_WINDOW_CREATE_HIGH_PIXEL_DENSITY_BOOLEAN` property set to `SDL_TRUE`. In this case, applications should
not manually attach viewports or change the surface scale value, as SDL will handle this internally. Calls
to `SDL_SetWindowSize()` should use the logical size of the window, and `SDL_GetWindowSizeInPixels()` should be used to
query the size of the backbuffer surface in pixels. If this property is not set or is `SDL_FALSE`, applications can
attach their own viewports or change the surface scale manually, and the SDL backend will not interfere or change any
values internally. In this case, calls to `SDL_SetWindowSize()` should pass the requested surface size in pixels, not
the logical window size, as no scaling calculations will be done internally.
All window functions that control window state aside from `SDL_SetWindowSize()` are no-ops with custom surfaces.
Please see the minimal example in `tests/testwaylandcustom.c` for an example of how to use a custom, roleless surface
and attach it to an application-managed toplevel window.
## Importing external surfaces into SDL windows
Wayland windows and surfaces are more intrinsically tied to the client library than other windowing systems, therefore,
when importing surfaces, it is necessary for both SDL and the application or toolkit to use the same `wl_display`
object. This can be set/queried via the global `SDL_PROPERTY_GLOBAL_VIDEO_WAYLAND_WL_DISPLAY_POINTER` property. To
import an external `wl_display`, set this property before initializing the SDL video subsystem, and read the value to
export the internal `wl_display` after the video subsystem has been initialized. Setting this property after the video
subsystem has been initialized has no effect, and reading it when the video subsystem is uninitialized will either
return the user provided value, if one was set while in the uninitialized state, or NULL.
Once this is done, and the application has created or obtained the `wl_surface` to be wrapped in an `SDL_Window`, the
window is created with `SDL_CreateWindowWithProperties()` with the
`SDL_PROPERTY_WINDOW_CREATE_WAYLAND_WL_SURFACE_POINTER` property to set to the `wl_surface` object that is to be
imported by SDL.
SDL receives no notification regarding size changes on external surfaces or toplevel windows, so if the external surface
needs to be resized, SDL must be informed by calling SDL_SetWindowSize() with the new dimensions.
If desired, SDL can automatically handle the scaling for the surface by setting the
`SDL_PROPERTY_WINDOW_CREATE_HIGH_PIXEL_DENSITY_BOOLEAN` property to `SDL_TRUE`, however, if the surface being imported
already has, or will have, a viewport/fractional scale manager attached to it by the application or an external toolkit,
a protocol violation will result. Avoid setting this property if importing surfaces from toolkits such as Qt or GTK.
If the window is flagged as high pixel density, calls to `SDL_SetWindowSize()` should pass the logical size of the
window and `SDL_GetWindowSizeInPixels()` should be used to retrieve the backbuffer size in pixels. Otherwise, calls to
`SDL_SetWindowSize()` should pass the requested surface size in pixels, not the logical window size, as no scaling
calculations will be done internally.
All window functions that control window state aside from `SDL_SetWindowSize()` are no-ops with external surfaces.
An example of how to use external surfaces with a `wl_display` owned by SDL can be seen in `tests/testnativewayland.c`,
and the following is a minimal example of interoperation with Qt 6, with Qt owning the `wl_display`:
```c++
#include <QApplication>
#include <QWindow>
#include <qpa/qplatformnativeinterface.h>
#include <SDL3/SDL.h>
int main(int argc, char *argv[])
{
int ret = -1;
int done = 0;
SDL_PropertiesID props;
SDL_Event e;
SDL_Window *sdlWindow = NULL;
SDL_Renderer *sdlRenderer = NULL;
struct wl_display *display = NULL;
struct wl_surface *surface = NULL;
/* Initialize Qt */
QApplication qtApp(argc, argv);
QWindow qtWindow;
/* The windowing system must be Wayland. */
if (QApplication::platformName() != "wayland") {
goto exit;
}
{
/* Get the wl_display object from Qt */
QNativeInterface::QWaylandApplication *qtWlApp = qtApp.nativeInterface<QNativeInterface::QWaylandApplication>();
display = qtWlApp->display();
if (!display) {
goto exit;
}
}
/* Set SDL to use the existing wl_display object from Qt and initialize. */
SDL_SetProperty(SDL_GetGlobalProperties(), SDL_PROPERTY_GLOBAL_VIDEO_WAYLAND_WL_DISPLAY_POINTER, display);
SDL_Init(SDL_INIT_VIDEO | SDL_INIT_EVENTS);
/* Create a basic, frameless QWindow */
qtWindow.setFlags(Qt::FramelessWindowHint);
qtWindow.setGeometry(0, 0, 640, 480);
qtWindow.show();
{
/* Get the native wl_surface backing resource for the window */
QPlatformNativeInterface *qtNative = qtApp.platformNativeInterface();
surface = (struct wl_surface *)qtNative->nativeResourceForWindow("surface", &qtWindow);
if (!surface) {
goto exit;
}
}
/* Create a window that wraps the wl_surface from the QWindow.
* Qt objects should not be flagged as DPI-aware or protocol violations will result.
*/
props = SDL_CreateProperties();
SDL_SetProperty(props, SDL_PROPERTY_WINDOW_CREATE_WAYLAND_WL_SURFACE_POINTER, surface);
SDL_SetBooleanProperty(props, SDL_PROPERTY_WINDOW_CREATE_OPENGL_BOOLEAN, SDL_TRUE);
SDL_SetNumberProperty(props, SDL_PROPERTY_WINDOW_CREATE_WIDTH_NUMBER, 640);
SDL_SetNumberProperty(props, SDL_PROPERTY_WINDOW_CREATE_HEIGHT_NUMBER, 480);
sdlWindow = SDL_CreateWindowWithProperties(props);
SDL_DestroyProperties(props);
if (!sdlWindow) {
goto exit;
}
/* Create a renderer */
sdlRenderer = SDL_CreateRenderer(sdlWindow, NULL, 0);
if (!sdlRenderer) {
goto exit;
}
/* Draw a blue screen for the window until ESC is pressed or the window is no longer visible. */
while (!done) {
while (SDL_PollEvent(&e)) {
if (e.type == SDL_EVENT_KEY_DOWN && e.key.keysym.sym == SDLK_ESCAPE) {
done = 1;
}
}
qtApp.processEvents();
/* Update the backbuffer size if the window scale changed. */
qreal scale = qtWindow.devicePixelRatio();
SDL_SetWindowSize(sdlWindow, SDL_lround(640. * scale), SDL_lround(480. * scale));
if (qtWindow.isVisible()) {
SDL_SetRenderDrawColor(sdlRenderer, 0, 0, 255, 255);
SDL_RenderClear(sdlRenderer);
SDL_RenderPresent(sdlRenderer);
} else {
done = 1;
}
}
ret = 0;
exit:
/* Cleanup */
if (sdlRenderer) {
SDL_DestroyRenderer(sdlRenderer);
}
if (sdlWindow) {
SDL_DestroyWindow(sdlWindow);
}
SDL_Quit();
return ret;
}
```

20
external/CMakeLists.txt vendored Normal file
View File

@ -0,0 +1,20 @@
cmake_minimum_required(VERSION 3.9 FATAL_ERROR)
add_subdirectory(./entt)
add_subdirectory(./solanaceae_util)
add_subdirectory(./solanaceae_contact)
add_subdirectory(./solanaceae_message3)
add_subdirectory(./solanaceae_plugin)
add_subdirectory(./toxcore)
add_subdirectory(./solanaceae_toxcore)
add_subdirectory(./solanaceae_tox)
add_subdirectory(./sdl)
add_subdirectory(./imgui)
add_subdirectory(./stb)
add_subdirectory(./libwebp)

4
external/entt/CMakeLists.txt vendored Normal file
View File

@ -0,0 +1,4 @@
cmake_minimum_required(VERSION 3.9 FATAL_ERROR)
add_subdirectory(./entt EXCLUDE_FROM_ALL)

41
external/entt/entt/.clang-format vendored Normal file
View File

@ -0,0 +1,41 @@
BasedOnStyle: llvm
---
AccessModifierOffset: -4
AlignEscapedNewlines: DontAlign
AllowShortBlocksOnASingleLine: Empty
AllowShortEnumsOnASingleLine: true
AllowShortFunctionsOnASingleLine: Empty
AllowShortIfStatementsOnASingleLine: WithoutElse
AllowShortLoopsOnASingleLine: true
AlwaysBreakTemplateDeclarations: Yes
BreakBeforeBinaryOperators: NonAssignment
BreakBeforeTernaryOperators: true
ColumnLimit: 0
DerivePointerAlignment: false
IncludeCategories:
- Regex: '<[[:alnum:]_]+>'
Priority: 1
- Regex: '<(gtest|gmock)/'
Priority: 2
- Regex: '<[[:alnum:]_./]+>'
Priority: 3
- Regex: '<entt/'
Priority: 4
- Regex: '.*'
Priority: 5
IndentPPDirectives: AfterHash
IndentWidth: 4
KeepEmptyLinesAtTheStartOfBlocks: false
Language: Cpp
PointerAlignment: Right
SpaceAfterCStyleCast: false
SpaceAfterTemplateKeyword: false
SpaceAroundPointerQualifiers: After
SpaceBeforeCaseColon: false
SpaceBeforeCtorInitializerColon: false
SpaceBeforeInheritanceColon: false
SpaceBeforeParens: Never
SpaceBeforeRangeBasedForLoopColon: false
Standard: Latest
TabWidth: 4
UseTab: Never

View File

@ -0,0 +1,4 @@
# These are supported funding model platforms
github: skypjack
custom: https://www.paypal.me/skypjack

View File

@ -0,0 +1,61 @@
name: analyzer
on:
push:
branches:
- master
- wip
jobs:
iwyu:
timeout-minutes: 30
env:
IWYU: 0.19
LLVM: 15
runs-on: ubuntu-latest
continue-on-error: true
steps:
- uses: actions/checkout@v3
- name: Install llvm/clang
# see: https://apt.llvm.org/
run: |
wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | sudo apt-key add -
sudo add-apt-repository "deb http://apt.llvm.org/focal/ llvm-toolchain-focal-$LLVM main"
sudo apt update
sudo apt remove -y "llvm*"
sudo apt remove -y "libclang-dev*"
sudo apt remove -y "clang*"
sudo apt install -y llvm-$LLVM-dev
sudo apt install -y libclang-$LLVM-dev
sudo apt install -y clang-$LLVM
- name: Compile iwyu
# see: https://github.com/include-what-you-use/include-what-you-use
working-directory: build
run: |
git clone https://github.com/include-what-you-use/include-what-you-use.git --branch $IWYU --depth 1
mkdir include-what-you-use/build
cd include-what-you-use/build
cmake -DCMAKE_C_COMPILER=clang-$LLVM \
-DCMAKE_CXX_COMPILER=clang++-$LLVM \
-DCMAKE_INSTALL_PREFIX=./ \
..
make -j4
bin/include-what-you-use --version
- name: Compile tests
working-directory: build
run: |
export PATH=$PATH:${GITHUB_WORKSPACE}/build/include-what-you-use/build/bin
cmake -DCMAKE_C_COMPILER=clang-$LLVM \
-DCMAKE_CXX_COMPILER=clang++-$LLVM \
-DENTT_BUILD_TESTING=ON \
-DENTT_BUILD_BENCHMARK=ON \
-DENTT_BUILD_EXAMPLE=ON \
-DENTT_BUILD_LIB=ON \
-DENTT_BUILD_SNAPSHOT=ON \
-DCMAKE_CXX_INCLUDE_WHAT_YOU_USE="include-what-you-use;-Xiwyu;--mapping_file=${GITHUB_WORKSPACE}/entt.imp;-Xiwyu;--no_fwd_decls;-Xiwyu;--verbose=1" \
..
make -j4

View File

@ -0,0 +1,144 @@
name: build
on: [push, pull_request]
jobs:
linux:
timeout-minutes: 15
strategy:
matrix:
os: [ubuntu-latest, ubuntu-20.04]
compiler:
- { pkg: g++, exe: 'g++', version: 7 }
- { pkg: g++, exe: 'g++', version: 8 }
- { pkg: g++, exe: 'g++', version: 9 }
- { pkg: g++, exe: 'g++', version: 10 }
- { pkg: g++, exe: 'g++', version: 11 }
- { pkg: g++, exe: 'g++', version: 12 }
- { pkg: clang, exe: 'clang++', version: 8 }
- { pkg: clang, exe: 'clang++', version: 9 }
- { pkg: clang, exe: 'clang++', version: 10 }
- { pkg: clang, exe: 'clang++', version: 11 }
- { pkg: clang, exe: 'clang++', version: 12 }
- { pkg: clang, exe: 'clang++', version: 13 }
- { pkg: clang, exe: 'clang++', version: 14 }
exclude:
- os: ubuntu-latest
compiler: { pkg: g++, exe: 'g++', version: 7 }
- os: ubuntu-latest
compiler: { pkg: g++, exe: 'g++', version: 8 }
- os: ubuntu-latest
compiler: { pkg: g++, exe: 'g++', version: 9 }
- os: ubuntu-latest
compiler: { pkg: clang, exe: 'clang++', version: 8 }
- os: ubuntu-latest
compiler: { pkg: clang, exe: 'clang++', version: 9 }
- os: ubuntu-latest
compiler: { pkg: clang, exe: 'clang++', version: 10 }
- os: ubuntu-latest
compiler: { pkg: clang, exe: 'clang++', version: 11 }
- os: ubuntu-20.04
compiler: { pkg: g++, exe: 'g++', version: 10 }
- os: ubuntu-20.04
compiler: { pkg: g++, exe: 'g++', version: 11 }
- os: ubuntu-20.04
compiler: { pkg: g++, exe: 'g++', version: 12 }
- os: ubuntu-20.04
compiler: { pkg: clang, exe: 'clang++', version: 12 }
- os: ubuntu-20.04
compiler: { pkg: clang, exe: 'clang++', version: 13 }
- os: ubuntu-20.04
compiler: { pkg: clang, exe: 'clang++', version: 14 }
runs-on: ${{ matrix.os }}
steps:
- uses: actions/checkout@v3
- name: Install compiler
run: |
sudo apt update
sudo apt install -y ${{ matrix.compiler.pkg }}-${{ matrix.compiler.version }}
- name: Compile tests
working-directory: build
env:
CXX: ${{ matrix.compiler.exe }}-${{ matrix.compiler.version }}
run: |
cmake -DENTT_BUILD_TESTING=ON -DENTT_BUILD_LIB=ON -DENTT_BUILD_EXAMPLE=ON ..
make -j4
- name: Run tests
working-directory: build
env:
CTEST_OUTPUT_ON_FAILURE: 1
run: ctest --timeout 30 -C Debug -j4
windows:
timeout-minutes: 15
strategy:
matrix:
toolset: [default, v141, v142, clang-cl]
include:
- toolset: v141
toolset_option: -T"v141"
- toolset: v142
toolset_option: -T"v142"
- toolset: clang-cl
toolset_option: -T"ClangCl"
runs-on: windows-latest
steps:
- uses: actions/checkout@v3
- name: Compile tests
working-directory: build
run: |
cmake -DENTT_BUILD_TESTING=ON -DENTT_BUILD_LIB=ON -DENTT_BUILD_EXAMPLE=ON ${{ matrix.toolset_option }} ..
cmake --build . -j 4
- name: Run tests
working-directory: build
env:
CTEST_OUTPUT_ON_FAILURE: 1
run: ctest --timeout 30 -C Debug -j4
macos:
timeout-minutes: 15
runs-on: macOS-latest
steps:
- uses: actions/checkout@v3
- name: Compile tests
working-directory: build
run: |
cmake -DENTT_BUILD_TESTING=ON -DENTT_BUILD_LIB=ON -DENTT_BUILD_EXAMPLE=ON ..
make -j4
- name: Run tests
working-directory: build
env:
CTEST_OUTPUT_ON_FAILURE: 1
run: ctest --timeout 30 -C Debug -j4
extra:
timeout-minutes: 15
strategy:
matrix:
os: [windows-latest, macOS-latest, ubuntu-latest]
id_type: ["std::uint32_t", "std::uint64_t"]
cxx_std: [cxx_std_17, cxx_std_20]
runs-on: ${{ matrix.os }}
steps:
- uses: actions/checkout@v3
- name: Compile tests
working-directory: build
run: |
cmake -DENTT_BUILD_TESTING=ON -DENTT_CXX_STD=${{ matrix.cxx_std }} -DENTT_ID_TYPE=${{ matrix.id_type }} ..
cmake --build . -j 4
- name: Run tests
working-directory: build
env:
CTEST_OUTPUT_ON_FAILURE: 1
run: ctest --timeout 30 -C Debug -j4

View File

@ -0,0 +1,38 @@
name: coverage
on: [push, pull_request]
jobs:
codecov:
timeout-minutes: 15
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Compile tests
working-directory: build
env:
CXXFLAGS: "--coverage -fno-elide-constructors -fno-inline -fno-default-inline"
CXX: g++
run: |
cmake -DENTT_BUILD_TESTING=ON -DENTT_BUILD_LIB=ON -DENTT_BUILD_EXAMPLE=ON ..
make -j4
- name: Run tests
working-directory: build
env:
CTEST_OUTPUT_ON_FAILURE: 1
run: ctest --timeout 30 -C Debug -j4
- name: Collect data
working-directory: build
run: |
sudo apt install lcov
lcov -c -d . -o coverage.info
lcov -l coverage.info
- name: Upload coverage to Codecov
uses: codecov/codecov-action@v3
with:
token: ${{ secrets.CODECOV_TOKEN }}
files: build/coverage.info
name: EnTT
fail_ci_if_error: true

View File

@ -0,0 +1,39 @@
name: deploy
on:
release:
types: published
jobs:
homebrew-entt:
timeout-minutes: 5
runs-on: ubuntu-latest
env:
GH_REPO: homebrew-entt
FORMULA: entt.rb
steps:
- uses: actions/checkout@v3
- name: Clone repository
working-directory: build
env:
PERSONAL_ACCESS_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
run: git clone https://$GITHUB_ACTOR:$PERSONAL_ACCESS_TOKEN@github.com/$GITHUB_ACTOR/$GH_REPO.git
- name: Prepare formula
working-directory: build
run: |
cd $GH_REPO
curl "https://github.com/${{ github.repository }}/archive/${{ github.ref }}.tar.gz" --location --fail --silent --show-error --output archive.tar.gz
sed -i -e '/url/s/".*"/"'$(echo "https://github.com/${{ github.repository }}/archive/${{ github.ref }}.tar.gz" | sed -e 's/[\/&]/\\&/g')'"/' $FORMULA
sed -i -e '/sha256/s/".*"/"'$(openssl sha256 archive.tar.gz | cut -d " " -f 2)'"/' $FORMULA
- name: Update remote
working-directory: build
run: |
cd $GH_REPO
git config --local user.email "action@github.com"
git config --local user.name "$GITHUB_ACTOR"
git add $FORMULA
git commit -m "Update to ${{ github.ref }}"
git push origin master

View File

@ -0,0 +1,31 @@
name: sanitizer
on: [push, pull_request]
jobs:
clang:
timeout-minutes: 15
strategy:
matrix:
compiler: [clang++]
id_type: ["std::uint32_t", "std::uint64_t"]
cxx_std: [cxx_std_17, cxx_std_20]
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Compile tests
working-directory: build
env:
CXX: ${{ matrix.compiler }}
run: |
cmake -DENTT_USE_SANITIZER=ON -DENTT_BUILD_TESTING=ON -DENTT_BUILD_LIB=ON -DENTT_BUILD_EXAMPLE=ON -DENTT_CXX_STD=${{ matrix.cxx_std }} -DENTT_ID_TYPE=${{ matrix.id_type }} ..
make -j4
- name: Run tests
working-directory: build
env:
CTEST_OUTPUT_ON_FAILURE: 1
run: ctest --timeout 30 -C Debug -j4

13
external/entt/entt/.gitignore vendored Normal file
View File

@ -0,0 +1,13 @@
# Conan
conan/test_package/build
# IDEs
*.user
.idea
.vscode
.vs
CMakeSettings.json
cpp.hint
# Bazel
/bazel-*

56
external/entt/entt/AUTHORS vendored Normal file
View File

@ -0,0 +1,56 @@
# Author
skypjack
# Contributors
alexames
BenediktConze
bjadamson
ceeac
ColinH
corystegel
Croydon
cschreib
cugone
dbacchet
dBagrat
djarek
DNKpp
DonKult
drglove
eliasdaler
erez-o
eugeneko
gale83
ghost
grdowns
Green-Sky
Innokentiy-Alaytsev
Kerndog73
Koward
Lawrencemm
markand
mhammerc
Milerius
Minimonium
morbo84
m-waka
netpoetica
NixAJ
Oortonaut
Paolo-Oliverio
pgruenbacher
prowolf
Qix-
stefanofiorentino
suVrik
szunhammer
The5-1
vblanco20-1
willtunnels
WizardIke
WoLfulus
w1th0utnam3
xissburg
zaucy

14
external/entt/entt/BUILD.bazel vendored Normal file
View File

@ -0,0 +1,14 @@
_msvc_copts = ["/std:c++17"]
_gcc_copts = ["-std=c++17"]
cc_library(
name = "entt",
visibility = ["//visibility:public"],
strip_include_prefix = "src",
hdrs = glob(["src/**/*.h", "src/**/*.hpp"]),
copts = select({
"@bazel_tools//src/conditions:windows": _msvc_copts,
"@bazel_tools//src/conditions:windows_msvc": _msvc_copts,
"//conditions:default": _gcc_copts,
}),
)

325
external/entt/entt/CMakeLists.txt vendored Normal file
View File

@ -0,0 +1,325 @@
#
# EnTT
#
cmake_minimum_required(VERSION 3.15.7)
#
# Read project version
#
set(ENTT_VERSION_REGEX "#define ENTT_VERSION_.*[ \t]+(.+)")
file(STRINGS "${CMAKE_CURRENT_SOURCE_DIR}/src/entt/config/version.h" ENTT_VERSION REGEX ${ENTT_VERSION_REGEX})
list(TRANSFORM ENTT_VERSION REPLACE ${ENTT_VERSION_REGEX} "\\1")
string(JOIN "." ENTT_VERSION ${ENTT_VERSION})
#
# Project configuration
#
project(
EnTT
VERSION ${ENTT_VERSION}
DESCRIPTION "Gaming meets modern C++ - a fast and reliable entity-component system (ECS) and much more"
HOMEPAGE_URL "https://github.com/skypjack/entt"
LANGUAGES C CXX
)
if(NOT CMAKE_BUILD_TYPE)
set(CMAKE_BUILD_TYPE Debug)
endif()
message(VERBOSE "*")
message(VERBOSE "* ${PROJECT_NAME} v${PROJECT_VERSION} (${CMAKE_BUILD_TYPE})")
message(VERBOSE "* Copyright (c) 2017-2023 Michele Caini <michele.caini@gmail.com>")
message(VERBOSE "*")
#
# CMake stuff
#
list(INSERT CMAKE_MODULE_PATH 0 ${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules)
#
# Compiler stuff
#
option(ENTT_USE_LIBCPP "Use libc++ by adding -stdlib=libc++ flag if available." OFF)
option(ENTT_USE_SANITIZER "Enable sanitizers by adding -fsanitize=address -fno-omit-frame-pointer -fsanitize=undefined flags if available." OFF)
if(ENTT_USE_LIBCPP)
if(NOT WIN32)
include(CheckCXXSourceCompiles)
include(CMakePushCheckState)
cmake_push_check_state()
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -stdlib=libc++")
check_cxx_source_compiles("
#include<type_traits>
int main() { return std::is_same_v<int, char>; }
" ENTT_HAS_LIBCPP)
cmake_pop_check_state()
endif()
if(NOT ENTT_HAS_LIBCPP)
message(VERBOSE "The option ENTT_USE_LIBCPP is set but libc++ is not available. The flag will not be added to the target.")
endif()
endif()
if(ENTT_USE_SANITIZER)
if(CMAKE_CXX_COMPILER_ID MATCHES "Clang|GNU")
set(ENTT_HAS_SANITIZER TRUE CACHE BOOL "" FORCE)
mark_as_advanced(ENTT_HAS_SANITIZER)
endif()
if(NOT ENTT_HAS_SANITIZER)
message(VERBOSE "The option ENTT_USE_SANITIZER is set but sanitizer support is not available. The flags will not be added to the target.")
endif()
endif()
#
# Add EnTT target
#
option(ENTT_INCLUDE_HEADERS "Add all EnTT headers to the EnTT target." OFF)
option(ENTT_INCLUDE_NATVIS "Add EnTT natvis files to the EnTT target." OFF)
if(ENTT_INCLUDE_NATVIS)
if(MSVC)
set(ENTT_HAS_NATVIS TRUE CACHE BOOL "" FORCE)
mark_as_advanced(ENTT_HAS_NATVIS)
endif()
if(NOT ENTT_HAS_NATVIS)
message(VERBOSE "The option ENTT_INCLUDE_NATVIS is set but natvis files are not supported. They will not be added to the target.")
endif()
endif()
include(GNUInstallDirs)
add_library(EnTT INTERFACE)
add_library(EnTT::EnTT ALIAS EnTT)
target_include_directories(
EnTT
INTERFACE
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src>
$<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>
)
target_compile_features(EnTT INTERFACE cxx_std_17)
if(ENTT_INCLUDE_HEADERS)
target_sources(
EnTT
INTERFACE
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/config/config.h>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/config/macro.h>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/config/version.h>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/container/dense_map.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/container/dense_set.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/container/fwd.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/core/algorithm.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/core/any.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/core/attribute.h>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/core/compressed_pair.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/core/enum.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/core/family.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/core/fwd.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/core/hashed_string.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/core/ident.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/core/iterator.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/core/memory.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/core/monostate.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/core/tuple.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/core/type_info.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/core/type_traits.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/core/utility.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/entity/component.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/entity/entity.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/entity/fwd.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/entity/group.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/entity/handle.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/entity/mixin.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/entity/helper.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/entity/observer.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/entity/organizer.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/entity/registry.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/entity/runtime_view.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/entity/snapshot.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/entity/sparse_set.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/entity/storage.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/entity/view.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/graph/adjacency_matrix.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/graph/dot.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/graph/flow.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/graph/fwd.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/locator/locator.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/meta/adl_pointer.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/meta/container.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/meta/context.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/meta/factory.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/meta/fwd.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/meta/meta.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/meta/node.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/meta/pointer.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/meta/policy.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/meta/range.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/meta/resolve.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/meta/template.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/meta/type_traits.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/meta/utility.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/platform/android-ndk-r17.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/poly/fwd.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/poly/poly.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/process/fwd.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/process/process.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/process/scheduler.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/resource/cache.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/resource/fwd.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/resource/loader.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/resource/resource.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/signal/delegate.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/signal/dispatcher.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/signal/emitter.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/signal/fwd.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/signal/sigh.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/entt.hpp>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/src/entt/fwd.hpp>
)
endif()
if(ENTT_HAS_NATVIS)
target_sources(
EnTT
INTERFACE
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/natvis/entt/config.natvis>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/natvis/entt/container.natvis>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/natvis/entt/core.natvis>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/natvis/entt/entity.natvis>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/natvis/entt/graph.natvis>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/natvis/entt/locator.natvis>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/natvis/entt/meta.natvis>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/natvis/entt/platform.natvis>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/natvis/entt/poly.natvis>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/natvis/entt/process.natvis>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/natvis/entt/resource.natvis>
$<BUILD_INTERFACE:${EnTT_SOURCE_DIR}/natvis/entt/signal.natvis>
)
endif()
if(ENTT_HAS_SANITIZER)
target_compile_options(EnTT INTERFACE $<$<CONFIG:Debug>:-fsanitize=address -fno-omit-frame-pointer -fsanitize=undefined>)
target_link_libraries(EnTT INTERFACE $<$<CONFIG:Debug>:-fsanitize=address -fno-omit-frame-pointer -fsanitize=undefined>)
endif()
if(ENTT_HAS_LIBCPP)
target_compile_options(EnTT BEFORE INTERFACE -stdlib=libc++)
endif()
#
# Install pkg-config file
#
include(JoinPaths)
set(EnTT_PKGCONFIG ${CMAKE_CURRENT_BINARY_DIR}/entt.pc)
join_paths(EnTT_PKGCONFIG_INCLUDEDIR "\${prefix}" "${CMAKE_INSTALL_INCLUDEDIR}")
configure_file(
${EnTT_SOURCE_DIR}/cmake/in/entt.pc.in
${EnTT_PKGCONFIG}
@ONLY
)
install(
FILES ${EnTT_PKGCONFIG}
DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig
)
#
# Install EnTT
#
include(CMakePackageConfigHelpers)
install(
TARGETS EnTT
EXPORT EnTTTargets
ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
)
write_basic_package_version_file(
EnTTConfigVersion.cmake
VERSION ${PROJECT_VERSION}
COMPATIBILITY AnyNewerVersion
)
configure_package_config_file(
${EnTT_SOURCE_DIR}/cmake/in/EnTTConfig.cmake.in
EnTTConfig.cmake
INSTALL_DESTINATION ${CMAKE_INSTALL_LIBDIR}/EnTT/cmake
)
export(
EXPORT EnTTTargets
FILE ${CMAKE_CURRENT_BINARY_DIR}/EnTTTargets.cmake
NAMESPACE EnTT::
)
install(
EXPORT EnTTTargets
FILE EnTTTargets.cmake
DESTINATION ${CMAKE_INSTALL_LIBDIR}/EnTT/cmake
NAMESPACE EnTT::
)
install(
FILES
${PROJECT_BINARY_DIR}/EnTTConfig.cmake
${PROJECT_BINARY_DIR}/EnTTConfigVersion.cmake
DESTINATION ${CMAKE_INSTALL_LIBDIR}/EnTT/cmake
)
install(DIRECTORY src/ DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
export(PACKAGE EnTT)
#
# Tests
#
option(ENTT_BUILD_TESTING "Enable building tests." OFF)
if(ENTT_BUILD_TESTING)
option(ENTT_FIND_GTEST_PACKAGE "Enable finding gtest package." OFF)
option(ENTT_BUILD_BENCHMARK "Build benchmark." OFF)
option(ENTT_BUILD_EXAMPLE "Build examples." OFF)
option(ENTT_BUILD_LIB "Build lib tests." OFF)
option(ENTT_BUILD_SNAPSHOT "Build snapshot test with Cereal." OFF)
set(ENTT_ID_TYPE std::uint32_t CACHE STRING "Type of identifiers to use for the tests")
set(ENTT_CXX_STD cxx_std_17 CACHE STRING "C++ standard revision to use for the tests")
include(CTest)
enable_testing()
add_subdirectory(test)
endif()
#
# Documentation
#
option(ENTT_BUILD_DOCS "Enable building with documentation." OFF)
if(ENTT_BUILD_DOCS)
find_package(Doxygen 1.8)
if(DOXYGEN_FOUND)
add_subdirectory(docs)
endif()
endif()

43
external/entt/entt/CONTRIBUTING.md vendored Normal file
View File

@ -0,0 +1,43 @@
# Contributing
First of all, thank you very much for taking the time to contribute to the
`EnTT` library.<br/>
How to do it mostly depends on the type of contribution:
* If you have a question, **please** ensure there isn't already an answer for
you by searching on GitHub under
[issues](https://github.com/skypjack/entt/issues). Do not forget to search
also through the closed ones. If you are unable to find a proper answer, feel
free to [open a new issue](https://github.com/skypjack/entt/issues/new).
Usually, questions are marked as such and closed in a few days.
* If you want to fix a typo in the inline documentation or in the README file,
if you want to add some new sections or if you want to help me with the
language by reviewing what I wrote so far (I'm not a native speaker after
all), **please** open a new
[pull request](https://github.com/skypjack/entt/pulls) with your changes.
* If you found a bug, **please** ensure there isn't already an answer for you by
searching on GitHub under [issues](https://github.com/skypjack/entt/issues).
If you are unable to find an open issue addressing the problem, feel free to
[open a new one](https://github.com/skypjack/entt/issues/new). **Please**, do
not forget to carefully describe how to reproduce the problem, then add all
the information about the system on which you are experiencing it and point
out the version of `EnTT` you are using (tag or commit).
* If you found a bug and you wrote a patch to fix it, open a new
[pull request](https://github.com/skypjack/entt/pulls) with your code.
**Please**, add some tests to avoid regressions in future if possible, it
would be really appreciated. Note that the `EnTT` library has a
[coverage at 100%](https://coveralls.io/github/skypjack/entt?branch=master)
(at least it was at 100% at the time I wrote this file) and this is the reason
for which you can be confident with using it in a production environment.
* If you want to propose a new feature and you know how to code it, **please**
do not issue directly a pull request. Before to do it,
[create a new issue](https://github.com/skypjack/entt/issues/new) to discuss
your proposal. Other users could be interested in your idea and the discussion
that will follow can refine it and therefore give us a better solution.
* If you want to request a new feature, I'm available for hiring. Take a look at
[my profile](https://github.com/skypjack) and feel free to write me.

21
external/entt/entt/LICENSE vendored Normal file
View File

@ -0,0 +1,21 @@
The MIT License (MIT)
Copyright (c) 2017-2023 Michele Caini, author of EnTT
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copy of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copy or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

428
external/entt/entt/README.md vendored Normal file
View File

@ -0,0 +1,428 @@
![EnTT: Gaming meets modern C++](https://user-images.githubusercontent.com/1812216/103550016-90752280-4ea8-11eb-8667-12ed2219e137.png)
<!--
@cond TURN_OFF_DOXYGEN
-->
[![Build Status](https://github.com/skypjack/entt/workflows/build/badge.svg)](https://github.com/skypjack/entt/actions)
[![Coverage](https://codecov.io/gh/skypjack/entt/branch/master/graph/badge.svg)](https://codecov.io/gh/skypjack/entt)
[![Try online](https://img.shields.io/badge/try-online-brightgreen)](https://godbolt.org/z/zxW73f)
[![Vcpkg port](https://img.shields.io/vcpkg/v/entt)](https://vcpkg.link/ports/entt)
[![Documentation](https://img.shields.io/badge/docs-doxygen-blue)](https://skypjack.github.io/entt/)
[![Gitter chat](https://badges.gitter.im/skypjack/entt.png)](https://gitter.im/skypjack/entt)
[![Discord channel](https://img.shields.io/discord/707607951396962417?logo=discord)](https://discord.gg/5BjPWBd)
[![Donate](https://img.shields.io/badge/donate-paypal-blue.svg)](https://www.paypal.me/skypjack)
> `EnTT` has been a dream so far, we haven't found a single bug to date and it's
> super easy to work with
>
> -- Every EnTT User Ever
`EnTT` is a header-only, tiny and easy to use library for game programming and
much more written in **modern C++**.<br/>
[Among others](https://github.com/skypjack/entt/wiki/EnTT-in-Action), it's used
in [**Minecraft**](https://minecraft.net/en-us/attribution/) by Mojang, the
[**ArcGIS Runtime SDKs**](https://developers.arcgis.com/arcgis-runtime/) by Esri
and the amazing [**Ragdoll**](https://ragdolldynamics.com/).<br/>
If you don't see your project in the list, please open an issue, submit a PR or
add the [#entt](https://github.com/topics/entt) tag to your _topics_! :+1:
---
Do you want to **keep up with changes** or do you have a **question** that
doesn't require you to open an issue?<br/>
Join the [gitter channel](https://gitter.im/skypjack/entt) and the
[discord server](https://discord.gg/5BjPWBd), meet other users like you. The
more we are, the better for everyone.<br/>
Don't forget to check the
[FAQs](https://github.com/skypjack/entt/wiki/Frequently-Asked-Questions) and the
[wiki](https://github.com/skypjack/entt/wiki) too. Your answers may already be
there.
Do you want to support `EnTT`? Consider becoming a
[**sponsor**](https://github.com/users/skypjack/sponsorship).
Many thanks to [these people](https://skypjack.github.io/sponsorship/) and
**special** thanks to:
[![mojang](https://user-images.githubusercontent.com/1812216/106253145-67ca1980-6217-11eb-9c0b-d93561b37098.png)](https://mojang.com)
[![imgly](https://user-images.githubusercontent.com/1812216/106253726-271ed000-6218-11eb-98e0-c9c681925770.png)](https://img.ly/)
# Table of Contents
* [Introduction](#introduction)
* [Code Example](#code-example)
* [Motivation](#motivation)
* [Performance](#performance)
* [Integration](#integration)
* [Requirements](#requirements)
* [CMake](#cmake)
* [Natvis support](#natvis-support)
* [Packaging Tools](#packaging-tools)
* [pkg-config](#pkg-config)
* [Documentation](#documentation)
* [Tests](#tests)
* [EnTT in Action](#entt-in-action)
* [Contributors](#contributors)
* [License](#license)
<!--
@endcond TURN_OFF_DOXYGEN
-->
# Introduction
The entity-component-system (also known as _ECS_) is an architectural pattern
used mostly in game development. For further details:
* [Entity Systems Wiki](http://entity-systems.wikidot.com/)
* [Evolve Your Hierarchy](http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/)
* [ECS on Wikipedia](https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system)
This project started off as a pure entity-component system. Over time the
codebase has grown as more and more classes and functionalities were added.<br/>
Here is a brief, yet incomplete list of what it offers today:
* Built-in **RTTI system** mostly similar to the standard one.
* A `constexpr` utility for human-readable **resource names**.
* Minimal **configuration system** built using the monostate pattern.
* Incredibly fast **entity-component system** with its own _pay for what you
use_ policy, unconstrained component types with optional pointer stability and
hooks for storage customization.
* Views and groups to iterate entities and components and allow different access
patterns, from **perfect SoA** to fully random.
* A lot of **facilities** built on top of the entity-component system to help
the users and avoid reinventing the wheel.
* General purpose **execution graph builder** for optimal scheduling.
* The smallest and most basic implementation of a **service locator** ever seen.
* A built-in, non-intrusive and macro-free runtime **reflection system**.
* **Static polymorphism** made simple and within everyone's reach.
* A few homemade containers, like a sparse set based **hash map**.
* A **cooperative scheduler** for processes of any type.
* All that is needed for **resource management** (cache, loaders, handles).
* Delegates, **signal handlers** and a tiny event dispatcher.
* A general purpose **event emitter** as a CRTP idiom based class template.
* And **much more**! Check out the
[**wiki**](https://github.com/skypjack/entt/wiki).
Consider this list a work in progress as well as the project. The whole API is
fully documented in-code for those who are brave enough to read it.<br/>
Please, do note that all tools are also DLL-friendly now and run smoothly across
boundaries.
One thing known to most is that `EnTT` is also used in **Minecraft**.<br/>
Given that the game is available literally everywhere, I can confidently say
that the library has been sufficiently tested on every platform that can come to
mind.
## Code Example
```cpp
#include <entt/entt.hpp>
struct position {
float x;
float y;
};
struct velocity {
float dx;
float dy;
};
void update(entt::registry &registry) {
auto view = registry.view<const position, velocity>();
// use a callback
view.each([](const auto &pos, auto &vel) { /* ... */ });
// use an extended callback
view.each([](const auto entity, const auto &pos, auto &vel) { /* ... */ });
// use a range-for
for(auto [entity, pos, vel]: view.each()) {
// ...
}
// use forward iterators and get only the components of interest
for(auto entity: view) {
auto &vel = view.get<velocity>(entity);
// ...
}
}
int main() {
entt::registry registry;
for(auto i = 0u; i < 10u; ++i) {
const auto entity = registry.create();
registry.emplace<position>(entity, i * 1.f, i * 1.f);
if(i % 2 == 0) { registry.emplace<velocity>(entity, i * .1f, i * .1f); }
}
update(registry);
}
```
## Motivation
I started developing `EnTT` for the _wrong_ reason: my goal was to design an
entity-component system to beat another well known open source library both in
terms of performance and possibly memory usage.<br/>
In the end, I did it, but it wasn't very satisfying. Actually it wasn't
satisfying at all. The fastest and nothing more, fairly little indeed. When I
realized it, I tried hard to keep intact the great performance of `EnTT` and to
add all the features I wanted to see in *my own library* at the same time.
Nowadays, `EnTT` is finally what I was looking for: still faster than its
_competitors_, lower memory usage in the average case, a really good API and an
amazing set of features. And even more, of course.
## Performance
The proposed entity-component system is incredibly fast to iterate entities and
components, this is a fact. Some compilers make a lot of optimizations because
of how `EnTT` works, some others aren't that good. In general, if we consider
real world cases, `EnTT` is somewhere between a bit and much faster than many of
the other solutions around, although I couldn't check them all for obvious
reasons.
If you are interested, you can compile the `benchmark` test in release mode (to
enable compiler optimizations, otherwise it would make little sense) by setting
the `ENTT_BUILD_BENCHMARK` option of `CMake` to `ON`, then evaluate yourself
whether you're satisfied with the results or not.
Honestly I got tired of updating the README file whenever there is an
improvement.<br/>
There are already a lot of projects out there that use `EnTT` as a basis for
comparison (this should already tell you a lot). Many of these benchmarks are
completely wrong, many others are simply incomplete, good at omitting some
information and using the wrong function to compare a given feature. Certainly
there are also good ones but they age quickly if nobody updates them, especially
when the library they are dealing with is actively developed.
The choice to use `EnTT` should be based on its carefully designed API, its
set of features and the general performance, **not** because some single
benchmark shows it to be the fastest tool available.
In the future I'll likely try to get even better performance while still adding
new features, mainly for fun.<br/>
If you want to contribute and/or have suggestions, feel free to make a PR or
open an issue to discuss your idea.
# Integration
`EnTT` is a header-only library. This means that including the `entt.hpp` header
is enough to include the library as a whole and use it. For those who are
interested only in the entity-component system, consider to include the sole
`entity/registry.hpp` header instead.<br/>
It's a matter of adding the following line to the top of a file:
```cpp
#include <entt/entt.hpp>
```
Use the line below to include only the entity-component system instead:
```cpp
#include <entt/entity/registry.hpp>
```
Then pass the proper `-I` argument to the compiler to add the `src` directory to
the include paths.
## Requirements
To be able to use `EnTT`, users must provide a full-featured compiler that
supports at least C++17.<br/>
The requirements below are mandatory to compile the tests and to extract the
documentation:
* `CMake` version 3.7 or later.
* `Doxygen` version 1.8 or later.
Alternatively, [Bazel](https://bazel.build) is also supported as a build system
(credits to [zaucy](https://github.com/zaucy) who offered to maintain it).<br/>
In the documentation below I'll still refer to `CMake`, this being the official
build system of the library.
## CMake
To use `EnTT` from a `CMake` project, just link an existing target to the
`EnTT::EnTT` alias.<br/>
The library offers everything you need for locating (as in `find_package`),
embedding (as in `add_subdirectory`), fetching (as in `FetchContent`) or using
it in many of the ways that you can think of and that involve `CMake`.<br/>
Covering all possible cases would require a treaty and not a simple README file,
but I'm confident that anyone reading this section also knows what it's about
and can use `EnTT` from a `CMake` project without problems.
## Natvis support
When using `CMake`, just enable the option `ENTT_INCLUDE_NATVIS` and enjoy
it.<br/>
Otherwise, most of the tools are covered via Natvis and all files can be found
in the `natvis` directory, divided by module.<br/>
If you spot errors or have suggestions, any contribution is welcome!
## Packaging Tools
`EnTT` is available for some of the most known packaging tools. In particular:
* [`Conan`](https://github.com/conan-io/conan-center-index), the C/C++ Package
Manager for Developers.
* [`vcpkg`](https://github.com/Microsoft/vcpkg), Microsoft VC++ Packaging
Tool.<br/>
You can download and install `EnTT` in just a few simple steps:
```
$ git clone https://github.com/Microsoft/vcpkg.git
$ cd vcpkg
$ ./bootstrap-vcpkg.sh
$ ./vcpkg integrate install
$ vcpkg install entt
```
Or you can use the `experimental` feature to test the latest changes:
```
vcpkg install entt[experimental] --head
```
The `EnTT` port in `vcpkg` is kept up to date by Microsoft team members and
community contributors.<br/>
If the version is out of date, please
[create an issue or pull request](https://github.com/Microsoft/vcpkg) on the
`vcpkg` repository.
* [`Homebrew`](https://github.com/skypjack/homebrew-entt), the missing package
manager for macOS.<br/>
Available as a homebrew formula. Just type the following to install it:
```
brew install skypjack/entt/entt
```
* [`build2`](https://build2.org), build toolchain for developing and packaging C
and C++ code.<br/>
In order to use the [`entt`](https://cppget.org/entt) package in a `build2`
project, add the following line or a similar one to the `manifest` file:
```
depends: entt ^3.0.0
```
Also check that the configuration refers to a valid repository, so that the
package can be found by `build2`:
* [`cppget.org`](https://cppget.org), the open-source community central
repository, accessible as `https://pkg.cppget.org/1/stable`.
* [Package source repository](https://github.com/build2-packaging/entt):
accessible as either `https://github.com/build2-packaging/entt.git` or
`ssh://git@github.com/build2-packaging/entt.git`.
Feel free to [report issues](https://github.com/build2-packaging/entt) with
this package.
Both can be used with `bpkg add-repo` or added in a project
`repositories.manifest`. See the official
[documentation](https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml#guide-repositories)
for more details.
Consider this list a work in progress and help me to make it longer if you like.
## pkg-config
`EnTT` also supports `pkg-config` (for some definition of _supports_ at least).
A suitable file called `entt.pc` is generated and installed in a proper
directory when running `CMake`.<br/>
This should also make it easier to use with tools such as `Meson` or similar.
# Documentation
The documentation is based on [doxygen](http://www.doxygen.nl/). To build it:
$ cd build
$ cmake .. -DENTT_BUILD_DOCS=ON
$ make
The API reference is created in HTML format in the `build/docs/html` directory.
To navigate it with your favorite browser:
$ cd build
$ your_favorite_browser docs/html/index.html
<!--
@cond TURN_OFF_DOXYGEN
-->
The same version is also available [online](https://skypjack.github.io/entt/)
for the latest release, that is the last stable tag.<br/>
Moreover, there exists a [wiki](https://github.com/skypjack/entt/wiki) dedicated
to the project where users can find all related documentation pages.
<!--
@endcond TURN_OFF_DOXYGEN
-->
# Tests
To compile and run the tests, `EnTT` requires *googletest*.<br/>
`cmake` downloads and compiles the library before compiling anything else. In
order to build the tests, set the `CMake` option `ENTT_BUILD_TESTING` to `ON`.
To build the most basic set of tests:
* `$ cd build`
* `$ cmake -DENTT_BUILD_TESTING=ON ..`
* `$ make`
* `$ make test`
Note that benchmarks are not part of this set.
<!--
@cond TURN_OFF_DOXYGEN
-->
# EnTT in Action
`EnTT` is widely used in private and commercial applications. I cannot even
mention most of them because of some signatures I put on some documents time
ago. Fortunately, there are also people who took the time to implement open
source projects based on `EnTT` and did not hold back when it came to
documenting them.
[Here](https://github.com/skypjack/entt/wiki/EnTT-in-Action) you can find an
incomplete list of games, applications and articles that can be used as a
reference.
If you know of other resources out there that are about `EnTT`, feel free to
open an issue or a PR and I'll be glad to add them to the list.
# Contributors
Requests for features, PRs, suggestions ad feedback are highly appreciated.
If you find you can help and want to contribute to the project with your
experience or you do want to get part of the project for some other reason, feel
free to contact me directly (you can find the mail in the
[profile](https://github.com/skypjack)).<br/>
I can't promise that each and every contribution will be accepted, but I can
assure that I'll do my best to take them all as soon as possible.
If you decide to participate, please see the guidelines for
[contributing](CONTRIBUTING.md) before to create issues or pull
requests.<br/>
Take also a look at the
[contributors list](https://github.com/skypjack/entt/blob/master/AUTHORS) to
know who has participated so far.
<!--
@endcond TURN_OFF_DOXYGEN
-->
# License
Code and documentation Copyright (c) 2017-2023 Michele Caini.<br/>
Colorful logo Copyright (c) 2018-2021 Richard Caseres.
Code released under
[the MIT license](https://github.com/skypjack/entt/blob/master/LICENSE).<br/>
Documentation released under
[CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).<br/>
All logos released under
[CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/).

26
external/entt/entt/TODO vendored Normal file
View File

@ -0,0 +1,26 @@
EXAMPLES
* filter on runtime values/variables (not only types)
* support to polymorphic types (see #859)
DOC:
* custom storage/view
* examples (and credits) from @alanjfs :)
* update entity doc when the storage based model is in place
* in-place O(1) release/destroy for non-orphaned entities, out-of-sync model
TODO (high prio):
* check natvis files (periodically :)
* resource cache: avoid using shared ptr with loader and the others
* further optimize exclusion lists in multi type views (no existence check)
* further improve the snapshot stuff, ie component functions
* use fixture for storage tests to reduce loc number and duplication as much as possible
* basic_view<...>::reach(...)
* doc: bump entities
WIP:
* get rid of observers, storage based views made them pointless - document alternatives
* exploit the tombstone mechanism to allow enabling/disabling entities (see bump, compact and clear for further details)
* process scheduler: reviews, use free lists internally
* deprecate non-owning groups in favor of owning views and view packs, introduce lazy owning views
* bring nested groups back in place (see bd34e7f)
* work stealing job system (see #100) + mt scheduler based on const awareness for types

1
external/entt/entt/WORKSPACE vendored Normal file
View File

@ -0,0 +1 @@
workspace(name = "com_github_skypjack_entt")

2
external/entt/entt/build/.gitignore vendored Normal file
View File

@ -0,0 +1,2 @@
*
!.gitignore

View File

@ -0,0 +1,5 @@
@PACKAGE_INIT@
set(EnTT_VERSION "@PROJECT_VERSION@")
include("${CMAKE_CURRENT_LIST_DIR}/EnTTTargets.cmake")
check_required_components("@PROJECT_NAME@")

View File

@ -0,0 +1,8 @@
prefix=@CMAKE_INSTALL_PREFIX@
includedir=@EnTT_PKGCONFIG_INCLUDEDIR@
Name: EnTT
Description: Gaming meets modern C++
Url: https://github.com/skypjack/entt
Version: @ENTT_VERSION@
Cflags: -I${includedir}

View File

@ -0,0 +1,23 @@
# This module provides function for joining paths
# known from most languages
#
# SPDX-License-Identifier: (MIT OR CC0-1.0)
# Copyright 2020 Jan Tojnar
# https://github.com/jtojnar/cmake-snips
#
# Modelled after Python<6F>s os.path.join
# https://docs.python.org/3.7/library/os.path.html#os.path.join
# Windows not supported
function(join_paths joined_path first_path_segment)
set(temp_path "${first_path_segment}")
foreach(current_segment IN LISTS ARGN)
if(NOT ("${current_segment}" STREQUAL ""))
if(IS_ABSOLUTE "${current_segment}")
set(temp_path "${current_segment}")
else()
set(temp_path "${temp_path}/${current_segment}")
endif()
endif()
endforeach()
set(${joined_path} "${temp_path}" PARENT_SCOPE)
endfunction()

37
external/entt/entt/conan/build.py vendored Normal file
View File

@ -0,0 +1,37 @@
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from cpt.packager import ConanMultiPackager
import os
if __name__ == "__main__":
username = os.getenv("GITHUB_ACTOR")
tag_version = os.getenv("GITHUB_REF")
tag_package = os.getenv("GITHUB_REPOSITORY")
login_username = os.getenv("CONAN_LOGIN_USERNAME")
package_version = tag_version.replace("refs/tags/v", "")
package_name = tag_package.replace("skypjack/", "")
reference = "{}/{}".format(package_name, package_version)
channel = os.getenv("CONAN_CHANNEL", "stable")
upload = os.getenv("CONAN_UPLOAD")
stable_branch_pattern = os.getenv("CONAN_STABLE_BRANCH_PATTERN", r"v\d+\.\d+\.\d+.*")
test_folder = os.getenv("CPT_TEST_FOLDER", os.path.join("conan", "test_package"))
upload_only_when_stable = os.getenv("CONAN_UPLOAD_ONLY_WHEN_STABLE", True)
disable_shared = os.getenv("CONAN_DISABLE_SHARED_BUILD", "False")
builder = ConanMultiPackager(username=username,
reference=reference,
channel=channel,
login_username=login_username,
upload=upload,
stable_branch_pattern=stable_branch_pattern,
upload_only_when_stable=upload_only_when_stable,
test_folder=test_folder)
builder.add()
filtered_builds = []
for settings, options, env_vars, build_requires, reference in builder.items:
if disable_shared == "False" or not options["{}:shared".format(package_name)]:
filtered_builds.append([settings, options, env_vars, build_requires])
builder.builds = filtered_builds
builder.run()

7
external/entt/entt/conan/ci/build.sh vendored Normal file
View File

@ -0,0 +1,7 @@
#!/bin/bash
set -e
set -x
conan user
python conan/build.py

View File

@ -0,0 +1,6 @@
#!/bin/bash
set -e
set -x
pip install -U conan_package_tools conan

View File

@ -0,0 +1,13 @@
cmake_minimum_required(VERSION 3.7.2)
project(test_package)
set(CMAKE_VERBOSE_MAKEFILE TRUE)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()
add_executable(${PROJECT_NAME} test_package.cpp)
target_link_libraries(${PROJECT_NAME} ${CONAN_LIBS})

View File

@ -0,0 +1,19 @@
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from conans import ConanFile, CMake
import os
class TestPackageConan(ConanFile):
settings = "os", "compiler", "build_type", "arch"
generators = "cmake"
def build(self):
cmake = CMake(self)
cmake.configure()
cmake.build()
def test(self):
bin_path = os.path.join("bin", "test_package")
self.run(bin_path, run_environment=True)

View File

@ -0,0 +1,56 @@
#include <entt/entt.hpp>
#include <cstdint>
struct position {
float x;
float y;
};
struct velocity {
float dx;
float dy;
};
void update(entt::registry &registry) {
auto view = registry.view<position, velocity>();
for(auto entity: view) {
// gets only the components that are going to be used ...
auto &vel = view.get<velocity>(entity);
vel.dx = 0.;
vel.dy = 0.;
// ...
}
}
void update(std::uint64_t dt, entt::registry &registry) {
registry.view<position, velocity>().each([dt](auto &pos, auto &vel) {
// gets all the components of the view at once ...
pos.x += vel.dx * dt;
pos.y += vel.dy * dt;
// ...
});
}
int main() {
entt::registry registry;
std::uint64_t dt = 16;
for(auto i = 0; i < 10; ++i) {
auto entity = registry.create();
registry.emplace<position>(entity, i * 1.f, i * 1.f);
if(i % 2 == 0) { registry.emplace<velocity>(entity, i * .1f, i * .1f); }
}
update(dt, registry);
update(registry);
// ...
return EXIT_SUCCESS;
}

27
external/entt/entt/conanfile.py vendored Normal file
View File

@ -0,0 +1,27 @@
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from conans import ConanFile
class EnttConan(ConanFile):
name = "entt"
description = "Gaming meets modern C++ - a fast and reliable entity-component system (ECS) and much more "
topics = ("conan," "entt", "gaming", "entity", "ecs")
url = "https://github.com/skypjack/entt"
homepage = url
author = "Michele Caini <michele.caini@gmail.com>"
license = "MIT"
exports = ["LICENSE"]
exports_sources = ["src/*"]
no_copy_source = True
def package(self):
self.copy(pattern="LICENSE", dst="licenses")
self.copy(pattern="*", dst="include", src="src", keep_path=True)
def package_info(self):
if not self.in_local_cache:
self.cpp_info.includedirs = ["src"]
def package_id(self):
self.info.header_only()

54
external/entt/entt/docs/CMakeLists.txt vendored Normal file
View File

@ -0,0 +1,54 @@
#
# Doxygen configuration (documentation)
#
FetchContent_Declare(
doxygen-awesome-css
GIT_REPOSITORY https://github.com/jothepro/doxygen-awesome-css
GIT_TAG main
GIT_SHALLOW 1
)
FetchContent_GetProperties(doxygen-awesome-css)
if(NOT doxygen-awesome-css_POPULATED)
FetchContent_Populate(doxygen-awesome-css)
set(doxygen-awesome-css_INCLUDE_DIR ${doxygen-awesome-css_SOURCE_DIR})
endif()
set(DOXY_SOURCE_DIRECTORY ${EnTT_SOURCE_DIR}/src)
set(DOXY_CSS_DIRECTORY ${doxygen-awesome-css_INCLUDE_DIR})
set(DOXY_DOCS_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
set(DOXY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
configure_file(doxy.in doxy.cfg @ONLY)
add_custom_target(
docs ALL
COMMAND ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/doxy.cfg
WORKING_DIRECTORY ${EnTT_SOURCE_DIR}
VERBATIM
SOURCES
dox/extra.dox
md/config.md
md/container.md
md/core.md
md/entity.md
md/faq.md
md/lib.md
md/links.md
md/locator.md
md/meta.md
md/poly.md
md/process.md
md/reference.md
md/resource.md
md/signal.md
md/unreal.md
doxy.in
)
install(
DIRECTORY ${DOXY_OUTPUT_DIRECTORY}/html
DESTINATION share/${PROJECT_NAME}-${PROJECT_VERSION}/
)

5
external/entt/entt/docs/dox/extra.dox vendored Normal file
View File

@ -0,0 +1,5 @@
/**
* @namespace entt
*
* @brief `EnTT` default namespace.
*/

2726
external/entt/entt/docs/doxy.in vendored Normal file

File diff suppressed because it is too large Load Diff

120
external/entt/entt/docs/md/config.md vendored Normal file
View File

@ -0,0 +1,120 @@
# Crash Course: configuration
<!--
@cond TURN_OFF_DOXYGEN
-->
# Table of Contents
* [Introduction](#introduction)
* [Definitions](#definitions)
* [ENTT_NOEXCEPTION](#entt_noexception)
* [ENTT_USE_ATOMIC](#entt_use_atomic)
* [ENTT_ID_TYPE](#entt_id_type)
* [ENTT_SPARSE_PAGE](#entt_sparse_page)
* [ENTT_PACKED_PAGE](#entt_packed_page)
* [ENTT_ASSERT](#entt_assert)
* [ENTT_ASSERT_CONSTEXPR](#entt_assert_constexpr)
* [ENTT_DISABLE_ASSERT](#entt_disable_assert)
* [ENTT_NO_ETO](#entt_no_eto)
* [ENTT_STANDARD_CPP](#entt_standard_cpp)
<!--
@endcond TURN_OFF_DOXYGEN
-->
# Introduction
`EnTT` has become almost completely customizable over time, in many
respects. These variables are just one of the many ways to customize how it
works.<br/>
In the vast majority of cases, users will have no interest in changing the
default parameters. For all other cases, the list of possible configurations
with which it's possible to adjust the behavior of the library at runtime can be
found below.
# Definitions
All options are intended as parameters to the compiler (or user-defined macros
within the compilation units, if preferred).<br/>
Each parameter can result in internal library definitions. It's not recommended
to try to also modify these definitions, since there is no guarantee that they
will remain stable over time unlike the options below.
## ENTT_NOEXCEPTION
Define this variable without assigning any value to it to turn off exception
handling in `EnTT`.<br/>
This is roughly equivalent to setting the compiler flag `-fno-exceptions` but is
also limited to this library only.
## ENTT_USE_ATOMIC
In general, `EnTT` doesn't offer primitives to support multi-threading. Many of
the features can be split over multiple threads without any explicit control and
the user is the one who knows if a synchronization point is required.<br/>
However, some features aren't easily accessible to users and are made
thread-safe by means of this definition.
## ENTT_ID_TYPE
`entt::id_type` is directly controlled by this definition and widely used within
the library.<br/>
By default, its type is `std::uint32_t`. However, users can define a different
default type if necessary.
## ENTT_SPARSE_PAGE
It's known that the ECS module of `EnTT` is based on _sparse sets_. What is less
known perhaps is that the sparse arrays are paged to reduce memory usage.<br/>
Default size of pages (that is, the number of elements they contain) is 4096 but
users can adjust it if appropriate. In all case, the chosen value **must** be a
power of 2.
## ENTT_PACKED_PAGE
As it happens with sparse arrays, packed arrays are also paginated. However, in
this case the aim isn't to reduce memory usage but to have pointer stability
upon component creation.<br/>
Default size of pages (that is, the number of elements they contain) is 1024 but
users can adjust it if appropriate. In all case, the chosen value **must** be a
power of 2.
## ENTT_ASSERT
For performance reasons, `EnTT` doesn't use exceptions or any other control
structures. In fact, it offers many features that result in undefined behavior
if not used correctly.<br/>
To get around this, the library relies on a lot of asserts for the purpose of
detecting errors in debug builds. By default, it uses `assert` internally. Users
are allowed to overwrite its behavior by setting this variable.
### ENTT_ASSERT_CONSTEXPR
Usually, an assert within a `constexpr` function isn't a big deal. However, in
case of extreme customizations, it might be useful to differentiate.<br/>
For this purpose, `EnTT` introduces an admittedly badly named variable to make
the job easier in this regard. By default, this variable forwards its arguments
to `ENTT_ASSERT`.
### ENTT_DISABLE_ASSERT
Assertions may in turn affect performance to an extent when enabled. Whether
`ENTT_ASSERT` and `ENTT_ASSERT_CONSTEXPR` are redefined or not, all asserts can
be disabled at once by means of this definition.<br/>
Note that `ENTT_DISABLE_ASSERT` takes precedence over the redefinition of the
other variables and is therefore meant to disable all controls no matter what.
## ENTT_NO_ETO
In order to reduce memory consumption and increase performance, empty types are
never instantiated nor stored by the ECS module of `EnTT`.<br/>
Use this variable to treat these types like all others and therefore to create a
dedicated storage for them.
## ENTT_STANDARD_CPP
`EnTT` mixes non-standard language features with others that are perfectly
compliant to offer some of its functionalities.<br/>
This definition prevents the library from using non-standard techniques, that
is, functionalities that aren't fully compliant with the standard C++.<br/>
While there are no known portability issues at the time of this writing, this
should make the library fully portable anyway if needed.

66
external/entt/entt/docs/md/container.md vendored Normal file
View File

@ -0,0 +1,66 @@
# Crash Course: containers
<!--
@cond TURN_OFF_DOXYGEN
-->
# Table of Contents
* [Introduction](#introduction)
* [Containers](#containers)
* [Dense map](#dense-map)
* [Dense set](#dense-set)
<!--
@endcond TURN_OFF_DOXYGEN
-->
# Introduction
The standard C++ library offers a wide range of containers and it's really
difficult to do better (although it's very easy to do worse, as many examples
available online demonstrate).<br/>
`EnTT` doesn't try in any way to replace what is offered by the standard. Quite
the opposite, given the widespread use that is made of standard containers.<br/>
However, the library also tries to fill a gap in features and functionalities by
making available some containers initially developed for internal use.
This section of the library is likely to grow larger over time. However, for the
moment it's quite small and mainly aimed at satisfying some internal needs.<br/>
For all containers made available, full test coverage and stability over time is
guaranteed as usual.
# Containers
## Dense map
The dense map made available in `EnTT` is a hash map that aims to return a
packed array of elements, so as to reduce the number of jumps in memory during
iterations.<br/>
The implementation is based on _sparse sets_ and each bucket is identified by an
implicit list within the packed array itself.
The interface is very close to its counterpart in the standard library, that is,
the `std::unordered_map` class.<br/>
However, both local and non-local iterators returned by a dense map belong to
the input iterator category although they respectively model the concepts of a
_forward iterator_ type and a _random access iterator_ type.<br/>
This is because they return a pair of references rather than a reference to a
pair. In other words, dense maps return a so called _proxy iterator_ the value
type of which is:
* `std::pair<const Key &, Type &>` for non-const iterator types.
* `std::pair<const Key &, const Type &>` for const iterator types.
This is quite different from what any standard library map returns and should be
taken into account when looking for a drop-in replacement.
## Dense set
The dense set made available in `EnTT` is a hash set that aims to return a
packed array of elements, so as to reduce the number of jumps in memory during
iterations.<br/>
The implementation is based on _sparse sets_ and each bucket is identified by an
implicit list within the packed array itself.
The interface is in all respects similar to its counterpart in the standard
library, that is, the `std::unordered_set` class.<br/>
Therefore, there is no need to go into the API description.

986
external/entt/entt/docs/md/core.md vendored Normal file
View File

@ -0,0 +1,986 @@
# Crash Course: core functionalities
<!--
@cond TURN_OFF_DOXYGEN
-->
# Table of Contents
* [Introduction](#introduction)
* [Any as in any type](#any-as-in-any-type)
* [Small buffer optimization](#small-buffer-optimization)
* [Alignment requirement](#alignment-requirement)
* [Compressed pair](#compressed-pair)
* [Enum as bitmask](#enum-as-bitmask)
* [Hashed strings](#hashed-strings)
* [Wide characters](wide-characters)
* [Conflicts](#conflicts)
* [Iterators](#iterators)
* [Input iterator pointer](#input-iterator-pointer)
* [Iota iterator](#iota-iterator)
* [Iterable adaptor](#iterable-adaptor)
* [Memory](#memory)
* [Power of two and fast modulus](#power-of-two-and-fast-modulus)
* [Allocator aware unique pointers](#allocator-aware-unique-pointers)
* [Monostate](#monostate)
* [Type support](#type-support)
* [Built-in RTTI support](#built-in-rtti-support)
* [Type info](#type-info)
* [Almost unique identifiers](#almost-unique-identifiers)
* [Type traits](#type-traits)
* [Size of](#size-of)
* [Is applicable](#is-applicable)
* [Constness as](#constness-as)
* [Member class type](#member-class-type)
* [N-th argument](#n-th-argument)
* [Integral constant](#integral-constant)
* [Tag](#tag)
* [Type list and value list](#type-list-and-value-list)
* [Unique sequential identifiers](#unique-sequential-identifiers)
* [Compile-time generator](#compile-time-generator)
* [Runtime generator](#runtime-generator)
* [Utilities](#utilities)
<!--
@endcond TURN_OFF_DOXYGEN
-->
# Introduction
`EnTT` comes with a bunch of core functionalities mostly used by the other parts
of the library.<br/>
Many of these tools are also useful in everyday work. Therefore, it's worth
describing them so as not to reinvent the wheel in case of need.
# Any as in any type
`EnTT` offers its own `any` type. It may seem redundant considering that C++17
introduced `std::any`, but it is not (hopefully).<br/>
First of all, the _type_ returned by an `std::any` is a const reference to an
`std::type_info`, an implementation defined class that's not something everyone
wants to see in a software. Furthermore, there is no way to bind it to the type
system of the library and therefore with its integrated RTTI support.
The `any` API is very similar to that of its most famous counterpart, mainly
because this class serves the same purpose of being an opaque container for any
type of value.<br/>
Instances also minimize the number of allocations by relying on a well known
technique called _small buffer optimization_ and a fake vtable.
Creating an object of the `any` type, whether empty or not, is trivial:
```cpp
// an empty container
entt::any empty{};
// a container for an int
entt::any any{0};
// in place construction
entt::any in_place{std::in_place_type<int>, 42};
```
Alternatively, the `make_any` function serves the same purpose but requires to
always be explicit about the type:
```cpp
entt::any any = entt::make_any<int>(42);
```
In both cases, the `any` class takes the burden of destroying the contained
element when required, regardless of the storage strategy used for the specific
object.<br/>
Furthermore, an instance of `any` isn't tied to an actual type. Therefore, the
wrapper is reconfigured when it's assigned a new object of a type other than
the one it contains.
There is also a way to directly assign a value to the variable contained by an
`entt::any`, without necessarily replacing it. This is especially useful when
the object is used in _aliasing mode_, as described below:
```cpp
entt::any any{42};
entt::any value{3};
// assigns by copy
any.assign(value);
// assigns by move
any.assign(std::move(value));
```
The `any` class performs a check on the type information and whether or not the
original type was copy or move assignable, as appropriate.<br/>
In all cases, the `assign` function returns a boolean value that is true in case
of success and false otherwise.
When in doubt about the type of object contained, the `type` member function
returns a const reference to the `type_info` associated with its element, or
`type_id<void>()` if the container is empty.<br/>
The type is also used internally when comparing two `any` objects:
```cpp
if(any == empty) { /* ... */ }
```
In this case, before proceeding with a comparison, it's verified that the _type_
of the two objects is actually the same.<br/>
Refer to the `EnTT` type system documentation for more details about how
`type_info` works and the possible risks of a comparison.
A particularly interesting feature of this class is that it can also be used as
an opaque container for const and non-const references:
```cpp
int value = 42;
entt::any any{std::in_place_type<int &>(value)};
entt::any cany = entt::make_any<const int &>(value);
entt::any fwd = entt::forward_as_any(value);
any.emplace<const int &>(value);
```
In other words, whenever `any` is explicitly told to construct an _alias_, it
acts as a pointer to the original instance rather than making a copy of it or
moving it internally. The contained object is never destroyed and users must
ensure that its lifetime exceeds that of the container.<br/>
Similarly, it's possible to create non-owning copies of `any` from an existing
object:
```cpp
// aliasing constructor
entt::any ref = other.as_ref();
```
In this case, it doesn't matter if the original container actually holds an
object or is as a reference for unmanaged elements already. The new instance
thus created doesn't create copies and only serves as a reference for the
original item.
It's worth mentioning that, while everything works transparently when it comes
to non-const references, there are some exceptions when it comes to const
references.<br/>
In particular, the `data` member function invoked on a non-const instance of
`any` that wraps a const reference returns a null pointer in all cases.
To cast an instance of `any` to a type, the library offers a set of `any_cast`
functions in all respects similar to their most famous counterparts.<br/>
The only difference is that, in the case of `EnTT`, they won't raise exceptions
but will only trigger an assert in debug mode, otherwise resulting in undefined
behavior in case of misuse in release mode.
## Small buffer optimization
The `any` class uses a technique called _small buffer optimization_ to reduce
the number of allocations where possible.<br/>
The default reserved size for an instance of `any` is `sizeof(double[2])`.
However, this is also configurable if needed. In fact, `any` is defined as an
alias for `basic_any<Len>`, where `Len` is the size above.<br/>
Users can easily set a custom size or define their own aliases:
```cpp
using my_any = entt::basic_any<sizeof(double[4])>;
```
This feature, in addition to allowing the choice of a size that best suits the
needs of an application, also offers the possibility of forcing dynamic creation
of objects during construction.<br/>
In other terms, if the size is 0, `any` suppresses the small buffer optimization
and always dynamically allocates objects (except for aliasing cases).
## Alignment requirement
The alignment requirement is optional and by default the most stringent (the
largest) for any object whose size is at most equal to the one provided.<br/>
It's provided as an optional second parameter following the desired size for the
internal storage:
```cpp
using my_any = entt::basic_any<sizeof(double[4]), alignof(double[4])>;
```
The `basic_any` class template inspects the alignment requirements in each case,
even when not provided and may decide not to use the small buffer optimization
in order to meet them.
# Compressed pair
Primarily designed for internal use and far from being feature complete, the
`compressed_pair` class does exactly what it promises: it tries to reduce the
size of a pair by exploiting _Empty Base Class Optimization_ (or _EBCO_).<br/>
This class **is not** a drop-in replacement for `std::pair`. However, it offers
enough functionalities to be a good alternative for when reducing memory usage
is more important than having some cool and probably useless feature.
Although the API is very close to that of `std::pair` (apart from the fact that
the template parameters are inferred from the constructor and therefore there is
no `entt::make_compressed_pair`), the major difference is that `first` and
`second` are functions for implementation requirements:
```cpp
entt::compressed_pair pair{0, 3.};
pair.first() = 42;
```
There isn't much to describe then. It's recommended to rely on documentation and
intuition. At the end of the day, it's just a pair and nothing more.
# Enum as bitmask
Sometimes it's useful to be able to use enums as bitmasks. However, enum classes
aren't really suitable for the purpose. Main problem is that they don't convert
implicitly to their underlying type.<br/>
The choice is then between using old-fashioned enums (with all their problems
that I don't want to discuss here) or writing _ugly_ code.
Fortunately, there is also a third way: adding enough operators in the global
scope to treat enum classes as bitmasks transparently.<br/>
The ultimate goal is to write code like the following (or maybe something more
meaningful, but this should give a grasp and remain simple at the same time):
```cpp
enum class my_flag {
unknown = 0x01,
enabled = 0x02,
disabled = 0x04
};
const my_flag flags = my_flag::enabled;
const bool is_enabled = !!(flags & my_flag::enabled);
```
The problem with adding all operators to the global scope is that these come
into play even when not required, with the risk of introducing errors that are
difficult to deal with.<br/>
However, C++ offers enough tools to get around this problem. In particular, the
library requires users to register the enum classes for which bitmask support
should be enabled:
```cpp
template<>
struct entt::enum_as_bitmask<my_flag>
: std::true_type
{};
```
This is handy when dealing with enum classes defined by third party libraries
and over which the user has no control. However, it's also verbose and can be
avoided by adding a specific value to the enum class itself:
```cpp
enum class my_flag {
unknown = 0x01,
enabled = 0x02,
disabled = 0x04,
_entt_enum_as_bitmask
};
```
In this case, there is no need to specialize the `enum_as_bitmask` traits, since
`EnTT` automatically detects the flag and enables the bitmask support.<br/>
Once the enum class is registered (in one way or the other), the most common
operators such as `&`, `|` but also `&=` and `|=` are available for use.
Refer to the official documentation for the full list of operators.
# Hashed strings
Hashed strings are human-readable identifiers in the codebase that turn into
numeric values at runtime, thus without affecting performance.<br/>
The class has an implicit `constexpr` constructor that chews a bunch of
characters. Once created, one can get the original string by means of the `data`
member function or convert the instance into a number.<br/>
A hashed string is well suited wherever a constant expression is required. No
_string-to-number_ conversion will take place at runtime if used carefully.
Example of use:
```cpp
auto load(entt::hashed_string::hash_type resource) {
// uses the numeric representation of the resource to load and return it
}
auto resource = load(entt::hashed_string{"gui/background"});
```
There is also a _user defined literal_ dedicated to hashed strings to make them
more _user-friendly_:
```cpp
using namespace entt::literals;
constexpr auto str = "text"_hs;
```
User defined literals in `EnTT` are enclosed in the `entt::literals` namespace.
Therefore, the entire namespace or selectively the literal of interest must be
explicitly included before each use, a bit like `std::literals`.<br/>
The class also offers the necessary functionalities to create hashed strings at
runtime:
```cpp
std::string orig{"text"};
// create a full-featured hashed string...
entt::hashed_string str{orig.c_str()};
// ... or compute only the unique identifier
const auto hash = entt::hashed_string::value(orig.c_str());
```
This possibility shouldn't be exploited in tight loops, since the computation
takes place at runtime and no longer at compile-time. It could therefore affect
performance to some degrees.
## Wide characters
The `hashed_string` class is an alias for `basic_hashed_string<char>`. To use
the C++ type for wide character representations, there exists also the alias
`hashed_wstring` for `basic_hashed_string<wchar_t>`.<br/>
In this case, the user defined literal to use to create hashed strings on the
fly is `_hws`:
```cpp
constexpr auto str = L"text"_hws;
```
The hash type of `hashed_wstring` is the same as its counterpart.
## Conflicts
The hashed string class uses FNV-1a internally to hash strings. Because of the
_pigeonhole principle_, conflicts are possible. This is a fact.<br/>
There is no silver bullet to solve the problem of conflicts when dealing with
hashing functions. In this case, the best solution is likely to give up. That's
all.<br/>
After all, human-readable unique identifiers aren't something strictly defined
and over which users have not the control. Choosing a slightly different
identifier is probably the best solution to make the conflict disappear in this
case.
# Iterators
Writing and working with iterators isn't always easy. More often than not it
also leads to duplicated code.<br/>
`EnTT` tries to overcome this problem by offering some utilities designed to
make this hard work easier.
## Input iterator pointer
When writing an input iterator that returns in-place constructed values if
dereferenced, it's not always straightforward to figure out what `value_type` is
and how to make it behave like a full-fledged pointer.<br/>
Conversely, it would be very useful to have an `operator->` available on the
iterator itself that always works without too much complexity.
The input iterator pointer is meant for this. It's a small class that wraps the
in-place constructed value and adds some functions on top of it to make it
suitable for use with input iterators:
```cpp
struct iterator_type {
using value_type = std::pair<first_type, second_type>;
using pointer = input_iterator_pointer<value_type>;
using reference = value_type;
using difference_type = std::ptrdiff_t;
using iterator_category = std::input_iterator_tag;
// ...
}
```
The library makes extensive use of this class internally. In many cases, the
`value_type` of the returned iterators is just an input iterator pointer.
## Iota iterator
Waiting for C++20, this iterator accepts an integral value and returns all
elements in a certain range:
```cpp
entt::iota_iterator first{0};
entt::iota_iterator last{100};
for(; first != last; ++first) {
int value = *first;
// ...
}
```
In the future, views will replace this class. Meanwhile, the library makes some
interesting uses of it when a range of integral values is to be returned to the
user.
## Iterable adaptor
Typically, a container class provides `begin` and `end` member functions (with
their const counterparts) for iteration.<br/>
However, it can happen that a class offers multiple iteration methods or allows
users to iterate different sets of _elements_.
The iterable adaptor is a utility class that makes it easier to use and access
data in this case.<br/>
It accepts a couple of iterators (or an iterator and a sentinel) and offers an
_iterable_ object with all the expected methods like `begin`, `end` and whatnot.
The library uses this class extensively.<br/>
Think for example of views, which can be iterated to access entities but also
offer a method of obtaining an iterable object that returns tuples of entities
and components at once.<br/>
Another example is the registry class which allows users to iterate its storage
by returning an iterable object for the purpose.
# Memory
There are a handful of tools within `EnTT` to interact with memory in one way or
another.<br/>
Some are geared towards simplifying the implementation of (internal or external)
allocator aware containers. Others are designed to help the developer with
everyday problems.
The former are very specific and for niche problems. These are tools designed to
unwrap fancy or plain pointers (`to_address`) or to help forget the meaning of
acronyms like _POCCA_, _POCMA_ or _POCS_.<br/>
I won't describe them here in detail. Instead, I recommend reading the inline
documentation to those interested in the subject.
## Power of two and fast modulus
Finding out if a number is a power of two (`is_power_of_two`) or what the next
power of two is given a random value (`next_power_of_two`) is very useful at
times.<br/>
For example, it helps to allocate memory in pages having a size suitable for the
fast modulus:
```cpp
const std::size_t result = entt::fast_mod(value, modulus);
```
Where `modulus` is necessarily a power of two. Perhaps not everyone knows that
this type of operation is far superior in terms of performance to the basic
modulus and for this reason preferred in many areas.
## Allocator aware unique pointers
A nasty thing in C++ (at least up to C++20) is the fact that shared pointers
support allocators while unique pointers don't.<br/>
There is a proposal at the moment that also shows (among the other things) how
this can be implemented without any compiler support.
The `allocate_unique` function follows this proposal, making a virtue out of
necessity:
```cpp
std::unique_ptr<my_type, entt::allocation_deleter<my_type>> ptr = entt::allocate_unique<my_type>(allocator, arguments);
```
Although the internal implementation is slightly different from what is proposed
for the standard, this function offers an API that is a drop-in replacement for
the same feature.
# Monostate
The monostate pattern is often presented as an alternative to a singleton based
configuration system.<br/>
This is exactly its purpose in `EnTT`. Moreover, this implementation is thread
safe by design (hopefully).
Keys are integral values (easily obtained by hashed strings), values are basic
types like `int`s or `bool`s. Values of different types can be associated with
each key, even more than one at a time.<br/>
Because of this, one should pay attention to use the same type both during an
assignment and when trying to read back the data. Otherwise, there is the risk
to incur in unexpected results.
Example of use:
```cpp
entt::monostate<entt::hashed_string{"mykey"}>{} = true;
entt::monostate<"mykey"_hs>{} = 42;
// ...
const bool b = entt::monostate<"mykey"_hs>{};
const int i = entt::monostate<entt::hashed_string{"mykey"}>{};
```
# Type support
`EnTT` provides some basic information about types of all kinds.<br/>
It also offers additional features that are not yet available in the standard
library or that will never be.
## Built-in RTTI support
Runtime type identification support (or RTTI) is one of the most frequently
disabled features in the C++ world, especially in the gaming sector. Regardless
of the reasons for this, it's often a shame not to be able to rely on opaque
type information at runtime.<br/>
The library tries to fill this gap by offering a built-in system that doesn't
serve as a replacement but comes very close to being one and offers similar
information to that provided by its counterpart.
Basically, the whole system relies on a handful of classes. In particular:
* The unique sequential identifier associated with a given type:
```cpp
auto index = entt::type_index<a_type>::value();
```
The returned value isn't guaranteed to be stable across different runs.<br/>
However, it can be very useful as index in associative and unordered
associative containers or for positional accesses in a vector or an array.
An external generator can also be used if needed. In fact, `type_index` can be
specialized by type and is also _sfinae-friendly_ in order to allow more
refined specializations such as:
```cpp
template<typename Type>
struct entt::type_index<Type, std::void_d<decltype(Type::index())>> {
static entt::id_type value() noexcept {
return Type::index();
}
};
```
Indexes **must** be sequentially generated in this case.<br/>
The tool is widely used within `EnTT`. Generating indices not sequentially
would break an assumption and would likely lead to undesired behaviors.
* The hash value associated with a given type:
```cpp
auto hash = entt::type_hash<a_type>::value();
```
In general, the `value` function exposed by `type_hash` is also `constexpr`
but this isn't guaranteed for all compilers and platforms (although it's valid
with the most well-known and popular ones).
This function **can** use non-standard features of the language for its own
purposes. This makes it possible to provide compile-time identifiers that
remain stable across different runs.<br/>
Users can prevent the library from using these features by means of the
`ENTT_STANDARD_CPP` definition. In this case, there is no guarantee that
identifiers remain stable across executions. Moreover, they are generated
at runtime and are no longer a compile-time thing.
As it happens with `type_index`, also `type_hash` is a _sfinae-friendly_ class
that can be specialized in order to customize its behavior globally or on a
per-type or per-traits basis.
* The name associated with a given type:
```cpp
auto name = entt::type_name<a_type>::value();
```
This value is extracted from some information generally made available by the
compiler in use. Therefore, it may differ depending on the compiler and may be
empty in the event that this information isn't available.<br/>
For example, given the following class:
```cpp
struct my_type { /* ... */ };
```
The name is `my_type` when compiled with GCC or CLang and `struct my_type`
when MSVC is in use.<br/>
Most of the time the name is also retrieved at compile-time and is therefore
always returned through an `std::string_view`. Users can easily access it and
modify it as needed, for example by removing the word `struct` to normalize
the result. `EnTT` doesn't do this for obvious reasons, since it would be
creating a new string at runtime otherwise.
This function **can** use non-standard features of the language for its own
purposes. Users can prevent the library from using these features by means of
the `ENTT_STANDARD_CPP` definition. In this case, the name is just empty.
As it happens with `type_index`, also `type_name` is a _sfinae-friendly_ class
that can be specialized in order to customize its behavior globally or on a
per-type or per-traits basis.
These are then combined into utilities that aim to offer an API that is somewhat
similar to that made available by the standard library.
### Type info
The `type_info` class isn't a drop-in replacement for `std::type_info` but can
provide similar information which are not implementation defined and don't
require to enable RTTI.<br/>
Therefore, they can sometimes be even more reliable than those obtained
otherwise.
Its type defines an opaque class that is also copyable and movable.<br/>
Objects of this type are generally returned by the `type_id` functions:
```cpp
// by type
auto info = entt::type_id<a_type>();
// by value
auto other = entt::type_id(42);
```
All elements thus received are nothing more than const references to instances
of `type_info` with static storage duration.<br/>
This is convenient for saving the entire object aside for the cost of a pointer.
However, nothing prevents from constructing `type_info` objects directly:
```cpp
entt::type_info info{std::in_place_type<int>};
```
These are the information made available by `type_info`:
* The index associated with a given type:
```cpp
auto idx = entt::type_id<a_type>().index();
```
This is also an alias for the following:
```cpp
auto idx = entt::type_index<std::remove_cv_t<std::remove_reference_t<a_type>>>::value();
```
* The hash value associated with a given type:
```cpp
auto hash = entt::type_id<a_type>().hash();
```
This is also an alias for the following:
```cpp
auto hash = entt::type_hash<std::remove_cv_t<std::remove_reference_t<a_type>>>::value();
```
* The name associated with a given type:
```cpp
auto name = entt::type_id<my_type>().name();
```
This is also an alias for the following:
```cpp
auto name = entt::type_name<std::remove_cv_t<std::remove_reference_t<a_type>>>::value();
```
Where all accessed features are available at compile-time, the `type_info` class
is also fully `constexpr`. However, this cannot be guaranteed in advance and
depends mainly on the compiler in use and any specializations of the classes
described above.
### Almost unique identifiers
Since the default non-standard, compile-time implementation of `type_hash` makes
use of hashed strings, it may happen that two types are assigned the same hash
value.<br/>
In fact, although this is quite rare, it's not entirely excluded.
Another case where two types are assigned the same identifier is when classes
from different contexts (for example two or more libraries loaded at runtime)
have the same fully qualified name. In this case, `type_name` returns the same
value for the two types.<br/>
Fortunately, there are several easy ways to deal with this:
* The most trivial one is to define the `ENTT_STANDARD_CPP` macro. Runtime
identifiers don't suffer from the same problem in fact. However, this solution
doesn't work well with a plugin system, where the libraries aren't linked.
* Another possibility is to specialize the `type_name` class for one of the
conflicting types, in order to assign it a custom identifier. This is probably
the easiest solution that also preserves the feature of the tool.
* A fully customized identifier generation policy (based for example on enum
classes or preprocessing steps) may represent yet another option.
These are just some examples of possible approaches to the problem but there are
many others. As already mentioned above, since users have full control over
their types, this problem is in any case easy to solve and should not worry too
much.<br/>
In all likelihood, it will never happen to run into a conflict anyway.
## Type traits
A handful of utilities and traits not present in the standard template library
but which can be useful in everyday life.<br/>
This list **is not** exhaustive and contains only some of the most useful
classes. Refer to the inline documentation for more information on the features
offered by this module.
### Size of
The standard operator `sizeof` complains if users provide it with functions or
incomplete types. On the other hand, it's guaranteed that its result is always
non-zero, even if applied to an empty class type.<br/>
This small class combines the two and offers an alternative to `sizeof` that
works under all circumstances, returning zero if the type isn't supported:
```cpp
const auto size = entt::size_of_v<void>;
```
### Is applicable
The standard library offers the great `std::is_invocable` trait in several
forms. This takes a function type and a series of arguments and returns true if
the condition is satisfied.<br/>
Moreover, users are also provided with `std::apply`, a tool for combining
invocable elements and tuples of arguments.
It would therefore be a good idea to have a variant of `std::is_invocable` that
also accepts its arguments in the form of a tuple-like type, so as to complete
the offer:
```cpp
constexpr bool result = entt::is_applicable<Func, std::tuple<a_type, another_type>>;
```
This trait is built on top of `std::is_invocable` and does nothing but unpack a
tuple-like type and simplify the code at the call site.
### Constness as
A utility to easily transfer the constness of a type to another type:
```cpp
// type is const dst_type because of the constness of src_type
using type = entt::constness_as_t<dst_type, const src_type>;
```
The trait is subject to the rules of the language. For example, _transferring_
constness between references won't give the desired effect.
### Member class type
The `auto` template parameter introduced with C++17 made it possible to simplify
many class templates and template functions but also made the class type opaque
when members are passed as template arguments.<br/>
The purpose of this utility is to extract the class type in a few lines of code:
```cpp
template<typename Member>
using clazz = entt::member_class_t<Member>;
```
### N-th argument
A utility to quickly find the n-th argument of a function, member function or
data member (for blind operations on opaque types):
```cpp
using type = entt::nth_argument_t<1u, &clazz::member>;
```
Disambiguation of overloaded functions is the responsibility of the user, should
it be needed.
### Integral constant
Since `std::integral_constant` may be annoying because of its form that requires
to specify both a type and a value of that type, there is a more user-friendly
shortcut for the creation of integral constants.<br/>
This shortcut is the alias template `entt::integral_constant`:
```cpp
constexpr auto constant = entt::integral_constant<42>;
```
Among the other uses, when combined with a hashed string it helps to define tags
as human-readable _names_ where actual types would be required otherwise:
```cpp
constexpr auto enemy_tag = entt::integral_constant<"enemy"_hs>;
registry.emplace<enemy_tag>(entity);
```
### Tag
Type `id_type` is very important and widely used in `EnTT`. Therefore, there is
a more user-friendly shortcut for the creation of constants based on it.<br/>
This shortcut is the alias template `entt::tag`.
If used in combination with hashed strings, it helps to use human-readable names
where types would be required otherwise. As an example:
```cpp
registry.emplace<entt::tag<"enemy"_hs>>(entity);
```
However, this isn't the only permitted use. Literally any value convertible to
`id_type` is a good candidate, such as the named constants of an unscoped enum.
### Type list and value list
There is no respectable library where the much desired _type list_ can be
missing.<br/>
`EnTT` is no exception and provides (making extensive use of it internally) the
`type_list` type, in addition to its `value_list` counterpart dedicated to
non-type template parameters.
Here is a (possibly incomplete) list of the functionalities that come with a
type list:
* `type_list_element[_t]` to get the N-th element of a type list.
* `type_list_index[_v]` to get the index of a given element of a type list.
* `type_list_cat[_t]` and a handy `operator+` to concatenate type lists.
* `type_list_unique[_t]` to remove duplicate types from a type list.
* `type_list_contains[_v]` to know if a type list contains a given type.
* `type_list_diff[_t]` to remove types from type lists.
* `type_list_transform[_t]` to _transform_ a range and create another type list.
I'm also pretty sure that more and more utilities will be added over time as
needs become apparent.<br/>
Many of these functionalities also exist in their version dedicated to value
lists. We therefore have `value_list_element[_v]` as well as
`value_list_cat[_t]`and so on.
# Unique sequential identifiers
Sometimes it's useful to be able to give unique, sequential numeric identifiers
to types either at compile-time or runtime.<br/>
There are plenty of different solutions for this out there and I could have used
one of them. However, I decided to spend my time to define a couple of tools
that fully embraces what the modern C++ has to offer.
## Compile-time generator
To generate sequential numeric identifiers at compile-time, `EnTT` offers the
`ident` class template:
```cpp
// defines the identifiers for the given types
using id = entt::ident<a_type, another_type>;
// ...
switch(a_type_identifier) {
case id::value<a_type>:
// ...
break;
case id::value<another_type>:
// ...
break;
default:
// ...
}
```
This is what this class template has to offer: a `value` inline variable that
contains a numeric identifier for the given type. It can be used in any context
where constant expressions are required.
As long as the list remains unchanged, identifiers are also guaranteed to be
stable across different runs. In case they have been used in a production
environment and a type has to be removed, one can just use a placeholder to
leave the other identifiers unchanged:
```cpp
template<typename> struct ignore_type {};
using id = entt::ident<
a_type_still_valid,
ignore_type<no_longer_valid_type>,
another_type_still_valid
>;
```
Perhaps a bit ugly to see in a codebase but it gets the job done at least.
## Runtime generator
The `family` class template helps to generate sequential numeric identifiers for
types at runtime:
```cpp
// defines a custom generator
using id = entt::family<struct my_tag>;
// ...
const auto a_type_id = id::value<a_type>;
const auto another_type_id = id::value<another_type>;
```
This is what a _family_ has to offer: a `value` inline variable that contains a
numeric identifier for the given type.<br/>
The generator is customizable, so as to get different _sequences_ for different
purposes if needed.
Identifiers aren't guaranteed to be stable across different runs. Indeed it
mostly depends on the flow of execution.
# Utilities
It's not possible to escape the temptation to add utilities of some kind to a
library. In fact, `EnTT` also provides a handful of tools to simplify the
life of developers:
* `entt::identity`: the identity function object that will be available with
C++20. It returns its argument unchanged and nothing more. It's useful as a
sort of _do nothing_ function in template programming.
* `entt::overload`: a tool to disambiguate different overloads from their
function type. It works with both free and member functions.<br/>
Consider the following definition:
```cpp
struct clazz {
void bar(int) {}
void bar() {}
};
```
This utility can be used to get the _right_ overload as:
```cpp
auto *member = entt::overload<void(int)>(&clazz::bar);
```
The line above is literally equivalent to:
```cpp
auto *member = static_cast<void(clazz:: *)(int)>(&clazz::bar);
```
Just easier to read and shorter to type.
* `entt::overloaded`: a small class template used to create a new type with an
overloaded `operator()` from a bunch of lambdas or functors.<br/>
As an example:
```cpp
entt::overloaded func{
[](int value) { /* ... */ },
[](char value) { /* ... */ }
};
func(42);
func('c');
```
Rather useful when doing metaprogramming and having to pass to a function a
callable object that supports multiple types at once.
* `entt::y_combinator`: this is a C++ implementation of **the** _y-combinator_.
If it's not clear what it is, there is probably no need for this utility.<br/>
Below is a small example to show its use:
```cpp
entt::y_combinator gauss([](const auto &self, auto value) -> unsigned int {
return value ? (value + self(value-1u)) : 0;
});
const auto result = gauss(3u);
```
Maybe convoluted at a first glance but certainly effective. Unfortunately,
the language doesn't make it possible to do much better.
This is a rundown of the (actually few) utilities made available by `EnTT`. The
list will probably grow over time but the size of each will remain rather small,
as has been the case so far.

2344
external/entt/entt/docs/md/entity.md vendored Normal file

File diff suppressed because it is too large Load Diff

215
external/entt/entt/docs/md/faq.md vendored Normal file
View File

@ -0,0 +1,215 @@
# Frequently Asked Questions
<!--
@cond TURN_OFF_DOXYGEN
-->
# Table of Contents
* [Introduction](#introduction)
* [FAQ](#faq)
* [Why is my debug build on Windows so slow?](#why-is-my-debug-build-on-windows-so-slow)
* [How can I represent hierarchies with my components?](#how-can-i-represent-hierarchies-with-my-components)
* [Custom entity identifiers: yay or nay?](#custom-entity-identifiers-yay-or-nay)
* [Warning C4307: integral constant overflow](#warning-C4307-integral-constant-overflow)
* [Warning C4003: the min, the max and the macro](#warning-C4003-the-min-the-max-and-the-macro)
* [The standard and the non-copyable types](#the-standard-and-the-non-copyable-types)
* [Which functions trigger which signals](#which-functions-trigger-which-signals)
<!--
@endcond TURN_OFF_DOXYGEN
-->
# Introduction
This is a constantly updated section where I'm trying to put the answers to the
most frequently asked questions.<br/>
If you don't find your answer here, there are two cases: nobody has done it yet
or this section needs updating. In both cases, you can
[open a new issue](https://github.com/skypjack/entt/issues/new) or enter either
the [gitter channel](https://gitter.im/skypjack/entt) or the
[discord server](https://discord.gg/5BjPWBd) to ask for help.<br/>
Probably someone already has an answer for you and we can then integrate this
part of the documentation.
# FAQ
## Why is my debug build on Windows so slow?
`EnTT` is an experimental project that I also use to keep me up-to-date with the
latest revision of the language and the standard library. For this reason, it's
likely that some classes you're working with are using standard containers under
the hood.<br/>
Unfortunately, it's known that the standard containers aren't particularly
performing in debugging (the reasons for this go beyond this document) and are
even less so on Windows apparently. Fortunately this can also be mitigated a
lot, achieving good results in many cases.
First of all, there are two things to do in a Windows project:
* Disable the [`/JMC`](https://docs.microsoft.com/cpp/build/reference/jmc)
option (_Just My Code_ debugging), available starting with Visual Studio 2017
version 15.8.
* Set the [`_ITERATOR_DEBUG_LEVEL`](https://docs.microsoft.com/cpp/standard-library/iterator-debug-level)
macro to 0. This will disable checked iterators and iterator debugging.
Moreover, set the `ENTT_DISABLE_ASSERT` variable or redefine the `ENTT_ASSERT`
macro to disable internal debug checks in `EnTT`:
```cpp
#define ENTT_ASSERT(...) ((void)0)
```
These asserts are introduced to help the users but they require to access to the
underlying containers and therefore risk ruining the performance in some cases.
With these changes, debug performance should increase enough in most cases. If
you want something more, you can also switch to an optimization level `O0` or
preferably `O1`.
## How can I represent hierarchies with my components?
This is one of the first questions that anyone makes when starting to work with
the entity-component-system architectural pattern.<br/>
There are several approaches to the problem and the best one depends mainly on
the real problem one is facing. In all cases, how to do it doesn't strictly
depend on the library in use, but the latter certainly allows or not different
techniques depending on how the data are laid out.
I tried to describe some of the approaches that fit well with the model of
`EnTT`. [This](https://skypjack.github.io/2019-06-25-ecs-baf-part-4/) is the
first post of a series that tries to _explore_ the problem. More will probably
come in future.<br/>
In addition, `EnTT` also offers the possibility to create stable storage types
and therefore have pointer stability for one, all or some components. This is by
far the most convenient solution when it comes to creating hierarchies and
whatnot. See the documentation for the ECS part of the library and in particular
what concerns the `component_traits` class for further details.
## Custom entity identifiers: yay or nay?
Custom entity identifiers are definitely a good idea in two cases at least:
* If `std::uint32_t` isn't large enough for your purposes, since this is the
underlying type of `entt::entity`.
* If you want to avoid conflicts when using multiple registries.
Identifiers can be defined through enum classes and class types that define an
`entity_type` member of type `std::uint32_t` or `std::uint64_t`.<br/>
In fact, this is a definition equivalent to that of `entt::entity`:
```cpp
enum class entity: std::uint32_t {};
```
There is no limit to the number of identifiers that can be defined.
## Warning C4307: integral constant overflow
According to [this](https://github.com/skypjack/entt/issues/121) issue, using a
hashed string under VS (toolset v141) could generate a warning.<br/>
First of all, I want to reassure you: it's expected and harmless. However, it
can be annoying.
To suppress it and if you don't want to suppress all the other warnings as well,
here is a workaround in the form of a macro:
```cpp
#if defined(_MSC_VER)
#define HS(str) __pragma(warning(suppress:4307)) entt::hashed_string{str}
#else
#define HS(str) entt::hashed_string{str}
#endif
```
With an example of use included:
```cpp
constexpr auto identifier = HS("my/resource/identifier");
```
Thanks to [huwpascoe](https://github.com/huwpascoe) for the courtesy.
## Warning C4003: the min, the max and the macro
On Windows, a header file defines two macros `min` and `max` which may result in
conflicts with their counterparts in the standard library and therefore in
errors during compilation.
It's a pretty big problem but fortunately it's not a problem of `EnTT` and there
is a fairly simple solution to it.<br/>
It consists in defining the `NOMINMAX` macro before including any other header
so as to get rid of the extra definitions:
```cpp
#define NOMINMAX
```
Please refer to [this](https://github.com/skypjack/entt/issues/96) issue for
more details.
## The standard and the non-copyable types
`EnTT` uses internally the trait `std::is_copy_constructible_v` to check if a
component is actually copyable. However, this trait doesn't really check whether
a type is actually copyable. Instead, it just checks that a suitable copy
constructor and copy operator exist.<br/>
This can lead to surprising results due to some idiosyncrasies of the standard.
For example, `std::vector` defines a copy constructor that is conditionally
enabled depending on whether the value type is copyable or not. As a result,
`std::is_copy_constructible_v` returns true for the following specialization:
```cpp
struct type {
std::vector<std::unique_ptr<action>> vec;
};
```
However, the copy constructor is effectively disabled upon specialization.
Therefore, trying to assign an instance of this type to an entity may trigger a
compilation error.<br/>
As a workaround, users can mark the type explicitly as non-copyable. This also
suppresses the implicit generation of the move constructor and operator, which
will therefore have to be defaulted accordingly:
```cpp
struct type {
type(const type &) = delete;
type(type &&) = default;
type & operator=(const type &) = delete;
type & operator=(type &&) = default;
std::vector<std::unique_ptr<action>> vec;
};
```
Note that aggregate initialization is also disabled as a consequence.<br/>
Fortunately, this type of trick is quite rare. The bad news is that there is no
way to deal with it at the library level, this being due to the design of the
language. On the other hand, the fact that the language itself also offers a way
to mitigate the problem makes it manageable.
## Which functions trigger which signals
Storage classes offer three _signals_ that are emitted following specific
operations. Maybe not everyone knows what these operations are, though.<br/>
If this isn't clear, below you can find a _vademecum_ for this purpose:
* `on_created` is invoked when a component is first added (neither modified nor
replaced) to an entity.
* `on_update` is called whenever an existing component is modified or replaced.
* `on_destroyed` is called when a component is explicitly or implicitly removed
from an entity.
Among the most controversial functions can be found `emplace_or_replace` and
`destroy`. However, following the above rules, it's quite simple to know what
will happen.<br/>
In the first case, `on_created` is invoked if the entity has not the component,
otherwise the latter is replaced and therefore `on_update` is triggered. As for
the second case, components are removed from their entities and thus freed when
they are recycled. It means that `on_destroyed` is triggered for every component
owned by the entity that is destroyed.

372
external/entt/entt/docs/md/graph.md vendored Normal file
View File

@ -0,0 +1,372 @@
# Crash Course: graph
<!--
@cond TURN_OFF_DOXYGEN
-->
# Table of Contents
* [Introduction](#introduction)
* [Data structures](#data-structures)
* [Adjacency matrix](#adjacency-matrix)
* [Graphviz dot language](#graphviz-dot-language)
* [Flow builder](#flow-builder)
* [Tasks and resources](#tasks-and-resources)
* [Fake resources and order of execution](#fake-resources-and-order-of-execution)
* [Sync points](#sync-points)
* [Execution graph](#execution-graph)
<!--
@endcond TURN_OFF_DOXYGEN
-->
# Introduction
`EnTT` doesn't aim to offer everything one needs to work with graphs. Therefore,
anyone looking for this in the _graph_ submodule will be disappointed.<br/>
Quite the opposite is true though. This submodule is minimal and contains only
the data structures and algorithms strictly necessary for the development of
some tools such as the _flow builder_.
# Data structures
As anticipated in the introduction, the aim isn't to offer all possible data
structures suitable for representing and working with graphs. Many will likely
be added or refined over time. However I want to discourage anyone expecting
tight scheduling on the subject.<br/>
The data structures presented in this section are mainly useful for the
development and support of some tools which are also part of the same submodule.
## Adjacency matrix
The adjacency matrix is designed to represent either a directed or an undirected
graph:
```cpp
entt::adjacency_matrix<entt::directed_tag> adjacency_matrix{};
```
The `directed_tag` type _creates_ the graph as directed. There is also an
`undirected_tag` counterpart which creates it as undirected.<br/>
The interface deviates slightly from the typical double indexing of C and offers
an API that is perhaps more familiar to a C++ programmer. Therefore, the access
and modification of an element takes place via the `contains`, `insert` and
`erase` functions rather than a double call to an `operator[]`:
```cpp
if(adjacency_matrix.contains(0u, 1u)) {
adjacency_matrix.erase(0u, 1u);
} else {
adjacency_matrix.insert(0u, 1u);
}
```
Both `insert` and` erase` are _idempotent_ functions which have no effect if the
element already exists or has already been deleted.<br/>
The first one returns an `std::pair` containing the iterator to the element and
a boolean value indicating whether the element was newly inserted or not. The
second one returns the number of deleted elements (0 or 1).
An adjacency matrix is initialized with the number of elements (vertices) when
constructing it but can also be resized later using the `resize` function:
```cpp
entt::adjacency_matrix<entt::directed_tag> adjacency_matrix{3u};
```
To visit all vertices, the class offers a function named `vertices` that returns
an iterable object suitable for the purpose:
```cpp
for(auto &&vertex: adjacency_matrix.vertices()) {
// ...
}
```
The same result is obtained with the following snippet, since the vertices are
plain unsigned integral values:
```cpp
for(auto last = adjacency_matrix.size(), pos = {}; pos < last; ++pos) {
// ...
}
```
As for visiting the edges, a few functions are available.<br/>
When the purpose is to visit all the edges of a given adjacency matrix, the
`edges` function returns an iterable object that is used to get them as pairs of
vertices:
```cpp
for(auto [lhs, rhs]: adjacency_matrix.edges()) {
// ...
}
```
If the goal is to visit all the in- or out-edges of a given vertex instead, the
`in_edges` and `out_edges` functions are meant for that:
```cpp
for(auto [lhs, rhs]: adjacency_matrix.out_edges(3u)) {
// ...
}
```
Both the functions expect the vertex to visit (that is, to return the in- or
out-edges for) as an argument.<br/>
Finally, the adjacency matrix is an allocator-aware container and offers most of
the functionalities one would expect from this type of containers, such as
`clear` or 'get_allocator` and so on.
## Graphviz dot language
As it's one of the most popular formats, the library offers minimal support for
converting a graph to a Graphviz dot snippet.<br/>
The simplest way is to pass both an output stream and a graph to the `dot`
function:
```cpp
std::ostringstream output{};
entt::dot(output, adjacency_matrix);
```
It's also possible to provide a callback to which the vertices are passed and
which can be used to add (`dot`) properties to the output as needed:
```cpp
std::ostringstream output{};
entt::dot(output, adjacency_matrix, [](auto &output, auto vertex) {
out << "label=\"v\"" << vertex << ",shape=\"box\"";
});
```
This second mode is particularly convenient when the user wants to associate
externally managed data to the graph being converted.
# Flow builder
A flow builder is used to create execution graphs from tasks and resources.<br/>
The implementation is as generic as possible and doesn't bind to any other part
of the library.
This class is designed as a sort of _state machine_ to which a specific task is
attached for which the resources accessed in read-only or read-write mode are
specified.<br/>
Most of the functions in the API also return the flow builder itself, according
to what is the common sense API when it comes to builder classes.
Once all tasks are registered and resources assigned to them, an execution graph
in the form of an adjacency matrix is returned to the user.<br/>
This graph contains all the tasks assigned to the flow builder in the form of
_vertices_. The _vertex_ itself is used as an index to get the identifier passed
during registration.
## Tasks and resources
Although these terms are used extensively in the documentation, the flow builder
has no real concept of tasks and resources.<br/>
This class works mainly with _identifiers_, that is, values of type `id_type`.
In other terms, both tasks and resources are identified by integral values.<br/>
This allows not to couple the class itself to the rest of the library or to any
particular data structure. On the other hand, it requires the user to keep track
of the association between identifiers and operations or actual data.
Once a flow builder is created (which requires no constructor arguments), the
first thing to do is to bind a task. This tells to the builder _who_ intends to
consume the resources that are specified immediately after:
```cpp
entt::flow builder{};
builder.bind("task_1"_hs);
```
The example uses the `EnTT` hashed string to generate an identifier for the
task.<br/>
Indeed, the use of `id_type` as an identifier type isn't by accident. In fact,
it matches well with the internal hashed string class. Moreover, it's also the
same type returned by the hash function of the internal RTTI system, in case the
user wants to rely on that.<br/>
However, being an integral value, it leaves the user full freedom to rely on his
own tools if necessary.
Once a task is associated with the flow builder, it's also assigned read-only or
read-write resources as appropriate:
```cpp
builder
.bind("task_1"_hs)
.ro("resource_1"_hs)
.ro("resource_2"_hs)
.bind("task_2"_hs)
.rw("resource_2"_hs)
```
As mentioned, many functions return the builder itself and it's therefore easy
to concatenate the different calls.<br/>
Also in the case of resources, they are identified by numeric values of type
`id_type`. As above, the choice is not entirely random. This goes well with the
tools offered by the library while leaving room for maximum flexibility.
Finally, both the `ro` and` rw` functions also offer an overload that accepts a
pair of iterators, so that one can pass a range of resources in one go.
### Rebinding
The `flow` class is resource based rather than task based. This means that graph
generation is driven by resources and not by the order of _appearance_ of tasks
during flow definition.<br/>
Although this concept is particularly important, it's almost irrelevant for the
vast majority of cases. However, it becomes relevant when _rebinding_ resources
or tasks.
In fact, nothing prevents rebinding elements to a flow.<br/>
However, the behavior changes slightly from case to case and has some nuances
that it's worth knowing about.
Directly rebinding a resource without the task being replaced trivially results
in the task's access mode for that resource being updated:
```cpp
builder.bind("task"_hs).rw("resource"_hs).ro("resource"_hs)
```
In this case, the resource is accessed in read-only mode, regardless of the
first call to `rw`.<br/>
Behind the scenes, the call doesn't actually _replace_ the previous one but is
queued after it instead, overwriting it when generating the graph. Thus, a large
number of resource rebindings may even impact processing times (very difficult
to observe but theoretically possible).
Rebinding resources and also combining it with changes to tasks has far more
implications instead.<br/>
As mentioned, graph generation takes place starting from resources and not from
tasks. Therefore, the result may not be as expected:
```cpp
builder
.bind("task_1"_hs)
.ro("resource"_hs)
.bind("task_2"_hs)
.ro("resource"_hs)
.bind("task_1"_hs)
.rw("resource"_hs);
```
What happens here is that the resource first _sees_ a read-only access request
from the first task, then a read-write request from the second task and finally
a new read-only request from the first task.<br/>
Although this definition would probably be counted as an error, the resulting
graph may be unexpected. This in fact consists of a single edge outgoing from
the second task and directed to the first task.<br/>
To intuitively understand what happens, it's enough to think of the fact that a
task never has an edge pointing to itself.
While not obvious, this approach has its pros and cons like any other solution.
For example, creating loops is actually simple in the context of resource-based
graph generations:
```cpp
builder
.bind("task_1"_hs)
.rw("resource"_hs)
.bind("task_2"_hs)
.rw("resource"_hs)
.bind("task_1"_hs)
.rw("resource"_hs);
```
As expected, this definition leads to the creation of two edges that define a
loop between the two tasks.
As a general rule, rebinding resources and tasks is highly discouraged because
it could lead to subtle bugs if users don't know what they're doing.<br/>
However, once the mechanisms of resource-based graph generation are understood,
it can offer to the expert user a flexibility and a range of possibilities
otherwise inaccessible.
## Fake resources and order of execution
The flow builder doesn't offer the ability to specify when a task should execute
before or after another task.<br/>
In fact, the order of _registration_ on the resources also determines the order
in which the tasks are processed during the generation of the execution graph.
However, there is a way to _force_ the execution order of two processes.<br/>
Briefly, since accessing a resource in opposite modes requires sequential rather
than parallel scheduling, it's possible to make use of fake resources to rule on
the execution order:
```cpp
builder
.bind("task_1"_hs)
.ro("resource_1"_hs)
.rw("fake"_hs)
.bind("task_2"_hs)
.ro("resource_2"_hs)
.ro("fake"_hs)
.bind("task_3"_hs)
.ro("resource_2"_hs)
.ro("fake"_hs)
```
This snippet forces the execution of `task_1` **before** `task_2` and `task_3`.
This is due to the fact that the former sets a read-write requirement on a fake
resource that the other tasks also want to access in read-only mode.<br/>
Similarly, it's possible to force a task to run **after** a certain group:
```cpp
builder
.bind("task_1"_hs)
.ro("resource_1"_hs)
.ro("fake"_hs)
.bind("task_2"_hs)
.ro("resource_1"_hs)
.ro("fake"_hs)
.bind("task_3"_hs)
.ro("resource_2"_hs)
.rw("fake"_hs)
```
In this case, since there are a number of processes that want to read a specific
resource, they will do so in parallel by forcing `task_3` to run after all the
others tasks.
## Sync points
Sometimes it's useful to assign the role of _sync point_ to a node.<br/>
Whether it accesses new resources or is simply a watershed, the procedure for
assigning this role to a vertex is always the same. First it's tied to the flow
builder, then the `sync` function is invoked:
```cpp
builder.bind("sync_point"_hs).sync();
```
The choice to assign an _identity_ to this type of nodes lies in the fact that,
more often than not, they also perform operations on resources.<br/>
If this isn't the case, it will still be possible to create no-op vertices to
which empty tasks are assigned.
## Execution graph
Once both the resources and their consumers have been properly registered, the
purpose of this tool is to generate an execution graph that takes into account
all specified constraints to return the best scheduling for the vertices:
```cpp
entt::adjacency_matrix<entt::directed_tag> graph = builder.graph();
```
Searching for the main vertices (that is, those without in-edges) is usually the
first thing required:
```cpp
for(auto &&vertex: graph) {
if(auto in_edges = graph.in_edges(vertex); in_edges.begin() == in_edges.end()) {
// ...
}
}
```
Then it's possible to instantiate an execution graph by means of other functions
such as `out_edges` to retrieve the children of a given task or `edges` to get
the identifiers.

97
external/entt/entt/docs/md/lib.md vendored Normal file
View File

@ -0,0 +1,97 @@
# Push EnTT across boundaries
<!--
@cond TURN_OFF_DOXYGEN
-->
# Table of Contents
* [Working across boundaries](#working-across-boundaries)
* [Smooth until proven otherwise](#smooth-until-proven-otherwise)
* [Meta context](#meta-context)
* [Memory management](#memory-management)
<!--
@endcond TURN_OFF_DOXYGEN
-->
# Working across boundaries
`EnTT` has historically had a limit when used across boundaries on Windows in
general and on GNU/Linux when default visibility was set to hidden. The
limitation was mainly due to a custom utility used to assign unique, sequential
identifiers with different types.<br/>
Fortunately, nowadays `EnTT` works smoothly across boundaries.
## Smooth until proven otherwise
Many classes in `EnTT` make extensive use of type erasure for their purposes.
This raises the need to identify objects whose type has been erased.<br/>
The `type_hash` class template is how identifiers are generated and thus made
available to the rest of the library. In general, this class doesn't arouse much
interest. The only exception is when a conflict between identifiers occurs
(definitely uncommon though) or when the default solution proposed by `EnTT`
isn't suitable for the user's purposes.<br/>
The section dedicated to `type_info` contains all the details to get around the
issue in a concise and elegant way. Please refer to the specific documentation.
When working with linked libraries, compile definitions `ENTT_API_EXPORT` and
`ENTT_API_IMPORT` are to import or export symbols, so as to make everything work
nicely across boundaries.<br/>
On the other hand, everything should run smoothly when working with plugins or
shared libraries that don't export any symbols.
For those who need more details, the test suite contains many examples covering
the most common cases (see the `lib` directory for all details).<br/>
It goes without saying that it's impossible to cover **all** possible cases.
However, what is offered should hopefully serve as a basis for all of them.
## Meta context
The runtime reflection system deserves a special mention when it comes to using
it across boundaries.<br/>
Since it's linked already to a static context to which the elements are attached
and different contexts don't relate to each other, they must be _shared_ to
allow the use of meta types across boundaries.
Fortunately, sharing a context is also trivial to do. First of all, the local
one is acquired in the main space:
```cpp
auto handle = entt::locator<entt::meta_ctx>::handle();
```
Then, it's passed to the receiving space that sets it as its default context,
thus discarding or storing aside the local one:
```cpp
entt::locator<entt::meta_ctx>::reset(handle);
```
From now on, both spaces refer to the same context and on it are attached all
new meta types, no matter where they are created.<br/>
Note that _replacing_ the main context doesn't also propagate changes across
boundaries. In other words, replacing a context results in the decoupling of the
two sides and therefore a divergence in the contents.
## Memory Management
There is another subtle problem due to memory management that can lead to
headaches.<br/>
It can occur where there are pools of objects (such as components or events)
dynamically created on demand. This is usually not a problem when working with
linked libraries that rely on the same dynamic runtime. However, it can occur in
the case of plugins or statically linked runtimes.
As an example, imagine creating an instance of `registry` in the main executable
and sharing it with a plugin. If the latter starts working with a component that
is unknown to the former, a dedicated pool is created within the registry on
first use.<br/>
As one can guess, this pool is instantiated on a different side of the boundary
from the `registry`. Therefore, the instance is now managing memory from
different spaces and this can quickly lead to crashes if not properly addressed.
To overcome the risk, it's recommended to use well-defined interfaces that make
fundamental types pass through the boundaries, isolating the instances of the
`EnTT` classes from time to time and as appropriate.<br/>
Refer to the test suite for some examples, read the documentation available
online about this type of issues or consult someone who has already had such
experiences to avoid problems.

304
external/entt/entt/docs/md/links.md vendored Normal file
View File

@ -0,0 +1,304 @@
# EnTT in Action
<!--
@cond TURN_OFF_DOXYGEN
-->
# Table of Contents
* [Introduction](#introduction)
* [EnTT in Action](#entt-in-action)
* [Games](#games)
* [Engines and the like](#engines-and-the-like)
* [Articles, videos and blog posts](#articles-videos-and-blog-posts)
* [Any Other Business](#any-other-business)
<!--
@endcond TURN_OFF_DOXYGEN
-->
# Introduction
`EnTT` is widely used in private and commercial applications. I cannot even
mention most of them because of some signatures I put on some documents time
ago. Fortunately, there are also people who took the time to implement open
source projects based on `EnTT` and didn't hold back when it came to documenting
them.
Below an incomplete list of games, applications and articles that can be used as
a reference.<br/>
Where I put the word _apparently_ means that the use of `EnTT` is documented but
the authors didn't make explicit announcements or contacted me directly.
If you know of other resources out there that are about `EnTT`, feel free to
open an issue or a PR and I'll be glad to add them to this page.<br/>
I hope the following lists can grow much more in the future.
# EnTT in Action
## Games
* [Minecraft](https://minecraft.net/en-us/attribution/) by
[Mojang](https://mojang.com/): of course, **that** Minecraft, see the
open source attributions page for more details.
* [Minecraft Earth](https://www.minecraft.net/en-us/about-earth) by
[Mojang](https://mojang.com/): an augmented reality game for mobile, that
lets users bring Minecraft into the real world.
* [Ember Sword](https://embersword.com/): a modern Free-to-Play MMORPG with a
player-driven economy, a classless combat system, and scarce, tradable
cosmetic collectibles.
* Apparently [Diablo II: Resurrected](https://diablo2.blizzard.com/) by
[Blizzard](https://www.blizzard.com/): monsters, heroes, items, spells, all
resurrected. Thanks unknown insider.
* [Apparently](https://www.youtube.com/watch?v=P8xvOA3ikrQ&t=1105s)
[Call of Duty: Vanguard](https://www.callofduty.com/vanguard) by
[Sledgehammer Games](https://www.sledgehammergames.com/): I can neither
confirm nor deny but there is a license I know in the credits.
* Apparently [D&D Dark Alliance](https://darkalliance.wizards.com) by
[Wizards of the Coast](https://company.wizards.com): your party, their
funeral.
* [TiltedOnline](https://github.com/tiltedphoques/TiltedOnline) by
[Tilted Phoques](https://github.com/tiltedphoques): Skyrim and Fallout 4 mod
to play online.
* [Antkeeper](https://github.com/antkeeper/antkeeper-source): an ant colony
simulation [game](https://antkeeper.com/).
* [Openblack](https://github.com/openblack/openblack): open source
reimplementation of the game _Black & White_ (2001).
* [Land of the Rair](https://github.com/LandOfTheRair/core2): the new backend
of [a retro-style MUD](https://rair.land/) for the new age.
* [Face Smash](https://play.google.com/store/apps/details?id=com.gamee.facesmash):
a game to play with your face.
* [EnTT Pacman](https://github.com/Kerndog73/EnTT-Pacman): an example of how
to make Pacman with `EnTT`.
* [Wacman](https://github.com/carlfindahl/wacman): a pacman clone with OpenGL.
* [Classic Tower Defence](https://github.com/kerndog73/Classic-Tower-Defence):
a tiny little tower defence game featuring a homemade font.
[Check it out](https://indi-kernick.itch.io/classic-tower-defence).
* [The Machine](https://github.com/Kerndog73/The-Machine): a box pushing
puzzler with logic gates and other cool stuff.
[Check it out](https://indi-kernick.itch.io/the-machine-web-version).
* [EnTTPong](https://github.com/DomRe/EnttPong): a basic game made to showcase
different parts of `EnTT` and C++17.
* [Randballs](https://github.com/gale93/randballs): simple `SFML` and `EnTT`
playground.
* [EnTT Tower Defense](https://github.com/Daivuk/tddod): a data oriented tower
defense example.
* [EnTT Breakout](https://github.com/vblanco20-1/entt-breakout): simple
example of a breakout game, using `SDL` and `EnTT`.
* [Arcade puzzle game with EnTT](https://github.com/MasonRG/ArcadePuzzleGame):
arcade puzzle game made in C++ using the `SDL2` and `EnTT` libraries.
* [Snake with EnTT](https://github.com/MasonRG/SnakeGame): simple snake game
made in C++ with the `SDL2` and `EnTT` libraries.
* [Mirrors lasers and robots](https://github.com/guillaume-haerinck/imac-tower-defense):
a small tower defense game based on mirror orientation.
* [PopHead](https://github.com/SPC-Some-Polish-Coders/PopHead/): 2D, Zombie,
RPG game made from scratch in C++.
* [Robotligan](https://github.com/Trisslotten/robotligan): multiplayer
football game.
* [DungeonSlayer](https://github.com/alohaeee/DungeonSlayer): 2D game made
from scratch in C++.
* [3DGame](https://github.com/kwarkGorny/3DGame): 2.5D top-down space shooter.
* [Pulcher](https://github.com/AODQ/pulcher): 2D cross-platform game inspired
by Quake.
* [Destroid](https://github.com/tyrannicaltoucan/destroid): _one-bazillionth_
arcade game about shooting dirty rocks in space, inspired by Asteroids.
* [Wanderer](https://github.com/albin-johansson/wanderer): a 2D exploration
based indie game.
* [Spelunky<EFBFBD> Classic remake](https://github.com/dbeef/spelunky-psp): a truly
multiplatform experience with a rewrite from scratch.
* [CubbyTower](https://github.com/utilForever/CubbyTower): a simple tower
defense game using C++ with Entity Component System (ECS).
* [Runeterra](https://github.com/utilForever/Runeterra): Legends of Runeterra
simulator using C++ with some reinforcement learning.
* [Black Sun](https://store.steampowered.com/app/1670930/Black_Sun/): fly your
space ship through a large 2D open world.
* [PokeMaster](https://github.com/utilForever/PokeMaster): Pokemon Battle
simulator using C++ with some reinforcement learning.
* [HomeHearth](https://youtu.be/GrEWl8npL9Y): choose your hero, protect the
town, before it's too late.
* [City Builder Game](https://github.com/PhiGei2000/CityBuilderGame): a simple
city-building game using C++ and OpenGL.
* [BattleSub](https://github.com/bfeldpw/battlesub): two player 2D submarine
game with some fluid dynamics.
* [Crimson Rush](https://github.com/WilKam01/LuaCGame): a dungeon-crawler and
rougelike inspired game about exploring and surviving as long as possible.
* [Space Fight](https://github.com/cholushkin/SpaceFight): one screen
multi-player arcade shooter game prototype.
* [Confetti Party](https://github.com/hexerei/entt-confetti): C++ sample
application as a starting point using `EnTT` and `SDL2`.
## Engines and the like:
* [Aether Engine](https://hadean.com/spatial-simulation/)
[v1.1+](https://docs.hadean.com/v1.1/Licenses/) by
[Hadean](https://hadean.com/): a library designed for spatially partitioning
agent-based simulations.
* [Fling Engine](https://github.com/flingengine/FlingEngine): a Vulkan game
engine with a focus on data oriented design.
* [NovusCore](https://github.com/novuscore/NovusCore): a modern take on World
of Warcraft emulation.
* [Chrysalis](https://github.com/ivanhawkes/Chrysalis): action RPG SDK for
CRYENGINE games.
* [LM-Engine](https://github.com/Lawrencemm/LM-Engine): the Vim of game
engines.
* [Edyn](https://github.com/xissburg/edyn): a real-time physics engine
organized as an ECS.
* [MushMachine](https://github.com/MadeOfJelly/MushMachine): engine...
vrooooommm.
* [Antara Gaming SDK](https://github.com/KomodoPlatform/antara-gaming-sdk):
the Komodo Gaming Software Development Kit.
* [XVP](https://ravingbots.com/xvp-expansive-vehicle-physics-for-unreal-engine/):
[_eXpansive Vehicle Physics_](https://github.com/raving-bots/xvp/wiki/Plugin-integration-guide)
plugin for Unreal Engine.
* [Apparently](https://teamwisp.github.io/credits/)
[Wisp](https://teamwisp.github.io/product/) by
[Team Wisp](https://teamwisp.github.io/): an advanced real-time ray tracing
renderer built for the demands of video game artists.
* [shiva](https://github.com/Milerius/shiva): modern C++ engine with
modularity.
* [ImGui/EnTT editor](https://github.com/Green-Sky/imgui_entt_entity_editor):
a drop-in, single-file entity editor for `EnTT` that uses `ImGui` as
graphical backend (with
[demo code](https://github.com/Green-Sky/imgui_entt_entity_editor_demo)).
* [SgOgl](https://github.com/stwe/SgOgl): a game engine library for OpenGL
developed for educational purposes.
* [Lumos](https://github.com/jmorton06/Lumos): game engine written in C++
using OpenGL and Vulkan.
* [Silvanus](https://github.com/hobbyistmaker/silvanus): Silvanus Fusion 360
Box Generator.
* [Lina Engine](https://github.com/inanevin/LinaEngine): an open-source,
modular, tiny and fast C++ game engine, aimed to develop 3D desktop games.
* [Spike](https://github.com/FahimFuad/Spike): a powerful game engine which
can run on a toaster.
* [Helena Framework](https://github.com/NIKEA-SOFT/HelenaFramework): a modern
framework in C++17 for backend development.
* [Unity/EnTT](https://github.com/TongTungGiang/unity-entt): tech demo of a
native simulation layer using `EnTT` and `Unity` as a rendering engine.
* [OverEngine](https://github.com/OverShifted/OverEngine): an over-engineered
game engine.
* [Electro](https://github.com/Electro-Technologies/Electro): high performance
3D game engine with a high emphasis on rendering.
* [Kawaii](https://github.com/Mathieu-Lala/Kawaii_Engine): a modern data
oriented game engine.
* [Becketron](https://github.com/Doctor-Foxling/Becketron): a game engine
written mostly in C++.
* [Spatial Engine](https://github.com/luizgabriel/Spatial.Engine): a
cross-platform engine created on top of google's filament rendering engine.
* [Kaguya](https://github.com/KaiH0717/Kaguya): D3D12 Rendering Engine.
* [OpenAWE](https://github.com/OpenAWE-Project/OpenAWE): open implementation
of the Alan Wake Engine.
* [Nazara Engine](https://github.com/DigitalPulseSoftware/NazaraEngine): fast,
cross-platform, object-oriented API to help in daily developer life.
* [Billy Engine](https://github.com/billy4479/BillyEngine): some kind of a 2D
engine based on `SDL2` and `EnTT`.
* [Ducktape](https://github.com/DucktapeEngine/Ducktape): an open source C++
2D & 3D game engine that focuses on being fast and powerful.
* [The Worst Engine](https://github.com/Parasik72/TWE): a game engine based on
OpenGL.
* [Ecsact](https://ecsact.dev/): a language aimed at describing ECS, with a
[runtime implementation](https://github.com/ecsact-dev/ecsact_rt_entt) based
on `EnTT`.
* [AGE (Arc Game Engine)](https://github.com/MohitSethi99/ArcGameEngine): an
open-source engine for building 2D & 3D real-time rendering and interactive
contents.
* [Kengine](https://github.com/phisko/kengine): the _Koala engine_ is a game
engine entirely implemented as an entity-component-ystem.
## Articles, videos and blog posts:
* [Some posts](https://skypjack.github.io/tags/#entt) on my personal
[blog](https://skypjack.github.io/) are about `EnTT`, for those who want to
know **more** on this project.
* [Game Engine series](https://www.youtube.com/c/TheChernoProject/videos) by
[The Cherno](https://github.com/TheCherno) (not only about `EnTT` but also
on the use of an ECS in general):
- [Intro to EnTT](https://www.youtube.com/watch?v=D4hz0wEB978).
- [Entities and Components](https://www.youtube.com/watch?v=-B1iu4QJTUc).
- [The ENTITY Class](https://www.youtube.com/watch?v=GfSzeAcsBb0).
- [Camera Systems](https://www.youtube.com/watch?v=ubZn7BlrnTU).
- [Scene Camera](https://www.youtube.com/watch?v=UKVFRRufKzo).
- [Native Scripting](https://www.youtube.com/watch?v=iIUhg88MK5M).
- [Native Scripting (now with virtual functions!)](https://www.youtube.com/watch?v=1cHEcrIn8IQ).
- [Scene Hierarchy Panel](https://www.youtube.com/watch?v=wziDnE8guvI).
- [Properties Panel](https://www.youtube.com/watch?v=NBpB0qscF3E).
- [Camera Component UI](https://www.youtube.com/watch?v=RIMt_6agUiU).
- [Drawing Component UI](https://www.youtube.com/watch?v=u3yq8s3KuSE).
- [Transform Component UI](https://www.youtube.com/watch?v=8JqcXYbzPJc).
- [Adding/Removing Entities and Components UI](https://www.youtube.com/watch?v=PsyGmsIgp9M).
- [Saving and Loading Scenes](https://www.youtube.com/watch?v=IEiOP7Y-Mbc).
- ... And so on.
[Check out](https://www.youtube.com/channel/UCQ-W1KE9EYfdxhL6S4twUNw) the
_Game Engine Series_ by The Cherno for more videos.
* [Warmonger Dynasty devlog series](https://david-delassus.medium.com/list/warmonger-dynasty-devlogs-f64b71f556de)
by [linkdd](https://github.com/linkdd): an interesting walkthrough of
developing a game (also) with EnTT.
* [Use EnTT When You Need An ECS](https://www.codingwiththomas.com/blog/use-entt-when-you-need-an-ecs)
by [Thomas](https://www.codingwiththomas.com/): I couldn't have said it
better.
* [Space Battle: Huge edition](http://victor.madtriangles.com/code%20experiment/2018/06/11/post-ecs-battle-huge.html):
huge space battle built entirely from scratch.
* [Space Battle](https://github.com/vblanco20-1/ECS_SpaceBattle): huge space
battle built on `UE4`.
* [Experimenting with ECS in UE4](http://victor.madtriangles.com/code%20experiment/2018/03/25/post-ue4-ecs-battle.html):
interesting article about `UE4` and `EnTT`.
* [Implementing ECS architecture in UE4](https://forums.unrealengine.com/development-discussion/c-gameplay-programming/1449913-implementing-ecs-architecture-in-ue4-giant-space-battle):
giant space battle.
* [Conan Adventures (SFML and EnTT in C++)](https://leinnan.github.io/blog/conan-adventuressfml-and-entt-in-c.html):
create projects in modern C++ using `SFML`, `EnTT`, `Conan` and `CMake`.
* [Adding EnTT ECS to Chrysalis](https://www.tauradius.com/post/adding-an-ecs-to-chrysalis/):
a blog entry (and its
[follow-up](https://www.tauradius.com/post/chrysalis-update-2020-08-02/))
about the integration of `EnTT` into `Chrysalis`, an action RPG SDK for
CRYENGINE games.
* [Creating Minecraft in One Week with C++ and Vulkan](https://vazgriz.com/189/creating-minecraft-in-one-week-with-c-and-vulkan/):
a crack at recreating Minecraft in one week using a custom C++ engine and
Vulkan ([code included](https://github.com/vazgriz/VoxelGame)).
* [Ability Creator](https://www.erichildebrand.net/blog/ability-creator-project-retrospect):
project retrospect by [Eric Hildebrand](https://www.erichildebrand.net/).
* [EnTT Entity Component System Gaming Library](https://gamefromscratch.com/entt-entity-component-system-gaming-library/):
`EnTT` on GameFromScratch.com.
* [Custom C++ server for UE5](https://youtu.be/fbXZVNCOvjM) optimized for
MMO(RPG)s and its [follow-up](https://youtu.be/yGlZeopx2hU) episode about
player bots and full external ECS: a series definitely worth looking at.
## Any Other Business:
* [ArcGIS Runtime SDKs](https://developers.arcgis.com/arcgis-runtime/) by
[Esri](https://www.esri.com/): they use `EnTT` for the internal ECS and the
cross platform C++ rendering engine. The SDKs are utilized by a lot of
enterprise custom apps, as well as by Esri for its own public applications
such as
[Explorer](https://play.google.com/store/apps/details?id=com.esri.explorer),
[Collector](https://play.google.com/store/apps/details?id=com.esri.arcgis.collector)
and
[Navigator](https://play.google.com/store/apps/details?id=com.esri.navigator).
* [FASTSUITE Edition 2](https://www.fastsuite.com/en_EN/fastsuite/fastsuite-edition-2.html)
by [Cenit](http://www.cenit.com/en_EN/about-us/overview.html): they use
`EnTT` to drive their simulation, that is, the communication between robot
controller emulator and renderer.
* [Ragdoll](https://ragdolldynamics.com/): real-time physics for Autodesk Maya
2020.
* [Project Lagrange](https://github.com/adobe/lagrange): a robust geometry
processing library by [Adobe](https://github.com/adobe).
* [AtomicDEX](https://github.com/KomodoPlatform/atomicDEX-Desktop): a secure
wallet and non-custodial decentralized exchange rolled into one application.
* [Apparently](https://www.linkedin.com/in/skypjack/)
[NIO](https://www.nio.io/): there was a collaboration to make some changes
to `EnTT`, at the time used for internal projects.
* [Apparently](https://www.linkedin.com/jobs/view/architekt-c%2B%2B-at-tieto-1219512333/)
[Tieto](https://www.tieto.com/): they published a job post where `EnTT` was
listed on their software stack.
* [Sequentity](https://github.com/alanjfs/sequentity): A MIDI-like
sequencer/tracker for C++ and `ImGui` (with `Magnum` and `EnTT`).
* [EnTT meets Sol2](https://github.com/skaarj1989/entt-meets-sol2): freely
available examples of how to combine `EnTT` and `Sol2`.
* [Godot meets EnTT](https://github.com/portaloffreedom/godot_entt_example/):
a simple example on how to use `EnTT` within
[`Godot`](https://godotengine.org/).
* [Godot and GameNetworkingSockets meet EnTT](https://github.com/portaloffreedom/godot_entt_net_example):
a simple example on how to use `EnTT` and
[`GameNetworkingSockets`](https://github.com/ValveSoftware/GameNetworkingSockets)
within [`Godot`](https://godotengine.org/).
* [MatchOneEntt](https://github.com/mhaemmerle/MatchOneEntt): port of
[Match One](https://github.com/sschmid/Match-One) for `Entitas-CSharp`.
* GitHub contains also
[many other examples](https://github.com/search?o=desc&q=%22skypjack%2Fentt%22&s=indexed&type=Code)
of use of `EnTT` from which to take inspiration if interested.

88
external/entt/entt/docs/md/locator.md vendored Normal file
View File

@ -0,0 +1,88 @@
# Crash Course: service locator
<!--
@cond TURN_OFF_DOXYGEN
-->
# Table of Contents
* [Introduction](#introduction)
* [Service locator](#service-locator)
* [Opaque handles](#opaque-handles)
<!--
@endcond TURN_OFF_DOXYGEN
-->
# Introduction
Usually, service locators are tightly bound to the services they expose and it's
hard to define a general purpose solution.<br/>
This tiny class tries to fill the gap and gets rid of the burden of defining a
different specific locator for each application.
# Service locator
The service locator API tries to mimic that of `std::optional` and adds some
extra functionalities on top of it such as allocator support.<br/>
There are a couple of functions to set up a service, namely `emplace` and
`allocate_emplace`:
```cpp
entt::locator<interface>::emplace<service>(argument);
entt::locator<interface>::allocate_emplace<service>(allocator, argument);
```
The difference is that the latter expects an allocator as the first argument and
uses it to allocate the service itself.<br/>
Once a service is set up, it's retrieved using the `value` function:
```cpp
interface &service = entt::locator<interface>::value();
```
Since the service may not be set (and therefore this function may result in an
undefined behavior), the `has_value` and `value_or` functions are also available
to test a service locator and to get a fallback service in case there is none:
```cpp
if(entt::locator<interface>::has_value()) {
// ...
}
interface &service = entt::locator<interface>::value_or<fallback_impl>(argument);
```
All arguments are used only if necessary, that is, if a service doesn't already
exist and therefore the fallback service is constructed and returned. In all
other cases, they are discarded.<br/>
Finally, to reset a service, use the `reset` function.
## Opaque handles
Sometimes it's useful to _transfer_ a copy of a service to another locator. For
example, when working across boundaries it's common to _share_ a service with a
dynamically loaded module.<br/>
Options aren't much in this case. Among these is the possibility of _exporting_
services and assigning them to a different locator.
This is what the `handle` and `reset` functions are meant for.<br/>
The former returns an opaque object useful for _exporting_ (or rather, obtaining
a reference to) a service. The latter also accepts an optional argument to a
handle which then allows users to reset a service by initializing it with an
opaque handle:
```cpp
auto handle = entt::locator<interface>::handle();
entt::locator<interface>::reset(handle);
```
It's worth noting that it's possible to get handles for uninitialized services
and use them with other locators. Of course, all a user will get is to have an
uninitialized service elsewhere as well.
Note that exporting a service allows users to _share_ the object currently set
in a locator. Replacing it won't replace the element even where a service has
been configured with a handle to the previous item.<br/>
In other words, if an audio service is replaced with a null object to silence an
application and the original service was shared, this operation won't propagate
to the other locators. Therefore, a module that share the ownership of the
original audio service is still able to emit sounds.

961
external/entt/entt/docs/md/meta.md vendored Normal file
View File

@ -0,0 +1,961 @@
# Crash Course: runtime reflection system
<!--
@cond TURN_OFF_DOXYGEN
-->
# Table of Contents
* [Introduction](#introduction)
* [Names and identifiers](#names-and-identifiers)
* [Reflection in a nutshell](#reflection-in-a-nutshell)
* [Any to the rescue](#any-to-the-rescue)
* [Enjoy the runtime](#enjoy-the-runtime)
* [Container support](#container-support)
* [Pointer-like types](#pointer-like-types)
* [Template information](#template-information)
* [Automatic conversions](#automatic-conversions)
* [Implicitly generated default constructor](#implicitly-generated-default-constructor)
* [From void to any](#from-void-to-any)
* [Policies: the more, the less](#policies-the-more-the-less)
* [Named constants and enums](#named-constants-and-enums)
* [Properties and meta objects](#properties-and-meta-objects)
* [Unregister types](#unregister-types)
* [Meta context](#meta-context)
<!--
@endcond TURN_OFF_DOXYGEN
-->
# Introduction
Reflection (or rather, its lack) is a trending topic in the C++ world and a tool
that can unlock a lot of interesting features in the specific case of `EnTT`. I
looked for a third-party library that met my needs on the subject, but I always
came across some details that I didn't like: macros, being intrusive, too many
allocations, and so on.<br/>
I finally decided to write a built-in, non-intrusive and macro-free runtime
reflection system for `EnTT`. Maybe I didn't do better than others or maybe yes,
time will tell me, but at least I can model this tool around the library to
which it belongs and not the opposite.
# Names and identifiers
The meta system doesn't force users to rely on the tools provided by the library
when it comes to working with names and identifiers. It does this by offering an
API that works with opaque identifiers that may or may not be generated by means
of a hashed string.<br/>
This means that users can assign any type of identifier to the meta objects, as
long as they're numeric. It doesn't matter if they're generated at runtime, at
compile-time or with custom functions.
That being said, the examples in the following sections are all based on the
`hashed_string` class as provided by this library. Therefore, where an
identifier is required, it's likely that a user defined literal is used as
follows:
```cpp
auto factory = entt::meta<my_type>().type("reflected_type"_hs);
```
For what it's worth, this is completely equivalent to:
```cpp
auto factory = entt::meta<my_type>().type(42u);
```
Obviously, human-readable identifiers are more convenient to use and highly
recommended.
# Reflection in a nutshell
Reflection always starts from actual C++ types. Users cannot reflect _imaginary_
types.<br/>
The `meta` function is where it all starts:
```cpp
auto factory = entt::meta<my_type>();
```
The returned value is a _factory object_ to use to continue building the meta
type.
By default, a meta type is associated with the identifier returned by the
runtime type identification system built-in in `EnTT`.<br/>
However, it's also possible to assign custom identifiers to meta types:
```cpp
auto factory = entt::meta<my_type>().type("reflected_type"_hs);
```
Identifiers are used to _retrieve_ meta types at runtime by _name_ other than by
type.<br/>
However, users can be interested in adding features to a reflected type so that
the reflection system can use it correctly under the hood, while they don't want
to also make the type _searchable_. In this case, it's sufficient not to invoke
`type`.
A factory is such that all its member functions return the factory itself. It's
generally used to create the following:
* _Constructors_. A constructors is assigned to a reflected type by specifying
its _list of arguments_. Free functions are also accepted if the return type
is the expected one. From a client perspective, nothing changes between a free
function or an actual constructor:
```cpp
entt::meta<my_type>().ctor<int, char>().ctor<&factory>();
```
Meta default constructors are implicitly generated, if possible.
* _Destructors_. Both free functions and member functions are valid destructors:
```cpp
entt::meta<my_type>().dtor<&destroy>();
```
The purpose is to offer the possibility to free up resources that require
_special treatment_ before an object is actually destroyed.<br/>
A function should neither delete nor explicitly invoke the destructor of a
given instance.
* _Data members_. Meta data members are actual data members of the underlying
type but also static and global variables or constants of any kind. From the
point of view of the client, all the variables associated with the reflected
type appear as if they were part of the type itself:
```cpp
entt::meta<my_type>()
.data<&my_type::static_variable>("static"_hs)
.data<&my_type::data_member>("member"_hs)
.data<&global_variable>("global"_hs);
```
The `data` function requires the identifier to use for the meta data member.
Users can then access it by _name_ at runtime.<br/>
Data members are also defined by means of a setter and getter pair. These are
either free functions, class members or a mix of them. This approach is also
convenient to create read-only properties from a non-const data member:
```cpp
entt::meta<my_type>().data<nullptr, &my_type::data_member>("member"_hs);
```
Multiple setters are also supported by means of a `value_list` object:
```cpp
entt::meta<my_type>().data<entt::value_list<&from_int, &from_string>, &my_type::data_member>("member"_hs);
```
* _Member functions_. Meta member functions are actual member functions of the
underlying type but also plain free functions. From the point of view of the
client, all the functions associated with the reflected type appear as if they
were part of the type itself:
```cpp
entt::meta<my_type>()
.func<&my_type::static_function>("static"_hs)
.func<&my_type::member_function>("member"_hs)
.func<&free_function>("free"_hs);
```
The `func` function requires the identifier to use for the meta data function.
Users can then access it by _name_ at runtime.<br/>
Overloading of meta functions is supported. Overloaded functions are resolved
at runtime by the reflection system according to the types of the arguments.
* _Base classes_. A base class is such that the underlying type is actually
derived from it:
```cpp
entt::meta<derived_type>().base<base_type>();
```
The reflection system tracks the relationship and allows for implicit casts at
runtime when required. In other terms, wherever a `base_type` is required, an
instance of `derived_type` is also accepted.
* _Conversion functions_. Conversion functions allow users to define conversions
that are implicitly performed by the reflection system when required:
```cpp
entt::meta<double>().conv<int>();
```
This is everything users need to create meta types. Refer to the inline
documentation for further details.
## Any to the rescue
The reflection system offers a kind of _extended version_ of the `entt::any`
class (see the core module for more details).<br/>
The purpose is to add some feature on top of those already present, so as to
integrate it with the meta type system without having to duplicate the code.
The API is very similar to that of the `any` type. The class `meta_any` _wraps_
many of the feature to infer a meta node, before forwarding some or all of the
arguments to the underlying storage.<br/>
Among the few relevant differences, `meta_any` adds support for containers and
pointer-like types, while `any` doesn't.<br/>
Similar to `any`, this class is also used to create _aliases_ for unmanaged
objects either with `forward_as_meta` or using the `std::in_place_type<T &>`
disambiguation tag, as well as from an existing object by means of the `as_ref`
member function.<br/>
Unlike `any` instead, `meta_any` treats an empty instance and one initialized
with `void` differently:
```cpp
entt::meta_any empty{};
entt::meta_any other{std::in_place_type<void>};
```
While `any` considers both as empty, `meta_any` treats objects initialized with
`void` as if they were _valid_ ones. This allows to differentiate between failed
function calls and function calls that are successful but return nothing.
Finally, the member functions `try_cast`, `cast` and `allow_cast` are used to
cast the underlying object to a given type (either a reference or a value type)
or to _convert_ a `meta_any` in such a way that a cast becomes viable for the
resulting object.<br/>
There is in fact no `any_cast` equivalent for `meta_any`.
## Enjoy the runtime
Once the web of reflected types is constructed, it's a matter of using it at
runtime where required.<br/>
There are a few options to search for a reflected type:
```cpp
// direct access to a reflected type
auto by_type = entt::resolve<my_type>();
// look up a reflected type by identifier
auto by_id = entt::resolve("reflected_type"_hs);
// look up a reflected type by type info
auto by_type_id = entt::resolve(entt::type_id<my_type>());
```
There exists also an overload of the `resolve` function to use to iterate all
reflected types at once. It returns an iterable object to be used in a range-for
loop:
```cpp
for(auto &&[id, type]: entt::resolve()) {
// ...
}
```
In all cases, the returned value is an instance of `meta_type` (possibly with
its id). This kind of objects offer an API to know their _runtime identifiers_,
to iterate all the meta objects associated with them and even to build instances
of the underlying type.<br/>
Meta data members and functions are accessed by name:
* Meta data members:
```cpp
auto data = entt::resolve<my_type>().data("member"_hs);
```
The returned type is `meta_data` and may be invalid if there is no meta data
object associated with the given identifier.<br/>
A meta data object offers an API to query the underlying type (for example, to
know if it's a const or a static one), to get the meta type of the variable
and to set or get the contained value.
* Meta function members:
```cpp
auto func = entt::resolve<my_type>().func("member"_hs);
```
The returned type is `meta_func` and may be invalid if there is no meta
function object associated with the given identifier.<br/>
A meta function object offers an API to query the underlying type (for
example, to know if it's a const or a static function), to know the number of
arguments, the meta return type and the meta types of the parameters. In
addition, a meta function object is used to invoke the underlying function and
then get the return value in the form of a `meta_any` object.
All the meta objects thus obtained as well as the meta types explicitly convert
to a boolean value to check for validity:
```cpp
if(auto func = entt::resolve<my_type>().func("member"_hs); func) {
// ...
}
```
Furthermore, all them (and a few more, like meta basis) are returned by a bunch
of overloads that provide the caller with iterable ranges of top-level elements.
As an example:
```cpp
for(auto &&[id, type]: entt::resolve<my_type>().base()) {
// ...
}
```
Meta type are also used to `construct` actual instances of the underlying
type.<br/>
In particular, the `construct` member function accepts a variable number of
arguments and searches for a match. It then returns a `meta_any` object that may
or may not be initialized, depending on whether a suitable constructor was found
or not.
There is no object that wraps the destructor of a meta type nor a `destroy`
member function in its API. Destructors are invoked implicitly by `meta_any`
behind the scenes and users have not to deal with them explicitly. Furthermore,
they've no name, cannot be searched and wouldn't have member functions to expose
anyway.<br/>
Similarly, conversion functions aren't directly accessible. They're used
internally by `meta_any` and the meta objects when needed.
Meta types and meta objects in general contain much more than what was said.
Refer to the inline documentation for further details.
## Container support
The runtime reflection system also supports containers of all types.<br/>
Moreover, _containers_ doesn't necessarily mean those offered by the C++
standard library. In fact, user defined data structures can also work with the
meta system in many cases.
To make a container be recognized as such by the meta system, users are required
to provide specializations for either the `meta_sequence_container_traits` class
or the `meta_associative_container_traits` class, according to the actual _type_
of the container.<br/>
`EnTT` already exports the specializations for some common classes. In
particular:
* `std::vector`, `std::array`, `std::deque` and `std::list` (but not
`std::forward_list`) are supported as _sequence containers_.
* `std::map`, `std::set` and their unordered counterparts are supported as
_associative containers_.
It's important to include the header file `container.hpp` to make these
specializations available to the compiler when needed.<br/>
The same file also contains many examples for the users that are interested in
making their own containers available to the meta system.
When a specialization of the `meta_sequence_container_traits` class exists, the
meta system treats the wrapped type as a sequence container. In a similar way,
a type is treated as an associative container if a specialization of the
`meta_associative_container_traits` class is found for it.<br/>
Proxy objects are returned by dedicated members of the `meta_any` class. The
following is a deliberately verbose example of how users can access a proxy
object for a sequence container:
```cpp
std::vector<int> vec{1, 2, 3};
entt::meta_any any = entt::forward_as_meta(vec);
if(any.type().is_sequence_container()) {
if(auto view = any.as_sequence_container(); view) {
// ...
}
}
```
The method to use to get a proxy object for associative containers is
`as_associative_container` instead.<br/>
It's not necessary to perform a double check actually. Instead, it's enough to
query the meta type or verify that the proxy object is valid. In fact, proxies
are contextually convertible to bool to check for validity. For example, invalid
proxies are returned when the wrapped object isn't a container.<br/>
In all cases, users aren't expected to _reflect_ containers explicitly. It's
sufficient to assign a container for which a specialization of the traits
classes exists to a `meta_any` object to be able to get its proxy object.
The interface of the `meta_sequence_container` proxy object is the same for all
types of sequence containers, although the available features differ from case
to case. In particular:
* The `value_type` member function returns the meta type of the elements.
* The `size` member function returns the number of elements in the container as
an unsigned integer value.
* The `resize` member function allows to resize the wrapped container and
returns true in case of success.<br/>
For example, it's not possible to resize fixed size containers.
* The `clear` member function allows to clear the wrapped container and returns
true in case of success.<br/>
For example, it's not possible to clear fixed size containers.
* The `begin` and `end` member functions return opaque iterators that is used to
iterate the container directly:
```cpp
for(entt::meta_any element: view) {
// ...
}
```
In all cases, given an underlying container of type `C`, the returned element
contains an object of type `C::value_type` which therefore depends on the
actual container.<br/>
All meta iterators are input iterators and don't offer an indirection operator
on purpose.
* The `insert` member function is used to add elements to the container. It
accepts a meta iterator and the element to insert:
```cpp
auto last = view.end();
// appends an integer to the container
view.insert(last, 42);
```
This function returns a meta iterator pointing to the inserted element and a
boolean value to indicate whether the operation was successful or not. A call
to `insert` may silently fail in case of fixed size containers or whether the
arguments aren't at least convertible to the required types.<br/>
Since meta iterators are contextually convertible to bool, users can rely on
them to know if the operation failed on the actual container or upstream, for
example due to an argument conversion problem.
* The `erase` member function is used to remove elements from the container. It
accepts a meta iterator to the element to remove:
```cpp
auto first = view.begin();
// removes the first element from the container
view.erase(first);
```
This function returns a meta iterator following the last removed element and a
boolean value to indicate whether the operation was successful or not. A call
to `erase` may silently fail in case of fixed size containers.
* The `operator[]` is used to access container elements. It accepts a single
argument, the position of the element to return:
```cpp
for(std::size_t pos{}, last = view.size(); pos < last; ++pos) {
entt::meta_any value = view[pos];
// ...
}
```
The function returns instances of `meta_any` that directly refer to the actual
elements. Modifying the returned object directly modifies the element inside
the container.<br/>
Depending on the underlying sequence container, this operation may not be as
efficient. For example, in the case of an `std::list`, a positional access
translates to a linear visit of the list itself (probably not what the user
expects).
Similarly, also the interface of the `meta_associative_container` proxy object
is the same for all types of associative containers. However, there are some
differences in behavior in the case of key-only containers. In particular:
* The `key_only` member function returns true if the wrapped container is a
key-only one.
* The `key_type` member function returns the meta type of the keys.
* The `mapped_type` member function returns an invalid meta type for key-only
containers and the meta type of the mapped values for all other types of
containers.
* The `value_type` member function returns the meta type of the elements.<br/>
For example, it returns the meta type of `int` for `std::set<int>` while it
returns the meta type of `std::pair<const int, char>` for
`std::map<int, char>`.
* The `size` member function returns the number of elements in the container as
an unsigned integer value.
* The `clear` member function allows to clear the wrapped container and returns
true in case of success.
* The `begin` and `end` member functions return opaque iterators that are used
to iterate the container directly:
```cpp
for(std::pair<entt::meta_any, entt::meta_any> element: view) {
// ...
}
```
In all cases, given an underlying container of type `C`, the returned element
is a key-value pair where the key has type `C::key_type` and the value has
type `C::mapped_type`. Since key-only containers don't have a mapped type,
their _value_ is nothing more than an invalid `meta_any` object.<br/>
All meta iterators are input iterators and don't offer an indirection operator
on purpose.
While the accessed key is usually constant in the associative containers and
is therefore returned by copy, the value (if any) is wrapped by an instance of
`meta_any` that directly refers to the actual element. Modifying it directly
modifies the element inside the container.
* The `insert` member function is used to add elements to a container. It gets
two arguments, respectively the key and the value to insert:
```cpp
auto last = view.end();
// appends an integer to the container
view.insert(last.handle(), 42, 'c');
```
This function returns a boolean value to indicate whether the operation was
successful or not. A call to `insert` may fail when the arguments aren't at
least convertible to the required types.
* The `erase` member function is used to remove elements from a container. It
gets a single argument, the key to remove:
```cpp
view.erase(42);
```
This function returns a boolean value to indicate whether the operation was
successful or not. A call to `erase` may fail when the argument isn't at least
convertible to the required type.
* The `operator[]` is used to access elements in a container. It gets a single
argument, the key of the element to return:
```cpp
entt::meta_any value = view[42];
```
The function returns instances of `meta_any` that directly refer to the actual
elements. Modifying the returned object directly modifies the element inside
the container.
Container support is minimal but likely sufficient to satisfy all needs.
## Pointer-like types
As with containers, it's also possible to _tell_ to the meta system which types
are _pointers_. This makes it possible to dereference instances of `meta_any`,
thus obtaining light _references_ to pointed objects that are also correctly
associated with their meta types.<br/>
To make the meta system recognize a type as _pointer-like_, users can specialize
the `is_meta_pointer_like` class. `EnTT` already exports the specializations for
some common classes. In particular:
* All types of raw pointers.
* `std::unique_ptr` and `std::shared_ptr`.
It's important to include the header file `pointer.hpp` to make these
specializations available to the compiler when needed.<br/>
The same file also contains many examples for the users that are interested in
making their own pointer-like types available to the meta system.
When a type is recognized as a pointer-like one by the meta system, it's
possible to dereference the instances of `meta_any` that contain these objects.
The following is a deliberately verbose example to show how to use this feature:
```cpp
int value = 42;
// meta type equivalent to that of int *
entt::meta_any any{&value};
if(any.type().is_pointer_like()) {
// meta type equivalent to that of int
if(entt::meta_any ref = *any; ref) {
// ...
}
}
```
It's not necessary to perform a double check. Instead, it's enough to query the
meta type or verify that the returned object is valid. For example, invalid
instances are returned when the wrapped object isn't a pointer-like type.<br/>
Dereferencing a pointer-like object returns an instance of `meta_any` which
_refers_ to the pointed object. Modifying it means modifying the pointed object
directly (unless the returned element is const).
In general, _dereferencing_ a pointer-like type boils down to a `*ptr`. However,
`EnTT` also supports classes that don't offer an `operator*`. In particular:
* It's possible to exploit a solution based on ADL lookup by offering a function
(also a template one) named `dereference_meta_pointer_like`:
```cpp
template<typename Type>
Type & dereference_meta_pointer_like(const custom_pointer_type<Type> &ptr) {
return ptr.deref();
}
```
* When not in control of the type's namespace, it's possible to inject into the
`entt` namespace a specialization of the `adl_meta_pointer_like` class
template to bypass the adl lookup as a whole:
```cpp
template<typename Type>
struct entt::adl_meta_pointer_like<custom_pointer_type<Type>> {
static decltype(auto) dereference(const custom_pointer_type<Type> &ptr) {
return ptr.deref();
}
};
```
In all other cases and when dereferencing a pointer works as expected regardless
of the pointed type, no user intervention is required.
## Template information
Meta types also provide a minimal set of information about the _nature_ of the
original type in case it's a class template.<br/>
By default, this works out of the box and requires no user action. However, it's
important to include the header file `template.hpp` to make this information
available to the compiler when needed.
Meta template information are easily found:
```cpp
// this method returns true if the type is recognized as a class template specialization
if(auto type = entt::resolve<std::shared_ptr<my_type>>(); type.is_template_specialization()) {
// meta type of the class template conveniently wrapped by entt::meta_class_template_tag
auto class_type = type.template_type();
// number of template arguments
std::size_t arity = type.template_arity();
// meta type of the i-th argument
auto arg_type = type.template_arg(0u);
}
```
Typically, when template information for a type are required, what the library
provides is sufficient. However, there are some cases where a user may want more
details or a different set of information.<br/>
Consider the case of a class template that is meant to wrap function types:
```cpp
template<typename>
struct function_type;
template<typename Ret, typename... Args>
struct function_type<Ret(Args...)> {};
```
In this case, rather than the function type, it might be useful to provide the
return type and unpacked arguments as if they were different template parameters
for the original class template.<br/>
To achieve this, users must enter the library internals and provide their own
specialization for the class template `entt::meta_template_traits`, such as:
```cpp
template<typename Ret, typename... Args>
struct entt::meta_template_traits<function_type<Ret(Args...)>> {
using class_type = meta_class_template_tag<function_type>;
using args_type = type_list<Ret, Args...>;
};
```
The reflection system doesn't verify the accuracy of the information nor infer a
correspondence between real types and meta types.<br/>
Therefore, the specialization is used as is and the information it contains is
associated with the appropriate type when required.
## Automatic conversions
In C++, there are a number of conversions allowed between arithmetic types that
make it convenient to work with this kind of data.<br/>
If this were to be translated into explicit registrations with the reflection
system, it would result in a long series of instructions such as the following:
```cpp
entt::meta<int>()
.conv<bool>()
.conv<char>()
// ...
.conv<double>();
```
Repeated for each type eligible to undergo this type of conversions. This is
both error-prone and repetitive.<br/>
Similarly, the language allows users to silently convert unscoped enums to their
underlying types and offers what it takes to do the same for scoped enums. It
would result in the following if it were to be done explicitly:
```cpp
entt::meta<my_enum>()
.conv<std::underlying_type_t<my_enum>>();
```
Fortunately, all of this can also be avoided. `EnTT` offers implicit support for
these types of conversions:
```cpp
entt::meta_any any{42};
any.allow_cast<double>();
double value = any.cast<double>();
```
With no need for registration, the conversion takes place automatically under
the hood. The same goes for a call to `allow_cast` involving a meta type:
```cpp
entt::meta_type type = entt::resolve<int>();
entt::meta_any any{my_enum::a_value};
any.allow_cast(type);
int value = any.cast<int>();
```
This makes working with arithmetic types and scoped or unscoped enums as easy as
it is in C++.<br/>
It's still possible to set up conversion functions manually and these are always
preferred over the automatic ones.
## Implicitly generated default constructor
Creating objects of default constructible types through the reflection system
while not having to explicitly register the meta type or its default constructor
is also possible.<br/>
For example, in the case of primitive types like `int` or `char`, but not just
them.
For default constructible types only, default constructors are automatically
defined and associated with their meta types, whether they are explicitly or
implicitly generated.<br/>
Therefore, this is all is needed to construct an integer from its meta type:
```cpp
entt::resolve<int>().construct();
```
Where the meta type is for example the one returned from a meta container,
useful for building keys without knowing or having to register the actual types.
In all cases, when users register default constructors, they are preferred both
during searches and when the `construct` member function is invoked.
## From void to any
Sometimes all a user has is an opaque pointer to an object of a known meta type.
It would be handy in this case to be able to construct a `meta_any` element from
it.<br/>
For this purpose, the `meta_type` class offers a `from_void` member function
designed to convert an opaque pointer into a `meta_any`:
```cpp
entt::meta_any any = entt::resolve(id).from_void(element);
```
Unfortunately, it's not possible to do a check on the actual type. Therefore,
this call can be considered as a _static cast_ with all its _problems_.<br/>
On the other hand, the ability to construct a `meta_any` from an opaque pointer
opens the door to some pretty interesting uses that are worth exploring.
## Policies: the more, the less
Policies are a kind of compile-time directives that can be used when registering
reflection information.<br/>
Their purpose is to require slightly different behavior than the default in some
specific cases. For example, when reading a given data member, its value is
returned wrapped in a `meta_any` object which, by default, makes a copy of it.
For large objects or if the caller wants to access the original instance, this
behavior isn't desirable. Policies are there to offer a solution to this and
other problems.
There are a few alternatives available at the moment:
* The _as-is_ policy, associated with the type `entt::as_is_t`.<br/>
This is the default policy. In general, it should never be used explicitly,
since it's implicitly selected if no other policy is specified.<br/>
In this case, the return values of the functions as well as the properties
exposed as data members are always returned by copy in a dedicated wrapper and
therefore associated with their original meta types.
* The _as-void_ policy, associated with the type `entt::as_void_t`.<br/>
Its purpose is to discard the return value of a meta object, whatever it is,
thus making it appear as if its type were `void`:
```cpp
entt::meta<my_type>().func<&my_type::member_function, entt::as_void_t>("member"_hs);
```
If the use with functions is obvious, perhaps less so is use with constructors
and data members. In the first case, the returned wrapper is always empty even
though the constructor is still invoked. In the second case, the property
isn't accessible for reading instead.
* The _as-ref_ and _as-cref_ policies, associated with the types
`entt::as_ref_t` and `entt::as_cref_t`.<br/>
They allow to build wrappers that act as references to unmanaged objects.
Accessing the object contained in the wrapper for which the _reference_ was
requested makes it possible to directly access the instance used to initialize
the wrapper itself:
```cpp
entt::meta<my_type>().data<&my_type::data_member, entt::as_ref_t>("member"_hs);
```
These policies work with constructors (for example, when objects are taken
from an external container rather than created on demand), data members and
functions in general.<br/>
If on the one hand `as_cref_t` always forces the return type to be const,
`as_ref_t` _adapts_ to the constness of the passed object and to that of the
return type if any.
Some uses are rather trivial, but it's useful to note that there are some less
obvious corner cases that can in turn be solved with the use of policies.
## Named constants and enums
As mentioned, the `data` member function is used to reflect constants of any
type.<br/>
This allows users to create meta types for enums that work exactly like any
other meta type built from a class. Similarly, arithmetic types are _enriched_
with constants of special meaning where required.<br/>
All values thus exported appear to users as if they were constant data members
of the reflected types. This avoids the need to _export_ what is the difference
between enums and classes in C++ directly in the space of the reflected types.
Exposing constant values or elements from an enum is quite simple:
```cpp
entt::meta<my_enum>()
.data<my_enum::a_value>("a_value"_hs)
.data<my_enum::another_value>("another_value"_hs);
entt::meta<int>().data<2048>("max_int"_hs);
```
Accessing them is trivial as well. It's a matter of doing the following, as with
any other data member of a meta type:
```cpp
auto value = entt::resolve<my_enum>().data("a_value"_hs).get({}).cast<my_enum>();
auto max = entt::resolve<int>().data("max_int"_hs).get({}).cast<int>();
```
All this happens behind the scenes without any allocation because of the small
object optimization performed by the `meta_any` class.
## Properties and meta objects
Sometimes (for example, when it comes to creating an editor) it might be useful
to attach properties to the meta objects created. Fortunately, this is possible
for most of them:
```cpp
entt::meta<my_type>().type("reflected_type"_hs).prop("tooltip"_hs, "message");
```
Properties are always in the key/value form. The key is a numeric identifier,
mostly similar to the identifier used to register meta objects. There are no
restrictions on the type of the value instead, as long as it's movable.<br/>
Key only properties are also supported out of the box:
```cpp
entt::meta<my_type>().type("reflected_type"_hs).prop(my_enum::key_only);
```
To attach multiple properties to a meta object, just invoke `prop` more than
once.<br/>
It's also possible to call `prop` at different times, as long as the factory is
reset to the meta object of interest.
The meta objects for which properties are supported are currently meta types,
meta data and meta functions.<br/>
These types also offer a couple of member functions named `prop` to iterate all
properties at once or to search a specific property by key:
```cpp
// iterate all properties of a meta type
for(auto &&[id, prop]: entt::resolve<my_type>().prop()) {
// ...
}
// search for a given property by name
auto prop = entt::resolve<my_type>().prop("tooltip"_hs);
```
Meta properties are objects having a fairly poor interface, all in all. They
only provide the `value` member function to retrieve the contained value in the
form of a `meta_any` object.
## Unregister types
A type registered with the reflection system can also be _unregistered_. This
means unregistering all its data members, member functions, conversion functions
and so on. However, base classes aren't unregistered as well, since they don't
necessarily depend on it.<br/>
Roughly speaking, unregistering a type means disconnecting all associated meta
objects from it and making its identifier no longer available:
```cpp
entt::meta_reset<my_type>();
```
It's also possible to reset types by their unique identifiers:
```cpp
entt::meta_reset("my_type"_hs);
```
Finally, there exists a non-template overload of the `meta_reset` function that
doesn't accept arguments and resets all meta types at once:
```cpp
entt::meta_reset();
```
A type can be re-registered later with a completely different name and form.
## Meta context
All meta types and their parts are created at runtime and stored in a default
_context_. This is obtained via a service locator as:
```cpp
auto &&context = entt::locator<entt::meta_context>::value_or();
```
By itself, a context is an opaque object that the user cannot do much with.
However, users can replace an existing context with another at any time:
```cpp
entt::meta_context other{};
auto &&context = entt::locator<entt::meta_context>::value_or();
std::swap(context, other);
```
This is useful for testing purposes or to define multiple context objects with
different meta type to use as appropriate.
If _replacing_ the default context isn't enough, `EnTT` also offers the ability
to use multiple and externally managed contexts with the runtime reflection
system.<br/>
For example, to create new meta types within a context other than the default
one, simply pass it as an argument to the `meta` call:
```cpp
entt::meta_ctx context{};
auto factory = entt::meta<my_type>(context).type("reflected_type"_hs);
```
By doing so, the new meta type isn't available in the default context but is
usable by passing around the new context when needed, such as when creating a
new `meta_any` object:
```cpp
entt::meta_any any{context, std::in_place_type<my_type>};
```
Similarly, to search for meta types in a context other than the default one,
it's necessary to pass it to the `resolve` function:
```cpp
entt::meta_type type = entt::resolve(context, "reflected_type"_hs)
```
More generally, when using externally managed contexts, it's always required to
provide the system with the context to use, at least at the _entry point_.<br/>
For example, once the `meta_type` instant is obtained, it's no longer necessary
to pass the context around as the meta type takes the information with it and
eventually propagates it to all its parts.<br/>
On the other hand, it's necessary to instruct the library on where meta types
are to be fetched when `meta_any`s and `meta_handle`s are constructed, a factory
created or a meta type resolved.

357
external/entt/entt/docs/md/poly.md vendored Normal file
View File

@ -0,0 +1,357 @@
# Crash Course: poly
<!--
@cond TURN_OFF_DOXYGEN
-->
# Table of Contents
* [Introduction](#introduction)
* [Other libraries](#other-libraries)
* [Concept and implementation](#concept-and-implementation)
* [Deduced interface](#deduced-interface)
* [Defined interface](#defined-interface)
* [Fulfill a concept](#fulfill-a-concept)
* [Inheritance](#inheritance)
* [Static polymorphism in the wild](#static-polymorphism-in-the-wild)
* [Storage size and alignment requirement](#storage-size-and-alignment-requirement)
<!--
@endcond TURN_OFF_DOXYGEN
-->
# Introduction
Static polymorphism is a very powerful tool in C++, albeit sometimes cumbersome
to obtain.<br/>
This module aims to make it simple and easy to use.
The library allows to define _concepts_ as interfaces to fulfill with concrete
classes without having to inherit from a common base.<br/>
Among others, this is one of the advantages of static polymorphism in general
and of a generic wrapper like that offered by the `poly` class template in
particular.<br/>
The result is an object to pass around as such and not through a reference or a
pointer, as it happens when it comes to working with dynamic polymorphism.
Since the `poly` class template makes use of `entt::any` internally, it also
supports most of its feature. For example, the possibility to create aliases to
existing and thus unmanaged objects. This allows users to exploit the static
polymorphism while maintaining ownership of objects.<br/>
Likewise, the `poly` class template also benefits from the small buffer
optimization offered by the `entt::any` class and therefore minimizes the number
of allocations, avoiding them altogether where possible.
## Other libraries
There are some very interesting libraries regarding static polymorphism.<br/>
The ones that I like more are:
* [`dyno`](https://github.com/ldionne/dyno): runtime polymorphism done right.
* [`Poly`](https://github.com/facebook/folly/blob/master/folly/docs/Poly.md):
a class template that makes it easy to define a type-erasing polymorphic
object wrapper.
The former is admittedly an experimental library, with many interesting ideas.
I've some doubts about the usefulness of some feature in real world projects,
but perhaps my lack of experience comes into play here. In my opinion, its only
flaw is the API which I find slightly more cumbersome than other solutions.<br/>
The latter was undoubtedly a source of inspiration for this module, although I
opted for different choices in the implementation of both the final API and some
feature.
Either way, the authors are gurus of the C++ community, people I only have to
learn from.
# Concept and implementation
The first thing to do to create a _type-erasing polymorphic object wrapper_ (to
use the terminology introduced by Eric Niebler) is to define a _concept_ that
types will have to adhere to.<br/>
For this purpose, the library offers a single class that supports both deduced
and fully defined interfaces. Although having interfaces deduced automatically
is convenient and allows users to write less code in most cases, it has some
limitations and it's therefore useful to be able to get around the deduction by
providing a custom definition for the static virtual table.
Once the interface is defined, a generic implementation is needed to fulfill the
concept itself.<br/>
Also in this case, the library allows customizations based on types or families
of types, so as to be able to go beyond the generic case where necessary.
## Deduced interface
This is how a concept with a deduced interface is defined:
```cpp
struct Drawable: entt::type_list<> {
template<typename Base>
struct type: Base {
void draw() { this->template invoke<0>(*this); }
};
// ...
};
```
It's recognizable by the fact that it inherits from an empty type list.<br/>
Functions can also be const, accept any number of parameters and return a type
other than `void`:
```cpp
struct Drawable: entt::type_list<> {
template<typename Base>
struct type: Base {
bool draw(int pt) const { return this->template invoke<0>(*this, pt); }
};
// ...
};
```
In this case, all parameters are passed to `invoke` after the reference to
`this` and the return value is whatever the internal call returns.<br/>
As for `invoke`, this is a name that is injected into the _concept_ through
`Base`, from which one must necessarily inherit. Since it's also a dependent
name, the `this-> template` form is unfortunately necessary due to the rules of
the language. However, there also exists an alternative that goes through an
external call:
```cpp
struct Drawable: entt::type_list<> {
template<typename Base>
struct type: Base {
void draw() const { entt::poly_call<0>(*this); }
};
// ...
};
```
Once the _concept_ is defined, users must provide a generic implementation of it
in order to tell the system how any type can satisfy its requirements. This is
done via an alias template within the concept itself.<br/>
The index passed as a template parameter to either `invoke` or `poly_call`
refers to how this alias is defined.
## Defined interface
A fully defined concept is no different to one for which the interface is
deduced, with the only difference that the list of types is not empty this time:
```cpp
struct Drawable: entt::type_list<void()> {
template<typename Base>
struct type: Base {
void draw() { entt::poly_call<0>(*this); }
};
// ...
};
```
Again, parameters and return values other than `void` are allowed. Also, the
function type must be const when the method to bind to it is const:
```cpp
struct Drawable: entt::type_list<bool(int) const> {
template<typename Base>
struct type: Base {
bool draw(int pt) const { return entt::poly_call<0>(*this, pt); }
};
// ...
};
```
Why should a user fully define a concept if the function types are the same as
the deduced ones?<br>
In fact, this is the limitation that can be worked around by manually defining
the static virtual table.
When things are deduced, there is an implicit constraint.<br/>
If the concept exposes a member function called `draw` with function type
`void()`, a concept is satisfied:
* Either by a class that exposes a member function with the same name and the
same signature.
* Or through a lambda that makes use of existing member functions from the
interface itself.
In other words, it's not possible to make use of functions not belonging to the
interface, even if they're part of the types that fulfill the concept.<br/>
Similarly, it's not possible to deduce a function in the static virtual table
with a function type different from that of the associated member function in
the interface itself.
Explicitly defining a static virtual table suppresses the deduction step and
allows maximum flexibility when providing the implementation for a concept.
## Fulfill a concept
The `impl` alias template of a concept is used to define how it's fulfilled:
```cpp
struct Drawable: entt::type_list<> {
// ...
template<typename Type>
using impl = entt::value_list<&Type::draw>;
};
```
In this case, it's stated that the `draw` method of a generic type is enough to
satisfy the requirements of the `Drawable` concept.<br/>
Both member functions and free functions are supported to fulfill concepts:
```cpp
template<typename Type>
void print(Type &self) { self.print(); }
struct Drawable: entt::type_list<void()> {
// ...
template<typename Type>
using impl = entt::value_list<&print<Type>>;
};
```
Likewise, as long as the parameter types and return type support conversions to
and from those of the function type referenced in the static virtual table, the
actual implementation may differ in its function type since it's erased
internally.<br/>
Moreover, the `self` parameter isn't strictly required by the system and can be
left out for free functions if not required.
Refer to the inline documentation for more details.
# Inheritance
_Concept inheritance_ is straightforward due to how poly looks like in `EnTT`.
Therefore, it's quite easy to build hierarchies of concepts if necessary.<br/>
The only constraint is that all concepts in a hierarchy must belong to the same
_family_, that is, they must be either all deduced or all defined.
For a deduced concept, inheritance is achieved in a few steps:
```cpp
struct DrawableAndErasable: entt::type_list<> {
template<typename Base>
struct type: typename Drawable::template type<Base> {
static constexpr auto base = std::tuple_size_v<typename entt::poly_vtable<Drawable>::type>;
void erase() { entt::poly_call<base + 0>(*this); }
};
template<typename Type>
using impl = entt::value_list_cat_t<
typename Drawable::impl<Type>,
entt::value_list<&Type::erase>
>;
};
```
The static virtual table is empty and must remain so.<br/>
On the other hand, `type` no longer inherits from `Base`. Instead, it forwards
its template parameter to the type exposed by the _base class_. Internally, the
_size_ of the static virtual table of the base class is used as an offset for
the local indexes.<br/>
Finally, by means of the `value_list_cat_t` utility, the implementation consists
in appending the new functions to the previous list.
As for a defined concept instead, the list of types is _extended_ in a similar
way to what is shown for the implementation of the above concept.<br/>
To do this, it's useful to declare a function that allows to convert a _concept_
into its underlying `type_list` object:
```cpp
template<typename... Type>
entt::type_list<Type...> as_type_list(const entt::type_list<Type...> &);
```
The definition isn't strictly required, since the function is only used through
a `decltype` as it follows:
```cpp
struct DrawableAndErasable: entt::type_list_cat_t<
decltype(as_type_list(std::declval<Drawable>())),
entt::type_list<void()>
> {
// ...
};
```
Similar to above, `type_list_cat_t` is used to concatenate the underlying static
virtual table with the new function types.<br/>
Everything else is the same as already shown instead.
# Static polymorphism in the wild
Once the _concept_ and implementation are defined, it's possible to use the
`poly` class template to _wrap_ instances that meet the requirements:
```cpp
using drawable = entt::poly<Drawable>;
struct circle {
void draw() { /* ... */ }
};
struct square {
void draw() { /* ... */ }
};
// ...
drawable instance{circle{}};
instance->draw();
instance = square{};
instance->draw();
```
This class offers a wide range of constructors, from the default one (which
returns an uninitialized `poly` object) to the copy and move constructors, as
well as the ability to create objects in-place.<br/>
Among others, there is also a constructor that allows users to wrap unmanaged
objects in a `poly` instance (either const or non-const ones):
```cpp
circle shape;
drawable instance{std::in_place_type<circle &>, shape};
```
Similarly, it's possible to create non-owning copies of `poly` from an existing
object:
```cpp
drawable other = instance.as_ref();
```
In both cases, although the interface of the `poly` object doesn't change, it
doesn't construct any element or take care of destroying the referenced objects.
Note also how the underlying concept is accessed via a call to `operator->` and
not directly as `instance.draw()`.<br/>
This allows users to decouple the API of the wrapper from that of the concept.
Therefore, where `instance.data()` invokes the `data` member function of the
poly object, `instance->data()` maps directly to the functionality exposed by
the underlying concept.
# Storage size and alignment requirement
Under the hood, the `poly` class template makes use of `entt::any`. Therefore,
it can take advantage of the possibility of defining at compile-time the size of
the storage suitable for the small buffer optimization as well as the alignment
requirements:
```cpp
entt::basic_poly<Drawable, sizeof(double[4]), alignof(double[4])>
```
The default size is `sizeof(double[2])`, which seems like a good compromise
between a buffer that is too large and one unable to hold anything larger than
an integer. The alignment requirement is optional and by default such that it's
the most stringent (the largest) for any object whose size is at most equal to
the one provided.<br/>
It's worth noting that providing a size of 0 (which is an accepted value in all
respects) will force the system to dynamically allocate the contained objects in
all cases.

217
external/entt/entt/docs/md/process.md vendored Normal file
View File

@ -0,0 +1,217 @@
# Crash Course: cooperative scheduler
<!--
@cond TURN_OFF_DOXYGEN
-->
# Table of Contents
* [Introduction](#introduction)
* [The process](#the-process)
* [Adaptor](#adaptor)
* [The scheduler](#the-scheduler)
<!--
@endcond TURN_OFF_DOXYGEN
-->
# Introduction
Processes are a useful tool to work around the strict definition of a system and
introduce logic in a different way, usually without resorting to other component
types.<br/>
`EnTT` offers minimal support to this paradigm by introducing a few classes used
to define and execute cooperative processes.
# The process
A typical task inherits from the `process` class template that stays true to the
CRTP idiom. Moreover, derived classes specify what the intended type for elapsed
times is.
A process should expose publicly the following member functions whether needed
(note that it isn't required to define a function unless the derived class wants
to _override_ the default behavior):
* `void update(Delta, void *);`
This is invoked once per tick until a process is explicitly aborted or ends
either with or without errors. Even though it's not mandatory to declare this
member function, as a rule of thumb each process should at least define it to
work _properly_. The `void *` parameter is an opaque pointer to user data (if
any) forwarded directly to the process during an update.
* `void init();`
This is invoked when the process joins the running queue of a scheduler. It
happens usually as soon as the process is attached to the scheduler if it's a
top level one, otherwise when it replaces its parent if it's a _continuation_.
* `void succeeded();`
This is invoked in case of success, immediately after an update and during the
same tick.
* `void failed();`
This is invoked in case of errors, immediately after an update and during the
same tick.
* `void aborted();`
This is invoked only if a process is explicitly aborted. There is no guarantee
that it executes in the same tick, it depends solely on whether the process is
aborted immediately or not.
Derived classes can also change the internal state of a process by invoking
`succeed` and `fail`, as well as `pause` and `unpause` the process itself.<br/>
All these are protected member functions made available to manage the life cycle
of a process from a derived class.
Here is a minimal example for the sake of curiosity:
```cpp
struct my_process: entt::process<my_process, std::uint32_t> {
using delta_type = std::uint32_t;
my_process(delta_type delay)
: remaining{delay}
{}
void update(delta_type delta, void *) {
remaining -= std::min(remaining, delta);
// ...
if(!remaining) {
succeed();
}
}
private:
delta_type remaining;
};
```
## Adaptor
Lambdas and functors can't be used directly with a scheduler because they aren't
properly defined processes with managed life cycles.<br/>
This class helps in filling the gap and turning lambdas and functors into
full-featured processes usable by a scheduler.
The function call operator has a signature similar to the one of the `update`
function of a process but for the fact that it receives two extra callbacks to
invoke whenever a process terminates with success or with an error:
```cpp
void(Delta delta, void *data, auto succeed, auto fail);
```
Parameters have the following meaning:
* `delta` is the elapsed time.
* `data` is an opaque pointer to user data if any, `nullptr` otherwise.
* `succeed` is a function to call when a process terminates with success.
* `fail` is a function to call when a process terminates with errors.
Both `succeed` and `fail` accept no parameters at all.
Note that usually users shouldn't worry about creating adaptors at all. A
scheduler creates them internally each and every time a lambda or a functor is
used as a process.
# The scheduler
A cooperative scheduler runs different processes and helps managing their life
cycles.
Each process is invoked once per tick. If it terminates, it's removed
automatically from the scheduler and it's never invoked again. Otherwise, it's
a good candidate to run one more time the next tick.<br/>
A process can also have a _child_. In this case, the parent process is replaced
with its child when it terminates and only if it returns with success. In case
of errors, both the parent process and its child are discarded. This way, it's
easy to create chain of processes to run sequentially.
Using a scheduler is straightforward. To create it, users must provide only the
type for the elapsed times and no arguments at all:
```cpp
entt::basic_scheduler<std::uint64_t> scheduler;
```
Otherwise, the `scheduler` alias is also available for the most common cases. It
uses `std::uint32_t` as a default type:
```cpp
entt::scheduler scheduler;
```
The class has member functions to query its internal data structures, like
`empty` or `size`, as well as a `clear` utility to reset it to a clean state:
```cpp
// checks if there are processes still running
const auto empty = scheduler.empty();
// gets the number of processes still running
entt::scheduler::size_type size = scheduler.size();
// resets the scheduler to its initial state and discards all the processes
scheduler.clear();
```
To attach a process to a scheduler there are mainly two ways:
* If the process inherits from the `process` class template, it's enough to
indicate its type and submit all the parameters required to construct it to
the `attach` member function:
```cpp
scheduler.attach<my_process>(1000u);
```
* Otherwise, in case of a lambda or a functor, it's enough to provide an
instance of the class to the `attach` member function:
```cpp
scheduler.attach([](auto...){ /* ... */ });
```
In both cases, the return value is an opaque object that offers a `then` member
function used to create chains of processes to run sequentially.<br/>
As a minimal example of use:
```cpp
// schedules a task in the form of a lambda function
scheduler.attach([](auto delta, void *, auto succeed, auto fail) {
// ...
})
// appends a child in the form of another lambda function
.then([](auto delta, void *, auto succeed, auto fail) {
// ...
})
// appends a child in the form of a process class
.then<my_process>(1000u);
```
To update a scheduler and therefore all its processes, the `update` member
function is the way to go:
```cpp
// updates all the processes, no user data are provided
scheduler.update(delta);
// updates all the processes and provides them with custom data
scheduler.update(delta, &data);
```
In addition to these functions, the scheduler offers an `abort` member function
that is used to discard all the running processes at once:
```cpp
// aborts all the processes abruptly ...
scheduler.abort(true);
// ... or gracefully during the next tick
scheduler.abort();
```

91
external/entt/entt/docs/md/reference.md vendored Normal file
View File

@ -0,0 +1,91 @@
# Similar projects
<!--
@cond TURN_OFF_DOXYGEN
-->
# Table of Contents
* [Introduction](#introduction)
* [Similar projects](#similar-projects)
<!--
@endcond TURN_OFF_DOXYGEN
-->
# Introduction
There are many projects similar to `EnTT`, both open source and not.<br/>
Some even borrowed some ideas from this library and expressed them in different
languages.<br/>
Others developed different architectures from scratch and therefore offer
alternative solutions with their pros and cons.
If you know of other similar projects out there, feel free to open an issue or a
PR and I'll be glad to add them to this page.<br/>
I hope the following lists can grow much more in the future.
# Similar projects
Below an incomplete list of similar projects that I've come across so far.<br/>
If some terms or designs aren't clear, I recommend referring to the
[_ECS Back and Forth_](https://skypjack.github.io/tags/#ecs) series for all the
details.
* C:
* [destral_ecs](https://github.com/roig/destral_ecs): a single-file ECS based
on sparse sets.
* [Diana](https://github.com/discoloda/Diana): an ECS that uses sparse sets to
keep track of entities in systems.
* [Flecs](https://github.com/SanderMertens/flecs): a multithreaded archetype
ECS based on semi-contiguous arrays rather than chunks.
* [lent](https://github.com/nem0/lent): the Donald Trump of the ECS libraries.
* C++:
* [decs](https://github.com/vblanco20-1/decs): a chunk based archetype ECS.
* [ecst](https://github.com/SuperV1234/ecst): a multithreaded compile-time
ECS that uses sparse sets to keep track of entities in systems.
* [EntityX](https://github.com/alecthomas/entityx): a bitset based ECS that
uses a single large matrix of components indexed with entities.
* [Gaia-ECS](https://github.com/richardbiely/gaia-ecs): a chunk based
archetype ECS.
* [Polypropylene](https://github.com/pmbittner/Polypropylene): a hybrid
solution between an ECS and dynamic mixins.
* C#
* [Arch](https://github.com/genaray/Arch): a simple, fast and _unity entities_
inspired archetype ECS with optional multithreading.
* [Entitas](https://github.com/sschmid/Entitas-CSharp): the ECS framework for
C# and Unity, where _reactive systems_ were invented.
* [LeoECS](https://github.com/Leopotam/ecs): simple lightweight C# Entity
Component System framework.
* [Svelto.ECS](https://github.com/sebas77/Svelto.ECS): a very interesting
platform agnostic and table based ECS framework.
* Go:
* [gecs](https://github.com/tutumagi/gecs): a sparse sets based ECS inspired
by `EnTT`.
* Javascript:
* [\@javelin/ecs](https://github.com/3mcd/javelin/tree/master/packages/ecs):
an archetype ECS in TypeScript.
* [ecsy](https://github.com/MozillaReality/ecsy): I haven't had the time to
investigate the underlying design of `ecsy` but it looks cool anyway.
* Perl:
* [Game::Entities](https://gitlab.com/jjatria/perl-game-entities): a simple
entity registry for ECS designs inspired by `EnTT`.
* Raku:
* [Game::Entities](https://gitlab.com/jjatria/raku-game-entities): a simple
entity registry for ECS designs inspired by `EnTT`.
* Rust:
* [Legion](https://github.com/TomGillen/legion): a chunk based archetype ECS.
* [Shipyard](https://github.com/leudz/shipyard): it borrows some ideas from
`EnTT` and offers a sparse sets based ECS with grouping functionalities.
* [Sparsey](https://github.com/LechintanTudor/sparsey): sparse set based ECS
written in Rust.
* [Specs](https://github.com/amethyst/specs): a parallel ECS based mainly on
hierarchical bitsets that allows different types of storage as needed.
* Zig
* [zig-ecs](https://github.com/prime31/zig-ecs): a _zig-ification_ of `EnTT`.

191
external/entt/entt/docs/md/resource.md vendored Normal file
View File

@ -0,0 +1,191 @@
# Crash Course: resource management
<!--
@cond TURN_OFF_DOXYGEN
-->
# Table of Contents
* [Introduction](#introduction)
* [The resource, the loader and the cache](#the-resource-the-loader-and-the-cache)
* [Resource handle](#resource-handle)
* [Loaders](#loader)
* [The cache class](#the-cache)
<!--
@endcond TURN_OFF_DOXYGEN
-->
# Introduction
Resource management is usually one of the most critical parts of a game.
Solutions are often tuned to the particular application. There exist several
approaches and all of them are perfectly fine as long as they fit the
requirements of the piece of software in which they are used.<br/>
Examples are loading everything on start, loading on request, predictive
loading, and so on.
`EnTT` doesn't pretend to offer a _one-fits-all_ solution for the different
cases.<br/>
Instead, the library comes with a minimal, general purpose resource cache that
might be useful in many cases.
# The resource, the loader and the cache
Resource, loader and cache are the three main actors for the purpose.<br/>
The _resource_ is an image, an audio, a video or any other type:
```cpp
struct my_resource { const int value; };
```
The _loader_ is a callable type the aim of which is to load a specific resource:
```cpp
struct my_loader final {
using result_type = std::shared_ptr<my_resource>;
result_type operator()(int value) const {
// ...
return std::make_shared<my_resource>(value);
}
};
```
Its function operator can accept any arguments and should return a value of the
declared result type (`std::shared_ptr<my_resource>` in the example).<br/>
A loader can also overload its function call operator to make it possible to
construct the same or another resource from different lists of arguments.
Finally, a cache is a specialization of a class template tailored to a specific
resource and (optionally) a loader:
```cpp
using my_cache = entt::resource_cache<my_resource, my_loader>;
// ...
my_cache cache{};
```
The class is designed to create different caches for different resource types
and to manage each one independently in the most appropriate way.<br/>
As a (very) trivial example, audio tracks can survive in most of the scenes of
an application while meshes can be associated with a single scene only, then
discarded when a player leaves it.
## Resource handle
Resources aren't returned directly to the caller. Instead, they are wrapped in a
_resource handle_, an instance of the `entt::resource` class template.<br/>
For those who know the _flyweight design pattern_ already, that's exactly what
it is. To all others, this is the time to brush up on some notions instead.
A shared pointer could have been used as a resource handle. In fact, the default
implementation mostly maps the interface of its standard counterpart and only
adds a few things on top of it.<br/>
However, the handle in `EnTT` is designed as a standalone class template. This
is due to the fact that specializing a class in the standard library is often
undefined behavior while having the ability to specialize the handle for one,
more or all resource types could help over time.
## Loaders
A loader is responsible for _loading_ resources (quite obviously).<br/>
By default, it's just a callable object that forwards its arguments to the
resource itself. That is, a _passthrough type_. All the work is demanded to the
constructor(s) of the resource itself.<br/>
Loaders also are fully customizable as expected.
A custom loader is a class with at least one function call operator and a member
type named `result_type`.<br/>
The loader isn't required to return a resource handle. As long as `return_type`
is suitable for constructing a handle, that's fine.
When using the default handle, it expects a resource type which is convertible
to or suitable for constructing an `std::shared_ptr<Type>` (where `Type` is the
actual resource type).<br/>
In other terms, the loader should return shared pointers to the given resource
type. However, this isn't mandatory. Users can easily get around this constraint
by specializing both the handle and the loader.
A cache forwards all its arguments to the loader if required. This means that
loaders can also support tag dispatching to offer different loading policies:
```cpp
struct my_loader {
using result_type = std::shared_ptr<my_resource>;
struct from_disk_tag{};
struct from_network_tag{};
template<typename Args>
result_type operator()(from_disk_tag, Args&&... args) {
// ...
return std::make_shared<my_resource>(std::forward<Args>(args)...);
}
template<typename Args>
result_type operator()(from_network_tag, Args&&... args) {
// ...
return std::make_shared<my_resource>(std::forward<Args>(args)...);
}
}
```
This makes the whole loading logic quite flexible and easy to extend over time.
## The cache class
The cache is the class that is asked to _connect the dots_.<br/>
It loads the resources, stores them aside and returns handles as needed:
```cpp
entt::resource_cache<my_resource, my_loader> cache{};
```
Under the hood, a cache is nothing more than a map where the key value has type
`entt::id_type` while the mapped value is whatever type its loader returns.<br/>
For this reason, it offers most of the functionalities a user would expect from
a map, such as `empty` or `size` and so on. Similarly, it's an iterable type
that also supports indexing by resource id:
```cpp
for(auto [id, res]: cache) {
// ...
}
if(entt::resource<my_resource> res = cache["resource/id"_hs]; res) {
// ...
}
```
Please, refer to the inline documentation for all the details about the other
functions (such as `contains` or `erase`).
Set aside the part of the API that this class _shares_ with a map, it also adds
something on top of it in order to address the most common requirements of a
resource cache.<br/>
In particular, it doesn't have an `emplace` member function which is replaced by
`load` and `force_load` instead (where the former loads a new resource only if
not present while the second triggers a forced loading in any case):
```cpp
auto ret = cache.load("resource/id"_hs);
// true only if the resource was not already present
const bool loaded = ret.second;
// takes the resource handle pointed to by the returned iterator
entt::resource<my_resource> res = ret.first->second;
```
Note that the hashed string is used for convenience in the example above.<br/>
Resource identifiers are nothing more than integral values. Therefore, plain
numbers as well as non-class enum value are accepted.
It's worth mentioning that the iterators of a cache as well as its indexing
operators return resource handles rather than instances of the mapped type.<br/>
Since the cache has no control over the loader and a resource isn't required to
also be convertible to bool, these handles can be invalid. This usually means an
error in the user logic but it may also be an _expected_ event.<br/>
It's therefore recommended to verify handles validity with a check in debug (for
example, when loading) or an appropriate logic in retail.

565
external/entt/entt/docs/md/signal.md vendored Normal file
View File

@ -0,0 +1,565 @@
# Crash Course: events, signals and everything in between
<!--
@cond TURN_OFF_DOXYGEN
-->
# Table of Contents
* [Introduction](#introduction)
* [Delegate](#delegate)
* [Runtime arguments](#runtime-arguments)
* [Lambda support](#lambda-support)
* [Raw access](#raw-access)
* [Signals](#signals)
* [Event dispatcher](#event-dispatcher)
* [Named queues](#named-queues)
* [Event emitter](#event-emitter)
<!--
@endcond TURN_OFF_DOXYGEN
-->
# Introduction
Signals are more often than not a core part of games and software architectures
in general.<br/>
They help to decouple the various parts of a system while allowing them to
communicate with each other somehow.
The so called _modern C++_ comes with a tool that can be useful in this regard,
the `std::function`. As an example, it can be used to create delegates.<br/>
However, there is no guarantee that an `std::function` doesn't perform
allocations under the hood and this could be problematic sometimes. Furthermore,
it solves a problem but may not adapt well to other requirements that may arise
from time to time.
In case that the flexibility and power of an `std::function` isn't required or
if the price to pay for them is too high, `EnTT` offers a complete set of
lightweight classes to solve the same and many other problems.
# Delegate
A delegate can be used as a general purpose invoker with no memory overhead for
free functions, lambdas and members provided along with an instance on which to
invoke them.<br/>
It doesn't claim to be a drop-in replacement for an `std::function`, so don't
expect to use it whenever an `std::function` fits well. That said, it's most
likely even a better fit than an `std::function` in a lot of cases, so expect to
use it quite a lot anyway.
The interface is trivial. It offers a default constructor to create empty
delegates:
```cpp
entt::delegate<int(int)> delegate{};
```
What is needed to create an instance is to specify the type of the function the
delegate _accepts_, that is the signature of the functions it models.<br/>
However, attempting to use an empty delegate by invoking its function call
operator results in undefined behavior or most likely a crash.
There exist a few overloads of the `connect` member function to initialize a
delegate:
```cpp
int f(int i) { return i; }
struct my_struct {
int f(const int &i) const { return i; }
};
// bind a free function to the delegate
delegate.connect<&f>();
// bind a member function to the delegate
my_struct instance;
delegate.connect<&my_struct::f>(instance);
```
The delegate class also accepts data members, if needed. In this case, the
function type of the delegate is such that the parameter list is empty and the
value of the data member is at least convertible to the return type.
Free functions having type equivalent to `void(T &, args...)` are accepted as
well. The first argument `T &` is considered a payload and the function will
receive it back every time it's invoked. In other terms, this works just fine
with the above definition:
```cpp
void g(const char &c, int i) { /* ... */ }
const char c = 'c';
delegate.connect<&g>(c);
delegate(42);
```
Function `g` is invoked with a reference to `c` and `42`. However, the function
type of the delegate is still `void(int)`. This is also the signature of its
function call operator.<br/>
Another interesting aspect of the delegate class is that it accepts functions
with a list of parameters that is shorter than that of its function type:
```cpp
void g() { /* ... */ }
delegate.connect<&g>();
delegate(42);
```
Where the function type of the delegate is `void(int)` as above. It goes without
saying that the extra arguments are silently discarded internally. This is a
nice-to-have feature in a lot of cases, as an example when the `delegate` class
is used as a building block of a signal-slot system.<br/>
In fact, this filtering works both ways. The class tries to pass its first
_count_ arguments **first**, then the last _count_. Watch out for conversion
rules if in doubt when connecting a listener!<br/>
Arbitrary functions that pull random arguments from the delegate list aren't
supported instead. Other feature were preferred, such as support for functions
with compatible argument lists although not equal to those of the delegate.
To create and initialize a delegate at once, there are a few specialized
constructors. Because of the rules of the language, the listener is provided by
means of the `entt::connect_arg` variable template:
```cpp
entt::delegate<int(int)> func{entt::connect_arg<&f>};
```
Aside `connect`, a `disconnect` counterpart isn't provided. Instead, there
exists a `reset` member function to use to clear a delegate.<br/>
To know if a delegate is empty, it can be used explicitly in every conditional
statement:
```cpp
if(delegate) {
// ...
}
```
Finally, to invoke a delegate, the function call operator is the way to go as
already shown in the examples above:
```cpp
auto ret = delegate(42);
```
In all cases, listeners don't have to strictly follow the signature of the
delegate. As long as a listener can be invoked with the given arguments to yield
a result that is convertible to the given result type, everything works just
fine.
As a side note, members of classes may or may not be associated with instances.
If they are not, the first argument of the function type must be that of the
class on which the members operate and an instance of this class must obviously
be passed when invoking the delegate:
```cpp
entt::delegate<void(my_struct &, int)> delegate;
delegate.connect<&my_struct::f>();
my_struct instance;
delegate(instance, 42);
```
In this case, it's not possible to _deduce_ the function type since the first
argument doesn't necessarily have to be a reference (for example, it can be a
pointer, as well as a const reference).<br/>
Therefore, the function type must be declared explicitly for unbound members.
## Runtime arguments
The `delegate` class is meant to be used primarily with template arguments.
However, as a consequence of its design, it also offers minimal support for
runtime arguments.<br/>
When used like this, some features aren't supported though. In particular:
* Curried functions aren't accepted.
* Functions with an argument list that differs from that of the delegate aren't
supported.
* Return type and types of arguments **must** coincide with those of the
delegate and _being at least convertible_ isn't enough anymore.
Moreover, for a given function type `Ret(Args...)`, the signature of the
functions connected at runtime must necessarily be `Ret(const void *, Args...)`.
Runtime arguments can be passed both to the constructor of a delegate and to the
`connect` member function. An optional parameter is also accepted in both cases.
This argument is used to pass arbitrary user data back and forth as a
`const void *` upon invocation.<br/>
To connect a function to a delegate _in the hard way_:
```cpp
int func(const void *ptr, int i) { return *static_cast<const int *>(ptr) * i; }
const int value = 42;
// use the constructor ...
entt::delegate delegate{&func, &value};
// ... or the connect member function
delegate.connect(&func, &value);
```
The type of the delegate is deduced from the function if possible. In this case,
since the first argument is an implementation detail, the deduced function type
is `int(int)`.<br/>
Invoking a delegate built in this way follows the same rules as previously
explained.
## Lambda support
In general, the `delegate` class doesn't fully support lambda functions in all
their nuances. The reason is pretty simple: a `delegate` isn't a drop-in
replacement for an `std::function`. Instead, it tries to overcome the problems
with the latter.<br/>
That being said, non-capturing lambda functions are supported, even though some
features aren't available in this case.
This is a logical consequence of the support for connecting functions at
runtime. Therefore, lambda functions undergo the same rules and
limitations.<br/>
In fact, since non-capturing lambda functions decay to pointers to functions,
they can be used with a `delegate` as if they were _normal functions_ with
optional payload:
```cpp
my_struct instance;
// use the constructor ...
entt::delegate delegate{+[](const void *ptr, int value) {
return static_cast<const my_struct *>(ptr)->f(value);
}, &instance};
// ... or the connect member function
delegate.connect([](const void *ptr, int value) {
return static_cast<const my_struct *>(ptr)->f(value);
}, &instance);
```
As above, the first parameter (`const void *`) isn't part of the function type
of the delegate and is used to dispatch arbitrary user data back and forth. In
other terms, the function type of the delegate above is `int(int)`.
## Raw access
While not recommended, a delegate also allows direct access to the stored
callable function target and underlying data, if any.<br/>
This makes it possible to bypass the behavior of the delegate itself and force
calls on different instances:
```cpp
my_struct other;
delegate.target(&other, 42);
```
It goes without saying that this type of approach is **very** risky, especially
since there is no way of knowing whether the contained function was originally a
member function of some class, a free function or a lambda.<br/>
Another possible (and meaningful) use of this feature is that of identifying a
particular delegate through its descriptive _traits_ instead.
# Signals
Signal handlers work with references to classes, function pointers and pointers
to members. Listeners can be any kind of objects and users are in charge of
connecting and disconnecting them from a signal to avoid crashes due to
different lifetimes. On the other side, performance shouldn't be affected that
much by the presence of such a signal handler.<br/>
Signals make use of delegates internally and therefore they undergo the same
rules and offer similar functionalities. It may be a good idea to consult the
documentation of the `delegate` class for further information.
A signal handler is can be used as a private data member without exposing any
_publish_ functionality to the clients of a class.<br/>
The basic idea is to impose a clear separation between the signal itself and the
`sink` class, that is a tool to be used to connect and disconnect listeners on
the fly.
The API of a signal handler is straightforward. If a collector is supplied to
the signal when something is published, all the values returned by its listeners
are literally _collected_ and used later by the caller. Otherwise, the class
works just like a plain signal that emits events from time to time.<br/>
To create instances of signal handlers it's sufficient to provide the type of
function to which they refer:
```cpp
entt::sigh<void(int, char)> signal;
```
Signals offer all the basic functionalities required to know how many listeners
they contain (`size`) or if they contain at least a listener (`empty`), as well
as a function to use to swap handlers (`swap`).
Besides them, there are member functions to use both to connect and disconnect
listeners in all their forms by means of a sink:
```cpp
void foo(int, char) { /* ... */ }
struct listener {
void bar(const int &, char) { /* ... */ }
};
// ...
entt::sink sink{signal};
listener instance;
sink.connect<&foo>();
sink.connect<&listener::bar>(instance);
// ...
// disconnects a free function
sink.disconnect<&foo>();
// disconnect a member function of an instance
sink.disconnect<&listener::bar>(instance);
// disconnect all member functions of an instance, if any
sink.disconnect(&instance);
// discards all listeners at once
sink.disconnect();
```
As shown above, listeners don't have to strictly follow the signature of the
signal. As long as a listener can be invoked with the given arguments to yield a
result that is convertible to the given return type, everything works just
fine.<br/>
In all cases, the `connect` member function returns by default a `connection`
object to be used as an alternative to break a connection by means of its
`release` member function.<br/>
A `scoped_connection` can also be created from a connection. In this case, the
link is broken automatically as soon as the object goes out of scope.
Once listeners are attached (or even if there are no listeners at all), events
and data in general are published through a signal by means of the `publish`
member function:
```cpp
signal.publish(42, 'c');
```
To collect data, the `collect` member function is used instead:
```cpp
int f() { return 0; }
int g() { return 1; }
// ...
entt::sigh<int()> signal;
entt::sink sink{signal};
sink.connect<&f>();
sink.connect<&g>();
std::vector<int> vec{};
signal.collect([&vec](int value) { vec.push_back(value); });
assert(vec[0] == 0);
assert(vec[1] == 1);
```
A collector must expose a function operator that accepts as an argument a type
to which the return type of the listeners can be converted. Moreover, it can
optionally return a boolean value that is true to stop collecting data, false
otherwise. This way one can avoid calling all the listeners in case it isn't
necessary.<br/>
Functors can also be used in place of a lambda. Since the collector is copied
when invoking the `collect` member function, `std::ref` is the way to go in this
case:
```cpp
struct my_collector {
std::vector<int> vec{};
bool operator()(int v) {
vec.push_back(v);
return true;
}
};
// ...
my_collector collector;
signal.collect(std::ref(collector));
```
# Event dispatcher
The event dispatcher class allows users to trigger immediate events or to queue
and publish them all together later.<br/>
This class lazily instantiates its queues. Therefore, it's not necessary to
_announce_ the event types in advance:
```cpp
// define a general purpose dispatcher
entt::dispatcher dispatcher{};
```
A listener registered with a dispatcher is such that its type offers one or more
member functions that take arguments of type `Event &` for any type of event,
regardless of the return value.<br/>
These functions are linked directly via `connect` to a _sink_:
```cpp
struct an_event { int value; };
struct another_event {};
struct listener {
void receive(const an_event &) { /* ... */ }
void method(const another_event &) { /* ... */ }
};
// ...
listener listener;
dispatcher.sink<an_event>().connect<&listener::receive>(listener);
dispatcher.sink<another_event>().connect<&listener::method>(listener);
```
Note that connecting listeners within event handlers can result in undefined
behavior.<br/>
The `disconnect` member function is used to remove one listener at a time or all
of them at once:
```cpp
dispatcher.sink<an_event>().disconnect<&listener::receive>(listener);
dispatcher.sink<another_event>().disconnect(&listener);
```
The `trigger` member function serves the purpose of sending an immediate event
to all the listeners registered so far:
```cpp
dispatcher.trigger(an_event{42});
dispatcher.trigger<another_event>();
```
Listeners are invoked immediately, order of execution isn't guaranteed. This
method can be used to push around urgent messages like an _is terminating_
notification on a mobile app.
On the other hand, the `enqueue` member function queues messages together and
helps to maintain control over the moment they are sent to listeners:
```cpp
dispatcher.enqueue<an_event>(42);
dispatcher.enqueue(another_event{});
```
Events are stored aside until the `update` member function is invoked:
```cpp
// emits all the events of the given type at once
dispatcher.update<an_event>();
// emits all the events queued so far at once
dispatcher.update();
```
This way users can embed the dispatcher in a loop and literally dispatch events
once per tick to their systems.
## Named queues
All queues within a dispatcher are associated by default with an event type and
then retrieved from it.<br/>
However, it's possible to create queues with different _names_ (and therefore
also multiple queues for a single type). In fact, more or less all functions
also take an additional parameter. As an example:
```cpp
dispatcher.sink<an_event>("custom"_hs).connect<&listener::receive>(listener);
```
In this case, the term _name_ is misused as these are actual numeric identifiers
of type `id_type`.<br/>
An exception to this rule is the `enqueue` function. There is no additional
parameter for it but rather a different function:
```cpp
dispatcher.enqueue_hint<an_event>("custom"_hs, 42);
```
This is mainly due to the template argument deduction rules and unfortunately
there is no real (elegant) way to avoid it.
# Event emitter
A general purpose event emitter thought mainly for those cases where it comes to
working with asynchronous stuff.<br/>
Originally designed to fit the requirements of
[`uvw`](https://github.com/skypjack/uvw) (a wrapper for `libuv` written in
modern C++), it was adapted later to be included in this library.
To create an emitter type, derived classes must inherit from the base as:
```cpp
struct my_emitter: emitter<my_emitter> {
// ...
}
```
Handlers for the different events are created internally on the fly. It's not
required to specify in advance the full list of accepted events.<br/>
Moreover, whenever an event is published, an emitter also passes a reference
to itself to its listeners.
To create new instances of an emitter, no arguments are required:
```cpp
my_emitter emitter{};
```
Listeners are movable and callable objects (free functions, lambdas, functors,
`std::function`s, whatever) whose function type is compatible with:
```cpp
void(Type &, my_emitter &)
```
Where `Type` is the type of event they want to receive.<br/>
To attach a listener to an emitter, there exists the `on` member function:
```cpp
emitter.on<my_event>([](const my_event &event, my_emitter &emitter) {
// ...
});
```
Similarly, the `reset` member function is used to disconnect listeners given a
type while `clear` is used to disconnect all listeners at once:
```cpp
// resets the listener for my_event
emitter.erase<my_event>();
// resets all listeners
emitter.clear()
```
To send an event to the listener registered on a given type, the `publish`
function is the way to go:
```cpp
struct my_event { int i; };
// ...
emitter.publish(my_event{42});
```
Finally, the `empty` member function tests if there exists at least a listener
registered with the event emitter while `contains` is used to check if a given
event type is associated with a valid listener:
```cpp
if(emitter.contains<my_event>()) {
// ...
}
```
This class introduces a _nice-to-have_ model based on events and listeners.<br/>
More in general, it's a handy tool when the derived classes _wrap_ asynchronous
operations but it's not limited to such uses.

107
external/entt/entt/docs/md/unreal.md vendored Normal file
View File

@ -0,0 +1,107 @@
# EnTT and Unreal Engine
<!--
@cond TURN_OFF_DOXYGEN
-->
# Table of Contents
* [Enable Cpp17](#enable-cpp17)
* [EnTT as a third party module](#entt-as-a-third-party-module)
* [Include EnTT](#include-entt)
<!--
@endcond TURN_OFF_DOXYGEN
-->
## Enable Cpp17
As of writing (Unreal Engine v4.25), the default C++ standard of Unreal Engine
is C++14.<br/>
On the other hand, note that `EnTT` requires C++17 to compile. To enable it, in
the main module of the project there should be a `<Game Name>.Build.cs` file,
the constructor of which must contain the following lines:
```cs
PCHUsage = PCHUsageMode.NoSharedPCHs;
PrivatePCHHeaderFile = "<PCH filename>.h";
CppStandard = CppStandardVersion.Cpp17;
```
Replace `<PCH filename>.h` with the name of the already existing PCH header
file, if any.<br/>
In case the project doesn't already contain a file of this type, it's possible
to create one with the following content:
```cpp
#pragma once
#include "CoreMinimal.h"
```
Remember to remove any old `PCHUsage = <...>` line that was previously there. At
this point, C++17 support should be in place.<br/>
Try to compile the project to ensure it works as expected before following
further steps.
Note that updating a *project* to C++17 doesn't necessarily mean that the IDE in
use will also start to recognize its syntax.<br/>
If the plan is to use C++17 in the project too, check the specific instructions
for the IDE in use.
## EnTT as a third party module
Once this point is reached, the `Source` directory should look like this:
```
Source
| MyGame.Target.cs
| MyGameEditor.Target.cs
|
+---MyGame
| | MyGame.Build.cs
| | MyGame.h (PCH Header file)
|
\---ThirdParty
\---EnTT
| EnTT.Build.cs
|
\---entt (GitHub repository content inside)
```
To make this happen, create the folder `ThirdParty` under `Source` if it doesn't
exist already. Then, add an `EnTT` folder under `ThirdParty`.<br/>
Within the latter, create a new file `EnTT.Build.cs` with the following content:
```cs
using System.IO;
using UnrealBuildTool;
public class EnTT: ModuleRules {
public EnTT(ReadOnlyTargetRules Target) : base(Target) {
Type = ModuleType.External;
PublicIncludePaths.Add(Path.Combine(ModuleDirectory, "entt", "src", "entt"));
}
}
```
The last line indicates that the actual files will be found in the directory
`EnTT/entt/src/entt`.<br/>
Download the repository for `EnTT` and place it next to `EnTT.Build.cs` or
update the path above accordingly.
Finally, open the `<Game Name>.Build.cs` file and add `EnTT` as a dependency at
the end of the list:
```cs
PublicDependencyModuleNames.AddRange(new[] {
"Core", "CoreUObject", "Engine", "InputCore", [...], "EnTT"
});
```
Note that some IDEs might require a restart to start recognizing the new module
for code-highlighting features and such.
## Include EnTT
In any source file of the project, add `#include "entt.hpp"` or any other path
to the file from `EnTT` to use it.<br/>
Try to create a registry as `entt::registry registry;` to make sure everything
compiles fine.

34
external/entt/entt/entt.imp vendored Normal file
View File

@ -0,0 +1,34 @@
[
{ "include": [ "@<gtest/internal/.*>", "private", "<gtest/gtest.h>", "public" ] },
{ "include": [ "@<gtest/gtest-.*>", "private", "<gtest/gtest.h>", "public" ] },
{ "include": [ "@[\"<].*/container/fwd.hpp[\">]", "private", "<entt/container/dense_map.hpp>", "public" ] },
{ "include": [ "@[\"<].*/container/fwd.hpp[\">]", "private", "<entt/container/dense_set.hpp>", "public" ] },
{ "include": [ "@[\"<].*/core/fwd.hpp[\">]", "private", "<entt/core/any.hpp>", "public" ] },
{ "include": [ "@[\"<].*/core/fwd.hpp[\">]", "private", "<entt/core/family.hpp>", "public" ] },
{ "include": [ "@[\"<].*/core/fwd.hpp[\">]", "private", "<entt/core/hashed_string.hpp>", "public" ] },
{ "include": [ "@[\"<].*/core/fwd.hpp[\">]", "private", "<entt/core/ident.hpp>", "public" ] },
{ "include": [ "@[\"<].*/core/fwd.hpp[\">]", "private", "<entt/core/monostate.hpp>", "public" ] },
{ "include": [ "@[\"<].*/core/fwd.hpp[\">]", "private", "<entt/core/type_info.hpp>", "public" ] },
{ "include": [ "@[\"<].*/core/fwd.hpp[\">]", "private", "<entt/core/type_traits.hpp>", "public" ] },
{ "include": [ "@[\"<].*/entity/fwd.hpp[\">]", "private", "<entt/entity/entity.hpp>", "public" ] },
{ "include": [ "@[\"<].*/entity/fwd.hpp[\">]", "private", "<entt/entity/group.hpp>", "public" ] },
{ "include": [ "@[\"<].*/entity/fwd.hpp[\">]", "private", "<entt/entity/handle.hpp>", "public" ] },
{ "include": [ "@[\"<].*/entity/fwd.hpp[\">]", "private", "<entt/entity/helper.hpp>", "public" ] },
{ "include": [ "@[\"<].*/entity/fwd.hpp[\">]", "private", "<entt/entity/observer.hpp>", "public" ] },
{ "include": [ "@[\"<].*/entity/fwd.hpp[\">]", "private", "<entt/entity/organizer.hpp>", "public" ] },
{ "include": [ "@[\"<].*/entity/fwd.hpp[\">]", "private", "<entt/entity/registry.hpp>", "public" ] },
{ "include": [ "@[\"<].*/entity/fwd.hpp[\">]", "private", "<entt/entity/runtime_view.hpp>", "public" ] },
{ "include": [ "@[\"<].*/entity/fwd.hpp[\">]", "private", "<entt/entity/snapshot.hpp>", "public" ] },
{ "include": [ "@[\"<].*/entity/fwd.hpp[\">]", "private", "<entt/entity/sparse_set.hpp>", "public" ] },
{ "include": [ "@[\"<].*/entity/fwd.hpp[\">]", "private", "<entt/entity/storage.hpp>", "public" ] },
{ "include": [ "@[\"<].*/entity/fwd.hpp[\">]", "private", "<entt/entity/view.hpp>", "public" ] },
{ "include": [ "@[\"<].*/meta/fwd.hpp[\">]", "private", "<entt/meta/meta.hpp>", "public" ] },
{ "include": [ "@[\"<].*/poly/fwd.hpp[\">]", "private", "<entt/poly/poly.hpp>", "public" ] },
{ "include": [ "@[\"<].*/resource/fwd.hpp[\">]", "private", "<entt/resource/cache.hpp>", "public" ] },
{ "include": [ "@[\"<].*/resource/fwd.hpp[\">]", "private", "<entt/resource/loader.hpp>", "public" ] },
{ "include": [ "@[\"<].*/resource/fwd.hpp[\">]", "private", "<entt/resource/resource.hpp>", "public" ] },
{ "include": [ "@[\"<].*/signal/fwd.hpp[\">]", "private", "<entt/signal/delegate.hpp>", "public" ] },
{ "include": [ "@[\"<].*/signal/fwd.hpp[\">]", "private", "<entt/signal/dispatcher.hpp>", "public" ] },
{ "include": [ "@[\"<].*/signal/fwd.hpp[\">]", "private", "<entt/signal/emitter.hpp>", "public" ] },
{ "include": [ "@[\"<].*/signal/fwd.hpp[\">]", "private", "<entt/signal/sigh.hpp>", "public" ] }
]

View File

@ -0,0 +1,3 @@
<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
</AutoVisualizer>

View File

@ -0,0 +1,33 @@
<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
<Type Name="entt::dense_map&lt;*&gt;">
<Intrinsic Name="size" Expression="packed.first_base::value.size()"/>
<Intrinsic Name="bucket_count" Expression="sparse.first_base::value.size()"/>
<DisplayString>{{ size={ size() } }}</DisplayString>
<Expand>
<Item Name="[capacity]" ExcludeView="simple">packed.first_base::value.capacity()</Item>
<Item Name="[bucket_count]" ExcludeView="simple">bucket_count()</Item>
<Item Name="[load_factor]" ExcludeView="simple">(float)size() / (float)bucket_count()</Item>
<Item Name="[max_load_factor]" ExcludeView="simple">threshold</Item>
<IndexListItems>
<Size>size()</Size>
<ValueNode>packed.first_base::value[$i].element</ValueNode>
</IndexListItems>
</Expand>
</Type>
<Type Name="entt::dense_set&lt;*&gt;">
<Intrinsic Name="size" Expression="packed.first_base::value.size()"/>
<Intrinsic Name="bucket_count" Expression="sparse.first_base::value.size()"/>
<DisplayString>{{ size={ size() } }}</DisplayString>
<Expand>
<Item Name="[capacity]" ExcludeView="simple">packed.first_base::value.capacity()</Item>
<Item Name="[bucket_count]" ExcludeView="simple">bucket_count()</Item>
<Item Name="[load_factor]" ExcludeView="simple">(float)size() / (float)bucket_count()</Item>
<Item Name="[max_load_factor]" ExcludeView="simple">threshold</Item>
<IndexListItems>
<Size>size()</Size>
<ValueNode>packed.first_base::value[$i].second</ValueNode>
</IndexListItems>
</Expand>
</Type>
</AutoVisualizer>

View File

@ -0,0 +1,32 @@
<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
<Type Name="entt::basic_any&lt;*&gt;">
<DisplayString>{{ type={ info->alias,na }, policy={ mode,en } }}</DisplayString>
</Type>
<Type Name="entt::compressed_pair&lt;*&gt;">
<Intrinsic Name="first" Optional="true" Expression="((first_base*)this)->value"/>
<Intrinsic Name="first" Optional="true" Expression="*(first_base::base_type*)this"/>
<Intrinsic Name="second" Optional="true" Expression="((second_base*)this)->value"/>
<Intrinsic Name="second" Optional="true" Expression="*(second_base::base_type*)this"/>
<DisplayString >({ first() }, { second() })</DisplayString>
<Expand>
<Item Name="[first]">first()</Item>
<Item Name="[second]">second()</Item>
</Expand>
</Type>
<Type Name="entt::basic_hashed_string&lt;*&gt;">
<DisplayString Condition="base_type::repr != nullptr">{{ hash={ base_type::hash } }}</DisplayString>
<DisplayString>{{}}</DisplayString>
<Expand>
<Item Name="[data]">base_type::repr,na</Item>
<Item Name="[length]">base_type::length</Item>
</Expand>
</Type>
<Type Name="entt::type_info">
<DisplayString>{{ name={ alias,na } }}</DisplayString>
<Expand>
<Item Name="[hash]">identifier</Item>
<Item Name="[index]">seq</Item>
</Expand>
</Type>
</AutoVisualizer>

View File

@ -0,0 +1,123 @@
<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
<Type Name="entt::basic_registry&lt;*&gt;">
<Intrinsic Name="to_entity" Expression="*((traits_type::entity_type *)&amp;entity) &amp; traits_type::entity_mask">
<Parameter Name="entity" Type="traits_type::value_type &amp;"/>
</Intrinsic>
<DisplayString>{{ pools={ pools.size() } }}</DisplayString>
<Expand>
<Item Name="[entities]">entities</Item>
<Synthetic Name="[pools]">
<DisplayString>{ pools.size() }</DisplayString>
<Expand>
<IndexListItems ExcludeView="simple">
<Size>pools.size()</Size>
<ValueNode>*pools.packed.first_base::value[$i].element.second</ValueNode>
</IndexListItems>
<IndexListItems IncludeView="simple">
<Size>pools.size()</Size>
<ValueNode>*pools.packed.first_base::value[$i].element.second,view(simple)</ValueNode>
</IndexListItems>
</Expand>
</Synthetic>
<Item Name="[groups]" ExcludeView="simple">groups.size()</Item>
<Synthetic Name="[vars]">
<DisplayString>{ vars.ctx.size() }</DisplayString>
<Expand>
<IndexListItems>
<Size>vars.ctx.size()</Size>
<ValueNode>vars.ctx.packed.first_base::value[$i].element.second</ValueNode>
</IndexListItems>
</Expand>
</Synthetic>
</Expand>
</Type>
<Type Name="entt::basic_sparse_set&lt;*&gt;">
<DisplayString>{{ size={ packed.size() }, type={ info->alias,na } }}</DisplayString>
<Expand>
<Item Name="[capacity]" ExcludeView="simple">packed.capacity()</Item>
<Item Name="[policy]">mode,en</Item>
<Synthetic Name="[sparse]">
<DisplayString>{ sparse.size() * traits_type::page_size }</DisplayString>
<Expand>
<ExpandedItem IncludeView="simple">sparse,view(simple)</ExpandedItem>
<CustomListItems ExcludeView="simple">
<Variable Name="pos" InitialValue="0"/>
<Variable Name="page" InitialValue="0"/>
<Variable Name="offset" InitialValue="0"/>
<Variable Name="last" InitialValue="sparse.size() * traits_type::page_size"/>
<Loop>
<Break Condition="pos == last"/>
<Exec>page = pos / traits_type::page_size</Exec>
<Exec>offset = pos &amp; (traits_type::page_size - 1)</Exec>
<If Condition="sparse[page] &amp;&amp; (*((traits_type::entity_type *)&amp;sparse[page][offset]) &lt; ~traits_type::entity_mask)">
<Item Name="[{ pos }]">*((traits_type::entity_type *)&amp;sparse[page][offset]) &amp; traits_type::entity_mask</Item>
</If>
<Exec>++pos</Exec>
</Loop>
</CustomListItems>
</Expand>
</Synthetic>
<Synthetic Name="[packed]">
<DisplayString>{ packed.size() }</DisplayString>
<Expand>
<ExpandedItem IncludeView="simple">packed,view(simple)</ExpandedItem>
<CustomListItems ExcludeView="simple">
<Variable Name="pos" InitialValue="0"/>
<Variable Name="last" InitialValue="packed.size()"/>
<Loop>
<Break Condition="pos == last"/>
<If Condition="*((traits_type::entity_type *)&amp;packed[pos]) &lt; ~traits_type::entity_mask">
<Item Name="[{ pos }]">packed[pos]</Item>
</If>
<Exec>++pos</Exec>
</Loop>
</CustomListItems>
</Expand>
</Synthetic>
</Expand>
</Type>
<Type Name="entt::basic_storage&lt;*&gt;">
<DisplayString>{{ size={ base_type::packed.size() }, type={ base_type::info->alias,na } }}</DisplayString>
<Expand>
<Item Name="[capacity]" Optional="true" ExcludeView="simple">payload.capacity() * traits_type::page_size</Item>
<Item Name="[page size]" Optional="true" ExcludeView="simple">traits_type::page_size</Item>
<Item Name="[length]" Optional="true" ExcludeView="simple">length</Item>
<Item Name="[base]" ExcludeView="simple">(base_type*)this,nand</Item>
<Item Name="[base]" IncludeView="simple">(base_type*)this,view(simple)nand</Item>
<!-- having SFINAE-like techniques in natvis is priceless :) -->
<CustomListItems Condition="payload.size() != 0" Optional="true">
<Variable Name="pos" InitialValue="0" />
<Variable Name="last" InitialValue="base_type::packed.size()"/>
<Loop>
<Break Condition="pos == last"/>
<If Condition="*((base_type::traits_type::entity_type *)&amp;base_type::packed[pos]) &lt; ~base_type::traits_type::entity_mask">
<Item Name="[{ pos }:{ base_type::packed[pos] }]">payload[pos / traits_type::page_size][pos &amp; (traits_type::page_size - 1)]</Item>
</If>
<Exec>++pos</Exec>
</Loop>
</CustomListItems>
</Expand>
</Type>
<Type Name="entt::basic_view&lt;*&gt;">
<DisplayString>{{ size_hint={ view->packed.size() } }}</DisplayString>
<Expand>
<Item Name="[pools]">pools,na</Item>
<Item Name="[filter]">filter,na</Item>
</Expand>
</Type>
<Type Name="entt::basic_runtime_view&lt;*&gt;">
<DisplayString Condition="pools.size() != 0u">{{ size_hint={ pools[0]->packed.size() } }}</DisplayString>
<DisplayString>{{ size_hint=0 }}</DisplayString>
<Expand>
<Item Name="[pools]">pools,na</Item>
<Item Name="[filter]">filter,na</Item>
</Expand>
</Type>
<Type Name="entt::null_t">
<DisplayString>&lt;null&gt;</DisplayString>
</Type>
<Type Name="entt::tombstone_t">
<DisplayString>&lt;tombstone&gt;</DisplayString>
</Type>
</AutoVisualizer>

View File

@ -0,0 +1,19 @@
<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
<Type Name="entt::adjacency_matrix&lt;*&gt;">
<DisplayString>{{ size={ vert } }}</DisplayString>
<Expand>
<CustomListItems>
<Variable Name="pos" InitialValue="0" />
<Variable Name="last" InitialValue="vert * vert"/>
<Loop>
<Break Condition="pos == last"/>
<If Condition="matrix[pos] != 0u">
<Item Name="{pos / vert}">pos % vert</Item>
</If>
<Exec>++pos</Exec>
</Loop>
</CustomListItems>
</Expand>
</Type>
</AutoVisualizer>

View File

@ -0,0 +1,3 @@
<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
</AutoVisualizer>

View File

@ -0,0 +1,121 @@
<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
<Type Name="entt::internal::meta_base_node">
<DisplayString>{{}}</DisplayString>
</Type>
<Type Name="entt::internal::meta_conv_node">
<DisplayString>{{}}</DisplayString>
</Type>
<Type Name="entt::internal::meta_ctor_node">
<DisplayString>{{ arity={ arity } }}</DisplayString>
</Type>
<Type Name="entt::internal::meta_data_node">
<Intrinsic Name="has_property" Expression="!!(traits &amp; property)">
<Parameter Name="property" Type="int"/>
</Intrinsic>
<DisplayString>{{ arity={ arity } }}</DisplayString>
<Expand>
<Item Name="[arity]">arity</Item>
<Item Name="[is_const]">has_property(entt::internal::meta_traits::is_const)</Item>
<Item Name="[is_static]">has_property(entt::internal::meta_traits::is_static)</Item>
<Item Name="[prop]">prop</Item>
</Expand>
</Type>
<Type Name="entt::internal::meta_func_node" >
<Intrinsic Name="has_property" Expression="!!(traits &amp; property)">
<Parameter Name="property" Type="int"/>
</Intrinsic>
<DisplayString>{{ arity={ arity } }}</DisplayString>
<Expand>
<Item Name="[is_const]">has_property(entt::internal::meta_traits::is_const)</Item>
<Item Name="[is_static]">has_property(entt::internal::meta_traits::is_static)</Item>
<Item Name="[next]" Condition="next != nullptr">*next</Item>
<Item Name="[prop]">prop</Item>
</Expand>
</Type>
<Type Name="entt::internal::meta_prop_node">
<DisplayString>{ value }</DisplayString>
</Type>
<Type Name="entt::internal::meta_template_node">
<DisplayString>{{ arity={ arity } }}</DisplayString>
</Type>
<Type Name="entt::internal::meta_type_node">
<Intrinsic Name="has_property" Expression="!!(traits &amp; property)">
<Parameter Name="property" Type="int"/>
</Intrinsic>
<DisplayString Condition="info != nullptr">{{ type={ info->alias,na } }}</DisplayString>
<DisplayString>{{}}</DisplayString>
<Expand>
<Item Name="[id]">id</Item>
<Item Name="[sizeof]">size_of</Item>
<Item Name="[is_arithmetic]">has_property(entt::internal::meta_traits::is_arithmetic)</Item>
<Item Name="[is_integral]">has_property(entt::internal::meta_traits::is_integral)</Item>
<Item Name="[is_signed]">has_property(entt::internal::meta_traits::is_signed)</Item>
<Item Name="[is_array]">has_property(entt::internal::meta_traits::is_array)</Item>
<Item Name="[is_enum]">has_property(entt::internal::meta_traits::is_enum)</Item>
<Item Name="[is_class]">has_property(entt::internal::meta_traits::is_class)</Item>
<Item Name="[is_meta_pointer_like]">has_property(entt::internal::meta_traits::is_meta_pointer_like)</Item>
<Item Name="[is_meta_sequence_container]">has_property(entt::internal::meta_traits::is_meta_sequence_container)</Item>
<Item Name="[is_meta_associative_container]">has_property(entt::internal::meta_traits::is_meta_associative_container)</Item>
<Item Name="[default_constructor]">default_constructor != nullptr</Item>
<Item Name="[conversion_helper]">conversion_helper != nullptr</Item>
<Item Name="[from_void]">from_void != nullptr</Item>
<Item Name="[template_info]">templ</Item>
<Item Name="[details]" Condition="details != nullptr">*details</Item>
</Expand>
</Type>
<Type Name="entt::meta_any">
<DisplayString Condition="node.info != nullptr">{{ type={ node.info->alias,na }, policy={ storage.mode,en } }}</DisplayString>
<DisplayString>{{}}</DisplayString>
<Expand>
<ExpandedItem>node</ExpandedItem>
<Item Name="[context]" Condition="ctx != nullptr">ctx->value</Item>
</Expand>
</Type>
<Type Name="entt::meta_handle">
<DisplayString>{ any }</DisplayString>
</Type>
<Type Name="entt::meta_associative_container">
<DisplayString>{ storage }</DisplayString>
<Expand>
<Item Name="[context]" Condition="ctx != nullptr">ctx->value</Item>
</Expand>
</Type>
<Type Name="entt::meta_sequence_container">
<DisplayString>{ storage }</DisplayString>
<Expand>
<Item Name="[context]" Condition="ctx != nullptr">ctx->value</Item>
</Expand>
</Type>
<Type Name="entt::meta_data">
<DisplayString Condition="node != nullptr">{ *node }</DisplayString>
<DisplayString>{{}}</DisplayString>
<Expand>
<ExpandedItem Condition="node != nullptr">node</ExpandedItem>
<Item Name="[context]" Condition="ctx != nullptr">ctx->value</Item>
</Expand>
</Type>
<Type Name="entt::meta_func">
<DisplayString Condition="node != nullptr">{ *node }</DisplayString>
<DisplayString>{{}}</DisplayString>
<Expand>
<ExpandedItem Condition="node != nullptr">node</ExpandedItem>
<Item Name="[context]" Condition="ctx != nullptr">ctx->value</Item>
</Expand>
</Type>
<Type Name="entt::meta_prop">
<DisplayString Condition="node != nullptr">{ *node }</DisplayString>
<DisplayString>{{}}</DisplayString>
<Expand>
<ExpandedItem Condition="node != nullptr">node</ExpandedItem>
<Item Name="[context]" Condition="ctx != nullptr">ctx->value</Item>
</Expand>
</Type>
<Type Name="entt::meta_type">
<DisplayString>{ node }</DisplayString>
<Expand>
<ExpandedItem>node</ExpandedItem>
<Item Name="[context]" Condition="ctx != nullptr">ctx->value</Item>
</Expand>
</Type>
</AutoVisualizer>

View File

@ -0,0 +1,3 @@
<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
</AutoVisualizer>

View File

@ -0,0 +1,6 @@
<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
<Type Name="entt::basic_poly&lt;*&gt;">
<DisplayString>{ storage }</DisplayString>
</Type>
</AutoVisualizer>

View File

@ -0,0 +1,3 @@
<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
</AutoVisualizer>

View File

@ -0,0 +1,15 @@
<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
<Type Name="entt::resource&lt;*&gt;">
<DisplayString>{ value }</DisplayString>
<Expand>
<ExpandedItem>value</ExpandedItem>
</Expand>
</Type>
<Type Name="entt::resource_cache&lt;*&gt;">
<DisplayString>{ pool.first_base::value }</DisplayString>
<Expand>
<ExpandedItem>pool.first_base::value</ExpandedItem>
</Expand>
</Type>
</AutoVisualizer>

View File

@ -0,0 +1,55 @@
<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
<Type Name="entt::delegate&lt;*&gt;">
<DisplayString>{{ type={ "$T1" } }}</DisplayString>
<Expand>
<Item Name="[empty]">fn == nullptr</Item>
<Item Name="[data]">instance</Item>
</Expand>
</Type>
<Type Name="entt::basic_dispatcher&lt;*&gt;">
<Intrinsic Name="size" Expression="pools.first_base::value.size()"/>
<DisplayString>{{ size={ size() } }}</DisplayString>
<Expand>
<Synthetic Name="[pools]">
<DisplayString>{ size() }</DisplayString>
<Expand>
<IndexListItems>
<Size>size()</Size>
<ValueNode>*pools.first_base::value.packed.first_base::value[$i].element.second</ValueNode>
</IndexListItems>
</Expand>
</Synthetic>
</Expand>
</Type>
<Type Name="entt::internal::dispatcher_handler&lt;*&gt;">
<DisplayString>{{ size={ events.size() }, event={ "$T1" } }}</DisplayString>
<Expand>
<Item Name="[signal]">signal</Item>
</Expand>
</Type>
<Type Name="entt::emitter&lt;*&gt;">
<DisplayString>{{ size={ handlers.first_base::value.packed.first_base::value.size() } }}</DisplayString>
</Type>
<Type Name="entt::connection">
<DisplayString>{{ bound={ signal != nullptr } }}</DisplayString>
</Type>
<Type Name="entt::scoped_connection">
<DisplayString>{ conn }</DisplayString>
</Type>
<Type Name="entt::sigh&lt;*&gt;">
<DisplayString>{{ size={ calls.size() }, type={ "$T1" } }}</DisplayString>
<Expand>
<IndexListItems>
<Size>calls.size()</Size>
<ValueNode>calls[$i]</ValueNode>
</IndexListItems>
</Expand>
</Type>
<Type Name="entt::sink&lt;*&gt;">
<DisplayString>{{ type={ "$T1" } }}</DisplayString>
<Expand>
<Item Name="[signal]">signal,na</Item>
</Expand>
</Type>
</AutoVisualizer>

299
external/entt/entt/scripts/amalgamate.py vendored Normal file
View File

@ -0,0 +1,299 @@
#!/usr/bin/env python
# coding=utf-8
# amalgamate.py - Amalgamate C source and header files.
# Copyright (c) 2012, Erik Edlund <erik.edlund@32767.se>
#
# Redistribution and use in source and binary forms, with or without modification,
# are permitted provided that the following conditions are met:
#
# * Redistributions of source code must retain the above copyright notice,
# this list of conditions and the following disclaimer.
#
# * Redistributions in binary form must reproduce the above copyright notice,
# this list of conditions and the following disclaimer in the documentation
# and/or other materials provided with the distribution.
#
# * Neither the name of Erik Edlund, nor the names of its contributors may
# be used to endorse or promote products derived from this software without
# specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
# ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
# ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
from __future__ import division
from __future__ import print_function
from __future__ import unicode_literals
import argparse
import datetime
import json
import os
import re
class Amalgamation(object):
# Prepends self.source_path to file_path if needed.
def actual_path(self, file_path):
if not os.path.isabs(file_path):
file_path = os.path.join(self.source_path, file_path)
return file_path
# Search included file_path in self.include_paths and
# in source_dir if specified.
def find_included_file(self, file_path, source_dir):
search_dirs = self.include_paths[:]
if source_dir:
search_dirs.insert(0, source_dir)
for search_dir in search_dirs:
search_path = os.path.join(search_dir, file_path)
if os.path.isfile(self.actual_path(search_path)):
return search_path
return None
def __init__(self, args):
with open(args.config, 'r') as f:
config = json.loads(f.read())
for key in config:
setattr(self, key, config[key])
self.verbose = args.verbose == "yes"
self.prologue = args.prologue
self.source_path = args.source_path
self.included_files = []
# Generate the amalgamation and write it to the target file.
def generate(self):
amalgamation = ""
if self.prologue:
with open(self.prologue, 'r') as f:
amalgamation += datetime.datetime.now().strftime(f.read())
if self.verbose:
print("Config:")
print(" target = {0}".format(self.target))
print(" working_dir = {0}".format(os.getcwd()))
print(" include_paths = {0}".format(self.include_paths))
print("Creating amalgamation:")
for file_path in self.sources:
# Do not check the include paths while processing the source
# list, all given source paths must be correct.
# actual_path = self.actual_path(file_path)
print(" - processing \"{0}\"".format(file_path))
t = TranslationUnit(file_path, self, True)
amalgamation += t.content
with open(self.target, 'w') as f:
f.write(amalgamation)
print("...done!\n")
if self.verbose:
print("Files processed: {0}".format(self.sources))
print("Files included: {0}".format(self.included_files))
print("")
def _is_within(match, matches):
for m in matches:
if match.start() > m.start() and \
match.end() < m.end():
return True
return False
class TranslationUnit(object):
# // C++ comment.
cpp_comment_pattern = re.compile(r"//.*?\n")
# /* C comment. */
c_comment_pattern = re.compile(r"/\*.*?\*/", re.S)
# "complex \"stri\\\ng\" value".
string_pattern = re.compile("[^']" r'".*?(?<=[^\\])"', re.S)
# Handle simple include directives. Support for advanced
# directives where macros and defines needs to expanded is
# not a concern right now.
include_pattern = re.compile(
r'#\s*include\s+(<|")(?P<path>.*?)("|>)', re.S)
# #pragma once
pragma_once_pattern = re.compile(r'#\s*pragma\s+once', re.S)
# Search for pattern in self.content, add the match to
# contexts if found and update the index accordingly.
def _search_content(self, index, pattern, contexts):
match = pattern.search(self.content, index)
if match:
contexts.append(match)
return match.end()
return index + 2
# Return all the skippable contexts, i.e., comments and strings
def _find_skippable_contexts(self):
# Find contexts in the content in which a found include
# directive should not be processed.
skippable_contexts = []
# Walk through the content char by char, and try to grab
# skippable contexts using regular expressions when found.
i = 1
content_len = len(self.content)
while i < content_len:
j = i - 1
current = self.content[i]
previous = self.content[j]
if current == '"':
# String value.
i = self._search_content(j, self.string_pattern,
skippable_contexts)
elif current == '*' and previous == '/':
# C style comment.
i = self._search_content(j, self.c_comment_pattern,
skippable_contexts)
elif current == '/' and previous == '/':
# C++ style comment.
i = self._search_content(j, self.cpp_comment_pattern,
skippable_contexts)
else:
# Skip to the next char.
i += 1
return skippable_contexts
# Returns True if the match is within list of other matches
# Removes pragma once from content
def _process_pragma_once(self):
content_len = len(self.content)
if content_len < len("#include <x>"):
return 0
# Find contexts in the content in which a found include
# directive should not be processed.
skippable_contexts = self._find_skippable_contexts()
pragmas = []
pragma_once_match = self.pragma_once_pattern.search(self.content)
while pragma_once_match:
if not _is_within(pragma_once_match, skippable_contexts):
pragmas.append(pragma_once_match)
pragma_once_match = self.pragma_once_pattern.search(self.content,
pragma_once_match.end())
# Handle all collected pragma once directives.
prev_end = 0
tmp_content = ''
for pragma_match in pragmas:
tmp_content += self.content[prev_end:pragma_match.start()]
prev_end = pragma_match.end()
tmp_content += self.content[prev_end:]
self.content = tmp_content
# Include all trivial #include directives into self.content.
def _process_includes(self):
content_len = len(self.content)
if content_len < len("#include <x>"):
return 0
# Find contexts in the content in which a found include
# directive should not be processed.
skippable_contexts = self._find_skippable_contexts()
# Search for include directives in the content, collect those
# which should be included into the content.
includes = []
include_match = self.include_pattern.search(self.content)
while include_match:
if not _is_within(include_match, skippable_contexts):
include_path = include_match.group("path")
search_same_dir = include_match.group(1) == '"'
found_included_path = self.amalgamation.find_included_file(
include_path, self.file_dir if search_same_dir else None)
if found_included_path:
includes.append((include_match, found_included_path))
include_match = self.include_pattern.search(self.content,
include_match.end())
# Handle all collected include directives.
prev_end = 0
tmp_content = ''
for include in includes:
include_match, found_included_path = include
tmp_content += self.content[prev_end:include_match.start()]
tmp_content += "// {0}\n".format(include_match.group(0))
if found_included_path not in self.amalgamation.included_files:
t = TranslationUnit(found_included_path, self.amalgamation, False)
tmp_content += t.content
prev_end = include_match.end()
tmp_content += self.content[prev_end:]
self.content = tmp_content
return len(includes)
# Make all content processing
def _process(self):
if not self.is_root:
self._process_pragma_once()
self._process_includes()
def __init__(self, file_path, amalgamation, is_root):
self.file_path = file_path
self.file_dir = os.path.dirname(file_path)
self.amalgamation = amalgamation
self.is_root = is_root
self.amalgamation.included_files.append(self.file_path)
actual_path = self.amalgamation.actual_path(file_path)
if not os.path.isfile(actual_path):
raise IOError("File not found: \"{0}\"".format(file_path))
with open(actual_path, 'r') as f:
self.content = f.read()
self._process()
def main():
description = "Amalgamate C source and header files."
usage = " ".join([
"amalgamate.py",
"[-v]",
"-c path/to/config.json",
"-s path/to/source/dir",
"[-p path/to/prologue.(c|h)]"
])
argsparser = argparse.ArgumentParser(
description=description, usage=usage)
argsparser.add_argument("-v", "--verbose", dest="verbose",
choices=["yes", "no"], metavar="", help="be verbose")
argsparser.add_argument("-c", "--config", dest="config",
required=True, metavar="", help="path to a JSON config file")
argsparser.add_argument("-s", "--source", dest="source_path",
required=True, metavar="", help="source code path")
argsparser.add_argument("-p", "--prologue", dest="prologue",
required=False, metavar="", help="path to a C prologue file")
amalgamation = Amalgamation(argsparser.parse_args())
amalgamation.generate()
if __name__ == "__main__":
main()

View File

@ -0,0 +1,8 @@
{
"project": "entt",
"target": "single_include/entt/entt.hpp",
"sources": [
"src/entt/entt.hpp"
],
"include_paths": ["src"]
}

60
external/entt/entt/scripts/update_homebrew.sh vendored Executable file
View File

@ -0,0 +1,60 @@
#!/bin/sh
# only argument should be the version to upgrade to
if [ $# != 1 ]
then
echo "Expected a version tag like v2.7.1"
exit 1
fi
VERSION="$1"
URL="https://github.com/skypjack/entt/archive/$VERSION.tar.gz"
FORMULA="entt.rb"
echo "Updating homebrew package to $VERSION"
echo "Cloning..."
git clone https://github.com/skypjack/homebrew-entt.git
if [ $? != 0 ]
then
exit 1
fi
cd homebrew-entt
# download the repo at the version
# exit with error messages if curl fails
echo "Curling..."
curl "$URL" --location --fail --silent --show-error --output archive.tar.gz
if [ $? != 0 ]
then
exit 1
fi
# compute sha256 hash
echo "Hashing..."
HASH="$(openssl sha256 archive.tar.gz | cut -d " " -f 2)"
# delete the archive
rm archive.tar.gz
echo "Sedding..."
# change the url in the formula file
# the slashes in the URL must be escaped
ESCAPED_URL="$(echo "$URL" | sed -e 's/[\/&]/\\&/g')"
sed -i -e '/url/s/".*"/"'$ESCAPED_URL'"/' $FORMULA
# change the hash in the formula file
sed -i -e '/sha256/s/".*"/"'$HASH'"/' $FORMULA
# delete temporary file created by sed
rm -rf "$FORMULA-e"
# update remote repo
echo "Gitting..."
git add entt.rb
git commit -m "Update to $VERSION"
git push origin master
# out of homebrew-entt dir
cd ..

File diff suppressed because it is too large Load Diff

View File

@ -0,0 +1,83 @@
#ifndef ENTT_CONFIG_CONFIG_H
#define ENTT_CONFIG_CONFIG_H
#include "version.h"
#if defined(__cpp_exceptions) && !defined(ENTT_NOEXCEPTION)
# define ENTT_CONSTEXPR
# define ENTT_THROW throw
# define ENTT_TRY try
# define ENTT_CATCH catch(...)
#else
# define ENTT_CONSTEXPR constexpr // use only with throwing functions (waiting for C++20)
# define ENTT_THROW
# define ENTT_TRY if(true)
# define ENTT_CATCH if(false)
#endif
#ifdef ENTT_USE_ATOMIC
# include <atomic>
# define ENTT_MAYBE_ATOMIC(Type) std::atomic<Type>
#else
# define ENTT_MAYBE_ATOMIC(Type) Type
#endif
#ifndef ENTT_ID_TYPE
# include <cstdint>
# define ENTT_ID_TYPE std::uint32_t
#endif
#ifndef ENTT_SPARSE_PAGE
# define ENTT_SPARSE_PAGE 4096
#endif
#ifndef ENTT_PACKED_PAGE
# define ENTT_PACKED_PAGE 1024
#endif
#ifdef ENTT_DISABLE_ASSERT
# undef ENTT_ASSERT
# define ENTT_ASSERT(condition, msg) (void(0))
#elif !defined ENTT_ASSERT
# include <cassert>
# define ENTT_ASSERT(condition, msg) assert(condition)
#endif
#ifdef ENTT_DISABLE_ASSERT
# undef ENTT_ASSERT_CONSTEXPR
# define ENTT_ASSERT_CONSTEXPR(condition, msg) (void(0))
#elif !defined ENTT_ASSERT_CONSTEXPR
# define ENTT_ASSERT_CONSTEXPR(condition, msg) ENTT_ASSERT(condition, msg)
#endif
#define ENTT_FAIL(msg) ENTT_ASSERT(false, msg);
#ifdef ENTT_NO_ETO
# define ENTT_ETO_TYPE(Type) void
#else
# define ENTT_ETO_TYPE(Type) Type
#endif
#ifdef ENTT_STANDARD_CPP
# define ENTT_NONSTD false
#else
# define ENTT_NONSTD true
# if defined __clang__ || defined __GNUC__
# define ENTT_PRETTY_FUNCTION __PRETTY_FUNCTION__
# define ENTT_PRETTY_FUNCTION_PREFIX '='
# define ENTT_PRETTY_FUNCTION_SUFFIX ']'
# elif defined _MSC_VER
# define ENTT_PRETTY_FUNCTION __FUNCSIG__
# define ENTT_PRETTY_FUNCTION_PREFIX '<'
# define ENTT_PRETTY_FUNCTION_SUFFIX '>'
# endif
#endif
#if defined _MSC_VER
# pragma detect_mismatch("entt.version", ENTT_VERSION)
# pragma detect_mismatch("entt.noexcept", ENTT_XSTR(ENTT_TRY))
# pragma detect_mismatch("entt.id", ENTT_XSTR(ENTT_ID_TYPE))
# pragma detect_mismatch("entt.nonstd", ENTT_XSTR(ENTT_NONSTD))
#endif
#endif

View File

@ -0,0 +1,7 @@
#ifndef ENTT_CONFIG_MACRO_H
#define ENTT_CONFIG_MACRO_H
#define ENTT_STR(arg) #arg
#define ENTT_XSTR(arg) ENTT_STR(arg)
#endif

View File

@ -0,0 +1,14 @@
#ifndef ENTT_CONFIG_VERSION_H
#define ENTT_CONFIG_VERSION_H
#include "macro.h"
#define ENTT_VERSION_MAJOR 3
#define ENTT_VERSION_MINOR 12
#define ENTT_VERSION_PATCH 2
#define ENTT_VERSION \
ENTT_XSTR(ENTT_VERSION_MAJOR) \
"." ENTT_XSTR(ENTT_VERSION_MINOR) "." ENTT_XSTR(ENTT_VERSION_PATCH)
#endif

File diff suppressed because it is too large Load Diff

Some files were not shown because too many files have changed in this diff Show More