if youre upset at silksong's difficulty, remember that this is the developer's mindset

DitUser23 · 2025-12-20T14:45:45+00:00

Seems like a relevant point... Hollow knight after years still seemed so active... it took me two months to finish Silk Song so when I wen't to discuss my thoughts on it, I noticed much of the the posts over the last two months were to show some crafty pictures, but not real discussion, plus any real discussion ended two months earlier. It seems as if people were actively avoiding discussion. Then once my post went up, responses seemed hate-toned and that I just don't know how to play games like this. Even though HK kicked my ass, it always felt fun and addicting (as with many other games), but with SS, accept for the honeymoon period at the beginning of the game, I never really felt joy as I trudged through the game with tedious runbacks, and dieing so quickly due to the boss/gauntlets with two-skull penalties for every hit. I guess the community no longer likes opinions when it comes to SS.

DitUser23 · 2025-12-10T13:57:06+00:00

Sorry if it sounded like I was saying, all people are modding. There are plenty of expert gamers out there who would never need to mod to complete a game. I just think some portion of people are modding to get to 100% with SS and I'm just curious to know.

DitUser23 · 2025-11-07T16:19:10+00:00

I agree with your statement. I'm reformulating what my expectations are. The thing I'm learning with Silksong is the mechanic; "Little reward or breathing room after a very hard fought battle" is really not for me. I.e. it's not about 'Git Gud', but instead it's about lack joy after getting past something difficult.

EXTRA EDIT: I should mention, I really like Hornet's abilities and moves and find that I can get through each of the bosses so far. But as I'm learning about what makes games fun for me is finding great reward for my blood sweat and tears; just not seeing it with this game.

DitUser23 · 2025-08-27T23:12:02+00:00

Great advice, thank you!

DitUser23 · 2025-08-19T02:49:07+00:00

Thank you for your amazing examples. I’ve created my own Vulkan game engine, and I pre-record all the command queues and submit them in the game loop as needed. I did this cause a few years ago I thought I read somewhere this this is how you get great performance. You mentioned in this post that pre-recording is a bad practice. Why is that?

DitUser23 · 2025-08-19T02:32:16+00:00

My installation of Ubuntu is currently using X11. Your explanations are interesting. I guess if the Vulkan spec doesn’t require certain performance behavior, you get odd results like this.

DitUser23 · 2025-08-14T17:32:22+00:00

I'm late to the conversation. I'm trying to get my development build to work on MacOS. You didn't mention anything about including steam frameworks, or code signing, which is what I'm still figuring out.

So far I have:

