profile
viewpoint
Theodore DeRego tedsta Seattle, WA

tedsta/deeplearn-rs 192

Neural networks in Rust

tedsta/gosfml 19

A rewrite of my favorite multimedia library, SFML, in Go

tedsta/gofission 3

A flexible game engine written in Go and based on the entity component system model.

tedsta/Fission 2

A simple, extensible C++ game engine designed around the entity component system paradigm

CPearring/Arduino_Control 1

Arduino Code for PISCES rover

CPearring/Linino_Control 1

Python script which runs on the Linino(ARM Linux side of Arduino Yun). Processes incoming messages via UDP/IP and sends commands to the robot via serial bridge

PISCES-HI/rover-gui 1

GUI for controlling PISCES rover over the internet

PISCES-HI/rover-onboard 1

PISCES rover's onboard software

sheinasim/LEP-Map_Pipe 1

Pipeline for generating a linkage map and supporting files for QTL analysis

push eventtedsta/wgpu-pbr

Teddy DeRego

commit sha cf5704cab3715c3ffbbfde0752fcbeb999650759

Add shader for texture + normals only (no metallic-roughness/ao).

view details

push time in a day

create barnchtedsta/wgpu-pbr

branch : shadows

created branch time in a day

issue commentchronotope/chrono

DateTime.with_timezone() seems not working with chrono::offset::Local in wasm32

@EndilWayfare I just ran into this as well but was able to solve it by enabling chrono's wasmbind feature:

[target.'cfg(not(target_arch = "wasm32"))'.dependencies.chrono]
version = "0.4.19"

[target.'cfg(target_arch = "wasm32")'.dependencies.chrono]
version = "0.4.19"
features = ["wasmbind"]

See here for why this is required: https://docs.rs/chrono/0.4.19/src/chrono/offset/local.rs.html#150-169

ip1981

comment created time in 8 days

startedudoprog/genco

started time in 8 days

push eventtedsta/iced

Teddy DeRego

commit sha 5628c48a79b5a5e5e380ecd3d871b07d107f9ed1

iced_web_winit: fix initial window size

view details

push time in 11 days

startedrust-crdt/rust-crdt

started time in 11 days

startedbrendangregg/pmc-cloud-tools

started time in 12 days

pull request commenthecrj/iced

Support glow backend on wasm target

@hecrj Do you have any thoughts on this? I think using WebGL and eventually WebGPU to render Iced UIs in browsers is valuable to have native widgets work as-is in the browser. I understand if you don't think it's the way to go. This work has served its purpose for me, I have an app that uses it that I don't expect to change much. I am willing to put some more work in to get this merge-able if you want it though - I would very much like to create custom widgets for myself without writing both native and web versions, and I don't mind limiting myself to places where WebGL is supported. No rush though.

tedsta

comment created time in 19 days

issue commentMeirBon/rfw-rs

Accessing mesh data as a user

Hey there, sorry it has been a while. I've been busy doing some DIY house stuff and moving into our new house. I do still plan to work on this. We finish moving this weekend, so hopefully I will have time next weekend.

The plan right now is to write an example of an animated character walking around a tri-mesh level using the new rapier physics engine. Maybe have a few convex hull meshes tumbling around too. Hopefully that will give me some ideas for how to polish the rfw API a bit more. I have started it but nothing to show yet.

tedsta

comment created time in a month

push eventtedsta/rfw-rs

Theodore DeRego

commit sha 53174d7967c2cf8b552b6ee2e06a3db67ccec4c8

