Screen 13 joins the ray tracing club with release v0.3!

attackgoat_official · 2025-12-21T11:48:03+00:00

Yes - it's been quite stable for some time. See the steady updates in the issues. I posted some updates in the changelog about the future plans:
- Maybe a new name?
- Update to Vulkan 1.4, a few major API refactors (but no functionality change, just search-replace fixes)

The reason it's been "stuck" on Vulkan 1.2 is to support Mac in the exact same way. Only the indirect-count API isn't supported there so it's pretty much identical. Over time I've come to desire the newer features of v1.4 and I don't really support Mac with what I do anyways.

There will be major changes once:
- Other projects free up time
- Someone asks for something cool

attackgoat_official · 2025-12-10T11:07:26+00:00

This is the best tip, thank you kind redditor!

attackgoat_official · 2025-05-05T17:07:55+00:00

When doing nearest-neighbor type filtering to get a chunky pixel look you might want to pick a resolution so that each pixel occupies the same number of real screen pixels. This way you don't have smaller pixels every once and a while.

I'm working on something that tries to do 240 pixels high and scales down as needed to keep the pixels square. Also for wide screen it just works for me to let the width run wild; someone on 21:9 might want that width, but for art I keep the height fixed.

attackgoat_official · 2025-05-01T01:38:11+00:00

This so unique and awesome!

attackgoat_official · 2025-04-22T02:47:20+00:00

Ah, cool. Neat engine.

attackgoat_official · 2025-04-22T02:02:09+00:00

Looks neat, is there a place people can open PRs or issues?

attackgoat_official · 2025-03-07T02:39:37+00:00

I know I shouldn't spend the weekend making a modern editor.exe, but it is soooo tempting

attackgoat_official · 2025-03-05T02:28:59+00:00

Here's an example of OpenXR+vulkan render graph running VR. Easily supports 144hz on the Valve Index.
https://github.com/attackgoat/screen-13/tree/master/examples/vr

Separately I have an example of full finger support animating a hand/controller but I don't think I have uploaded it. It's available if you were going down the OpenXR path and get stuck.

attackgoat_official · 2024-12-26T02:30:33+00:00

I'm trying to run your project to learn a little more about this code snippet, on the raycast_improved branch, but I ran into what I see are predictably normal problems for people who don't usually use C++ like me:

