Someone

Tangentially, it's worth noting that, to the extent it's not usable, it would be because modern software is poorly written, not because the hardware is insufficient for doing the majority of the tasks the average user needs to do on a daily basis. If you run 2011 software on a 2011 laptop, it runs fine and provides essentially the same features as the equivalent 2026 software that will run dog-slow on the 2011 laptop. When I've gone back and tested even ~2005 software on ~2005 hardware, I find that the software, if anything, is more responsive doing the same operations than its equivalent today on modern hardware - which is insane considering how much faster modern hardware is :( If you'd like a video, I already recorded one of those when someone was a dick on Twitter about it and it really pissed me off: youtu.be/GC-0tCy4P1U?t=… I feel like people don't realize that programs like Visual Studio used to be fairly responsive two decades ago. It's only their modern incarnations that are sluggish despite orders of magnitude faster hardware. I think there are good arguments about supporting q limited number of hardware configurations for simplicity and reliability reasons (eg., it's harder to develop and test on five separate instructions set targets, like x86, x64-SSE2, x64-AVX, x64-AVX2, x64-AVX-512, than it is to just target one modern one like x64-AVX2). But performance by itself is not a reasonable argument against supporting old machines unless you're working on software that handles extremely performance-intensive workloads, which 90+% of software is demonstrably not.

genuinely i have seen like 2 ngl. Tracy, the profiler and imgui. Imgui is at the top of my list, it has never failed me, its just so simple to use and read and understand.

@SebAaltonen do you think this would work for car physics?

Signed distance fields (SDF) are super nice for physics sim. Claybook had SDF based GPGPU physics engine. With SDF you always know where is the closest surface, even inside the objects. Pushing particles out is simple. Triangles = thin surface. Tunneling is a real issue.

@smartbackwards What are you studying? Data science or maths?

oh and by the way thank you for 5000 followers, i appreciate every single one of you!! need to write a masters thesis by june 1st so if i post less thats why (still, i will solve xfactor for lau)

@Vitality_apEX next up: highest rounds winstreak ever?

@Dispatch_Graph Thats not bad!

@NotTheRealFirst 50ms/frame for native 4k, but it's a reference PT so it's fine

Man. Pathtracing looks so good

@ThourCS2 Hello

Let's see who all can reply to this post.

A month ago, I acquired what I thought was a complete set of 9 CS:GO Major pins. Recently, I discovered the "Boston 2018" pin is missing! Since these were ONLY for players & casters, finding it is a massive milestone for me. Random RT gets a free pin! 🎁 Help me find it pls!

pls fix the MacOs corners #wwdc26

@SebAaltonen Thank you!

@NotTheRealFirst Yes. Binary format of course. Page load time is super important in web browser.

Loaded Bistro in our new "mini-engine"...

@SebAaltonen How are you doing the costum formats? As binaries?

@NotTheRealFirst Custom scene/model format. Convert GLB files to it offline.

@TheCherno For just explaining how an engine is built its fine i guess. Just do a disclaimer that its not „good“ code probably

Should I start a new Game Engine series but this time I use AI to write most of the code 👀

@gdechichi how long does the window init take in your engine? I have around 80ms with glfw (just for the window, vulkan takes another around 200ms i believe). Is yours a lot faster? If yes i will switch to my own api and try to make it run faster

@SebAaltonen why did you rebuild it? is it a replacement for hype hype or something different?

1.16ms for all this: - 4x shadow cascades (4K atlas) - G-buffer (3x 32-bit + Z-buffer) - SSAO (custom GTAO) - Deferred lighting (GGX/HDR, sun only + IBL indirect) - Bloom (HDR, very wide kernel) - Post: ACES tonemap, color grading LUT, vignette - Temporal AA (custom)

After porting HypeHype shaders to our new project (and from GLSL to WGSL), I restored gather4 and fp16 optimizations... Biggest gains: SSAO: 0.992ms -> 0.555ms (-46%) Lighting: 0.149ms -> 0.108ms (-28%) Total frame time in test scene = 1.16ms (M3 Max)

@sun_apanasovich nikos smashed table or apex

Which player should I do something similar with?

@Dispatch_Graph Thats true, but you cant optimize Raytracing so much

@NotTheRealFirst Not sure but my thought was if I get regular M5 it will teach me a lot more about optimization.

I made sure my mesh exporter also included meshlets so that when I get my new MacBook Pro M5 I could immediately start working on GPU driven meshlet culling. Since I'm on M2, not only are mesh shaders emulated, but I do not support indirect mesh shaders via ICB. So, for the time being, enjoy mesh shaders on regular Bistro and Intel Sponza!

@Dispatch_Graph is swift performant? Im currently writing an engine in raw c, but will buy a mbp in summer because i need a new laptop for uni and I‘m a Mac Lover and also Photographer, but Im wondering if ill have to switch to swift

@NotTheRealFirst Renderer is written in Swift, asset baker in Objective-C++

Implement a debug renderer in your engine! It will save you a lot of pain! Say you are trying to debug cascaded shadow maps or frustum culling. With a debug renderer, visualising camera frustum or bounding volumes is as easy as calling DebugDraw.drawBox! Take it a step further even, make it GPU driven so that any of your shaders can emit draw calls to pass to your debug pass. With that, you can do ray debugging, normal debugging, and honestly draw anything that lives on the GPU only. A debug renderer is something I always implement ASAP when I start a rendering project. I advise everyone to do the same!