Loading scenes into a standalone(ish) objects (#14) * Descriptors-based scene loading. * Update examples.

view details

Mèir Noordermeer

commit sha c0690b06b63f4156cd167e0e90cb1bf6fe157403

Preallocate storage for HashMap and Vec in NodeGraph

view details

Mèir Noordermeer

commit sha 72f5ba6a44958101df67115c40515578e2b1f951

Add from descriptor functions for NodeGraph

view details

push time in a month

startedalessandrod/snuffy

started time in a month

pull request commenthecrj/iced

[WIP] Support glow backend on wasm target

Alright I think I've gotten this into a fairly good state. Summary of changes:

  • Make iced_web_winit crate that is analogous to iced_glutin (in that it builds on top of iced_winit for a specific renderer). Eventually I imagine with some clever use of feature items these 3 crates could be consolidated if GLCompositor and Compositor can be consolidated. I'd be willing to take a stab at it if you'd like.
  • Use wasm_timer::Instant in place of std::time::Instant everywhere for the wasm32 target.
  • Don't require runtime's Message Stream/Sync to be Send on wasm32 target. Ultimately this was required because something didn't implement Send under wasm32 target... for the life of me I can't remember... maybe it was EventStream or iced_futures::subscription::Tracker? I'll try to figure it out again so we know for sure these changes are required.
  • Use crate::BoxFuture instead of getting it from futures crate in iced_futures::time. Related to the Send / !Send discrepancy between wasm32 and non-wasm targets.
  • Rename distance function to quad_distance in iced_glow quad fragment shader. It was failing to compile under WebGL, guessing there's a builtin function named distance.
  • Add wasm / non-wasm specific instantiation of glow Context in iced_glow crate.
  • Work around lack of draw_elements_base_vertex for wasm32 target in glow crate.
  • Disable font-kit dependency under wasm32 target.
tedsta

comment created time in 2 months

push eventtedsta/iced

Teddy DeRego

commit sha c558782e07ee840f4d535c9579accc48b89f9e0a

Fix text box interation on web with glow backend.

view details

push time in 2 months

push eventtedsta/iced

Teddy DeRego

commit sha 0c590d9795821f9871c57e277a855497de046464

rustfmt

view details

push time in 2 months

push eventtedsta/iced

Teddy DeRego

commit sha 500aa3f0014f3664512772bb9afec3ee90c42704

Fix 'debug' feature on wasm target. Fix some warnings on wasm target. Add script to bundle todos example for web.

view details

push time in 2 months

push eventtedsta/iced

Teddy DeRego

commit sha 7e10dca106bd9a70b8ba37980e70d6b8f80fe8a6

Allow iced_web_winit to build on non-wasm32 targets.

view details

push time in 2 months

push eventtedsta/iced

Teddy DeRego

commit sha f2ea6ae1a11363dc3e651248731996f94c005a90

Tweaks to features to make it closer to current setup.

view details

Teddy DeRego

commit sha ea2238a77edeea5638cc844c6b8a9cd601402627

Run rustfmt

view details

Teddy DeRego

commit sha 1e33757427ac80917315a2732cc3e763d16276da

More features system fixes.

view details

Teddy DeRego

commit sha 13fac149d9b08981df915deaa2481a89e7afb73f

rustfmt

view details

push time in 2 months

pull request commentMeirBon/rfw-rs

Loading scenes into a standalone(ish) objects

No problem, glad you like it! I'll do a followup post in the issue thread about ideas on where to go next after some thinking. I think I want to try integrating that new rapier physics engine (in a separate add-on library) and see where that takes me.

tedsta

comment created time in 2 months

PR opened hecrj/iced

[WIP] Support glow backend on wasm target

Hello!

This PR adds proof-of-concept support for the glow backend on web. I did this because I wanted the Canvas widget for the web in my application. I had to modify modify the version in the shaders to be #version 300 es, and they still work on the native target for me so maybe it's fine to just leave them that way? Otherwise I can put logic in to have it be #version 330 for native and #version 300 es for web.

This allows you to build the solar system example if you use the following features: iced = { path = "../..", default-features = false, features = ["glow", "glow_canvas", "winit"] } I also had trouble with the rand crate on wasm so had to remove the random star position generation.

I had to do some questionable things to make things !Send for the wasm32 target...

I have to do more tests so definitely not merge-able as-is. One thing I know is broken is text boxes on the web with the glow backend.

iced-solar-system

+814 -70

0 comment

29 changed files

pr created time in 2 months

push eventtedsta/iced

Teddy DeRego

commit sha 034282e10a365e8ec8ae8e890b5080e69602e430

Add support for iced_futures::time module for wasm32 target.

view details

push time in 2 months

create barnchtedsta/iced

branch : web-glow

created branch time in 2 months

fork tedsta/iced

A cross-platform GUI library for Rust, inspired by Elm

fork in 2 months

push eventtedsta/glow_glyph

Teddy DeRego

commit sha cf3462437b9db59ff9c953c05e0f91f9ba7e28e1

Fix shader compilation on WebGL

view details

push time in 2 months

fork tedsta/glow_glyph

A fast text renderer for glow (https://github.com/grovesNL/glow)

fork in 2 months

PR opened MeirBon/rfw-rs

Loading scenes into a standalone(ish) objects

This PR changes the gltf loader to produce a new SceneDescriptor. In this structure nodes directly store their children. Not 100% happy with this, I don't like that we have to make a temporary node_map: HashMap<u32, u32> while loading a SceneDescriptor into a NodeGraph, but I haven't found a way around it yet.

+352 -304

0 comment

7 changed files

pr created time in 2 months

push eventtedsta/rfw-rs

Teddy DeRego

commit sha 7fcd12962d44f6f074a3c4e8b4207a598d3ecbf1

Fix animated example

view details

push time in 2 months

push eventtedsta/rfw-rs

Teddy DeRego

commit sha e82abd95be9be214d39e33c73b383d1cec974e4e

Update examples.

view details

push time in 2 months

push eventtedsta/rfw-rs

Teddy DeRego

commit sha f4cbc92eb8d253713df4a1797fd92dced7f1962e

Descriptors-based scene loading.

view details

push time in 2 months

push eventtedsta/rfw-rs

Teddy DeRego

commit sha eab9a4d8207c14feb4ee84bb64182f5c08f976c0

Descriptors-based scene loading.

view details

push time in 2 months

push eventtedsta/rfw-rs

Mèir Noordermeer

commit sha 149ede1ba09f5b116a4aca12400610fe8db4d302

Fix compile errors in renderers

view details

Mèir Noordermeer

commit sha 0cb61c61d39022d277f82675d2629a2d8aab99e1

Remove incomplete vulkan renderer

view details

Mèir Noordermeer

commit sha e52990dea454665a95fe6ac0c037e1f5d4970ac8

Defer loading scenes from gltf files, scenes now have to be explicitly added

view details

Mèir Noordermeer

commit sha 001b1490b33fd2cadcff3dc247036302fe074163

Rewrite task pool, fix skins not working when using multiple instances of same scene

view details

Mèir Noordermeer

commit sha 6a08644031f1cb2e7c8870a9110b304506fc2860

Update readme

view details

Mèir Noordermeer

commit sha dc177288c1a1f760bc751b8520a915e8a5a866bc

Improve synchronization performance of deferred

view details

Teddy DeRego

commit sha dc48a4f52a6fb672b12e838f9c8b95b7e75b99cd

Descriptors-based scene loading.

view details

push time in 2 months

issue commentMeirBon/rfw-rs

Accessing mesh data as a user

I think what you have right now is quite close to gltf - list of meshes, list of skins, list of nodes, and things refer to each other by ID. TBH I quite like the current design - some small things could be moved around but the overall structure is good I think. I just want to be able to load scenes into a standalone object then load (perhaps only pieces of) that scene into the active scene. And I want to be able to re-arrange the node hierarchy freely. And I want to be able to manually create nodes and manually attach meshes to them.

Some more opinions + ideas:

  • I like that instances are separate from nodes - then renderer backends don't have to worry about the scene graph, they just handle rendering instances.
  • I think RenderSystem::scene could be public to allow easy access to materials, meshes, nodes, etc.
    • Maybe hide Instance concept from users? Users could just add and remove a MeshId from a NodeId, and instances would be manipulated automatically.
    • Probably make all the Scene fields pub(crate) instead of pub, only allow user access through methods.
  • Instead of wrapping every TrackedStorage<T> in a Mutex, I wonder if it could be more performant to queue up mutations to the scene in a set of lock-free command queues (separate queue for each command type, e.g. AddNodeCommand), then apply them all during synchronize. This way Scene would only be mutated from the thread doing the synchronizing. I doubt contention for the locks will ever be very high, though, so probably in the 99.9% case the atomic operation to acquire the lock will be faster than the atomic operation to queue the command + copying the command data to the queue's buffer in the heap. But it would remove all of the locking in the rfw_scene crate, which could be worth it. Would be fun to give this a shot and do a benchmark farther down the line.

I'll try to come up with a PR for the *Descriptor stuff on top of the multi-NodeGraph stuff you did by the end of this weekend. If it's no good no pressure we can toss it out - I just want to see how it'll turn out.

tedsta

comment created time in 2 months

issue commentMeirBon/rfw-rs

Accessing mesh data as a user

Instances are just individual meshes to be rendered, right? And a node can have multiple instances associated with it? I kind of like the current separation of nodes and instances.

tedsta

comment created time in 2 months

issue commentMeirBon/rfw-rs

Accessing mesh data as a user

When you say remove the NodeGraph struct, do you mean just have TrackedStorage<Node> and still having nodes refer to their children by ID, or do you mean actually storing the data for children within the Node itself?

I still like having the ID approach, I think it will be hard to refer to non-root nodes if nodes store their children directy, e.g. child_nodes: Vec<Node>. In that case you'd probably have to have something like a struct NodePath(Vec<NodeChildIndex>); which would add a lot of indirection when referring to deeply nested nodes (and as a user I would want to refer to joint nodes).

tedsta

comment created time in 2 months

issue commentMeirBon/rfw-rs

Accessing mesh data as a user

Regarding decoupling animations from node graph - I do like having the joints as nodes (how it is now) since then it is straight forward to e.g. attach a sword to the player's hand joint using the node graph, which the user will already be familiar with. But what would be nice I think if Node::skin, Node::weights, and maybe even Node::meshes lived somewhere else so that Nodes are just hierarchical objects with a transform an nothing else. I'll give it some thought to see if there is a nice way to do it but meh doesn't matter too much.

Nice just saw the multiple-node-graphs stuff. That is a nice idea. I think that does give me what I was originally looking for. Maybe we don't need the *Descriptors stuff if we can get all the features we need out of this?

The approach I was going to go for was to produce a SceneDescriptor that might look something like this:

struct SceneDescriptor {
    root_nodes: Vec<NodeDescriptor>,
    animations: Vec<AnimationDescriptor>,
}

And be able to load that into the single NodeGraph, or even selectively load just parts of it into the NodeGraph.

I understand it's WIP so maybe you have plans for these things but these are my initial thoughts:

  • Probably want to support having multiple active animations in a single NodeGraph? I could see having a glTF file that has separate animations for e.g. windmills or other mechanical structures in the background.
  • Can you move nodes from one NodeGraph to another? E.g. say I loaded a skinned object and wanted to attach it to a joint on the character's body, which is in a separate NodeGraph. It could get expensive translating node IDs between NodeGraphs if it's happening a lot. There is a nice simplicity to having only a single "address space" for node IDs. But I might be overestimating the cost. But maybe we can just say "nodes can't move between node graphs" and if you want to move nodes around the hierarchy you have to stick them in the same graph. Then maybe we have both "multiple node graphs" and "descriptors" as orthogonal features?
tedsta

comment created time in 2 months

issue commentMeirBon/rfw-rs

Accessing mesh data as a user

Oh cool I didn't know gfx had a wgpu backend, nice!

Just want to pop in and say I'm still working on this, still getting acquainted with all the internals. I'm wondering if there's a way to decouple animations from the NodeGraph system (like add it as a layer on top rather than having it be integrated inside). But for now I plan to leave it as is.

Some notes:

  • Channel::sampler_ids field seems unused?
  • scene::graph::animation::Sampler struct seems unused?
  • It looks like Node::weights field is unused? It is animated but I don't see the end result being used anywhere.

Here's what I'm thinking so far:

pub struct NodeDescriptor {
    pub name: String,
    pub child_nodes: Vec<NodeDescriptor>,

    pub translation: Vec3A,
    pub rotation: Quat,
    pub scale: Vec3A,

    pub meshes: Vec<NodeMeshDescriptor>,
    pub skin: Option<SkinDescriptor>,
    pub weights: Vec<f32>,
}

#[derive(Debug, Clone)]
pub enum NodeMeshDescriptor {
    Static(Mesh),
    Animated(AnimatedMesh),
}

#[derive(Debug, Clone)]
pub struct SkinDescriptor {
    pub name: String,
    pub inverse_bind_matrices: Vec<Mat4>,
}

#[derive(Debug, Clone)]
pub struct AnimationDescriptor {
    pub name: String,
    // (joint index, animation channel)
    pub channels: Vec<(u32, Channel)>,
}

When instantiating a NodeDescriptor, joint indices would be mapped to node IDs at that time. I would remove rfw_scene::graph::animation::Channel::node_id field and instead store Channels as a Vec<(u32, Channel)> where the u32 is the node_id (maybe make a NodeId struct for clarity? And AnimationId, SkindId, etc.?). This way Channel can be re-used as is in the *Descriptor objects.

Sound ok?

tedsta

comment created time in 2 months

push eventtedsta/rfw-rs

Theodore DeRego

commit sha db5a263e7c0938e9adfc97e47efb89116810b15e

Fix loading textures embedded within glTF files (#6) * Fix glTF embedded textures. * Generate mipmaps in MaterialList::push_texture

view details

Mèir Noordermeer

commit sha c5a9e58dafcf1bd09508f57aa3722a8d2d3722e3

Fix wrong material ID in deferred shaders

view details

Mèir Noordermeer

commit sha 712c6e04eee5e507866e574d6ad15b0e0044d68b

Update wgpu-rs to 0.6.0, make renderer trait a bit more efficient, initial gfx rendering backend (#8) * Start working on a gfx-based renderer (to replace/improve-on deferred) * Update to gfx-hal 0.6 * Update to wgpu-rs 0.6

view details

Mèir Noordermeer

commit sha 72542ab529ca65b0956bde97df7a801180b30217

(Re-)implement serialization of scenes

view details

Mèir Noordermeer

commit sha 25b5c50b68bb6211358289b7ee27f5b88457173f

Fix mip levels not being generated for default texture

view details

Mèir Noordermeer

commit sha a56260fd70cebbffdf07a88f5c94b2461aa9b4c0

Add initial support for metallic & roughness textures

view details

Mèir Noordermeer

commit sha 798360fd410f859c12a9da1fc16de1fd739a0a49

Add material access functions

view details

push time in 2 months

issue commentMeirBon/rfw-rs

Accessing mesh data as a user

Yeah I think this project has a lot of potential! What I really want in Rust is a modern version of Irrlicht, if you remember that library. Just a batteries-included renderer but nothing more - no physics engine or editor or scripting or any of that - integrations for those things can live elsewhere.

The gfx thing sounds neat. I think it'd be sad to give up the possibility of eventually running this on the web using wgpu. But faster raytracing without HW support does sound very cool. The slowness of mapping might be something to ask about in the wgpu IRC, they are quite active there.

I can take a stab at "loading glTFs + objs into a standalone object that is later added to the scene" and we can see how you like it. I don't mind throwing work out if it's no good.

tedsta

comment created time in 2 months

issue openedMeirBon/rfw-rs

Accessing mesh data as a user

Right now unless I'm missing something there doesn't seem to be a way to get at vertex / index data from a RenderSystem - its TriangleScene field would provide this but the field is private.

Also there doesn't seem to be a way to selectively load nodes from a glTF file - they all get loaded directly into the scene.

I was thinking it could be nice to load scenes / meshes into a stand-alone object that stores all the data that could later be added to the scene. Would probably still want it to be tied to a resource manager so that things could be cached since most material / mesh data is immutable. But that resource manager can be decoupled from the rest of the RenderSystem.

The reason for this is I want to write some physx integration. I guess in most real-world use-cases you'd probably load a separate, lower poly mesh for e.g. the terrain's triangle mesh. In which case maybe I should just write a separate glTF loader that just loads the mesh data for physics.

Curious to hear your thoughts!

created time in 2 months

issue commentMeirBon/rfw-rs

Polishing into a library

I think we can close this open-ended issue and I'll file more specific issues?

tedsta

comment created time in 2 months

pull request commentMeirBon/rfw-rs

Fix loading textures embedded within glTF files

Sorry for the delay on that, such a simple change! It's been a crazy week for me.

Renders nicely now! image

tedsta

comment created time in 2 months

push eventtedsta/rfw-rs

Teddy DeRego

commit sha fe07dc9199d507777fe92b751136f347845ef9ee

Generate mipmaps in MaterialList::push_texture

view details

push time in 2 months

pull request commentMeirBon/rfw-rs

Fix loading textures embedded within glTF files

Yep I'll make the change in this PR.

tedsta

comment created time in 2 months

pull request commentMeirBon/rfw-rs

Fix loading textures embedded within glTF files

Ohhh cool good to know thanks!

tedsta

comment created time in 2 months

PR opened MeirBon/rfw-rs

Fix loading textures embedded within glTF files

This allows me to load the binary version of the SciFi helmet model that has the textures bundled inside the glTF file. It is rendered oddly from a distance in the deferred renderer though. Is there a distance limit in the shaders?

You can grab SciFiHelmet.glb from the assets I uploaded here: https://www.dropbox.com/s/5rl9ji77s3qnhdk/assets.zip

+114 -42

0 comment

2 changed files

pr created time in 2 months

push eventtedsta/rfw-rs

Teddy DeRego

commit sha 7465bfa86617154de80a4a909ee5b2cd6db8c63a

Fix glTF embedded textures.

view details

push time in 2 months

push eventtedsta/rfw-rs

Theodore DeRego

commit sha ba169b5c278661ae083cf99f6de022cc3c5b726e

Librarify deferred renderer (#5)

view details

Mèir Noordermeer

commit sha 1dcded64e2bcffedf6a07b348899d3ffabf676c0

Move cesium example to seperate example folder and make it compilable

view details

Mèir Noordermeer

commit sha 474d162af05ccc06d667ee4e1b011b60ac56abad

Merge branch 'master' of github.com:MeirBon/rfw-rs into master

view details

Mèir Noordermeer

commit sha f1391c81a94a7466cee45e0ec05c854af09a20bc

Add gpu-rt as option in animated example

view details

Mèir Noordermeer

commit sha cb1edc3d4f2e5f0095db475256a21a351d67e87b

First vulkan triangle

view details

Mèir Noordermeer

commit sha 1f5730af0236dac1dac096d3772b16c7a7b1def1

Fix some compiler warnings

view details

Mèir Noordermeer

commit sha e149790860486beacb817e965067131fe1837659

Add simple physics test

view details

Mèir Noordermeer

commit sha 4f0be8f4d1a14e4d13242faaf41da70ae8165825

Fix compilation errors

view details

Mèir Noordermeer

commit sha 44acd680ab353aee4266eb6c195767ac4b0646d8

Add more timers to examples

view details

Mèir Noordermeer

commit sha 8176d4174f460800d444fb616eb7b0fc64c8b272

Fix dir lights, fix warnings and add nphysics example

view details

Mèir Noordermeer

commit sha 376bfcaaa29063c223363a651de936ff9529b672

Fix compiler warnings

view details

push time in 2 months

PR opened MeirBon/rfw-rs

Librarify deferred renderer

Let me know if this is alright, happy to move things around.

+39 -45

0 comment

10 changed files

pr created time in 3 months

push eventtedsta/rfw-rs

Teddy DeRego

commit sha 8621225a667ef251b92aa7232b615c7045174e29

Librarify deferred renderer

view details

push time in 3 months

fork tedsta/rfw-rs

Framework for playing around with rendering libraries in Rust

fork in 3 months

issue commentMeirBon/rfw-rs

Polishing into a library

Yeah it would be sweet if webgpu supports hardware RT in the future! Looks like somebody is working on it: https://github.com/maierfelix/dawn-ray-tracing

No need to give me access, I'll work through pull requests.

Cool I'll start with the library thing but make two separate examples, one for deferred and one for gpu-rt. Then give bloom a shot.

tedsta

comment created time in 3 months

issue commentMeirBon/rfw-rs

Polishing into a library

Cool! I was thinking a good place to warm up would be to turn the renderers into libraries and move the "cesium man" example scene into a separate example bin crate. Maybe even have it so you can dynamically switch between renderers using keyboard shortcuts?

For ECS, TBH it's what turned me off from Amethyst because it basically forces the game to also use ECS. Maybe if you could hide the ECS-ness so the game doesn't have to worry about the complex setup I would find it more palatable. I used to do everything game-related with ECS but nowadays I feel you can get the same benefits by just following the general ECS philosophy but not using an ECS framework - e.g. store "components" in Vecs and tie them together in custom game object structs that reference the components by ID. But I will follow your lead.

If there's an easier graphics feature you'd like but are uninterested in implementing feel free to delegate it to me and I'll probably be able to figure it out :smile: Like perhaps bloom for the deferred renderer?

tedsta

comment created time in 3 months

issue openedMeirBon/rfw-rs

Polishing into a library

Hi! I think this project is super cool. I'm working on a game as a hobby with a friend of mine and have been putting together / using this renderer. But I'd like to just drop that in favor of rfw-rs.

Do you intend to turn this into a library? I'd love to help out if you are open to it. I'm no graphics wizard but I can help with the docs / API / examples / performance side of things and can do a little bit of graphics (I think the repo I linked is a pretty accurate representation of my abilities graphics-wise).

created time in 3 months

push eventtedsta/wgpu_glyph

Teddy DeRego

commit sha e9c4ccee5a148006ec1221eaeee6858b70e980ba

Update wgpu

view details

push time in 3 months

fork tedsta/wgpu_glyph

A fast text renderer for wgpu (https://github.com/gfx-rs/wgpu)

https://docs.rs/wgpu_glyph

fork in 3 months

push eventtedsta/bbqueue

Teddy DeRego

commit sha 7cdfbd1f79dd69bc80d381366133dd95b7f3a39f

Make bbqtest pass

view details

push time in 3 months

push eventtedsta/bbqueue

Teddy DeRego

commit sha 7e1ecd80780e5c0d1a41165f44858fede55e1022

cargo fmt

view details

push time in 3 months

push eventtedsta/bbqueue

Teddy DeRego

commit sha 7f0416ec57d9db2842a660d5a556675457e63a8c

Remove lifetime requirement from N parameter in producer/consumer types. Not required when using pointer-casting to get underlying slice when creating grants.

view details

push time in 3 months

push eventtedsta/bbqueue

Teddy DeRego

commit sha cf24da413a7a5a942e0d30ab2bea9a685d71cb00

Switch to 'alloc' crate for 'heap' module instead of using 'std'.

view details

push time in 3 months

PR opened jamesmunns/bbqueue

WIP heap-allocated BBBuffer

Hi there,

I took a stab at #41 here. What's missing is a bbqueue::heap::FramedProducer and bbqueue::heap::FramedConsumer. Also I'm unsure of how you want to structure the crate in terms of heap vs globally-allocated/stack-allocated.

For heap-allocated framed producer/consumer, here's what I'm thinking:

  • Move framed::FramedProducer and framed::FramedConsumer into common, make them use common::Producer / common::Consumer instead of bbqueue::Producer / bbqueue::Consumer.
  • Export wrapped bbqueue::FramedProducer / bbqueue::FramedConsumer with lifetimes re-added.
  • Export wrapped heap::FramedProducer / heap::FramedConsumer with reference counter for dropping (duplicate heap::Producer / heap::Consumer dropping code.

If you like that plan I can go ahead an implement it.

I split the common code into a separate common module that has Producer<N> and Consumer<N> types without lifetimes. The bbbuffer module exports wrapped Producer<'a, N> and Consumer<'a, N> types with the lifetimes. The heap module exports wrapped Producer<N> and Consumer<N> types that include a reference counter to determine if the underlying ConstBBBuffer should be dropped when the producer/consumer is dropped.

+1193 -635

0 comment

5 changed files

pr created time in 3 months

create barnchtedsta/bbqueue

branch : heap

created branch time in 3 months

fork tedsta/bbqueue

A SPSC, lockless, no_std, thread safe, queue, based on BipBuffers

fork in 3 months

more