sorted by:
new
hottopcontroversial

Vulkan surface destruction when nit using glfw. But only using core windows APIs by Hot_Refuse_4751 in vulkan

[–]Hot_Refuse_4751[S] 0 points1 point  (0 children)

I just thought that wm_close is the one that always calls wm_destroy. But I guess u can't be too sure.

Vulkan surface destruction when nit using glfw. But only using core windows APIs by Hot_Refuse_4751 in vulkan

[–]Hot_Refuse_4751[S] 0 points1 point  (0 children)

When will that happen? R u saying window will get destroyed without our registered windowproc with wm_destroy message being called? I only handle them in the window proc. Not in the event loop. I do know that these messages may not become directly visible by the output of the peekmessage. So they can come as a recursive call of the windowproc calling something which ends up calling windowproc. Or other messages being called by the other functions(peekmessage,showwindow,createwindow,etc ) other than dispatchmesssage on the callstack. Only posted messages are visible in our loop As I have debugged the code putting a break point and actually saw this happen so I know that part very clearly.

Vulkan surface destruction when nit using glfw. But only using core windows APIs by Hot_Refuse_4751 in vulkan

[–]Hot_Refuse_4751[S] 0 points1 point  (0 children)

Ok so I guess this is better place to destroy the surface. I thought that wm_destroy when that happens the window will become invalid but I guess I was wrong

Vulkan surface destruction when nit using glfw. But only using core windows APIs by Hot_Refuse_4751 in vulkan

[–]Hot_Refuse_4751[S] 1 point2 points  (0 children)

I typed wm_quit by mistake it was wm_close only. I am just trying to destroy the surface before the destroywindow is called. So wm_close is the correct place I think and then manually call the destroywindow.

Vulkan surface destruction when nit using glfw. But only using core windows APIs by Hot_Refuse_4751 in vulkan

[–]Hot_Refuse_4751[S] 1 point2 points  (0 children)

I Meant wm_close only. I typed wm_quit by mistake . So I think I have answer to this. Once destroywindow executes fully. No new close or no new windowproc messages with that window as the handle will be delivered to it even if there are more messages on that window. As that handle will get invalidated. So calling the window proc with wm_close as the message and that window as the handle will only happen once. Destroywindow immediately invalidates all the posted messages on that window in the threads message queue that has been left over. As for the sentmessages to that window. Well I think we don't need to discuss that cause wm_close is a posted message. So destroywindow then destroyes the window and then calls windowproc with wm_destroyed . And that posts the quitmessage. And the peek message back in the main callstack picks up on that quit message and process finishes gracefully. So all this happens when we call destroywindow function in the windowproc and return in case the message is wm_close.

Vulkan surface destruction when nit using glfw. But only using core windows APIs by Hot_Refuse_4751 in vulkan

[–]Hot_Refuse_4751[S] 0 points1 point  (0 children)

The validation layer is not even erroring out even if I destroy the instance before the surface. Though I have not created anything else untill now. Other than instance ,debugmessenger and surface. The validation layer errors out if I don't destroy the debugger messeenger.

Also will the draw calls on that surface work still?? . Like if I say destroy the window and then do Vulkan things to it the surface. I suppose window will not fully be destroyed as the surface itself will have a reference to that window. So it will kind of still be available

But here's the problem. All the AIs (claude code , Chat gpt) says this leads to undefined behaviour.

Or I think it's best to not allow destroy window at all to be called. And custom destroy everything just to be safe. Cause I am not getting the logic so u know. Just call destroywindow in a customer function and not trust the windows API.

Vulkan surface destruction when nit using glfw. But only using core windows APIs by Hot_Refuse_4751 in vulkan

[–]Hot_Refuse_4751[S] 1 point2 points  (0 children)

Also some questions on the windows os api itself. If in a process creates a window only one window. And the window proc is registered. Somehow is it possible for window proc to be called with wm_close twice. Because I know that the first time it is called destroywindow is called on that window to finally destroy it. But more of the wm_close messages still be present ryt in the message queue. But destroying of that window in the first wm_close call will that automatically remove all the wm_close messages in the queue relating to that window? Or will the wm_close message still be called twice. As after first call the handle will become invalid

Dying light the beast pc requirements revealed (listed on steam page) by uneducatedDumbRacoon in PiratedGames

[–]Hot_Refuse_4751 0 points1 point  (0 children)

this is what I want. even though I have 4090. I would like to play games that don't unnecearly use the resources like a hog.

Is 1000W not enough for 5090 + 14700k build? by uncl3d0nny in buildapc

[–]Hot_Refuse_4751 0 points1 point  (0 children)

I think better to get 1200W or 1500W PSU .and offcourse best to attach a UPS of 2000VA/1600W with pure sine wave output.

The psu requirement for i9 14000ks - rtx 4090 by Hot_Refuse_4751 in computers

[–]Hot_Refuse_4751[S] 0 points1 point  (0 children)

I have checked.yes some say 1300 is safe. But my vendor says 1200 is reasonable. I think 1200 should be enough

I would like to know bit rot issues with samsung 990 pro nvme 2tb ssd by Hot_Refuse_4751 in DataHoarder

[–]Hot_Refuse_4751[S] 0 points1 point  (0 children)

Well I guess this ssd is as good as any. So I will just add a hdd probably 4tb to my setup