Please always post the full error log. It's impossible to say what's going on without that.

Bobsolo1

Mario is not in today, but will take a look at your issue very soon. We appreciate your patience and we'll try to help you as soon as possible.

Also, if possible, please go to the error list and do a Ctrl-A to select all the errors, right-click, and then select copy. You can then paste them to a text file so that we can parse the errors you're receiving.

Thanks for the error log. It appears you are not linking SFML itself. The linker complains that all of SFML is basically missing.

You have the target type set to x64, the 64-bit version of Intel's instruction set. However, the SFML libraries you have stored locally are for 32-bit Intel.

Two ways to solve this:

• select 32-bit (not sure what the list item is called) here.
• Clone the spine-runtimes repository again and start fresh, you have old SFML binaries in your build tree. Alternatively, you can run git clean -x -f -d on the command line in your current clone of the spine-runtimes

Yes of course, you can use our example as a basis for your app. Though I feel that if setting up a vanilla project with a game toolkit is so hard for new users, that is probably not a great game toolkit in general. That's not your fault, that's SFML's fault. Why stick with SFML? There are many others that don't involve such pain. I'm partial to libgdx, which is what the Spine editor is written in.

When creating a new app using SFML or SDL plus the respective Spine Runtime, I'd set it all up in a single CMake project. That's what our examples do. The alternative is to compile each of those things into .dlls or static .lib libraries, which is a major pain, especially if you want to modify the source code. The "everything in a single CMake build" also enables you to more easily debug everything.