Help needed with KHR extensions

Another newbie question:
I am in a Win10/MSVS 2015 environment and using freeglut to interface with the windowing system.

I have created a Vulkan instance, now want to create a surface. So I enabled KHR extensions as below in instance creation:

	std::vector<const char*> enabledExtensions;

	createInfo.enabledExtensionCount = enabledExtensions.size();
	createInfo.ppEnabledExtensionNames = &enabledExtensions[0];

Next, to make the surface I start with:

	VkWin32SurfaceCreateInfoKHR createInfo;
	createInfo.hwnd = windowHandle;
	createInfo.hinstance = processHandle;

And there’s where I run into trouble. There’s a red line under VkWin32SurfaceCreateInfoKHR. I guess this has to do with including some header file but not sure what.

Follow-up question after, hopefully, the above is resolved. To create the surface I have

VkResult result = vkCreateWin32SurfaceKHR(instance, &createInfo, NULL, &surface);

Again vkCreateWin32SurfaceKHR is underlined so same problem there I guess. But is this the correct statement in the first place? Reason I ask is that I have seen code in another tutorial which uses a statement containing PFN_vkCreateWin32SurfaceKHR - I don’t understand the PFN_ deal at all.

Btw, I use the following to find the window and process handles:

	processHandle = GetModuleHandle(nullptr);
	windowHandle = FindWindow(NULL, LPCTSTR("Window title"));

Correct I hope.

Another thing, I know that GLFW is more Vulkan-friendly then freeglut but I’ve used freeglut a lot with OpenGL so want to keep with it.

The platform-specific surface creation functions need be enabled using defines. For Windows you need to define VK_USE_PLATFORM_WIN32_KHR in your project’s windows build configuration somewhere:

#define VK_KHR_win32_surface 1
#include <windows.h>

#define VK_KHR_WIN32_SURFACE_EXTENSION_NAME "VK_KHR_win32_surface"

typedef VkFlags VkWin32SurfaceCreateFlagsKHR;

typedef struct VkWin32SurfaceCreateInfoKHR {

If code uses PFN_vkCreateWin32SurfaceKHR then it probably does manual function pointer loading, which is not required in most cases unless you use extensions that are not part of the core or wsi.

AFAIK FreeGLUT does not support Vulkan. It would probably try to create OpenGL context on top of the created window, which would put a wrench in things. Besides, you have to use a hack to get the HWnd out of it. And besides doing it in non-multi-platform way. Don’t be afraid to learn new things; is fun. GLFW is quite basic. You will learn it in no time. Or you could steal my stuff to get started:

Be specific. Gimme real compiler errors, not “squiggles”. Likely the missing VK_USE_PLATFORM_WIN32_KHR though.

You don’t need to worry about PFN_. As long as you are using the official Vulkan Loader, the core and the WSI commands will be loaded automagically.

For completness: PFN_ is a function pointer type of the given Vulkan command. It is useful when loading commands yourself. You would get a void*, so you need to convert it to appropriate command, e.g.

PFN_vkCreateDebugReportCallbackEXT pvkCreateDebugReportCallbackEXT = reinterpret_cast<PFN_vkCreateDebugReportCallbackEXT>(
    vkGetInstanceProcAddr( instance, "vkCreateDebugReportCallbackEXT" )

Thanks, Sascha Willems and krOoze.

krOoze: “It would probably try to create OpenGL context on top of the created window, which would put a wrench in things.” Absolutely right, just checked: glutCreateWindow() creates an OpenGL context.

So that settles my problems with freeglut because I am not going to try to use it with Vulkan anymore. GLFW it is, which I have used a bit before but just wanted to see if I could wrangle some of the Vulkan tutorial code out there from GLFW to freeglut figuring I would learn Vulkan in the process too having to break the code down.

Ah, well. Thanks again.