Conversation
|
Quick drop-in opinion: I don’t think it makes sense to have unsafe wrappers to what could definitely be safe functions. I would much rather these functions to be defined using the already existing wrapping functionality (like |
Yeah so I agree on both points. The first one see #41 for the issues there, for the second one I would like to statically ensure that its in linear memory but I don't think we can do that without requiring some kind of wrapper like |
| ); | ||
| } | ||
|
|
||
| //instance.draw_arrays(buffer::Primitive::Triangles, vbo_data); |
There was a problem hiding this comment.
Is this just leftover from copy-pasting the existing triangle example?
There was a problem hiding this comment.
I might call this cube-indexed.rs or something just to make it clear that it uses an index buffer as compared to the existing triangle xample
| let mut indecies = Vec::with_capacity_in(indecies_a.len(), ctru::linear::LinearAllocator); | ||
| indecies.extend_from_slice(&indecies_a); |
There was a problem hiding this comment.
Maybe to enforce lifetimes for index buffers we could have something like buffer::Info::index_buffer(&[usize]). I think if we had that it could resolve at least partially some of the lifetime issues, since Slice already captures the lifetime of the vertex buffer. Then I think the code would look something like this?
let (attr_info, _vbo_data) = prepare_vbos(&mut buf_info, &vbo_data);
let mut index_buffer = buf_info.index_buffer();
// This possibly also checks that all the new indices are valid for the vertex data:
index_buffer.extend_from_slice(&indices_a);Edit: actually, I guess we'd also need to make sure the vertex buffer was added at some point, so maybe this would be a method on buffer::Slice instead, or a new buffer::Info::add_indexed(vbo_data, attrib_info, indices) or something. I'm not sure what the best API would be but maybe something along those lines
| @@ -0,0 +1,6 @@ | |||
| /// Check if pointer is in linear memory | |||
| pub fn is_linear_ptr<P>(p: *const P) -> bool { | |||
There was a problem hiding this comment.
This does seem useful to have — I've also thought about having some kind of type safety around this, e.g.
trait Linear {}
impl<T> Linear for Vec<T, LinearAllocator> {}The problem is that other APIs would end up with somewhat inconvenient definitions, e.g.
pub fn add<'this, 'a, T, V>(
&'this mut self,
vbo_data: &T,
attrib_info: &attrib::Info,
) -> crate::Result<Slice<'a>>
where
'this: 'a,
T: Deref<Target = [V]> + Linear,
{But maybe the type safety would be worth it and then we wouldn't need panics or Err types for all these things that require linear allocation.
| /// # Safety | ||
| /// If `indices` goes out of scope before the current frame ends it will cause a use-after-free (possibly by the GPU) | ||
| /// If `buf` does not contain all the vertices references by `indices` it will cause an invalid access by the GPU (this crashes citra) |
There was a problem hiding this comment.
I think I'm fine with having a new unsafe API for now, but definitely would like to see if we can solve this with the type system somehow. I mentioned a possible option for the second issue in my other comment and I think the first issue could be solved with other stuff for #41 so I think we at least have a path forward.
3 participants
This adds a wrapper for
C3D_DrawElementswhich is index based drawing. It is marked unsafe for reasons which are explained in the doc comment and #41. I've also added an example to both test it works and demonstrate its usage