This specifically implies to the value returning to_string overloads
Added a range based StringFunc::Join overload.
Reduced the number of AZStd::to_string calls in the TranslationKey
operator<< function.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Add RoundUpToMultiple and DivideAndRoundUp functions to MathUtils.h
Signed-off-by: Tommy Walton <waltont@amazon.com>
* Rename DivideByMultiple2 back to DivideByMultiple, now that I've confirmed it's not in use in the codebase. RHI::DivideByMultiple can be fully deprecated in favor of AZ::DivideAndRoundUp at a later date, once the deprecation strategy has been finalized.
Signed-off-by: Tommy Walton <waltont@amazon.com>
* Update based on PR feedback
Signed-off-by: Tommy Walton <waltont@amazon.com>
* Switched from std::numeric_limits to AZStd::numeric_limits and updated the header to indicate it works for non-power of two alignments, but that SizeAlignUp is more efficient if the alignment is a power of 2
Signed-off-by: Tommy Walton <waltont@amazon.com>
* Added missing arguments to the assert, and a missing namespace and include that failed to compile on non-unity builds
Signed-off-by: Tommy Walton <waltont@amazon.com>
* Updated Launching of Lua Editor to supply the project-path
The Lua Launch logic also uses the AzFramework ProcessLauncher instead
of Qt. This has the benefit of being able to pass arguments as an array
instead of in a single string. Therefore paths with spaces in them also
work.
Tweak the Settings Registry logic to locate the
project-path/engine-path by scanning upwards for a
project.json/engine.json respectively to inject the found paths to the
front of the command line parameters instead of the back.
This has the effect of making sure that command line parameters for the
project-path/engine-path always takes precedence over scanning upwards
for a project.json/engine.json.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Removed prepend of EngineRoot in CheckProjectPathProvided
The Editor would attempt to validate that the project path supplied via
the command line contained a valid project.json file before contining
the Editor startup flow.
This was taking the engine root path and appending the project path to
it, which works when the project path is absolute
But when the project path is relative it is treated as relative to the
current working directory by the SettingsRegistry, but the logic in the
CheckProjectPathProvided was treating it has relative to the engine
root. Therefore supplying a relative path as part of the Editor.exe
launch command would fail.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Fixed resolving of relative paths to absolute paths in the Editor
The Editor was changing the current working directory to the nearest
ancestor directory containing an `engine.json` file.
This resulted in the ConvertToAbsolutePath function resolving relative
paths to that directory instead of the launch directory of the Editor.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
Consolidated the contents of CpuProfilerImp.h into CpuProfiler.h
Renamed CpuProfilerImpl.cpp to CpuProfiler.cpp
Collapsed the CpuProfilerImpl class into the intermediary CpuProfiler interface class, removing that interface type
Replaced all calls to the old CpuProfiler interface with AZ::Debug::ProfilerSystemInterface
Added accessor to see if a continuous capture is in progress to AZ::Debug::ProfilerRequests
Signed-off-by: AMZN-ScottR 24445312+AMZN-ScottR@users.noreply.github.com
* Change AtomTressFX passes to write to exsiting DepthLinear buffer instead of creating a new one as output.
Signed-off-by: Qing Tao <55564570+VickyAtAZ@users.noreply.github.com>
* Added new api in RPI to apply render pipeline changes from FP
Signed-off-by: Qing Tao <55564570+VickyAtAZ@users.noreply.github.com>
* Update AtomTressFX gem to create hair parent pass at runtime
Signed-off-by: Qing Tao <55564570+VickyAtAZ@users.noreply.github.com>
* Change Scene::ApplyRenderPipelineChange() to TryApplyRenderPIpelineChanges().
Have TryApplyRenderPIpelineChanges() called automatically when a render pipeline is added to a Scene.
Re-apply the render pipeline change when RenderPipeline got recreated (Pass hot-reloading support)
Add AddPassBefore() and AddPassAfter() function to RenderPIpeline class.
Signed-off-by: Qing Tao <55564570+VickyAtAZ@users.noreply.github.com>
GCC doesn't accept accessing member variables inside the noexcept expression of a member function.
GCC also requires that template specializations for an inner template be outside of all classes.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
- Use `unordred_map` (speed is about the same but providing a hash is slightly nicer than operator<)
- Do better arg forwarding where applicable
- Swap EXPECT_ test ordering
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
* Up the hard coded size for the HpAllocator buffer to 18KiB
Added a static assert in the HphaSchema.cpp file to validate that the
HpAllocator aligned storage buffer is at least the size of the
HpAllocator class.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Removed comment blocks with username from HphaSchema.h
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
Previously, with no level loaded in the main editor, and no assets loaded
in the EMotionFX editor, the AnimGraph viewport would only update at 15fps,
even on a 64 core machine.
Digging into this with Pix, I found that EMotionFX's UI would only get
updated for every other call to the ComponentApplication tick.
The Editor's QApplication instance controls how the
`ComponentApplication::OnTick` method is called. This is done in the
`maybeProcessIdle()` method. Generally, I found callstacks like this:
```
EditorQtApplication::maybeProcessIdle()
CCryEditApp::OnIdle()
CCryEditApp::IdleProcessing()
CGameEngine::Update() # ~2.2ms
PhysX::Update() # ~1.8ms
EMotionFX::Update() # ~0.2ms
calls QWidget::update() on all the widgets that change per
frame, only puts update events on the event queue, doesn't
paint anything
AZ::ComponentApplication::TickSystem() # ~25ms
renders the frame with Atom # ~24ms
```
The `maybeProcessIdle()` method is invoked by a QTimer, with a timeout
that changes depending on the application state. If the Editor is in
game mode, it used a timeout of 0, which essentially forced the game to
run at as high an fps as possible. If the Editor application has focus,
it used a timeout of 1ms, asking for the idle processing to happen at
1000 fps. Otherwise, it used a timeout of 10ms, asking for idle
processing at 100 fps.
Those fps targets are not realistic. What happened in this case is that
while the PhysX system was being updated, while the previous
`maybeProcessIdle()` call was still processing, the idle processing
timer would timeout again, and place a timer event on Qt's event queue,
before anything else had a chance to do anything. Only afterward would
EMotionFX's MainWindow::OnTick would be invoked, placing paint events on
Qt's event queue.
The fix for this is to use a single shot timer at the end of each
`maybeProcessIdle()` call. This ensures that any events that are
enqueued during the `maybeProcessIdle()` call are processed prior to the
next call to `maybeProcessIdle()`.
Signed-off-by: Chris Burel <burelc@amazon.com>
Tom Hulton-Harrop
lumberyard-employee-dm
Danilo Aimini
Tommy Walton
Chris Galvan
Luis Sempé
Scott Romero
Vincent Liu
amzn-mike
Allen Jackson
puvvadar
Qing Tao
John Jones-Steele
Nicholas Van Sickle
Mike Balfour
Ronald Koppers
Chris Burel
Olex Lozitskiy