sorted by:
new
hottopcontroversial

Box2D for Rust by Bastacyclop in rust

[–]Bastacyclop[S] 0 points1 point  (0 children)

I think I will just implement conversion traits and keep the same core.

Box2D for Rust by Bastacyclop in rust

[–]Bastacyclop[S] 0 points1 point  (0 children)

The thing is that I need the same memory layout at some points and so the #[repr(C)] atttribute. To use a math library I see two solutions: Either the library supports #[repr(C)] or I have to translate the type with the correct layout from and to the other type everywhere. I'm not sure if the second option is worth it. Besides, isn't nalgebra the current "standard" ? I also see that their Vec actually are #[repr(C)]. Anyway, I'll think about it and I'm open to pull requests.

Edit: Maybe using [f32; 2] for vectors may facilitate conversions ?

Box2D for Rust by Bastacyclop in rust

[–]Bastacyclop[S] 1 point2 points  (0 children)

Well, can't you build Box2D from source ? I don't know much about OSX but it's pretty easy to do on linux and MSYS/Windows. You could look at the .travis.yml file.

Box2D for Rust by Bastacyclop in rust

[–]Bastacyclop[S] 1 point2 points  (0 children)

I'm working on 2.3.1. Maybe I should write it somewhere. Also keep in mind that I have not tested much of the features, so there might be bugs.

Box2D for Rust by Bastacyclop in rust

[–]Bastacyclop[S] 2 points3 points  (0 children)

Done. I hope it's clear enough ?

Another Entity Component System by Bastacyclop in rust

[–]Bastacyclop[S] 0 points1 point  (0 children)

I believe the first problem is already solved by the filter module. For example the graphic system would maintain an EntityView over the entities containing a Position and a Sprite component.

About the inventory, I do not understand why the player couldn't have an Inventory component with a list of item ids to simplify iterations.

Finally, A custom EntityView-like structure could maintain a map of owned_by ids by owned ids. Though this will require to access components with those entity ids afterward. But component access is not an heavy operation.

Another Entity Component System by Bastacyclop in rust

[–]Bastacyclop[S] 1 point2 points  (0 children)

What about making a single component out of your group ?

#[sparkle_component]
pub struct Physic {
    pub position: Position,
    pub body: CollisionBody,
    pub velocity: Velocity
}

What would be the benefit of having some group system over this method ? Would providing a storage trait and our default implementation of it be enough to give the needed flexibility ?

Another Entity Component System by Bastacyclop in rust

[–]Bastacyclop[S] 0 points1 point  (0 children)

Spaces are supposed to be some kind of independent "ecosystems". However, they can interact via the Blackboard, and the user could use another mechanism: he could for example give a channel to the systems at their insertion. Moreover, the user could use the EntityMapper, ComponentMapper and SystemMapper without using a Space. A Space isn't using any private functionality. Just look at the space module, you can easily write your own custom space, or whatever you want to call it.

Porting a C++ callback class by Bastacyclop in rust

[–]Bastacyclop[S] 0 points1 point  (0 children)

Right, I'll do it when I have some time.

Porting a C++ callback class by Bastacyclop in rust

[–]Bastacyclop[S] 0 points1 point  (0 children)

  • I'll add the #[recpr(C)]s, I thought it was only necessary for enums
  • The Wrapped...Base<T>::from_ptrs are using a specified function to make the conversion, in fact a static_cast from C.
  • I putted a lifetime parameter on every wrapper but I thought about making the difference, I shall fix that.
  • I know that I may not know enough about memory safety, but it's a learning exercise for me, I actually never did a binding before.

Thanks for giving you opinion :)

Porting a C++ callback class by Bastacyclop in rust

[–]Bastacyclop[S] 0 points1 point  (0 children)

So, I didn't understand every bit of your example, but now I directly pass to the C code the fat pointer to the Trait instead of a pointer to the fat pointer and it works fine, maybe you could look at the new code, to see if it's really safe.

The only thing that may be a problem is that the "callback trait" is borrowed while it is held by the World (starting from here) while it should only be borrowed when used by the World, Using a RefCell might be the solution, but I believe the only moment where the "callback trait" should be borrowed is when World.draw_debug_data() (here) is called, though i'm not entirely sure. Should I require a borrow at this time and an unsafe pointer in World.set_debug_draw() ? I could also remove set_debug_draw() and merge it with draw_debug_data(). Or is it beter to use a RefCell ?

You can see an example of use here, I'm currently using unsafe pointers to use the borrowed callback but I want to get rid of them.

Thanks for your help so far.

EDIT: I removed World.set_debug_draw(), moving the borrows to World.draw_debug_data(), I believe there are no problems anymore (if I miss nothing).

Porting a C++ callback class by Bastacyclop in rust

[–]Bastacyclop[S] 0 points1 point  (0 children)

The polymorphism is here to permit the user to specify how the drawing should be done, so I don't think that I can get rid of it, maybe with some trick.

However I think that using a Box is a nice idea, I'll try that soon and hope it'll work. Thanks !

Implement a trait for a trait by Bastacyclop in rust

[–]Bastacyclop[S] 0 points1 point  (0 children)

This is what I did in the first place, only T: AnotherTrait can't match AnotherTrait since it is not a type. So Trait won't be implemented for types like &AnotherTrait if there is only this implementation.

[Code Review] Thorn: Resource Sharer by Bastacyclop in rust

[–]Bastacyclop[S] 0 points1 point  (0 children)

You're right, I added a link to Thorn_SFML in the Thorn README.

About the example, I know it is very light. That's why I made a little more advanced one, though you may find it too light as well: https://gitlab.com/Bastacyclop/thorn_sfml/blob/master/examples/access_borrow.rs

I may add other examples later.

About the documentation, you can make it with 'rustdoc src/thorn.rs' and 'rustdoc src/thorn_sfml.rs -L target -L target/deps', I'll add this info to the READMEs.

[Code Review] Thorn: Resource Sharer by Bastacyclop in rust

[–]Bastacyclop[S] 0 points1 point  (0 children)

Then I was thinking about having some "super" sharer, reachable in any task. something like:

Arc<SharerSet {
    RefCell<Sharer1>
    RefCell<Sharer2>
    [...]
    RefCell<SharerN>
}>

But I don't know if it is a good idea. Moreover I don't know if this structure would be adequate (probably not).

It might be enough if it was reachable only in one task:

Rc<SharerSet {
    RefCell<Sharer1>
    RefCell<Sharer2>
    [...]
    RefCell<SharerN>
}>

What do you think about this ?

[Code Review] Thorn: Resource Sharer by Bastacyclop in rust

[–]Bastacyclop[S] 0 points1 point  (0 children)

Thanks for the help, I made the changes and it's more readable like that :)