lumberyard-employee-dm d7ee248df5 Range adaptor support (#7388)
* Updated the SFINAE checks in concepts.h and range.h

To use conjunction and disjunction for short-circuiting behavior.

Replaced AZStd::optional implementation with std::optional alias

Added range adaptor support and the following views: ref_view,
owning_view

Added bitwise or(|) overload for chaining range adaptor closures together

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Adding indirectly invocable concepts.

These concepts are used to determine whether a callable can be invoked
with a dereferenced iterator instance.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Add implementation of range relational function objects

Add implementation of range min max functions which uses the range
relation function objects(ranges::less, ranges::equal_to, etc...)

This is needed to implement ranges::zip_view

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Adding interface for zip_view which compiles successfully

The implementation for the zip view functions still need to be filled.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Adding function definitions for zip_view classes.

Adding empty header of subrange.h for the ranges::subrange class

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Adding additional view implementations.

The following range and view classes have been added: empty_view,
single_view and subrange.

Moved the AZ_NO_UNIQUE_ADDRESS macro to PlatformDef.h to allow other
code to specify the [[no_unique_address]] attribute.

Added additional test for view structures.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Adding missing includes for non-unity builds

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Workaround for NDK21 clang 9.0.9 compile issue.

The AZStd::ranges::zip_view::iterator::iter_swap friend function is in the
AZStd::ranges namespace, while the customization point object of
`AZStd::ranges::customization_point_object::iter_swap` is in the regular
namespace of `AZStd::ranges` and the inline namespace of
`customization_point`.

This issue is fixed in NDK23, but as Jenkins uses NDK21 at the time, the
entire zip_view implementation has moved to inline namespace of
`zip_view_internal`

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Added iterator algorithm requiremetn concepts

Fixed the ambiguity in the ranges::iter_swap exchange overload to
exclude itself as a candidate if the iterator reference types are
swappable with each other.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Adding type alias for borrowed_subrange_t

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Fixed convertible to ref_view check in the ranges::all
customization_point

Updated SFINAE detection of whether AZStd::to_address is invocable

Moved the

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Fixed private variable access in ranges::subrange get specialization.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Removing ranges::view constraint from the ranges::views::single
customization_point.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Adding C++23 range overload for string_view.

It is detailed in the [C++draft strings](https://eel.is/c++draft/strings#lib:basic_string_view,constructor____) section

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Adding implementations of ranges, find, search, mismatch and equal
functions.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Adding implementation of ranges split_view along with test.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Adding const overloads to SceneAPI ProxyPointer container

The Proxy Pointer class operator* and operator-> was unable to be
invoked with a const instance before. Now it returns a const view of the
pointer it contains.
This allows it to be invoked in `AZStd::to_address` as part of an SINAE
context for the contiguous_iterator concept

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Refactored the to_address implementation to better work with SFINAE.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Adding general non-unity build fixes

This is unrelated to the RangeAdaptor changes.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Allow range algorithms to be used with rvalue ranges

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Workaround MSVC Internal Compiler erroy by removing enable_if
condition in the operator bool of the view_interface class.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Corrected the non_propagating_cache helper class to have public
functions

Fixed the order of creating the perfect forwarding call wrapper for an
outer closure around another closure.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Specialized the borrowed_range and view concepts

For the AZ PathView class, since it is a immutable view around a path.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Removed inline namespace around the zip_view class.

It was needed to workaround a clang 10 or below issue where a friend
function in a namespace and a variable within underneath an inline
namespace within the function namespace would cause an improper symbol
redefinition.

The workaround is to create a placeholder namespace containing the
inline namespace and then bring that placeholder namespace into the
parent scope.

https://bugs.llvm.org/show_bug.cgi?id=37556

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Adding implementation of the elemetns_view and join_view classes

It is up to date with the standard as of the current draft:
https://eel.is/c++draft/ranges.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Separated definitions of concepts out of concepts.h

This allows the ranges::iter_swap and ranges::swap customization point to be moved
outside of the concepts folder and into the ranges folder.

The concepts.h header previously had to define those objects to avoid
circular dependencies.

Added the work around for ranges::iter_swap and ranges::iter_move
customization_point causing an improper symbol redefinition in clang 10
or below: https://bugs.llvm.org/show_bug.cgi?id=37556

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Alias more std:: names into the AZStd namespace.

Removed our custom implementation of toaddress.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Adding more range view test.

The join_view and elements_view classes now have UnitTest.

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Adding deduction guides for AZStd associative containers

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Moved zip_view::sentinel iterator accessor function to zip_view.inl

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>

* Fixed variable shadowing issues with clang 12+

Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
2022-02-11 12:50:12 -06:00
2022-02-10 13:32:22 -08:00
2022-02-11 12:50:12 -06:00
2022-02-11 12:50:12 -06:00
2021-03-08 14:30:57 -08:00
2022-01-10 10:01:17 -08:00
2021-07-02 12:10:40 -07:00
2021-03-08 14:30:57 -08:00
2021-06-28 12:53:49 -07:00
2021-07-19 14:58:18 -05:00
2021-03-08 14:30:57 -08:00
2022-01-31 11:25:58 +01:00
2021-11-11 15:10:46 +00:00
2021-03-08 14:30:57 -08:00

O3DE (Open 3D Engine)

O3DE (Open 3D Engine) is an open-source, real-time, multi-platform 3D engine that enables developers and content creators to build AAA games, cinema-quality 3D worlds, and high-fidelity simulations without any fees or commercial obligations.

Contribute

For information about contributing to Open 3D Engine, visit https://o3de.org/docs/contributing/.

Download and Install

This repository uses Git LFS for storing large binary files.

Verify you have Git LFS installed by running the following command to print the version number.

git lfs --version 

If Git LFS is not installed, download and run the installer from: https://git-lfs.github.com/.

Install Git LFS hooks

git lfs install

Clone the repository

git clone https://github.com/o3de/o3de.git

Building the Engine

Build requirements and redistributables

For the latest details and system requirements, refer to System Requirements in the documentation.

Windows

Optional

  • Wwise audio SDK
    • For the latest version requirements and setup instructions, refer to the Wwise Audio Engine Gem reference in the documentation.

Quick start engine setup

To set up a project-centric source engine, complete the following steps. For other build options, refer to Setting up O3DE from GitHub in the documentation.

  1. Create a writable folder to cache downloadable third-party packages. You can also use this to store other redistributable SDKs.

  2. Install the following redistributables:

    • Visual Studio and VC++ redistributable can be installed to any location.
    • CMake can be installed to any location, as long as it's available in the system path.
  3. Configure the engine source into a solution using this command line, replacing <your build path>, <your source path>, and <3rdParty package path> with the paths you've created:

    cmake -B <your build path> -S <your source path> -G "Visual Studio 16" -DLY_3RDPARTY_PATH=<3rdParty package path>
    

    Example:

    cmake -B C:\o3de\build\windows -S C:\o3de -G "Visual Studio 16" -DLY_3RDPARTY_PATH=C:\o3de-packages
    

    Note: Do not use trailing slashes for the <3rdParty package path>.

  4. Alternatively, you can do this through the CMake GUI:

    1. Start cmake-gui.exe.
    2. Select the local path of the repo under "Where is the source code".
    3. Select a path where to build binaries under "Where to build the binaries".
    4. Click Add Entry and add a cache entry for the <3rdParty package path> folder you created, using the following values:
      1. Name: LY_3RDPARTY_PATH
      2. Type: STRING
      3. Value: <3rdParty package path>
    5. Click Configure.
    6. Wait for the key values to populate. Update or add any additional fields that are needed for your project.
    7. Click Generate.
  5. Register the engine with this command:

    scripts\o3de.bat register --this-engine
    
  6. The configuration of the solution is complete. You are now ready to create a project and build the engine.

For more details on the steps above, refer to Setting up O3DE from GitHub in the documentation.

Setting up new projects and building the engine

  1. From the O3DE repo folder, set up a new project using the o3de create-project command.

    scripts\o3de.bat create-project --project-path <your new project path>
    
  2. Configure a solution for your project.

    cmake -B <your project build path> -S <your new project source path> -G "Visual Studio 16"
    

    Example:

    cmake -B C:\my-project\build\windows -S C:\my-project -G "Visual Studio 16"
    

    Note: Do not use trailing slashes for the <3rdParty cache path>.

  3. Build the project, Asset Processor, and Editor to binaries by running this command inside your project:

    cmake --build <your project build path> --target <New Project Name>.GameLauncher Editor --config profile -- /m
    

    Note: Your project name used in the build target is the same as the directory name of your project.

This will compile after some time and binaries will be available in the project build path you've specified, under bin/profile.

For a complete tutorial on project configuration, see Creating Projects Using the Command Line Interface in the documentation.

License

For terms please see the LICENSE*.TXT files at the root of this distribution.

S
Description
Open 3D Engine (O3DE) is an Apache 2.0-licensed multi-platform 3D engine that enables developers and content creators to build AAA games, cinema-quality 3D worlds, and high-fidelity simulations without any fees or commercial obligations.
Readme 150 MiB
Languages
C++ 82.6%
Python 13.1%
CMake 1.5%
Roff 1.2%
Lua 0.5%
Other 0.8%