1
SFML projects / Re: Millie Megavolte 8: Millie and the Mole King
« on: February 26, 2024, 04:55:11 pm »
I recently implemented the Steam Input API for the sole purpose of including the controller button icons.
One thing I love about SFML is the documentation. Every function is explained and there are even tons of step-by-step instructions and examples of how to use different modules. SFML's documentation is something other libraries should strive for. It is certainly something Valve's team should strive for.
As of the time of writing, without being too much of a Negative Nancy, the Steamworks API documentation sucks. It's outdated, some of the example files throw errors, some of the newer functions/constants aren't listed anywhere in the documentation or even online.
If you plan on implementing Steam Input in your own SFML game, here is what I learned and what I recommend:
Link to developer tutorial for Steam Input
I have attached some relevant files, including the manager I wrote, the InputConstants it mentions, and the in-game actions vdf file for the game.
Anyway here's a progress video of Millie 8 with one of the most recent characters added:
https://www.youtube.com/watch?v=2riH2uza0Z0
One thing I love about SFML is the documentation. Every function is explained and there are even tons of step-by-step instructions and examples of how to use different modules. SFML's documentation is something other libraries should strive for. It is certainly something Valve's team should strive for.
As of the time of writing, without being too much of a Negative Nancy, the Steamworks API documentation sucks. It's outdated, some of the example files throw errors, some of the newer functions/constants aren't listed anywhere in the documentation or even online.
If you plan on implementing Steam Input in your own SFML game, here is what I learned and what I recommend:
Link to developer tutorial for Steam Input
- In the spirit of SFML, please make sure your game can run and rebind controls without the Steam Input API implemented or enabled.
- Being an API, it needs time to start up and won't get things right away. If you initialize the API in class constructors, have your game try to get relevant information a second or so later. Otherwise, if it tries to get things like controller bindings right away, it will return garbage or worse yet, nullptrs.
- Instead of keys, think of the inputs of your game as actions instead. Example: instead of seeing if the space bar is down, have a Jump action with an associated keyboard key and test for that instead. Steam Input works on Actions, not specific keys.
- ACTION_LAYERS DOES NOT WORK. IT IS A MYTH. Either it was deprecated or it just flat out doesn't work anymore. If you include an "action_layers" section in your controller vdf, it will throw errors. Just forget about it. I wanted to use action_layers so I could have separate confirm/cancel buttons for menus but it just doesn't work. Instead, define it as a separate action set and switch between them in-game as needed. Action sets can share actions (example: you can have up/down/left/right in more than one set and they'll still refer to the same action)
- Oh, and guess what: if your vdf has errors, Steam will tell you it has errors, but not what they are. Clicking the button to view errors displays basic information about the configuration instead. Useless.
- unFlags: Since this isn't documented anywhere, here is what the uint32 flag does for GetGlyphPNGForActionOrigin(). It changes the style of the glyph it gets. 0 = knockout, 1 = light, 2 = dark.
I have attached some relevant files, including the manager I wrote, the InputConstants it mentions, and the in-game actions vdf file for the game.
Anyway here's a progress video of Millie 8 with one of the most recent characters added:
https://www.youtube.com/watch?v=2riH2uza0Z0