sandbox VS image

I've made a similar game: https://github.com/JMS55/sandbox, and it looks like we've had a lot of the same ideas :)

If you're interested in game development, you may enjoy playing around with Sandbox. It's a game I created where you place sand, water, acid, fire, etc and watch them interact.

> WebGPU is years away to become usable

As a counterpoint, I've been using WebGPU (through wgpu-rs) for the past 1.5 years. It's been a pleasure to use. For instance, here's the CPU-side code for a glow post-process shader using 4 render passes https://github.com/JMS55/sandbox/blob/master/src/glow_post_p....

I've considered implementing Sandbox using wgpu compute sharers (all the rendering is already done with wgpu). The reason I didn't is because I couldn't figure out how to make particles update in parallel - how to handle conflicts between two particles wanting to move into the same position, updating a particle that's supposed to be destroyed, etc. I'd love to get this working however. My last attempt was a the "multithread" branch where I tried to use rayon as a means of prototyping the game using parallel update logic.

Unrelated to a club, but you might enjoy looking at a game I built with Rust + WebGPU https://github.com/JMS55/sandbox.

Counterpoint: https://flathub.org/apps/details/com.github.jms55.Sandbox

Not a GSOC project, but my game Sandbox is open to contributions! https://github.com/JMS55/sandbox

Overflowing the stack: Use a Vec, or Box<[T; N]> (boxed array). A boxed array is a heap allocated array, where the box part just points to some data on the heap, so it's cheap to move around. Both are pretty much equivalent, boxed array is maybe slightly more faster/correct. Note that if you use a boxed array, due to some missing compiler optimizations, you'll probably just get a stack overflow anyways, as the compiler will first store the array on the stack, and then copy it to the heap. This can be solved with some unsafe code, such as in https://github.com/JMS55/sandbox/blob/master/src/heap_array.rs.

With the help of the image crate, loading an image from disk is fairly straightforward.

FTR there is a WebP decoder implementation in safe Rust in the image crate: https://github.com/image-rs/image

It used to be quite incomplete for a long time, but work last year has implemented many webp features. Chromium now has a policy of allowing the use of Rust dependencies, so maybe Chromium could start adopting it?

Hello! So I have a local app that I am currently running on desktop (windows). I'm using egui for the UI, and the program basically opens a folder, gets all the images in the folder, and then uses the image-rs library to resize and create a grid of images / some other operations.

png is the de-facto standard Rust crate for reading and writing PNG images, used e.g. by the image crate.

There's also a CLI to convert between formats. It uses the crate image.

exr is a is a 100% Rust and 100% safe code library for reading and writing OpenEXR images. It is used by the popular image crate to read and write OpenEXR.

We're currently looking for contributors to add support for zune-jpeg to the image crate. The image maintainers are open to it, but don't have the capacity to do it themselves. You can find more details here.

It would be helpful to contribute to the general change towards an untyped buffer with runtime representations for color space information and fallible conversions. (https://github.com/image-rs/image/pull/1718). It's currently stalling on having too few eyeballs to judge the impact and need for that complexity.

It uses https://github.com/1Password/arboard and https://github.com/image-rs/image under the hood. I haven't tested deeply but I assume it should handle many formats out of the box.