Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few comments, it's a bit hard to review since you can't see what the actual changes are. I'm gonna clone the branch myself later and create a diff so I can review it better.
amethyst_renderer_new/Cargo.toml
Outdated
repository = "https://github.com/amethyst/amethyst" | ||
|
||
readme = "README.md" | ||
license = "MIT OR Apache-2.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MIT/Apache-2.0
amethyst_renderer_new/src/back.rs
Outdated
@@ -0,0 +1,39 @@ | |||
|
|||
#[cfg(feature = "metal")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we at some point allow to dynamically choose the backend? I think for an actual game it's preferable to have one binary which supports all the backends.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll think about it
amethyst_renderer_new/src/memory.rs
Outdated
|
||
use back::*; | ||
|
||
error_chain! { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 👍 I scanned the error_chain!
source today and I think it's something I want to have in Amethyst.
amethyst_renderer_new/src/memory.rs
Outdated
} | ||
|
||
|
||
/// This allocator is do dumb it can't even free memory |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe "is so dumb"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
correct!
amethyst_renderer_new/src/memory.rs
Outdated
impl DumbAllocator { | ||
pub fn new() -> Self { | ||
DumbAllocator { | ||
granularity: 268_435_456, // 256 MB |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe 256 * 1024 * 1024
is better here?
amethyst_renderer_new/rustfmt.toml
Outdated
@@ -0,0 +1,2 @@ | |||
reorder_imported_names = true | |||
take_source_hints = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can remove this file, the base config for the workspace is applied
I'll make it easier to view changes. |
amethyst_renderer/Cargo.toml
Outdated
categories = ["rendering", "rendering::engine"] | ||
|
||
documentation = "https://www.amethyst.rs/doc/master/amethyst_renderer/" | ||
documentation = "https://docs.rs/amethyst_renderer/0.1.0/amethyst_renderer/" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it a good thing to change this? Especially locking the version isn't a good thing IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Old link leads to 404
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think https://docs.rs/amethyst_renderer
will be ideal. It will redirect to newest version automatically
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the main crate has the correct link
amethyst_renderer/src/lib.rs
Outdated
|
||
pub mod error; | ||
pub mod cam; | ||
pub mod mesh; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are you removing all my imports? Could we please leave the crate structure flat?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file was written from scratch. I'll add everything required later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay. Please just make the modules private and reexport everything if that's possible.
amethyst_renderer/src/memory.rs
Outdated
} | ||
} | ||
|
||
impl From<OutOfMemory> for Error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this use links
in the error-chain
macro?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OutOfMemory
isn't Error
links are for other error-chain
s. For non-chain errors there is foreign_links
. But it still required to implement Error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And OutOfMemory
doesn't implement Error
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeap
It would be really nice if you could just change what's absolutely necessary, because I don't want to end up with a renderer rewrite 2.0 that rewrites the whole engine (and blocks everything else). If there are things you need to change which don't have anything to do with the internals of the renderer crate, please create another PR if possible. |
I think the renderer is gonna be mostly rewritten, because hal is such a big change it's kind of required. |
True, but if you had seen the previous renderer rewrite you'd know what I mean. It did change the whole crate, not just the renderer. |
Oh I saw, and shuddered :) |
@torkleyy I try to make render API to look mostly the same. |
This one probably won't be as bad because of how well we've separated out our crates. The last renderer rewrite was functionally a rewrite of the whole project, this one isn't. |
4b06eb0
to
6fe6a19
Compare
I'm really happy to see this PR making progress, keep up the good work @omni-viral! |
THIS IS AWESOME!! |
I'm very confident I can review this in December, in case you didn't already merge it then. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it a lot! Much simplified. A large PR mandates a large review, so here's 19 review comments for you :P
//! Pass tells renderer how to convert inputs to image. | ||
//! | ||
//! # Definition | ||
//! Pass - is a box which get some: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be better to use:
Pass is a trait that takes these inputs
...
...
and provides these outputs:
...
...
//! * Push constants | ||
//! * Outputs | ||
//! * Attachments | ||
//! * Results of queries (Let's forget about it for now) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forget about what? I'm not clear what's being said here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
About queries
//! | ||
//! But it gets executed on the GPU. | ||
//! So instead of writing it as a function and calling with arguments needed | ||
//! we have to record commands into buffers and send them to the GPU. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't 100% true as some passes like UI are pretty CPU driven (out of necessity). I think a more accurate way to describe this might be
The pass prepares and sends data to GPU shader buffers, the shaders will then process the data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shaders are only part of pipeline.
//! So instead of writing it as a function and calling with arguments needed | ||
//! we have to record commands into buffers and send them to the GPU. | ||
//! | ||
//! We want a way to define a box which will record all necessarry commands in declarative fasion. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
*fashion.
//! | ||
//! We want a way to define a box which will record all necessarry commands in declarative fasion. | ||
//! In order to feed this box with data we also need define `World -> [Input]` conversion | ||
//! (in declarative fasion where possible). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
*fashion
amethyst_renderer_new/src/staging.rs
Outdated
|
||
use back::*; | ||
|
||
pub enum StagingBuffer { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's this for? The line bringing this module in is commented out so should we just get rid of this file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's under construction 😄
amethyst_renderer_new/src/vertex.rs
Outdated
} | ||
unsafe impl Pod for Color {} | ||
impl Attribute for Color { | ||
const NAME: &'static str = "1_color"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not "color"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Attribute values (name + format) should be in strict order. Forcing it with name prefix was fast fix. It'll go away.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The order is Position -> Color -> Normal -> Tangent -> TexCoord.
Buffers can only contain those attributes in sorted order. And Mesh has to contain Buffers in sorted order. Why? To bind mesh for O(n + k) insted of O(n*k).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then maybe it would be better to have a separate constant for the order?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@torkleyy Correct. Prefixing names is for fast-fixing
amethyst_renderer_new/src/vertex.rs
Outdated
} | ||
unsafe impl Pod for Normal {} | ||
impl Attribute for Normal { | ||
const NAME: &'static str = "2_normal"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not "normal"?
amethyst_renderer_new/src/vertex.rs
Outdated
} | ||
unsafe impl Pod for Tangent {} | ||
impl Attribute for Tangent { | ||
const NAME: &'static str = "3_tangent"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above
amethyst_renderer_new/src/vertex.rs
Outdated
} | ||
unsafe impl Pod for TexCoord {} | ||
impl Attribute for TexCoord { | ||
const NAME: &'static str = "4_tex_coord"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above.
/// Reflects [`Pass::draw`] function | ||
/// | ||
/// [`Pass::draw`]: trait.Pass.html#tymethod.draw | ||
fn draw<'a>(&mut self, cbuf: &mut B::CommandBuffer, world: &'a World); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why have a lifetime here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No reason
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wheew, that's quite a large PR. Just a few notes from my side regarding some internal stuff. I haven't looked trough the whole code.
swapchain.present(queue, &presents); | ||
|
||
// Wait defice to finish the work | ||
device.wait_for_fences(&[finish], WaitFor::All, !0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should be multiple fences to reduce waiting time on the GPU. Currently it's CPU -> (submit) -> GPU -> (wait) -> CPU. This requires multiple command buffers per frame, etc. The main point is to reduce the time the CPU waits on the GPU to finish processing the currently requested frame. That's a pretty crucial design point imo to achieve good performance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What pattern of using fences I should follow?
I was thinking of waiting for fence before rendering next frame instead of after.
I'm not sure if starting rendering next frame before previous is complete is a good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made a small figure which visualizes the issue, I think. The current implementation introduces a stall between GPU-CPU due to the wait for the fence. The general proposal is to buffer a few frames (basically following double/tripple buffering of the swapchain) to give the GPU time to catch up and reducing the waiting time on the fence. In the figure I used frame3 waits unitl frame0 has finished on the GPU and can then re-use data (in particular, command pools, query buffers, etc.) of frame0. The drawback here is that this makes synchronization a bit trickier as fences ensure that objects can be safely accessed again. So, each frame in the chain requires an own command pool for example.
} | ||
} | ||
|
||
pub fn build( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The definition of a pass seems quite focused on Vulkan's renderpass concept. If I understand it correctly a pass is defined here as one renderpass with one subpass and pipeline. I would advise a lower level implementation which focuses purely on scheduling tasks and reducing the amount of synchronization handling for users writing rendering code. It might be tricky here to extend the current implementation to support compute and further optimizations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The concept of Pass
is quite abstract here. It's a function-like thing that can have Behavior
-like (from FRP) arguments (attachments and buffers) and return Behavior
-like result.
What you see in this method is mapping of general concept to RenderPass
es.
It's tricky to implement this so I started with simples unoptimized solution. I'll try to make it faster in next iterations.
let descriptor_set_layout = device.create_descriptor_set_layout(pass.bindings()); | ||
|
||
// Create `PipelineLayout` from single `DescriptorSetLayout` | ||
let pipeline_layout = device.create_pipeline_layout(&[&descriptor_set_layout]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pipeline layouts and pipelines are not necessarily strongly-coupled. A pipeline layout can be compatible with multiple pipelines. Switching (non-compatible) pipeline layouts introduces costs due to rebinding descriptor sets and push constants.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But how often different pipelines can share pipeline layout?
Doesn't pipeline layout defines bindigs interface of shaders?
How often different shaders share bindings interface?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it defines the interface but can be a superset (some sort of 'uberlayout'). There is always a tradeoff between both approaches: minimal pipeline layout vs 'uberlayout'. Which to choose depends on the available pipelines. It might be interesting when having a lot of similar materials with lightly varying pipelines. I would say that expecially latest gen architectures can live with only a few pipeline layouts by using large descriptor sets, only bound once, but I'm not an expert.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense but I'd like to hide such details from user. So I need to magically create super-layout for few consecutive passes.
Reviewed 4 of 17 files at r1, 5 of 18 files at r2, 2 of 20 files at r3, 1 of 6 files at r5, 2 of 24 files at r6. amethyst_renderer_new/Cargo.toml, line 15 at r7 (raw file):
Should be "MIT/Apache-2.0" amethyst_renderer_new/Cargo.toml, line 27 at r7 (raw file):
Don't forget to specify versions here. amethyst_renderer_new/rustfmt.toml, line 1 at r7 (raw file):
Do we really need one config per crate? amethyst_renderer_new/src/relevant.rs, line 2 at r7 (raw file):
Types don't get dropped. amethyst_renderer_new/src/relevant.rs, line 4 at r7 (raw file):
"than" should be "then", but I'd probably rewrite the sentence as "If a structure has a amethyst_renderer_new/src/relevant.rs, line 12 at r7 (raw file):
Rename to amethyst_renderer_new/src/relevant.rs, line 23 at r7 (raw file):
This really isn't something I want the user to deal with, I hope we can keep this fully internal. amethyst_renderer_new/src/utils.rs, line 4 at r7 (raw file):
This seems very expensive for what it's doing. I don't know where it's used, but if it's necessary I'd recommend to just check if amethyst_renderer_new/src/utils.rs, line 14 at r7 (raw file):
Same as above. examples/hal/hal.vert, line 2 at r7 (raw file):
Is this something we should recommend for all shaders until there is a good shading solution (cross-API, eventually in Rust) available? examples/hal/main.rs, line 37 at r7 (raw file):
How much of this low-level code will the user need to set up a basic game in the final iteration? Comments from Reviewable |
So I've reviewed the easy files now so that I can concentrate on the other stuff. Is there some strategy you'd recommend for reviewing? Or some high-level overview that would make it easier? FYI, I reviewed on https://reviewable.io, so it's probably easier to respond there. |
Reviewed 2 of 33 files at r12, 1 of 108 files at r15, 3 of 31 files at r20. Cargo.toml, line 46 at r20 (raw file):
Just marking as unresolved, so we don't forget to fix it. Cargo.toml, line 47 at r20 (raw file):
Not too related to this PR, but maybe we should be using amethyst_renderer/src/cirque.rs, line 7 at r20 (raw file):
Please add docs what this type is for. amethyst_renderer/src/cirque.rs, line 18 at r20 (raw file):
Please rename to amethyst_renderer/src/cirque.rs, line 35 at r20 (raw file):
I also don't understand this check. Please add some comments or docs here. amethyst_renderer/src/epoch.rs, line 167 at r15 (raw file): Previously, omni-viral (Zakarum) wrote…
I agree, please add a amethyst_renderer/src/epoch.rs, line 92 at r20 (raw file):
Cells should be invariant over amethyst_renderer/src/epoch.rs, line 125 at r20 (raw file):
Ah, finally some docs. Nice! amethyst_renderer/src/epoch.rs, line 141 at r20 (raw file):
This is marked as unsafe, thus needs to document what guarantees the user needs to uphold. amethyst_renderer/src/epoch.rs, line 325 at r20 (raw file):
Is this a good idea? Can't we support 32-bit? Comments from Reviewable |
Forget about that note about variance, I just realized it's immutable only, so it should be correct. |
Review status: all files reviewed at latest revision, 83 unresolved discussions. amethyst_renderer/src/epoch.rs, line 212 at r20 (raw file):
This does not require an atomic operation. amethyst_renderer/src/epoch.rs, line 315 at r20 (raw file):
Err..we need to acquire a lock here if I'm not completely mistaken. This line can lead to severe memory bugs. amethyst_renderer/src/epoch.rs, line 316 at r20 (raw file):
This isn't correct, it can cause a race condition. Comments from Reviewable |
Review status: all files reviewed at latest revision, 83 unresolved discussions. amethyst_renderer/src/epoch.rs, line 84 at r19 (raw file): Previously, Rhuagh (Simon Rönnberg) wrote…
amethyst_renderer/src/epoch.rs, line 138 at r19 (raw file): Previously, Rhuagh (Simon Rönnberg) wrote…
Yeap. amethyst_renderer/src/epoch.rs, line 125 at r20 (raw file): Previously, torkleyy (Thomas Schaller) wrote…
=^_^= amethyst_renderer/src/epoch.rs, line 325 at r20 (raw file): Previously, torkleyy (Thomas Schaller) wrote…
We should. But it requires Comments from Reviewable |
Review status: all files reviewed at latest revision, 82 unresolved discussions. amethyst_renderer/src/epoch.rs, line 138 at r19 (raw file): Previously, omni-viral (Zakarum) wrote…
Ah that makes sense. Please add this to the documentation above. amethyst_renderer/src/epoch.rs, line 325 at r20 (raw file): Previously, omni-viral (Zakarum) wrote…
Just casting it to a Comments from Reviewable |
Review status: 80 of 100 files reviewed at latest revision, 81 unresolved discussions. Cargo.toml, line 47 at r20 (raw file): Previously, torkleyy (Thomas Schaller) wrote…
Let's take this as a separate discussion. amethyst_renderer/src/epoch.rs, line 138 at r19 (raw file): Previously, torkleyy (Thomas Schaller) wrote…
I agree, documentation is enough then Comments from Reviewable |
Reviewed 5 of 108 files at r15, 2 of 31 files at r20, 18 of 20 files at r21. amethyst_animation/Cargo.toml, line 25 at r21 (raw file):
Why use the git version? amethyst_renderer/src/graph/pass.rs, line 114 at r21 (raw file):
These docs are identical to draw_inline below, that doesn't seem right? Comments from Reviewable |
Reviewed 2 of 108 files at r15, 2 of 20 files at r21. Comments from Reviewable |
Review status: all files reviewed at latest revision, 83 unresolved discussions. amethyst_animation/Cargo.toml, line 25 at r21 (raw file): Previously, Rhuagh (Simon Rönnberg) wrote…
Entry API. amethyst_renderer/src/epoch.rs, line 212 at r20 (raw file): Previously, torkleyy (Thomas Schaller) wrote…
This one doesn't amethyst_renderer/src/epoch.rs, line 315 at r20 (raw file): Previously, torkleyy (Thomas Schaller) wrote…
The whole point of using atomics here is to not acquire locks. amethyst_renderer/src/epoch.rs, line 316 at r20 (raw file): Previously, torkleyy (Thomas Schaller) wrote…
It can in general. amethyst_renderer/src/epoch.rs, line 325 at r20 (raw file): Previously, torkleyy (Thomas Schaller) wrote…
No. We need to store Comments from Reviewable |
Review status: all files reviewed at latest revision, 83 unresolved discussions. amethyst_renderer/src/epoch.rs, line 315 at r20 (raw file): Previously, omni-viral (Zakarum) wrote…
With locks I was talking about atomics, actually. amethyst_renderer/src/epoch.rs, line 316 at r20 (raw file): Previously, omni-viral (Zakarum) wrote…
This doesn't establish any sort of happens-before relation, so how and why do you think it works? amethyst_renderer/src/epoch.rs, line 325 at r20 (raw file): Previously, omni-viral (Zakarum) wrote…
Yeah, I know. Still, it's an alternative. Comments from Reviewable |
Review status: all files reviewed at latest revision, 82 unresolved discussions. amethyst_renderer/src/epoch.rs, line 316 at r20 (raw file): Previously, torkleyy (Thomas Schaller) wrote…
Because Comments from Reviewable |
Reviewed 1 of 31 files at r11, 1 of 33 files at r12, 10 of 108 files at r15, 1 of 20 files at r19, 2 of 31 files at r20, 22 of 22 files at r22. amethyst_renderer/src/cirque.rs, line 66 at r22 (raw file):
I think this should say immutable? Comments from Reviewable |
Reviewed 5 of 39 files at r6, 3 of 31 files at r11, 14 of 108 files at r15, 82 of 82 files at r23. Comments from Reviewable |
@omni-viral Looks like you have a lot of commits in here merged from prior PRs. Looks like this could use a rebase. |
@Xaeroxe indeed. But they aren't merged. I rebased to "develop". But this PR is created against "hal-integration" |
Reviewed 2 of 83 files at r23, 2 of 39 files at r24, 2 of 21 files at r25. amethyst_core/Cargo.toml, line 21 at r25 (raw file):
No need for an inline table.x amethyst_core/src/events_pump.rs, line 3 at r25 (raw file):
Does this file belong into this PR? As I've requested before, could you please extract some parts from your PR and create a separate PR that we can merge right now? That would help reviewers of this PR by reducing the number of files and you don't have to rebase if we change files. amethyst_renderer/Cargo.toml, line 33 at r24 (raw file):
No need for an inline table anymore.xxx amethyst_renderer/Cargo.toml, line 43 at r24 (raw file):
No need for an inline table. amethyst_renderer/src/camera.rs, line 96 at r25 (raw file):
Why create a Comments from Reviewable |
b7e1687
to
d20ec89
Compare
Review status: 38 of 99 files reviewed at latest revision, 86 unresolved discussions, some commit checks failed. amethyst_core/src/events_pump.rs, line 3 at r25 (raw file): Previously, torkleyy (Thomas Schaller) wrote…
That would require quite a bit of restructuring of the old renderer unfortunately Comments from Reviewable |
Reviewed 5 of 40 files at r6, 3 of 31 files at r11, 2 of 67 files at r13, 22 of 111 files at r15, 1 of 22 files at r19, 2 of 32 files at r20, 11 of 39 files at r24, 6 of 21 files at r25, 52 of 52 files at r26. amethyst_renderer/src/upload.rs, line 53 at r26 (raw file):
If possible, can we use imports instead? Comments from Reviewable |
Review status: all files reviewed at latest revision, 87 unresolved discussions, some commit checks failed. amethyst_renderer/src/upload.rs, line 53 at r26 (raw file): Previously, Rhuagh (Simon Rönnberg) wrote…
I'll try 😄 Comments from Reviewable |
Review status: all files reviewed at latest revision, 87 unresolved discussions, some commit checks failed. amethyst_core/src/events_pump.rs, line 3 at r25 (raw file): Previously, Rhuagh (Simon Rönnberg) wrote…
You can just not use it with old renderer 😸 Comments from Reviewable |
Review status: all files reviewed at latest revision, 87 unresolved discussions, some commit checks failed. amethyst_core/src/events_pump.rs, line 3 at r25 (raw file): Previously, omni-viral (Zakarum) wrote…
Or we use it from the inside the old renderer. Comments from Reviewable |
#Roadmap.
What's left:
This change is