tsherif

Thank you!

Thank you!

Thanks! Nothing against SDL. It's a great library, and I referenced its source code a lot while writing the platform layers. But I did find it incredibly satisfying to write everything myself. If you do ever decide to take a crack at it, I highly recommend Handmade Hero as a starting point: https://handmadehero.org/

Thanks for the tip! I'll try to figure out if something similar is happening on either of the machines I'm using. That's a bummer that an in-place update function would be allocating behind the scenes...

Thanks! My first child was born last year, and I started a new job 3 months earlier, so time was definitely not an abundant resource! But between the stress of all that and the pandemic, I found squeezing in an hour or two for this project here and there was one of the few things keeping me sane, and that's what got me through it.

Ack! Right I hadn't thought of that. I'll have to decide if I'm ok with breaking the "written in standard C" constraint on this project...

Thanks! I definitely tried to focus on only using as much abstraction as was actually helpful in getting it to work the way I wanted it to.

Sweet, thanks for sharing! I'll definitely take a look.

Thanks! This was a revelation for me on a few levels:

1. That memory management doesn't have to be scary with a little forethought, at least for programs where you can set a reasonable upper bound on the resource requirements.

2. That it's possible to structure at least a subset of programs in such a way that error states can only be entered during initialization, and that makes the rest of the program much easier to reason about.

i even found out that a call like glBufferSubData will call malloc or related functions. so doing that on each frame seems to be a bad idea as well.

That's interesting and not what I'd expect at all! Is there documentation you could point me to or did you find that out with some tooling? And is there a better way to update attribute buffers for instanced draw calls?

Hadn't seen this before, but that's a flattering comparison. Thanks!

That's an interesting idea. Probably won't change the format for this project, but something I might consider in future ones. Thanks for the tip!

In a sense, I did use SDL. The source code of SDL, along with GLFW and Sokol, were my primary references when writing the platform layers.

For now, it's Windows/Linux only. I hope to write a Mac platform layer eventually. I just don't currently have a Mac machine to work on...

Thanks!

If you go through the architecture doc (which I'm almost done writing), you'll find links to most of the references I used: https://github.com/tsherif/space-shooter.c/blob/master/ARCHI...

Top one, though, would be Handmade Hero: https://handmadehero.org/

Yeah, I was fiddling with the parameters until I found something I kind of liked. A couple of important factors:

1. Stiffness of the cloth depends on the number of particles vs. the number of iterations you do to resolve the constraints (maybe there's a way to speed this up?). So making things stiffer (at the same grid resolution) does take more time.

2. The faster things are moving, the higher the likelihood that that collisions will be missed. You can already see this if you move the ball very quickly, it can pass through the cloth. With higher gravity, I found the cloth would often get pushed through the ball.

If you want to fiddle around with it, you can clone and tweak the physics parameters here:https://github.com/tsherif/picogl.js/blob/master/examples/cl... and the simulation parameters here: https://github.com/tsherif/picogl.js/blob/master/examples/cl...

Totally! And it's still crazy to me that you can just send out a link to share this kind of thing with people.

Yeah, for sure. Not doing any self-collision detection. If you know of any good references for how to that on the GPU, I'll give it a shot.

The basic system is pretty simple: just make sure the points you're tracking on the cloth don't move further than a certain distance away from each other. Doing it on the GPU is a bit tricky because you have to know which constraints you can check in parallel.

Here are the two primary references I used: https://viscomp.alexandra.dk/?p=147 http://http.download.nvidia.com/developer/presentations/2005...

It looks like this might be an issue with Apple's AMD driver, since everyone who's having problems seems to be on Mac/AMD setup. I'll look into this when I get my hands on a machine to test on.

Transform feedback is great, but I'm not actually using it for this because I need access to adjacent positions in the grid. I'm using float textures to store the positions and normals.

Three.js is a great library. I used it for BrainBrowser, the neurology project I mentioned in the post. But I disagree with the attitude that because a great library exists to do something, you shouldn't learn how to do that thing yourself. It's like saying that because jQuery exists, web devs shouldn't learn how to manipulate the DOM directly. Part of my reasoning is that I think using these libraries effectively for anything non-trivial requires an understanding of how they work. The other part is that the more people understand how an open-source library works, the more they can contribute and make it better.

Although I disagree with a lot of Google's policies (with respect to privacy, etc.), the claims made by the author here don't make much sense. It's pretty clear that the author and many of the people commenting don't understand how web development for multiple platforms works. Using a new web standard technology (http://www.w3.org/TR/media-source/) that isn't implemented by all browsers and providing a polyfill for non-compliant browsers isn't "crippling" the other browsers. It's considered best practice. If websites only used technologies that are available in all browsers, the web would never move forward.