Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: How to build a project that relies on relative paths  (Read 1252 times)

0 Members and 1 Guest are viewing this topic.

TheSpaceEvader

  • Newbie
  • *
  • Posts: 6
    • View Profile
    • Email
How to build a project that relies on relative paths
« on: July 06, 2018, 05:14:31 pm »
So I recently made a post asking why, when I built my project using CMake, none of my resources (images, sounds, fonts etc) were loading: https://en.sfml-dev.org/forums/index.php?topic=24218.msg163942
I now know, as eXpl0it3r rightfully pointed out, that the cause of my problem was due to my over-reliance on relative files and how, once the project is built, this is meaningless to the built program when executed. It's my understanding that there (atleast) two solutions to this for me:
  • Convert my resources to RGBA's, which are then stored in their own respective C source files, as seen here: https://en.sfml-dev.org/forums/index.php?topic=17256.msg124792#msg124792. However, my problems with this option are:
    • What tool would I use to convert image files into a string of RGBA values? I have attempted to use both sites such as convertio.co and tools like ImageMagick, but none of these appear to allow me to extract the values as a string?
    • As some of these images are relatively large, surely the RGBA string they are converted into would be absolutely massive? I attempted to convert one of my larger JPG's into a C source file using Gimp to test this and exported file was 20MB! Is this really the most feasible way of doing this?
  • An alternative that I have seen suggested is to have CMake copy these resources into my build directory. Then, where I would previously load from a relative path, have the project determine the actual, absolute path to the program using something like this: https://stackoverflow.com/questions/143174/how-do-i-get-the-directory-that-a-program-is-running-from
So, my question is, which of these, or perhaps another, solution is most often used/considered best practice by the community? #1 seems like the more portable solution but does not seem to allow for regular image sizes?
« Last Edit: July 06, 2018, 05:16:36 pm by TheSpaceEvader »

 

anything