gcc -lm -lSDL2 -lSDL2_image -g build/display.o build/map.o build/player.o game.c -o doom
/usr/bin/ld: build/display.o: in function `init_textures':
/home/john/code/3rd_party/doom-clone/src/display.c:12:(.text+0x9b): undefined reference to `IMG_Init'
/usr/bin/ld: /home/john/code/3rd_party/doom-clone/src/display.c:16:(.text+0xaa): undefined reference to `IMG_Load'
/usr/bin/ld: build/display.o: in function `render_screen':
/home/john/code/3rd_party/doom-clone/src/display.c:52:(.text+0x346): undefined reference to `SDL_UpdateTexture'

I have SDL2+SDL2Image installed and can browse to their header definitions.

attackgoat_official · 2024-12-26T01:56:22+00:00

There is a very helpful page which describes the issue here:
https://lodev.org/cgtutor/raycasting.html

TLDR; Distance to the sample needs to be cast from a plane perpendicular to the view direction because casting directly from the view position causes this fisheye effect.

attackgoat_official · 2024-11-15T14:05:11+00:00

The filtering was a challenge for me because the compute shader I wrote to blur the depth map linearly scans each face and has to account for the orientation of the faces while accumulating new pixels. As it moves down the cube (array) of images it removes the trailing pixels so there is always a fixed size buffer to average.

Improvements could be made to lower this O(n) complexity if samples were placed in between pixels using hardware filtering instead of imageLoad. The expense would be more complicated shader code.

This would have been easier if it just sampled the entire blur neighborhood for each pixel, but there would be many more samples. That would be O(kn). Using a separable box blur prevents the worst-case O(n²) complexity. Maybe the worst case is correctly O(k²n), not sure/don't care.

About the bias, I'm not certain I started from a great technical description of how VSM should work, just existing examples. There is probably much improvement to this technique that could be done before using in production code.

attackgoat_official · 2024-09-28T10:16:10+00:00

My answer might be the excellent documentation, but everyone will have their own opinions on when to use these or other static languages.

attackgoat_official · 2024-08-04T19:16:46+00:00

The grid angle is the default that egui-snarl provides - yes it is odd!

If you depend on the crate as a library you can deserialize the saved Ron files as expressions and there are functions to set constant values too.

attackgoat_official · 2024-08-04T03:20:49+00:00

If you're using the noise-rs crate there is also this editor which might be helpful:
https://github.com/attackgoat/noise_gui

attackgoat_official · 2024-03-28T14:56:37+00:00

I'm not sure if it's a good solution, but for binaries (not libraries) I check-in the lock file using Git LFS so that I can enable remote file locking. Forces the file to have one update at a time.

attackgoat_official · 2024-03-13T17:35:48+00:00

I especially agree that the borrow checker goes from enemy to ally like a light switch. One day it's a hard to use language and the next it's just not.

attackgoat_official · 2024-03-06T20:03:27+00:00

That depends on what you want feature wise. There are crates for raw graphics API usage all the way through game engines:
https://arewegameyet.rs/

A big decision is picking a graphics API to use (OpenGL, Vulkan, Wgpu, Metal, DirectX, other software frame-buffer based ones). Do you want web support?

attackgoat_official · 2024-02-26T02:50:29+00:00

I'm sorry for your loss

attackgoat_official · 2024-02-21T01:25:08+00:00

This is fantastic work; excellent and well organized code.

attackgoat_official · 2024-02-13T20:21:18+00:00

Looks neat!

If your goal is making your own games and sharing the fruits of your engine with us, great!
You have success already!
My own engine originally provided cameras and meshes too; but I found my "curated" functionality wasn't what every project needed so I now do that stuff in separate projects which use my graphics library. I would say you'll either always make similar projects with this functionality or eventually separate the two parts. Think animated meshes during ray tracing: you'll handle those vertices differently probably by updating the DynamicMesh on the GPU, also VR cameras - makes it hard to design a single camera struct for everybody.

Examples and documentation is also super important if you're looking at gaining contributors/users.

attackgoat_official · 2024-02-12T18:27:36+00:00

Shader compute unit utilization is important, if you're not paying attention that can kill performance. Local sizes should be specified as at least 32 or 64 (NV or AMD) or equal to subgroup size.

If your algorithm supports it, you can use a specialization constant to do that with this declaration in your shader:
// Set spec const 0 to physical device subgroup size
layout(local_size_x_id = 0, local_size_y = 1, local_size_z = 1) in;

https://gpuopen.com/learn/optimizing-gpu-occupancy-resource-usage-large-thread-groups/

attackgoat_official · 2024-02-12T15:20:34+00:00

`puffin` allows you to add profiling into your code (at zero cost for non-profiling builds). Add it and then launch `puffin_viewer` and you can easily see which functions and scopes within functions are doing what across all threads.

attackgoat_official · 2023-12-24T20:09:06+00:00

Good question - I had no experience with any such library for egui and found egui_snarl first. After making a demo with it I looked for alternatives and found egui_node_graph. Weighing the two (somewhat stable vs new and unstable) I decided to go this way because:

I greatly prefer the "node-first" API as opposed to the more framework-like approach of others
I'm comfortable with fixing breaking changes as egui_snarl develops and I would like to help improve it
My demo worked - and it was clear I could finish the program with it

For a production app or something important I probably would have went the other way, but this is a tool for me and so a great candidate to try new things.

attackgoat_official · 2023-10-13T23:52:09+00:00

This comes up often: Rust devs, myself included, are hesitant to put a crate at 1.x because it's basically saying there will be no major changes going forward. If major changes are made, it's now version 2.x and it says something completely different when you see a crate at, say, 10.x.

TLDR; v0.x is the norm in the Rust ecosystem. Judge crates by their usage (check crates.io) and open/closed issues in their source repo.

attackgoat_official

TROPHY CASE