Posts by floooh@mastodon.gamedev.place
(DIR) Post #Azf7Z2lSSMDinuAcmu by floooh@mastodon.gamedev.place
2025-10-26T14:34:26Z
0 likes, 0 repeats
sokol-gfx experimental Vulkan backend progress:- staging uploads into immutable buffers- binding immutable vertex- and index-buffers- ...and multiple rewrites along the way as I'm getting a feel for how syncing/staging/barriers should be done......next up is the (untextured) cube sample which requires a depth buffer and uniform data uploads.Progress is slow though since I only work on weekends on the backend, and Vulkan is incompatible with quick evening coding sessions :)
(DIR) Post #Azf7Z3gt0q9pg12UIi by floooh@mastodon.gamedev.place
2025-10-27T13:43:20Z
0 likes, 0 repeats
...and uniform uploads working :) This is using a double-buffered, host-visible, persistently-mapped uniform buffer which accumulates all uniform updates for one frame, and uses the new-ish vkCmdPushDescriptorSet() call to record the offset to the uniform data snippet into the frame's command buffer.
(DIR) Post #Azf7Z4rudKZVKVCo7s by floooh@mastodon.gamedev.place
2025-10-28T08:07:46Z
0 likes, 0 repeats
@WAHa_06x36 it's funny in a sad way discovering all the different places where Vulkan repeats OpenGL's mistakes. Vendor extensions are the obvious one, but a side effect of that is that there are places where input parameters are interpreted entirely differently depending on 'context', and those have been shoehorned into the API later as a result of extensions that have been incorporated into core...
(DIR) Post #Azf7Z5VGH22zIXcESW by floooh@mastodon.gamedev.place
2025-10-28T08:11:06Z
0 likes, 0 repeats
@WAHa_06x36 some really useful later additions (like push descriptors) hardly have any documentation and no example code anywhere on the internet, they basically expect that you followed Vulkan's development since the beginning and stumbled over the problem that the new funcitionality fixes in a certain way (together with three other alternatives which fix the same problem in other ways) - which is the exact same problem that modern OpenGL has (except there's more example code for GL).
(DIR) Post #Azf7Z61AMPZGtUXiBk by floooh@mastodon.gamedev.place
2025-10-28T08:12:31Z
0 likes, 0 repeats
@WAHa_06x36 TL;DR: Vulkan is already the same mess (or even worse) after one decade that OpenGL has become after 25 years (kinda predictable tbh, but it still sucks)
(DIR) Post #Azf7ZELfO4igjOCCFk by floooh@mastodon.gamedev.place
2025-10-27T13:48:11Z
0 likes, 0 repeats
...for regular resource bindings (textures, storage buffers/images and samplers) I'll need to use the traditional descriptor handling, because only one descriptor set can use the push-method.There's also VK_EXT_descriptor_buffer, but I'll need to check how well that's supported...
(DIR) Post #AzfCtYM9CxxiLXvlL6 by floooh@mastodon.gamedev.place
2025-10-28T09:10:36Z
0 likes, 0 repeats
@shironeko @WAHa_06x36 that's where Microsoft's iron fist was really important in the DX7..DX10 era. MS did a much better job at that cat herding thing than Khronos (who mostly also just followed Microsoft's lead and updated GL to support the features introduced in the last major D3D version).
(DIR) Post #AzfGf0vj5YcSRJtYI4 by floooh@mastodon.gamedev.place
2025-10-28T10:00:35Z
0 likes, 0 repeats
@shironeko @WAHa_06x36 for me it reminds me of the late 90s where every GPU vendor did entirely pointless experiments like Matrox's 'environmental mapped bump mapping' or NVIDIA's 'quadratic texture mapping' which then never were adopted by other GPU vendors. The Microsoft DirectX team played an important role to harmonize early GPU features by putting the foot down and not supporting those silly experiments in D3D.
(DIR) Post #AzfSVcuSE4Eomjaeg4 by floooh@mastodon.gamedev.place
2025-10-28T12:15:04Z
0 likes, 0 repeats
@shironeko @WAHa_06x36 I don't believe that anymore, after all PC gaming has been declared dead since aroud the late 90s, but is stronger today than ever before.The simpler explanation is that Khronos is simply shit at designing 3D APIs ;)
(DIR) Post #AzfbalHhPm7TnKzDBg by floooh@mastodon.gamedev.place
2025-10-28T13:52:19Z
1 likes, 0 repeats
@shironeko @WAHa_06x36 only anectodal evidence, but my nephew has been growing up with Minecraft and PC MMOs and then has started to build his own gaming rigs. Mobile and console gaming never really interested him.The youngest generation in my wider family don't seem to be interested in video games at all though, no matter the platform, instead they seem to go back to passive entertainment (basically watching short-attention-span video clips).
(DIR) Post #Azm8wVxxVm5A5mUbzs by floooh@mastodon.gamedev.place
2025-10-31T17:43:51Z
0 likes, 0 repeats
Blargh... if you have a Windows/Linux dual-boot setup do yourself a favour and check if Bitlocker (called 'Device Encryption' in Win11) is turned off.I just had a near heart attack because when trying to boot into Windows I suddenly ended up in the Bitlocker Recovery screen asking me for a recovery key which I was never aware that it actually exists, and my laptop not showing up in my long forgotten Microsoft account...)
(DIR) Post #Azm8wegv4Unf9XadBg by floooh@mastodon.gamedev.place
2025-10-31T17:46:29Z
0 likes, 0 repeats
...turns out the recovery key *was* somewhere hidden in the Microsoft account, but not in the place where the internet or Microsoft documentation says ...which always points you to some registered device which should show up in the Microsoft account under 'devices' (which is empty for me).You'll need to go to the special https://aka.ms/myrecoverykey URL which then magically unveails the recovery key in the Microsoft Account device section.
(DIR) Post #Azm9F4mOoXjvHEw8HI by floooh@mastodon.gamedev.place
2025-10-31T17:49:49Z
1 likes, 0 repeats
@shironeko I set it up myself, I just don't remember if I did the 'use local account' trick by unplugging the network or not. I have two Microsoft accounts, but my new laptop doesn't show up as registered device in any of the two accounts and the recovery key can't be found by going through the regular account properties. It only shows up when logging in via the special https://aka.ms/myrecoverykey URL.
(DIR) Post #B1AMNfBZQEc4G4In2G by floooh@mastodon.gamedev.place
2025-12-12T07:45:01Z
0 likes, 0 repeats
@andrewrk @regehr I remember from the original Xbox documentation that they recommended to duplicate data when it can help avoiding a disc seek. But that was for a CD-ROM drive where seek times are measured in hundreds of milliseconds, and the CD-ROM size put an upper limit to the duplication.I wonder if that general idea still floats around as a cargo-culted meme.
(DIR) Post #B1uMNVhFuHoOZHxeMq by floooh@mastodon.gamedev.place
2026-01-03T12:10:50Z
2 likes, 1 repeats
@andrewrk I think it's an eternal cycle. I remember that I was equally depressed as today where software development is heading back in the 90s.It looked like everything was becoming industrially developed OOP databases written by human bots in Java. All the cool stuff was dying (Amiga, Atari, Silicon Graphics, Sun) and the dark side would take over (IBM, Oracle, Microsoft, ...).The solution was simple back then and now: ignore the dark side, move underground and work on cool stuff ;)
(DIR) Post #B2XVh5S44XHSVIZKjY by floooh@mastodon.gamedev.place
2026-01-22T08:48:56Z
0 likes, 0 repeats
Missing server-side-decoration in Gnome is essentially why sokol_app.h has no Wayland backend and instead relies on XWayland to draw the window decorations (at least that way it's consistent with the other windows).... such a simple and obvious thing held back by stupid stubborness of the Gnome team...https://blister.zip/posts/gnome-ssd/
(DIR) Post #B2XlGvdZXPK1noV4NM by floooh@mastodon.gamedev.place
2026-01-22T10:26:31Z
0 likes, 0 repeats
@shironeko that would be a technical solution yeah, but it adds too much maintenance overhead and redundancy. I'd rather only have a single backend on Linux.I wouldn't call the Xlib "legacy", it's just another window system client API and XWayland is just another library that happens to implement the X11 APIs on top of Wayland.What's actually underneath this client API (e.g. a "real" X server or just a compatibility shim like XWayland) doesn't really matter, e.g. XWayland is like Proton.
(DIR) Post #B2XlGwOMjQki8wORJQ by floooh@mastodon.gamedev.place
2026-01-22T10:30:27Z
1 likes, 0 repeats
@shironeko FWIW, I would really like to see a slim standardized window system client library that sits on top of Wayland and provides a more traditional window system API (create/resize/move/close decorated windows, get input events, copy-paste and 3D API glue, but no UI framework).Both KDE and GTK should sit on top of this minimal window system API instead of talking directly to the compositor.E.g. there's a missing abstraction layer in desktop Linux between UI frameworks and compositor.
(DIR) Post #B2XlH3drmCJKd2hPwe by floooh@mastodon.gamedev.place
2026-01-22T10:38:46Z
0 likes, 0 repeats
@shironeko ...and *if* such a common window system client library exists, then *this* should do the window decoration instead of the compositor. The key is that all UI frameworks (KDE/Qt, GTK, ...) are supposed to use this common client library instead of talking to the compositor. The compositor should be *entirely irrelevant* - not even accessible - for Linux desktop applications, no matter if they use a popular UI framework or do all their rendering via GL or Vulkan.
(DIR) Post #B2XqGqNfa4onGpqBnc by floooh@mastodon.gamedev.place
2026-01-22T13:31:27Z
1 likes, 0 repeats
@shironeko sokol_app.h is just a cross-platform wrapper around such APIs - similar to GLFW or Rust's winit.Such a new client-library would only make sense when it's a system DLL and guaranteed to be installed on each and every desktop Linux machine.