Guard framebufferTexture2D against a not-yet-allocated attachment image

VkGlFramebuffer.framebufferTexture2D unconditionally attaches the target
texture's backing VulkanImage, but a texture can legitimately be attached
to an FBO before its storage has been allocated (real GL leaves the FBO
incomplete until then). setAttachmentTexture only null-checks the
VkGlTexture, not its VulkanImage, so setAttachmentImage throws
"NullPointerException: Image is null" — crashing e.g. Xaero's
ImprovedFramebuffer.

Skip the attach/create/beginRendering when the texture is missing or its
image is not yet allocated, mirroring the leniency already applied in the
sibling framebufferRenderbuffer.

Author: Chaos02

src/main/java/net/vulkanmod/gl/VkGlFramebuffer.java

@@ -110,6 +110,17 @@ public static void framebufferTexture2D(int target, int attachment, int texTarge
             throw new UnsupportedOperationException();
         }
 
+        // Deferred-attach guard: a texture may be attached to an FBO before its
+        // backing storage (VulkanImage) has been allocated. Real GL tolerates
+        // this — the FBO is simply incomplete until the storage exists — so skip
+        // the attach/create/begin instead of throwing "Image is null" in
+        // setAttachmentImage. Mirrors the leniency of framebufferRenderbuffer
+        // below (which returns early instead of dereferencing a not-ready state).
+        // Fixes the crash triggered by Xaero's ImprovedFramebuffer.
+        VkGlTexture vkGlTexture = VkGlTexture.getTexture(texture);
+        if (vkGlTexture == null || vkGlTexture.getVulkanImage() == null)
+            return;
+
         boundFramebuffer.setAttachmentTexture(attachment, texture);
         boundFramebuffer.create();
         VkGlFramebuffer.beginRendering(boundFramebuffer);