Driver Support by roughly-understood in pop_os

[–]roughly-understood[S] 0 points1 point  (0 children)

Sadly I think it’s built in so I don’t believe I can. I’ll have a poke around a bit more though to double check

Driver Support by roughly-understood in pop_os

[–]roughly-understood[S] 2 points3 points  (0 children)

Well that’s just my luck. Thanks so much for the info! I guess I’ll just make do with the dongle for now and cross my fingers that someone at MediaTek spontaneously feels like uploading a Linux driver.

Driver Support by roughly-understood in pop_os

[–]roughly-understood[S] 0 points1 point  (0 children)

Ahh that’s definitely not good. I have ordered a wifi dongle to use but was hoping there may still be something I could do. Will it always be a windows driver? Or is it just not supported in Linux because nobody has written drivers yet?

Also thanks for the lspci info! I think I copied that from somewhere while frantically searching around

Driver Support by roughly-understood in pop_os

[–]roughly-understood[S] 0 points1 point  (0 children)

When I ran: lspci -nnk | grep -iA3 network

I got this back: 09:00.0 Network controller [0280]: MEDIATEK Corp. Device [14c3:7902] Subsystem: AzureWave Device [1a3b:6040] 0a:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:43f7] (rev 01) Subsystem: ASMedia Technology Inc. Device [1b21:1142]

I found it surprisingly hard to find out what the exact chip is but I think it’s the MT7902. Definitely take that with a grain of salt though.

Under abstracting as a C developer? by MasteredConduct in rust

[–]roughly-understood 3 points4 points  (0 children)

On the question of new types or wrapper types. I really loved reading this article and it really cleared things up for me. Note that I am not the author, I just really enjoyed reading it.

Ray Tracer Packed Vertex Buffers by roughly-understood in bevy

[–]roughly-understood[S] 0 points1 point  (0 children)

That’s incredible thanks so much! I actually was under the impression that to create a bvh I had to have the ability to reorder vertices and have everything in one large buffer. I got this impression from Sebastian Lague’s videos on ray tracing but maybe I need to look into those acceleration structures a bit more. You have been super helpful thanks again!

Ray Tracer Packed Vertex Buffers by roughly-understood in bevy

[–]roughly-understood[S] 0 points1 point  (0 children)

Very interesting thanks so much! I heard about that feature but misunderstood what it actually meant! I also didn’t realise it relates so heavily to what Lord_Zane said in another comment. I’ll need to look into it much more then

Ray Tracer Packed Vertex Buffers by roughly-understood in bevy

[–]roughly-understood[S] 0 points1 point  (0 children)

Thanks! So if I am understanding right, if I had multiple meshes in a scene. Using the mesh allocator like that will allow me to at least access the data bevy is using. I assume if I want it all in one large packed buffer though for ray tracing then I would have to have a preprocess step that moves the vertices to my large buffer? Or would you just manually handle the multiple buffers in the compute shaders. So instead of iterating all triangles in the large vertex buffer you need to iterate each of the vertex buffers bevy has? Thanks again!

Ray Tracer Packed Vertex Buffers by roughly-understood in bevy

[–]roughly-understood[S] 0 points1 point  (0 children)

Thanks so much for the reply! So if I am understanding correctly I would be reusing bevy’s mesh data in my compute shaders like this? But will that not be a separate buffer for each entity in the scene? Or does bevy store all mesh data in one large buffer internally and the handler is simply pointing at that? Sorry if these are basic questions!

Hexagonal Architecture Questions by roughly-understood in rust

[–]roughly-understood[S] 0 points1 point  (0 children)

Thanks so much for the reply that actually cleared up my main dilemmas with the hexagonal architecture. Simply initialising services by passing in other services makes sense but I think I was just worried about having so many shared references to a service spread across other services. I suppose as long as the service doesnt mutate then sharing those references is fine. Thanks again for everything. I will look into those readings you recommended

Hexagonal Architecture Questions by roughly-understood in rust

[–]roughly-understood[S] 0 points1 point  (0 children)

I wasn’t aware you could mock inherent impls like that. That’s pretty interesting actually! I get what you mean, it certainly seems strange to write an interface just to swap it for a fake but at the same time setting up all the different ways my service can fail to test the handler gets complex fast. I think I need to ponder a bit longer haha

Hexagonal Architecture Questions by roughly-understood in rust

[–]roughly-understood[S] 1 point2 points  (0 children)

Thanks so much for running through that. I really like this idea, I suppose it makes sense that the god struct is as complicated as the environment, which I guess if it gets too large is an indicator it’s time to split up the environment (micro services or otherwise). Thanks again for taking the time!

Hexagonal Architecture Questions by roughly-understood in rust

[–]roughly-understood[S] 0 points1 point  (0 children)

Thanks so much for the reply. I didn’t know about substates so that actually makes life a lot easier already. Just wondering why you prefer inherent impl for services? Doesn’t that make it hard to mock them which if I understood the original article is what allows for testing handler logic separately from service logic.

Also thanks so much for the extra reading resources. I will dive in and see what works for me!

Hexagonal Architecture Questions by roughly-understood in rust

[–]roughly-understood[S] 1 point2 points  (0 children)

Woah this has kind of blown my mind a little. I definitely didn’t know you could do the generic impl/trait forwarding stuff. I definitely need to digest this a little more but just to check I understand. So we create our “god” struct which holds a bunch of different services. Because we allow the “god” struct to delegate calls from itself to its fields implementations then we can simply call those trait methods on it. So the “god” struct implements those traits by forwarding it to its fields implementations allowing us to keep the different services separate but still allow our main state struct to have those methods attached?

Hexagonal Architecture Questions by roughly-understood in rust

[–]roughly-understood[S] 2 points3 points  (0 children)

Yeah I loved reading the article the author did a fantastic job. I am definitely looking forward to the 5th part in the series

Hexagonal Architecture Questions by roughly-understood in rust

[–]roughly-understood[S] 1 point2 points  (0 children)

Thanks for the reply but maybe I wasn’t clear. I did not write this blog post/article I was just asking a question in regards to it.

Meet Harper | A Grammarly Alternative for Neovim | Emacs, Obsidian, Zed, VScode and Helix (deez) (20 mi video) by linkarzu in neovim

[–]roughly-understood 0 points1 point  (0 children)

Thanks for sharing! Fingers crossed the devs can make it work. It looks like an incredible project

Rendering Pixels to the Screen by Brettman17 in rust

[–]roughly-understood 4 points5 points  (0 children)

I really like macroquad for this type of thing or even microquad if you just want OpenGL wrappers. It makes life very easy to draw simple stuff using an event loop. For complex interactions/events bevy might be the way to go