Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 May 2009
Offline Last Active Sep 19 2016 11:02 AM

Posts I've Made

In Topic: Dependency Management in a Cross Platform, Multi Developer Environment

16 June 2016 - 09:20 AM

For the most part, I just write the CMake file for them. It's rarely more than a handful of lines for something tiny like Lua, and most larger libraries seem to use CMake already.

Yeah, that's true. Even most of the small libraries I use are using CMake, and you're right, for something like Lua it's trivial to write one.

The option() command is your friend

I didn't realise option could be used that way, that's so much easier than what I've been doing. I've been using set like this, which is a real pain as the description has to match exactly.

set(SDL_SHARED false CACHE BOOL "Build a shared version of the library" FORCE)

I think I'll go for using git submodules for anything open source and then for the few non-open dependencies I have I'll just bundle the binaries in the repo. Thanks for the help.

In Topic: Dependency Management in a Cross Platform, Multi Developer Environment

16 June 2016 - 01:09 AM

Including compiled libraries in a source repo has always lead to trouble somewhere down the road. Maybe you need different versions for similar platforms that have slightly different dependencies? (thinking of different Linux distros here).


I think the most practical way is to let developers install "well known" libraries from their OS's package manager and put less well known things as a submodule and have them compile along your own source.


That maybe true, but as I'm only aiming to support a very limited set of platforms to begin with (not myriad Linux distros) I'm less concerned about this. My aim is to have the process of on-boarding new people as easy as possible, but also to have everyone working from a "known good" state, to rule our library version issues, etc.


These days I use the git submodule approach, with CMake wired up to build all the submodules too. It's a bit of a pain to setup, but it honestly works extremely well, provided you don't have source code licensing issues, or dependencies that need to be distributed as binaries...

On previous projects I have maintained pre-compiled libraries for each platform on a central server, and have each developer rsync them to their devbox on a nightly basis. Its not pretty, but it is very flexible and easy.

Ultimately, I feel like the answer may just be to use a better build system with dependency management built in. Java has Gradle, Rust has Cargo... for some reason C++ still limps along without anything.


I like the sound of the ultimate solution, and using these types of systems is what I've done in the past... if only one existed for C++.


As for the submodule approach, how do you handle dependencies that don't have their own CMakeLists.txt (to pick a well-known example, Lua), do you find a fork with a CMakeLists.txt (e.g. LuaDist/lua) or is there a way I can get CMake to figure out how to use their makefile (even as I'm typing this it sounds insane)?


EDIT: Further to that, how do you handle all of the set calls that need to be made to turn off features in your dependencies builds (e.g. building tests), doing it in the CMakeLists.txt is fine, but messy, is that just something you have to live with doing it this way?


Every actual job that I've had has used option #2. If using Git, sometimes these dependencies are in a separate repo (e.g. Project and ProjectDeps which are checked out / cloned to side-by-side locations by each developer) to avoid bloating your main repo with large binary files, seeing that git sucks at that...


The open source / nix world tends to use #1, and some kind of package manager.


From what I've seen of your posts around here you've got a pretty impressive job history and been involved in some big projects, so if that's how you've worked in the past it's making me think that whilst it may not be the ideal world approach, it's probably the best one.

In Topic: Loading TMX files with SDL2 using Baylej's C library

23 March 2016 - 02:42 AM

tilecount is populated which would suggest that your tiles are getting parsed properly.

What do you see if you expand the tiles node in the debugger?

In Topic: Simple 2D collision detection for a platform game (easiest solution possible...

16 December 2015 - 03:43 AM

This is one of the best explanations of continuous collision detection using bounding boxes that I've seen:


You don't need to use 2 bounding boxes, nor do need to do the splitting into top/bottom and left/right boxes if you don't want, this technique works equally well with a single bounding box and I've used it to great effect in games that I've written.


Doing the same with a single bounding box is explained in this video, although it's explained mostly through code rather than diagrams:


In case the video isn't clear enough, the basic steps (regardless of how many bounding boxes you use) are as follows:

  • Calculate your desired move distance.
  • Choose an axis to resolve first (I tend to go with x)
  • Take your desired move distance in the chosen direction and extend the bounds of your bounding box by that much in that direction.
  • Get all of the tiles within your new bounding box.
  • Check for collision in the direction of travel against only the tiles within your new bounding box.
  • If there is no collision, move your full desired move distance.
  • If there is a collision, do whatever your collision behavior is (most likely, move as far as you can then stop)
  • Repeat for the other axis.

In Topic: Setting up CMake for SDL-GL

11 May 2015 - 06:46 AM

This is how I do this in my project. On Windows I populate CMAKE_PREFIX_PATH with the paths to the various library directories, and on OS X/Linux it "just works".

  # Tell CMake where to search for includes, libs and DLLs on Windows
find_package(OpenGL REQUIRED)
message(FATAL_ERROR "OpenGL not found!")
target_link_libraries(${PROJECT_NAME} ${OPENGL_LIBRARIES})

find_package(GLEW REQUIRED)
message(FATAL_ERROR "GLEW not found!")
target_link_libraries(${PROJECT_NAME} ${GLEW_LIBRARY})

find_package(SDL2 REQUIRED)
message(FATAL_ERROR "SDL2 not found!")
target_link_libraries(${PROJECT_NAME} ${SDL2_LIBRARY})