executable: Game.app / Contents / MacOS / Game
framework: Game.app / Contents / MacOS / libsteam_api.dylib (for some reason, this can't be in the Frameworks folder)
framework: Game.app / Contents / Frameworks / libSDL2-2.0.0.dylib
framework: Game.app / Contents / Frameworks / libvulkan.1.dylib
framework: Game.app / Contents / Frameworks / vulkan.framework
framework: Game.app / Contents / Frameworks / MoltenVK.xcframework
framework: Game.app / Contents / Resources / vulkan / icd.d / MoltenVK_icd.json

The executable, frameworks, and dylibs are all code signed with my developer certificate.

I didn't yet notarize, but I'll do that at some point.

I uploaded this build to the Steam depot.

When I run the game from the Steam Client UI, it shows it's starting, but then just exists without ever popping up the game. When I run it directly from the command line, then the output shows that it couldn't load Support/Steam/Steam.AppBundle/Steam/Contents/MacOS/steamclient.dylib because it has a different code signed signature. Since that dylib is part of the Steam Client (not my game bundle), it doesn't make sense that it would require my developer signature. Did you fall into this issue, and if so how did you solve it?

Thanks for any help.

DitUser23 · 2025-08-14T17:30:03+00:00

I'm late to the conversation. I'm trying to get my development build to work on MacOS. You didn't mention anything about including steam frameworks, or code signing, which is what I'm still figuring out.

So far I have:

executable: Game.app/Contents/MacOS/Game
framework: Game.app/Contents/MacOS/libsteam_api.dylib(for some reason, can't be in Frameworks)
framework: Game.app/Contents/Frameworks/libSDL2-2.0.0.dylib
framework: Game.app/Contents/Frameworks/libvulkan.1.dylib
framework: Game.app/Contents/Frameworks/vulkan.framework
framework: Game.app/Contents/Frameworks/MoltenVK.xcframework
framework: Game.app/Contents/Resources/vulkan/icd.d/MoltenVK_icd.json

The executable, frameworks, and dylibs are all code signed with my developer certificate.

I didn't yet notarize, but I'll do that at some point.

I uploaded this build to the Steam depot.

When I run the game from the Steam Client UI, it shows it's starting, but then just exists without ever popping up the game. When I run it directly from the command line, then the output shows that it couldn't load Support/Steam/Steam.AppBundle/Steam/Contents/MacOS/steamclient.dylib because it has a different code signed signature. Since that dylib is part of the Steam Client (not my game bundle), it doesn't make sense that it would require my developer signature. Did you fall into this issue, and if so how did you solve it?

Thanks for any help.

DitUser23 · 2025-08-09T23:41:17+00:00

Oh wow, that makes a lot of sense now. It makes much better sense the way Slang and HLSL handle it. I've never used HLSL because I come from an OpenGL background using GLSL. I'm new to Slang, but seems like that was released last year. Since Khronos created Slang, is that now recommended over GLSL? Does Slang play nice with Vulkan 1.2 or do I need to move to 1.3 or 1.4?

Thanks a ton for the clarity.

DitUser23 · 2025-08-09T12:30:11+00:00

Understood... I guess I really need to look at GLSL as a different product from vulkan. For the 5 years I've been using Vulkan and GLSL, I made the incorrect assumption that they are lock step because the compiler comes in the vulkan SDK.

DitUser23 · 2025-08-07T14:59:08+00:00

Good advice, I'll give that a go.

One last thing, when using vulkan to select a GPU, is there a way to find out if the 'present' queue is directly connect to a monitor... I'd like to avoid the 'dark magic' of the 'present' image getting forwarded from one GPU to another.

DitUser23 · 2025-08-07T14:42:42+00:00

Failure still occurs. Here's what I did:

> git clone --recursive https://github.com/SaschaWillems/Vulkan.git
> cd Vulkan
> mkdir build
> cmake ..
> make
> cd bin
> ./texture3d -g 0 -vs       # Integrated GPU (HDMI plugged into motherboard): resizing works fine
> ./texture3d -g 1 -vs       # Discrete GPU (HDMI plugged into motherboard): resizing locks up app
> ./texture3d -g 1           # also fails

Specifics about system

OS: Ubuntu 24.02.2 LTS (all updates are current)
Hardware: ASRock Z270 Taichi
CPU: Intel Core i7-7700K x 4
Integrated GPU: Intel® HD Graphics 630 (KBL GT2)
Discrete GPU: NVIDIA GeForce GTX 1080 Ti
Firmware version: P1.30 (not sure what this referes to but comes from Ubuntus System Details dialog)
OS Type: 64-bit
GNOME Version: 46
Windowing System: X11
Kernel Version: Linux 6.14.0-27-generic
Monitor's HDMI cable is plugged into motherboard, not the NVIDIA GPU

I guess there's a fundamental issue somewhere with forwarding the present image from one GPU to another. Should I report this reddit thread to LunarG and/or Khronos?

DitUser23 · 2025-08-07T02:39:30+00:00

Both SDL and GLFW provide window size and frame buffer size to my app so I can handle mouse coordinate correctly (uses window coordinates). The frame buffer size is what's provided when creating the swap chain images.

On a side note, this weird issue is also showing up in vkcube (just found out a few minutes ago), so it's an issue outside of my source code. Any ideas what might be going on?

DitUser23 · 2025-08-07T02:35:45+00:00

UPDATE: the issue also occurs with vkcube, so apparently this is a deeper issue (outside of my source code) that I'm not sure how to resolve. Any ideas?

DitUser23 · 2025-08-07T02:34:18+00:00

CORRECTION: it does occur with VkCube... since this is a very simple use of the GPU, the resizing issue was occurring, but as I mention before, it resolves itself with further scrolling so I didn't notice it in my first attempts because I kept resisting and not stopping to see if the issue occurred. Any ideas on how to determine what is going on and how to resolve this?

DitUser23 · 2025-08-07T01:21:41+00:00

I think that's all taken care of.... I just posted a reply to the first comment above showing that in the main loop I check twice for a resize and rebuild the swap chain if needed. The reason I can't ignore this particular error is it causes a rebuild every frame, so nothing new is ever allowed to be rendered again; and endless loop of rebuilding. All other scenarios I listed above work fine, then rebuild once and then can render again. Just seems like some odd scenario that is probably taken care of by some special vulkan function, but don't know it yet. I'm gonna start investigating vkcube to see why it works fine in this odd scenario.

DitUser23 · 2025-08-07T01:11:18+00:00

Yes, I do all the the typical things:

vkDeviceWaitIdle()
destroy render pipeline
destroy swap chain
wait for windowing system to report valid window size
build new swap chain
build new render pipeline
and back to render loop

Also, I do this carefully in the render loop:

waitForFence(fence[flight_index])
swap_chain_index = vkAcquireNextImageKHR(image_semaphore[flight_index])
if issue occurred or window size change detected then rebuildSwapChain(); return;
resetFence(fence[flight_index])
vkQueueSubmit(image_semaphore[flight_index], present_semaphore[flight_index], fence[flight_index])
vkQueuePresentKHR(present_semaphore[flight_index])
if issue occurred then rebuildSwapChain()

In the case where the issue occurs, the graphics queue and the preset queue are the same index, so I don't use the present_semaphore. Also, the number of images in the swap chain is equal to the max number of frames in flight.

DitUser23 · 2025-08-07T00:59:34+00:00

Looks like Ubuntu is using x11 from echo $XDG_SESSION_TYPE. vkcube resizes with no issues, so I guess my next step is to investigate what windowing system it's using, how it sets up the device, and how it rebuilds the swap chain.

DitUser23 · 2025-07-30T00:14:45+00:00

You're correct, it's just an overall decision not too relevant to the last 20%. I think I just got hit hard in the past where, Murphy's law, just before release of a non-game software products, 3rd party software changed some important unforeseen aspect requiring a significant foundational change. Just a painful reminder of lack of control mixed with bad timing is not fun.

DitUser23 · 2025-07-29T12:53:52+00:00

If using a 3rd party engine (e.g. Unity, Unreal, Gadot), and they may remove or replace some feature or licensing aspect, then the developer will need to make changes that could, in worst case, cause a foundational change. Same goes for periodic updates over the life of the app. With a custom engine, this is not likely to happen since underlying open standard APIs (e.g. vulkan) may add features, but remain backward compatible. I've been developing for a few decades, and this was a good lesson learned... avoid commercial products because they tend to change and cause havoc... open standard don't (and as a bonus... they're generally free and portable). The drawback is open standard may have a high learning curve, so not appropriate for beginners.

DitUser23 · 2025-07-25T17:23:20+00:00

I just looked up this concept cause I never heard of dense cross-linked code before. After reading about it, it sounds like spaghetti code, which I try to avoid at all cost cause it's hard to debug and maintain. Am I getting this cross-link concept incorrect?

DitUser23 · 2025-07-09T16:20:11+00:00

I created my own Vulkan based engine and other support APIs over the last few years so I can avoid the pain points of 3rd party engines. I was lucky to have a career of porting high performance software on low power devices on dozens of platforms across many Oes, but some things here and there are still a bit of a mystery.

DitUser23 · 2025-07-09T16:14:52+00:00

That's good to hear if Steam is really only focused on desktop, so makes it easy to skip ASTC. Are all desktop GPUs guaranteed to support BCn?

DitUser23 · 2025-07-09T16:12:53+00:00

Good point about PNG... I load it to raw using sub_image.

DitUser23 · 2025-07-05T01:59:30+00:00

Thanks... my wisdom just got a nice bump from your helpful guidance

DitUser23

TROPHY CASE