New Release 0.9.7-beta

2 weeks, 4 days ago
Hi there,

I am back and I have another release for you all!

We finally have Vulkan support now in FPL and a much cleaner video backend architecture ;-)
Also i added seamless resize support for windows using fibers. In addition i fixed lots of bugs, updated a few demos and more.

As usual, the release is tagged as "0.9.7-beta" and the documentation are updated.

To get the release I recommend cloning the repo ( and build the demos.

Vulkan support:

After a very long fight, FPL now officially supports Vulkan.
Initially i wanted just to add a function for creating the Surface, but i found a much cleaner way which fits FPL better:
- Pass in your existing VkInstance to the fplSettings or let FPL create the VkInstance for you
- Call fplPlatformInit() and the VkSurfaceKHR is created
- Use fplGetVideoSurface() to get the VkInstance and the VkSurfaceKHR
- After that the normal Vulkan process continues: Physical-Device, Logical-Device, Swap-Chain, etc.

The full process looks like this:

fplSettings settings = fplMakeDefaultSettings(); = fplVideoBackendType_Vulkan;

fplVulkanSettings *vulkanSettings = &;

// Create an instance
vulkanSettings->apiVersion = fplStructInit(fplVersionInfo, "1.1.0", "1", "1", "0");
vulkanSettings->appName = "My app";
vulkanSettings->appVersion = fplStructInit(fplVersionInfo, "1.0.0", "1", "0", "0");
vulkanSettings->engineName = "My engine";
vulkanSettings->engineVersion = fplStructInit(fplVersionInfo, "1.0.0", "1", "0", "0");
vulkanSettings->validationLayerMode = fplVulkanValidationLayerMode_Logging;

// or pass in an existing instance
vulkanSettings->instanceHandle = yourVulkanInstance;

if (fplPlatformInit(fplInitFlags_All, &settings)) {
  const fplVideoSurface *surface = fplGetVideoSurface();
  VkInstance instanceHandle = surface->vulkan.instance;
  VkSurfaceKHR surfaceHandle = surface->vulkan.surfaceKHR;
  // ... continue with the massive initialization of Vulkan.... Physical-Device, Logical-Device, Swap-Chain, etc.

One thing which held me up a lot, was a crash in X11 when XCloseDisplay() was called.
You dont want to destroy the VkInstance or unload the Vulkan Library, while a X11 window is still active!

New demo: FPL_Vulkan

To test the new Vulkan backend, i added a new demo which initializes Vulkan and renders a blue window to the screen. Ya i know, its not much - but it will be improved a lot!

So if you want to play around with Vulkan, you can compile and run the demo.

- > It would be nice, to get some feedback for that. Does it work? Compile errors?

Seamless window resize on Win32

This version of FPL uses fibers for handling window messages now, but only when fplPollEvents() is used instead of fplPollEvent()!
The advantage of that is, if you resize your window, all video backends will resize properly - without locking the window.

In the future fplPollEvent() should use fibers as well, but this function only polls one event from the OS and therefore the fiber polling for all events wont work here :-(
If someone have an idea, how to translate the fiber event handling technique to a single event polling, please contact me!

Console handling

In the previous releases of FPL, the console is created after the platform has been initialized - which is bad, if you log the initialization to the console.
Therefore i changed that now, that a console window will always be created before main() is called, but is hidden when fplInitFlags_Console is not set.
This way i can have a console to print stuff without requiring to initialize the platform, which is nice.
Of course if the console is fully disabled (FPL_APPTYPE_WINDOW) then even before main() no console is open.


For the next version i will simplify a few things (Fullscreen-Support) and hopefully implement the rest of the X11 methods which are missing (Styles, Clipboard, Cursor). Also i want to get more into linux, to fix the lock-to-device /dev/input/js0 problem.

In addition i want to improve all the demos which renders fonts, because i have 4 different font renderers and want to merge it down to just one.

See full project log for more details:

Full changelog

## v0.9.7-beta

### Short
- Added Vulkan support
- Added seamless window resizing support for Win32
- Added query functions for accessing video backend handles
- Improved video system stability
- Improved console window handling for Win32
- Fixed some major & minor bugs

### Detail
- New: Added structs fplVideoRequirements, fplVideoRequirementsVulkan
- New: Added function fplGetVideoRequirements() to query any requirements for a particular video backend
- New: Added macro fplAssertPtr() for simply (exp != fpl_null) assertions
- New: Added typedef fplVulkanValidationLayerCallback
- New: Added enums fplVulkanValidationLayerMode, fplVulkanValidationSeverity
- New: Added struct fplVulkanSettings
- New: Added structs fplVideoWindow, fplVideoWindowWin32, fplVideoWindowX11
- New: Added structs fplVideoSurface, fplVideoSurfaceOpenGL, fplVideoSurfaceVulkan
- New: Added function fplGetVideoSurface() for query the current @ref fplVideoSurface
- New[#48]: Added function fplGetVideoProcedure() for query functions from the active video backend
- New[#18]: [Win32] Support for message proc fibers to support seamless window resize -> works only with fplPollEvents()
- New[#105]: [Win32] Added support for creating and using a console in addition to a window
- New[#31]: [Win32] Added support for Vulkan
- New[#32]: [X11] Added support for Vulkan

- Changed: Changed video system to use jump tables instead, to support more backends in the future
- Changed: Added field @ref fplVulkanSettings to @ref fplGraphicsApiSettings
- Changed[#116]: AudioDriver/VideoDriver renamed to AudioBackend/VideoBackend
- Changed[#98]: [Win32] Use YieldProcessor instead of SwitchToThread for fplThreadYield()
- Changed[#111]: [Win32] Use SetConsoleTitle with @ref fplConsoleSettings.title
- Changed[#113]: [Win32] Properly show window on initialize (Foreground, Focus)

- Fixed[#109]: fplS32ToString is not working anymore
- Fixed[#121]: fplMutexHandle isValid flag was never working properly
- Fixed[#122]: Compile errors on Arm32/C99 for "asm volatile"
- Fixed[#123]: Compile error for wrong usage of fplStructInit in fplCPUID() for non-x86 architectures
- Fixed[#110]: [Win32] Erasing of background when no video driver hides window always
- Fixed[#114]: [Win32] Console window does not appear at the very first

Simon Anciaux
2 weeks, 4 days ago
I tried the vulkan demo and it's not working on my config (Windows 7 64bit, i7 860, radeon r9 280 with up to date drivers).

First I tried to compile from the command line. After the first try, I figured I needed the vulkan headers, I got those (before figuring out there was a dependency folder with everything in it). An then it built. Having a simple batch file I can launch from the demo folder to build would be nice. Also some instruction about the dependencies.

The application fails to create the vulkan instance (I know nothing about vulkan so that might not be the correct term).

The console in itself is bad because, if I launch the application and it closes because of the error I can't see what's inside it; and if I break in the debugger I can't copy the text that's in it. If I launch from the command line it creates a second console instead of attaching to the current one.

You could maybe write the log to a text file when there is an error ?

I then tried to compile using the demo solution, but got an error because I don't have windows SDK 8.1 (I only have 10.x).

1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.Cpp.WindowsSDK.targets(46,5): error MSB8036: The Windows SDK version 8.1 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution".
1>Done building project "FPL_Vulkan.vcxproj" -- FAILED.

I change the SDK version to "latest" in the project properties and it built, but with the same error when I try to start it.
2 weeks, 4 days ago
Okay first of all, please try to disable the validation in the fplVulkanSettings (validationLayerMode = fplVulkanValidationLayerMode_Disabled).

If you dont have the Vulkan SDK installed, enabled validations wont work :-(
Therefore no instance can´t be created. Maybe in that case, i will add a fallback to create a Vulkan instance without any validations enabled. I created a ticket for that (

The missing of batch files to compile the demos with VStudio is a good idea and i will add that. The only thing which will be hard, is to find out which VStudio is installed and execute the (vcvars64/vcvars32.bat file). Or i assume that VC is already in the environment path... Ticket ticket (

I hate visual studio and that MSBuild shit, its always the same - version incompabiltities between project files (8.1 vs 10.1, 10.12, 10.3, etc.).... *sigh*

There are three things i can do about that:
- Setup the VStudio projects to require the current versions (VS 2019 and latest toolset for 10.x)
- Setup the projects to require the oldest versions and VStudio 2017 (8.1) -> requires some people to install 8.1 toolset into VStudio
- Or i can simply use "premake" to create the VStudio projects automatically - but of course this would require premake and i hate build systems :-(

But regardless, if you have CMake installed - you can compile the demos with crappy CMake as well.
Simon Anciaux
2 weeks, 4 days ago
With the validation layer disabled it's working.

For the batch file, I think it's OK to ask the user to call vcvarsall.bat themselves if some variable isn't present. I believe 4coder checks for %Platform% and calls vcvarsall.bat it if it's not present or the correct platform.

I don't care about Visual Studio project building. I just wanted to point out the issue I encountered. Isn't there an option to use the "most recent version installed" hoping that it will just work ?
2 weeks, 1 day ago
With the validation layer disabled it's working.

Great, for the next version I have an idea of how to make it more robust: I will add a new mode fplVulkanValidationLayerMode_Force, which will stop the initialization when the validation layer is present. The current one _Enabled will be changed, so that it won't stop anymore and fallback to non-validation mode.

Also, I will get rid of the "vulkan.h" and make a "final_dynamic_vulkan.h", in the same format as "final_dynamic_opengl.h".

For the batch file, I think it's OK to ask the user to call vcvarsall.bat themselves if some variable isn't present. I believe 4coder checks for %Platform% and calls vcvarsall.bat it if it's not present or the correct platform.

Okay, that's a fine solution - I will do that. Thanks for the tip ;-)

I don't care about Visual Studio project building. I just wanted to point out the issue I encountered. Isn't there an option to use the "most recent version installed" hoping that it will just work ?

That's great, I very rarely get any feedback for FPL, so i appreciate it ;-)

I may have an idea to get VS projects working in VStudio 2017 and 2019 with all SDKs: Simply one PropertyGroup for each Platform SDK Target using the MSBuild conditionals.

Basic idea is here:

Log in to comment