• Content count

  • Joined

  • Last visited

Community Reputation

751 Good

About adt7

  • Rank
  1. 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.   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. [source]set(SDL_SHARED false CACHE BOOL "Build a shared version of the library" FORCE)[/source] 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.
  2.   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.     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?     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.
  3. I've been working on a C++ project using CMake as my build-system generator and I'm about to get a second developer on board.   I work on OSX with dependencies installed using Homebrew.   They are going to work on Windows (they are going to work on some of the cross-platform issues, so this choice is deliberate).   What I'm struggling with, is how to manage the dependencies in the project so that it's as easy as possible to onboard this new developer and any future ones (agnostic of platform).   The approaches I've considered are as follows: Make developers install all dependencies using brew/apt/downloading them and letting my FindX.cmake scripts sort it out (with special environment variables for Windows). Include pre-compiled dependencies in a folder within the project and link to those (for all supported platforms). Use git submodules to include the source of the dependencies in the project and use add_subfolder in CMake to compile them.   I think the second approach is the "right" one, as it's the least friction for new developers and means that the dependencies don't have to be compiled the first time.   The only concern I have about this is that at some point (before I'm ready to distribute the project) I want to switch to static linking (is this even a good idea?). This is fine for simple dependencies with no dependencies themselves.   However, what about the more complex ones like SDL? Do I then need to include static versions of all it's dependencies (OpenGL etc.), that doesn't seem great. I noticed SFML does this (in the /extlibs folder), but it doesn't include everything is depends on, only a few (for example OpenGL is not included), how do I know which ones I need to include and which I don't?
  4. 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?
  5. 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.
  6. My current project is a 2D platformer where the whole game is made up of a series of "rooms" (like a level of Shovel Knight, but without a world map to split it up).   My rooms are currently defined like this (pseudo code): room = {     tilemap = "tilemap.tmx",     init = {          // Perform the initialisation of anything not in the tilemap, e.g. enemies and collectable items     }, // Other irrelevant stuff } Each time you enter a room, the init code is run and all of the enemies/collectables you killed/picked up/whatever are all back in their original place. This is exactly how I want this to work.   At the moment saving the game is simple, I just serialize out the state of the player, which room they are on and that's it.   The problem I'm having is that I'm now at the point where I want to add one-off collectables (like the morph ball in the Metroid games) or one-off enemies (e.g. an extra hard one that spawns only once), once you've collected/defeated them, they are gone - and when you enter/re-enter a room they shouldn't be re-spawned along with everything else.   I'm struggling to come up with a concept to handle this without some kind of global manager to look after everything which feels a bit wrong to me.   I'm working with an ECS architecture (as a purely educational exercise, I don't want to go into the merits of ECS vs. non-ECS), and I know that I shouldn't try and force everything into it, but it feels like this is a problem that I should be able to solve with it.   As a rough stab at it I was thinking of the following: a Persistence component which stores a key a PersistenceSystem which keeps track of these keys and their state when a Persistence component is added to an entity, if the PersistenceSystem says the entity shouldn't exist anymore, destroy it (this is to handle the case when I reload a room) when I save the game I serialize the keys and their states from the PersistenceSystem along with my other data Is this is a sensible approach? Is this something that should sit outside of the ECS? How have other people tackled this problem?
  7. Setting up CMake for SDL-GL

    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". if(WIN32)   # Tell CMake where to search for includes, libs and DLLs on Windows   set(CMAKE_PREFIX_PATH ${CMAKE_PREFIX_PATH}     "${PROJECT_SOURCE_DIR}/extern/glew"     "${PROJECT_SOURCE_DIR}/extern/SDL2"   ) endif(WIN32) find_package(OpenGL REQUIRED) if(NOT OPENGL_FOUND) message(FATAL_ERROR "OpenGL not found!") endif(NOT OPENGL_FOUND) include_directories(${OPENGL_INCLUDE_DIR}) target_link_libraries(${PROJECT_NAME} ${OPENGL_LIBRARIES}) find_package(GLEW REQUIRED) if(NOT GLEW_FOUND) message(FATAL_ERROR "GLEW not found!") endif(NOT GLEW_FOUND) include_directories(${GLEW_INCLUDE_DIR}) target_link_libraries(${PROJECT_NAME} ${GLEW_LIBRARY}) find_package(SDL2 REQUIRED) if(NOT SDL2_FOUND) message(FATAL_ERROR "SDL2 not found!") endif(NOT SDL2_FOUND) include_directories(${SDL2_INCLUDE_DIR}) target_link_libraries(${PROJECT_NAME} ${SDL2_LIBRARY})  
  8. Have you tried making use of SDL_GetPerformanceCounter (alongside SDL_GetPerformanceFrequency) rather than SDL_GetTicks? It should give you a more accurate timing value.
  9.   Wait, is that actually representative of your actual code? Those calls to sleep (especially in the physics thread) will not be doing you any good. The accumulation loop you posted is design to run as quickly as possible (i.e. in a while(true) style loop) and fire the Physics events at the correct time. With the setup you have now the simulation will not be being called at the correct frequency due to differences in sleep time and the fact that your time deltas are going to be huge.
  10. The clock() function gives you the ticks elapsed since the program was launch. PhysX expects its delta times in seconds. Try dividing your clock values by CLOCKS_PER_SEC and working in seconds rather than ticks.
  11. A lot of methods/constants have been changed/removed for SDL2. For example, SDL_GL_SwapBuffers() is now SDL_GL_SwapWindow(). You need to update your code to use the new SDL2 methods.
  12. XNA - Making A Sprite Fire A Projectile

    Without seeing any code it's hard to give any advice on how to fit it into your existing setup. Coudl you post snippets of the relavent parts of your Sprite, SpriteManager, UserController and ProjectileSprite classes? Or at least the parts that seem to be causing you difficulty?
  13. For my latest (small) project I thought I'd try out a slightly different way of doing things, namely I've decided to try using MVC for a game.   I've got a reasonable handle on it in terms of observers and events in the model and communicating these to the view (and controller), however I'm having a bit of difficultly in figuring out how to completely eliminate data about the graphical representation from the model.   Take this (massively simple) example of a fairly basic RPG. Since my model is data-driven, I have a single "Unit" class which contains information about the units (no need for Troll, Goblin, etc subclasses).   class Unit { string name; //Friendly name, e.g. Dave int hp; int damage; int range; Unit(string name, int hp, int damage); } Then in my model I keep a list of these Units as well as a method to retrieve them so the view can access them.   class Model // LevelState or similar would be a better name for this { Unit[] units; Unit[] GetUnits(); }   The problem occurs when I come to drawing the units, as far as my model is concerned it doesn't care about if the unit is a goblin, an archer or a giant salamader, all it cares about is the unit's stats which define it's behavior.   However, the view very much cares about if the unit is a goblin, an archer or a giant salamader as it will have to draw different sprites for each of them.   What is the best way to solve this? I could add an enumerated "type" field to the Unit class, but this feels wrong as it's polluting the model with data that it doesn't care about, but I really can't see any other way of doing this.   Am I just overthinking and getting too concerned with what is "right" and "clean"?
  14. First adroid app wont work *SOLVED*

    It exits unexpectedly because the following lines of code need to be moved to onCreate, after the call to SetContentView.         TextView textField = (TextView) findViewById(; TextView result = (TextView) findViewById(; EditText gameObjective = (EditText) findViewById(R.string.gameObjective); Button button = (Button) findViewById(R.string.submitButton);