{"id":22225146,"url":"https://github.com/mid1i/corners-game","last_synced_at":"2025-03-25T08:21:13.175Z","repository":{"id":98295926,"uuid":"576708308","full_name":"Mid1i/Corners-Game","owner":"Mid1i","description":"Kind of Corners Game on C++ by SFML graphics","archived":false,"fork":false,"pushed_at":"2023-04-07T13:58:56.000Z","size":294,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-01-30T07:31:35.297Z","etag":null,"topics":["cpp","cpp-game","sfml"],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Mid1i.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-12-10T18:10:51.000Z","updated_at":"2023-04-07T15:02:53.000Z","dependencies_parsed_at":null,"dependency_job_id":"f9b2a820-5be9-4cbe-954b-ed54d9fdb7e5","html_url":"https://github.com/Mid1i/Corners-Game","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Mid1i%2FCorners-Game","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Mid1i%2FCorners-Game/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Mid1i%2FCorners-Game/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Mid1i%2FCorners-Game/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Mid1i","download_url":"https://codeload.github.com/Mid1i/Corners-Game/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":245423681,"owners_count":20612836,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cpp","cpp-game","sfml"],"created_at":"2024-12-03T00:15:48.258Z","updated_at":"2025-03-25T08:21:13.154Z","avatar_url":"https://github.com/Mid1i.png","language":"C++","funding_links":[],"categories":[],"sub_categories":[],"readme":"# sfml-vscode-boilerplate\n\nA cross-platform [SFML](https://www.sfml-dev.org) 2.5.1 \u0026 C++17 build environment for [Visual Studio Code](https://code.visualstudio.com/)\n\n\u003e Note: This project has been superseded by: [https://github.com/chalet-org/chalet-example-sfml](https://github.com/chalet-org/chalet-example-sfml), utilizing a new build system called [Chalet](https://www.chalet-work.space/). Please give that a try instead!\n\n---\n\n## Features\n\n- Cross-platform build environments (Windows, Linux \u0026 MacOS)\n- GCC \u0026 Clang Compiler Configuration\n- Debugger support or standalone Debug build\n- Unit testing (with Catch2)\n- Static Profiler on Windows/Linux (gprof)\n- Bash terminal integration\n- Automated copying of dependencies\n- Automated production build\n- Automated app bundling on MacOS\n- Basic app bundle on Linux\n- Optionally auto-generate assembly from compiled objects (using objdump)\n- Optional precompiled header (cross-platform as well)\n- Optional Keybindings (F8, F9 \u0026 F10)\n- Optionally build on Raspberry Pi! (see bottom of Readme)\n\n---\n\n## Prerequisites\n\n### Windows\n\n- [SFML 2.5.1 - GCC 7.3.0 MinGW (DW2) 32-bit (for Windows)](https://www.sfml-dev.org/files/SFML-2.5.1-windows-gcc-7.3.0-mingw-32-bit.zip)\n- [GCC 7.3.0 MinGW (DW2) 32-bit (for Windows)](https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/7.3.0/threads-posix/dwarf/i686-7.3.0-release-posix-dwarf-rt_v5-rev0.7z/download)\n- [Git Bash (for Windows) ](https://git-scm.com/downloads)\n\n### MacOS\n\n- [SFML 2.5.1 - Clang 64-bit](https://www.sfml-dev.org/files/SFML-2.5.1-macOS-clang.tar.gz)\n- Command Line Tools / XCode (type \"xcode-select --install\" in terminal to trigger the installer)\n\n### Linux\n\n- Get SFML 2.5.1 from your distro if it has it, or compile from source\n\n### All\n\n- [Visual Studio Code](https://code.visualstudio.com/download)\n- Extensions (install from Extensions panel):\n  - [Official C/C++ Extension (0.21.0+)](https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools)\n  - [Shader languages support for VS Code (Optional Syntax Highlighting)](https://marketplace.visualstudio.com/items?itemName=slevesque.shader)\n  - [x86 and x86_64 Assembly (Optional Syntax Highlighting)](https://marketplace.visualstudio.com/items?itemName=13xforever.language-x86-64-assembly)\n  - [Studio Icons (Optional Icon Theme)](https://marketplace.visualstudio.com/items?itemName=jtlowe.vscode-icon-theme)\n\n---\n\n## Installation\n\n### Windows\n\n1. Download \u0026 Extract SFML to **C:/SFML-2.5.1/** where the bin/lib/include folders are contained within\n2. Download \u0026 Extract MinGW to **C:/mingw32/** where the bin/lib/include folders are contained within\n\n### MacOS\n\n1. Install \"Command Line Tools\" in MacOS if they're not already installed (type \"xcode-select --install\" in terminal)\n2. Follow the \"Installing SFML\" directions here: https://www.sfml-dev.org/tutorials/2.5/start-osx.php#installing-sfml\n\n### Linux\n\n1. Ensure the GCC Toolchain is installed (**sudo apt install build-essential**) (**sudo pacman -S base-devel**)\n2. Install libsfml (**sudo apt install libsfml-dev**) (**sudo pacman -S sfml**). The SFML version you got will vary depending on the distro. 2.5.1 is included in [Ubuntu 19.04 Disco Dingo](http://cdimage.ubuntu.com/daily-live/current/HEADER.html) for example.\n\n### All\n\n3. Download \u0026 Install Visual Studio Code if you don't already have it.\n4. Install the official **C/C++** Extension, reload the window \u0026 wait for the dependencies to install.\n5. If on Windows, install **Git Bash**, and ensure the **\"terminal.integrated.shell.windows\"** property in the project's **settings.json** is set to **bash.exe**'s correct location (default: C:/Program Files/Git/bin/bash.exe). We'll be using this for the terminal in our workspace so that the Makefile can run in both Windows, Mac \u0026 Linux\n6. In **settings.json** Ensure **Path** in the **terminal.integrated.env.windows** object is set to the correct location of the compiler's executable (example: C:\\\\mingw32\\\\bin) and the SFML directory is correct as well. Keep in mind Paths should be separated by a semi-colon with no spaces between.\n\n**Note:** You can manage the \"Path\" environment variable from Windows if you'd like, but I've found sandboxing it in VS Code is better for tracking things like .dll dependencies.\n\n---\n\n## Configuration\n\nAt this point, everything you need is installed\n\n1. Open the **sfml-vscode-boilerplate** folder in VS Code.\n2. With Main.cpp (or any source file) open, check the lower-right to ensure \"Win32/Mac/Linux\" is the configuration set (this should be auto-selected by the C++ plugin). If it is not correct, hit **Ctrl+Shift+B** and select **C/Cpp: Select a configuration...** and choose the platform you're working on.\n3. At this point you should be able to run a build task (**Ctrl+Shift+B** \u003e **Build \u0026 Run**), but it'll be nicer to add keybindings for these tasks so you can build with 1 keypress.\n4. Open the .vscode folder and click on the **\\_keybindings.json** file. This is not an officially recognized file, but just contains the keybindings you can copy into the actual keybindings.json file.\n5. Go into **File** \u003e **Preferences** \u003e **Keyboard Shortcuts** \u0026 click on the keybindings.json link at the top.\n6. Copy the keybindings into this file. Feel free to change them if you don't like them later.\n7. Hit the **F9** key to run the **Build \u0026 Run: Release** task. It should run the Makefile, find the compiler, build the Main.cpp into Main.o, and launch the sample SFML app. **Shift+F9** will launch the basic Debug build, and F8 will launch the actual Debugger alongside the Debug build.\n\n---\n\n## Adding Source Files\n\nSource files and folders are automatically detected by the Makefile. It looks for them in the \"src\" folder, and at the moment builds from .c, .cpp, .cc \u0026 .rc files.\n\n---\n\n## Adding external libraries (the \"lib\" folder)\n\nThis build system assumes that any libraries includes in the \"lib\" folder are either pre-built or header-only. It's auto-included as one of the search directories in the Makefile.\n\nUsage example:\n\n```\n+ lib/\n  + catch2/\n    + catch.hpp\n  + nlohmann_json/\n    + json.hpp\n  + XInput/\n    + XInput.h\n    + XInput.lib\n```\n\ntest/test_someTest.cpp\n\n```\n#include \u003ccatch2/catch.hpp\u003e\n...\n```\n\nsrc/JsonImpl.hpp\n\n```\n#include \u003cnlohmann_json/json.hpp\u003e\n...\n```\n\nsrc/InputManager.hpp\n\n```\n#include \u003cXInput/XInput.h\u003e\n...\n```\n\nenv/windows.all.mk\n\n```makefile\nLINK_LIBRARIES := \\\n  XInput\n```\n\n---\n\n## Makefile Environment\n\nThe environment variables used by the Makefile are managed from the **env** folder in separate .mk (Make) files, organized by build type \u0026 platform, so you can customize which SFML libraries to include if you want, or pretty much anything without having to edit the tasks.json. Each file is outlined below:\n\n    ./build.sh: Contains the build scripts that tasks.json calls\n\n    ./env/.all.mk: All platforms \u0026 builds\n    ./env/.debug.mk: All platforms, Debug build\n    ./env/.release.mk: All platforms, Release build\n\n    ./env/linux.all.mk: Linux, All builds\n    ./env/linux.debug.mk: Linux, Debug build\n    ./env/linux.release.mk: Linux, Release build\n\n    ./env/osx.all.mk: MacOS, All builds\n    ./env/osx.debug.mk: MacOS, Debug build\n    ./env/osx.release.mk: MacOS, Release build\n\n    ./env/rpi.release.mk: Linux (Raspberry Pi), Release build\n\n    ./env/windows.all.mk: Windows, All builds\n    ./env/windows.debug.mk: Windows, Debug build\n    ./env/windows.release.mk: Windows, Release build\n\nUnit Tests use the same settings as the Release build.\n\nThe environment variables that can be added to each .mk file are outlined below. If you need a line-break anywhere simply add a **\"\\\\\"** character. You can set base variables in _.all.mk and then build specific variables using \"VAR := $(VAR)\" syntax in _.debug.mk or \\*.release.mk. The hierarchy goes:\n\n    ./env/.all.mk\n    ./env/.(build).mk\n    ./env/(platform).all.mk\n    ./env/(platform).(build).mk\n\n---\n\n## Environment Variables\n\n**CFLAGS**:  \nCompiler flags to use.\n\n**MAX_PARALLEL_JOBS**:  \nMax number of parallel jobs to run, based on number of cpus cores available\n\n**CLEAN_OUTPUT**:  \nIf set to 'true', the build output will only show the path/filename of the source file being built as well as the linking step and a couple helpful messages. All other commands will be hidden (including assembly dumps)\n\n**DUMP_ASSEMBLY**:  \nIf set to 'true', \\*.o.asm files will generate within the bin/(Build)/asm folder. The bin folder is hidden from VS Code by default, but you can open the asm folder in a separate instance and browse the assembly that way if you'd like to, or customize it from settings.json.\n\n**PRECOMPILED_HEADER**:  \nDefine a precompiled header file (no extension). If this variable is not defined in the env files, then the precompiled header will not be used. This file will be excluded from Rebuild/Build tasks, but if the bin/(build) directory is removed, it will be as well.\n\nIf you're unfamiliar with how precompiled headers work, these speed up compile time by precompiling commonly used includes like standard libraries and the SFML includes. The PCH.hpp gets implicitly included in each cpp file, so you don't need to manually include it each time like with Visual Studio. When it actually compiles, it can be large, but it does not affect the size of the final binary (which would be the same size with or without the PCH).\n\n```makefile\nPRECOMPILED_HEADER:=PCH\n```\n\n**LIB_DIRS**:  \nAdd any additional lib directories (full path)\n\n```makefile\nLIB_DIRS= \\\n  C:/sfeMovie/lib \\\n  C:/myLibraries/lib\n```\n\n**INCLUDE_DIRS**:  \nAdd any additional include directories (full path)\n\n```makefile\nINCLUDE_DIRS= \\\n  C:/sfeMovie/include \\\n  C:/myLibraries/include\n```\n\n**LINK_LIBRARIES**:  \nAdd any additional link libraries\n\n```makefile\nLINK_LIBRARIES= \\\n  XInput \\\n  user32 \\\n  something\n```\n\n**BUILD_FLAGS**:  \nAdditional compiler flags for the particular build (including prefix)\n\n```makefile\nBUILD_FLAGS= \\\n  -mwindows\n```\n\n**BUILD_MACROS**:  \nMacros to include in the build\n\n```makefile\nBUILD_MACROS= \\\n  _DEBUG\n```\n\n**BUILD_DEPENDENCIES**:  \nDependency .dll/.so files to include in the bin/(build) folders\n\n```makefile\nBUILD_DEPENDENCIES= \\\n\tC:/SFML-2.5.1/bin/openal32.dll\n```\n\n## MacOS-specific:\n\n**MACOS_FRAMEWORK_PATHS**:  \nFramework paths, other than /System/Library/Frameworks\n\n```makefile\nMACOS_FRAMEWORK_PATHS= \\\n\t/Library/Frameworks\n```\n\n**MACOS_FRAMEWORKS**:\nFrameworks to include, (no extension)\n\n```makefile\nMACOS_FRAMEWORKS= \\\n\tCoreFoundation\n```\n\n---\n\n## Build: Production\n\nI thought it was important to include a build task that creates a final \"build\" folder and copies the files in the bin/Release folder, any dependency .dlls, and any other directories into it. It's accessed via (**Ctrl+Shift+B** \u003e **Build: Production**) and uses a couple special environment variables:\n\n**PRODUCTION_DEPENDENCIES**:  \nFiles \u0026 folders to copy into the \"build\" folder upon using the \"Build: Production\" task. In MacOS, this is anything going into the the app bundle's \"Resources\" folder.\n\n```makefile\nPRODUCTION_DEPENDENCIES= \\\n  C:/mingw32/bin/libgcc_s_dw2-1.dll \\\n  C:/mingw32/bin/libstdc++-6.dll \\\n  C:/mingw32/bin/libwinpthread-1.dll \\\n  C:/SFML-2.5.1/bin/openal32.dll \\\n  C:/SFML-2.5.1/bin/sfml-audio-2.dll \\\n  C:/SFML-2.5.1/bin/sfml-graphics-2.dll \\\n  C:/SFML-2.5.1/bin/sfml-network-2.dll \\\n  C:/SFML-2.5.1/bin/sfml-system-2.dll \\\n  C:/SFML-2.5.1/bin/sfml-window-2.dll \\\n  content\n```\n\n**PRODUCTION_EXCLUDE**:  \nFiles \u0026 extensions to exclude from the production build.\n\n```makefile\nPRODUCTION_EXCLUDE= \\\n  *.psd \\\n  *.rar \\\n  *.7z \\\n  Thumbs.db\n```\n\n**PRODUCTION_FOLDER**:  \nThe folder the production build will go into. This can be an absolute path or a relative path. Defaults to \"build\" if not defined.\n\n```makefile\nPRODUCTION_FOLDER=build\n```\n\n---\n\n## Build: Production (MacOS)\n\nOption 1: The \"Build: Production\" script creates a bundle \u0026 a basic .dmg image, but it does no code signing whatsoever! You must do that yourself (for now). There's a lot to document about, but to start, it requires a MacOS/MacHelper.cpp file to ensure the working directory is looking for resources inside the bundle's Resource folder. There's an Info.plist.json that gets compiled to the binary Info.plist, and an icon that gets compiled to an \\*.icns file. See osx.all.mk for additional production environment variables. Be aware some of it is still pretty experimental. The variables are outlined below.\n\nOption 2: Use Xcode to bundle your final build! It's as simple as that. Follow the rest of the directions outlined [HERE](https://www.sfml-dev.org/tutorials/2.5/start-osx.php), copy your code-base in the Xcode project folder, and go from there.\n\n**PRODUCTION_MACOS_ICON**:  \nThe app bundle's icon (.png, no extension)\n\n```makefile\nPRODUCTION_MACOS_ICON := sfml\n```\n\n**PRODUCTION_MACOS_BUNDLE_DEVELOPER**:  \nYour name, company, etc.\n\n```makefile\nPRODUCTION_MACOS_BUNDLE_DEVELOPER := developer\n```\n\n**PRODUCTION_MACOS_BUNDLE_DISPLAY_NAME**:  \nApp's display name (used everywhere)\n\n```makefile\nPRODUCTION_MACOS_BUNDLE_DISPLAY_NAME := SFML Boilerplate\n```\n\n**PRODUCTION_MACOS_BUNDLE_NAME**:  \nInternal app name (used somewhere by MacOS... ???)\n\n```makefile\nPRODUCTION_MACOS_BUNDLE_NAME := SFML Boilerplate\n```\n\n**PRODUCTION_MACOS_MAKE_DMG**:  \nset to \"true\" to make a .dmg image\n\n```makefile\nPRODUCTION_MACOS_MAKE_DMG := true\n```\n\n**PRODUCTION_MACOS_BACKGROUND**:  \nBackground image file (.png) to use in the .dmg image. A \"...@2x.png\" file is also expected\n\n```makefile\nPRODUCTION_MACOS_BACKGROUND := dmg-background\n```\n\n**PRODUCTION_MACOS_DYLIBS**:  \nDynamically linked libraries to include in the final build.\n\n```makefile\nPRODUCTION_MACOS_DYLIBS := \\\n\t/usr/local/lib/libsfml-graphics.2.5 \\\n\t/usr/local/lib/libsfml-audio.2.5 \\\n\t/usr/local/lib/libsfml-network.2.5 \\\n\t/usr/local/lib/libsfml-window.2.5 \\\n\t/usr/local/lib/libsfml-system.2.5\n```\n\n**PRODUCTION_MACOS_FRAMEWORKS**:  \nAny frameworks to add to the app bundle's \"Frameworks\" folder. (Path, no extension)\n\n```makefile\nPRODUCTION_MACOS_FRAMEWORKS :=\n  /Library/Frameworks/ogg\n```\n\n---\n\n## Build: Production (Linux/Ubuntu)\n\nA default Ubuntu app build is included, but beyond that, you're on your own. The App's configuration is set in env/linux/exec.desktop. Similar to MacOS build these are the linux specific variables:\n\n**PRODUCTION_LINUX_ICON**:  \nThe app icon (.png, no extension)\n\n```makefile\nPRODUCTION_LINUX_ICON := sfml\n```\n\n**PRODUCTION_LINUX_APP_NAME**:  \nThe app's name\n\n```makefile\nPRODUCTION_LINUX_APP_NAME := SFML Boilerplate\n```\n\n**PRODUCTION_LINUX_APP_COMMENT**:  \nThe app's description\n\n```makefile\nPRODUCTION_LINUX_APP_COMMENT := My SFML Game\n```\n\n---\n\n## Build \u0026 Run: Tests\n\nUnit Testing uses [Catch2](https://github.com/catchorg/Catch2).\n\nOne can build \u0026 run the unit tests with the appropriately named \"Build \u0026 Run: Tests\" task in vscode. The Unit tests are a slightly different build target. You create tests in the **test/** directory, and they get built alongside the \"Release\" build target. Refer to the Catch2 docs to build your test cases.\n\nHow you write your unit tests will obviously depend on how you write your engine code, but here are some examples:\n\n- Tests for any non-rendering functions (bezier curves, rngs, utility classes, etc)\n- Tests for rendering functions that create \u0026 display a window briefly\n- Tests for implementations of any external libraries\n\n---\n\n## Profile: Debug\n\nRunning the **Profile: Debug** task will build the Debug target (if necessary) and generate a **profiler_analysis.stats** file from a **gmon.out** file using gcc's \"gprof\" profiler. You can then examine the stats file in the workspace.\n\n---\n\n## Include directories \u0026 .vscode folder\n\nIf you need to add additional external libraries, these are a couple different places to keep in mind.\n\n- **.vscode/c_cpp_properties.json** - You'll see **compilerPath** \u0026 **includePath**. The compilerPath includes all the compiler's directories so, the includePath only needs the root project directory and any additional libraries you want to include. SFML is included as well in this boilerplate. See details below.\n\n  - **compilerPath** - Path to the compiler's binary to use (in our case, it's MinGW GCC.\n  - **includePath** - Used by the C/C++ extension for additional include directories. The relative project directory is included by default. You can also add directories recursively with **/\\*\\***\n\n- **.vscode/settings.json** - Contain all of your workspace settings \u0026 overrides VS Code's main settings.json. Here are some settings of interest:\n\n  - **files.exclude** - Add any filetypes you want to exclude from the folder panel. By default, some of the build files are excluded from VS Code, so that one can focus on just coding.\n  - **files.encoding** - This has been set to **utf8** by default, but you may want to use **windows1252** instead if you want less headaches. Feel free to change this to suit your needs.\n  - **editor.fontFamily** - Set to Courier by default. Change/remove this line if you want to stick to VS Code's default (Consolas), or your own preference. I'm a big fan of [Courier Prime Code](https://quoteunquoteapps.com/courierprime/).\n  - **terminal.integrated.env.(platform)** - Environment variables for use when the terminal runs. Note: These purposefully override the OS defaults so you can have an isolated environment.\n\n- **.vscode/launch.json** - Used to store the configuration to launch the debugger.\n- **.vscode/tasks.json** - Used to store the task definitions (Build \u0026 Run commands, etc.).\n- **.vscode/\\_keybindings.json** - As mentioned before, this is used purely to store handy keybindings that one can add themselves, and not recognized by VS Code.\n\n---\n\n## Creating an application icon on Windows\n\nThere's some interesting nuances to creating Windows icons, so I've included two easy-to-use shell scripts that will create an icon for you from .png files:\n\n```\nwin-make_icon_from_all.sh\nwin-make_icon_from256.sh\n```\n\nThey only require you to install ImageMagick, available here:\nhttps://www.imagemagick.org/script/download.php#windows (top-most binary)\n\nThe \"win-make_icon_from_all.sh\" script looks for 4 files: icon_16.png, icon_32.png, icon_48.png \u0026 icon_256.png. Edit them in the program of your choice \u0026 run the script using git bash and you'll get an app.ico file that you can import in `src/Win32/Icon.rc`. The `WindowsHelper` class will read all the icons from the .ico file, and pick out the 16x16 \u0026 32x32 ones for use as the application icon, while windows uses the other sizes for explorer.\n\nThe \"win-make_icon_from256.sh\" script is even simpler. You make one icon - icon_256.png, and it will generate the other sizes for you and output the app.ico file.\n\nYou can obviously modify these scripts to support other sizes used in edge cases (scaling factors use 20, 40, 64 \u0026 96 for instance), but the 4 included are the most widely used.\n\n---\n\n## Multiple Projects\n\nRecently, I wanted to avoid duplicate Makefiles in my various projects, so I found a nice little solution to do this.\n\n1. Start by creating a folder structure where something like **SFML** is your root folder for SFML projects, and the **sfml-vscode-boilerplate** is contained within. We'll rename it to **sfml-project1**.\n2. Copy the Makefile from **sfml-project1** to the root **SFML** directory\n3. Edit the Makefile in **sfml-project1**, replace the entire contents to simply have:\n\n```\ninclude ../Makefile\n```\n\n4. Copy the build.sh from **sfml-project1** to the root **SFML** directory\n5. Edit the build.sh in **sfml-project1**, replace the entire contents to simply have:\n\n```\n#!/bin/bash\nbash ../build.sh $1 $2 $3 $4\n```\n\n6. Make a copy of **sfml-project1** and call it **sfml-project2**\n7. Open either project in vscode, and they should each should compile! Voila! You can now use a shared Makefile between projects this way\n\n---\n\n## Multiple Targets (experimental)\n\nMultiple targets (dynamic libraries + 1 executable) are supported at the moment, although there's a couple setup changes you'll need.\n\n1. Place all the files in **src** into a new folder called **main**. \"main\" is a special target that will compile the main executable\n2. Create a new folder in **src** with your library's name. Place the code of that target within that folder.\n3. Optionally, add the same folder name in the **env** folder \u0026 add any .mk files (same patterns) into that folder. For instance, you might have a library \u0026 a main target that depends on that library. You would need to supply the main target with \"LINK_LIBRARIES := my_lib\" that way, but can still use the main .mk files to configure both targets.\n4. Now, you just need to supply build.sh with the target names. You can do this 2 ways. If you only plan on editing \u0026 building inside of vscode, you can add this to .vscode/tasks.json:\n\n```json\n\"options\": {\n    \"env\": {\n        \"BUILD_TARGETS\": \"target1 target2 main\"\n    }\n}\n```\n\n**BUILD_TARGETS** is a simple list of the folders, which then get output as the library name. For instance, \"target1\" would build out to \"target1.dll\" in Release, and \"target1-d.dll\" in Debug. \"main\" triggers the main target, and outputs \"(root folder).exe\" as it does w/o multiple targets.\n\nNote: Ordered from first built to last built (main must be last if it's included)\n\n6. However, if you want to build outside of vscode, you just need to add that as an environment variable. The best place for it is at the top of build.sh (which stays nice and clean if you followed the multiple projects step). That version would look like:\n\n```bash\n#!/bin/bash\nexport BUILD_TARGETS='target1 target2 main'\n\nbash ../build.sh $1 $2 $3 $4\n```\n\n7. At this point, you can build away, and you'll notice some extra verbiage related to multiple targets in the build output.\n\n---\n\n## Notes\n\n- This configuration assumes all source files are contained within the **src** folder, but uses the **root** as the working directory for assets \u0026 things referenced in your project. It also includes a **content** folder if you'd like to contain those asset files further (recommended).\n- By default, this configuration uses C++17. You can change the compiler flags in **env/\\\u003cplatform\\\u003e.all.mk** under **CFLAGS**.\n\nThis will be an ongoing project that I'll try to update as new SFML versions come out. Updating SFML releases should be relatively painless as I'll keep the pre-reqs up to date as well. Feel free to offer suggestions/report issues if there's anything I missed, or could do better.\n\nThat should be all you need to get started. Happy game making and/or programming!\n\n---\n\n## Build Without VS Code (experimental)\n\nIf you have a reason to build your project without Code (on Raspbian or something), you can run build.sh the following way:\n\n1. Use any bash terminal (Git Bash if Windows).\n2. Run a variation of the following:\n\n```\nbash build.sh (build|buildrun|rebuild|run|buildprod|profile) (Debug|Release) (executable commmand line options)\n```\n\nFor instance, to build \u0026 run the Release build, you'd use:\n\n```\nbash build.sh buildrun Release\n```\n\nIf you run the script without any parameters, it's the same as the following:\n\n```\nbash build.sh buildprod Release\n```\n\nTo build \u0026 run the unit tests, use:\n\n```\nbash build.sh buildrun Tests vscode '-w NoTests -s'\n```\n\n(The last parameter contains Catch2 command line options)\n\nIf the build mode is not Debug or Release, it will default to Release. If you need to, change the \"Path\" variables within the build.sh file in the \"if [[$VSCODE != 'vscode']] ; then\" block.\n\n---\n\n## Build on Raspberry Pi (experimental)\n\nI'll maybe make a full guide for this, but I'd recommend doing your development on another machine, and then just pulling the project via git and building it on the Pi with the build script in the previous section. Raspbian Lite (as of 1/6/2019) only comes with GCC 6.x, so you'll want to add GCC 8.x via **[this guide](https://solarianprogrammer.com/2017/12/08/raspberry-pi-raspbian-install-gcc-compile-cpp-17-programs/)** and compile SFML 2.5.1 from source. Once your app/game is compiled, you can launch it via startx \u0026 matchbox-window-manager (after enabling OpenGL from raspi-config).\n\nIn the precompiled header (src/PCH.hpp), I added an extra SFML define for the Pi aptly named **SFML_SYSTEM_PI** so you can conditionalize parts of your code for PI specific things (think \"kiosk mode\"). From there, you're in the wild west.\n\n---\n\n## MSYS2 (on Windows) (or changing the mingw version)\n\nGCC 7.3.0 is still probably the most stable GCC build on Windows, but if you want to try out newer versions, you can use [MSYS2](https://www.msys2.org/).\n\nStart with a clean install from here:\n\n- [MSYS2 (64-bit, 5/24/2019 stable)](http://repo.msys2.org/distrib/x86_64/msys2-x86_64-20190524.exe)\n\n1. Install to `C:/msys64` (default)\n2. Run `pacman -Syu` \u0026 restart Msys2 when it tells you do.\n3. Run `pacman -Su` to update packages\n4. Run the following command:\n\n```\npacman -S mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain mingw-w64-i686-openal mingw-w64-x86_64-openal\n```\n\n5. That will install both x86 \u0026 x64 versions (so you can try both) of GCC 10.1.0 (as of 5/16/20). It may take a while, but once finished, exit msys2.\n6. Build SFML. To start with, install CMake \u0026 doxygen (64 bit version). Then download [this script](https://gist.github.com/rewrking/5f8ea0eda064cbfb33f4f5d373011e0b) and edit the GCC_DIR line to either \"/c/msys64/mingw64/bin\" or \"/c/msys64/mingw32/bin\" depending on which architecture you want to target. Run the script, and if all goes well, you should have a compiled version of SFML in C:/SFML/2.5.1. You can also build from \"master\" instead by calling the script with that as a parameter.\n7. rename that folder so its architecture specific. For my own build, I did \"C:/SFML-2.5.1-gcc-10.1.0/mingw64\"\n8. Open sfml-vscode-boilerplate in VS Code, go into settings.json and comment out \".vscode/launch.json in \"files.exclude\", because we need to edit it. Also comment out \"build.sh\"\n9. Also in settings.json, go down to \"terminal.integrated.env.windows\" and change it to \"C:/msys64/mingw64/bin;C:/SFML-2.5.1-gcc-10.1.0/mingw64/bin\" (the new paths)\n10. In \".vscode/c_cpp_properties.json\", go to the Win32 configuration and change the \"compilerPath\" to \"C:/msys64/mingw64/bin/gcc.exe\" and the SFML \"includePath\" to \"C:/SFML-2.5.1-gcc-10.1.0/mingw64/include\"\n11. In \".vscode/launch.json\", go to the \"windows\" configuration and change \"miDebuggerPath\" to \"C:/msys64/mingw64/bin/gdb.exe\"\n12. Finally, in env/windows.all.mk, change \\_MINGW \u0026 \\_SFML (arbitrary variables) to:\n\n```makefile\n_MINGW := C:/msys64/mingw64/bin\n_SFML := C:/SFML-2.5.1-gcc-10.1.0/mingw64\n```\n\n13. Finally, in build.sh, line 44, (windows path if running the script outside vscode), change to 'export PATH=\"/c/SFML-2.5.1/bin:/c/mingw32/bin:$PATH\"', or alternatively if you're building without vscode (described above), you can add this snippet of in build.sh above \"bash ../build.sh $1 $2 $3 $4\":\n\n```shell\nif [[ $1 == '' \u0026\u0026 $2 == '' ]]; then\n\tif [[ $OSTYPE == 'msys' || $OSTYPE == 'win32' ]]; then\n\t\texport PATH=\"/c/SFML-2.5.1-gcc-10.1.0/mingw64/bin:/c/msys64/mingw64/bin:$PATH\"\n\t\tbash ../build.sh buildprod Release vscode\n\t\texit 0\n\tfi\nfi\n```\n\nRun any build task (from scratch) and you should be good to go!\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmid1i%2Fcorners-game","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmid1i%2Fcorners-game","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmid1i%2Fcorners-game/lists"}