next »

[Glaiel-Gamer]

I transitioned over to SDL from GLUT today... got the window opening and rendering stuff again, only one problem: I can't load any files for some reason. None. No PNGs, no shader source codes, none of my custom ones, nothing. They're all in the same place they were before, but I can't load any.

Does SDL do anything funky with the file IO?

[Gold Cray]

I've never had any problems with it (I have but they weren't caused by SDL). What does your code look like?

[Glaiel-Gamer]

I have way too much code to show, but my file IO stuff is fairly standard stuff

I was checking the GLUT version again, and apparantly if I don't make a window, the file IO doesnt work there.

std::string str;
  std::ifstream inf;
  inf.open(filename.c_str(), std::ios::in);
  if(inf.is_open()){
    while(!inf.eof()){
      std::string buffer;
      inf >> buffer;
      str += buffer + " ";
    }
    std::cout << str << std::endl << std::endl;
    inf.close();
  }
  return str;

// glut version

  glutInit(&argc, argv);
  glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GLUT_MULTISAMPLE);
  glutInitWindowSize(WINDOW_WIDTH, WINDOW_HEIGHT);
  glutCreateWindow("Closure");
  setup();
...

in setup is where I have file loading stuff. If i comment out glutCreateWindow or more, files don't open. If I don't, they do. It setps through the same way besides failing at if(!inf.is_open())

[Glaiel-Gamer]

apparantly it had something to do with not having the correct path to the Resources folder.... I had to hard code that it... although it would be nice if there was a way to find the right directory dynamically

[Average Software]

apparantly it had something to do with not having the correct path to the Resources folder.... I had to hard code that it... although it would be nice if there was a way to find the right directory dynamically

When you refer to the Resources folder, are you talking about the OS X bundle Resources folder?  If so, there is way to it dynamically.  Try this:

Code:

CFURLRef resourceURL = CFBundleCopyResourcesDirectoryURL(CFBundleGetMainBundle());
unsigned char resourcePath[4096];
CFURLGetFileSystemRepresentation(resourceURL, TRUE, resourcePath, 4096);
chdir((const char*)resourcePath);
CFRelease(resourceURL);

That will get you there.  There's a cleaner Objective C way to do it as well, if you're linking to Cocoa.

By the way, ios::in is implicit in the fact that you declared an ifstream, it's the default value for that parameter.  There's no need to put that there.

[Glaiel-Gamer]

apparantly it had something to do with not having the correct path to the Resources folder.... I had to hard code that it... although it would be nice if there was a way to find the right directory dynamically

When you refer to the Resources folder, are you talking about the OS X bundle Resources folder?  If so, there is way to it dynamically.  Try this:

Code:

CFURLRef resourceURL = CFBundleCopyResourcesDirectoryURL(CFBundleGetMainBundle());
unsigned char resourcePath[4096];
CFURLGetFileSystemRepresentation(resourceURL, TRUE, resourcePath, 4096);
chdir((const char*)resourcePath);
CFRelease(resourceURL);

That will get you there.  There's a cleaner Objective C way to do it as well, if you're linking to Cocoa.

By the way, ios::in is implicit in the fact that you declared an ifstream, it's the default value for that parameter.  There's no need to put that there.

THANKS!

[increpare]

I'd also like to thanks you for that, average!

[Glaiel-Gamer]

Now my code is filled with #ifdef __APPLE__ ... #endif
I look professional!

Of course, some of it is pretty ugly

#ifdef __APPLE__
#define Point OSX_Point
#include <CoreFoundation/CoreFoundation.h>
#undef Point
#endif

damn generic named classes conflicting with my own


On a second note, am I gonna have to worry about this when I build in windows? Is it guaranteed to open in the directory the exe is in or do I have to do some win32 magic to find the folders I bundle with it

[mcc]

Now my code is filled with #ifdef __APPLE__ ... #endif
I look professional!

Of course, some of it is pretty ugly

#ifdef __APPLE__
#define Point OSX_Point
#include <CoreFoundation/CoreFoundation.h>
#undef Point
#endif

damn generic named classes conflicting with my own


On a second note, am I gonna have to worry about this when I build in windows? Is it guaranteed to open in the directory the exe is in or do I have to do some win32 magic to find the folders I bundle with it

What I do is I have an "InternalPath()" function. I give it a filename (or, well, a snprintf specification for a filename) and it returns the corresponding file from my Resources folder.

On the Mac build, this function calls all the funny CFUrl stuff.

On the Windows and Linux builds, this function just prepends "./Internal" to the file name (and my makefile copies the files that would have been in the Resources folder in os x into a folder in the same dir as the exe named "Internal").

This seems to work well.

EDIT: Sorry, I think I misunderstood the question. In all of my experience windows sets the working directory to be the directory of the .exe, unless you set it to something else with like a special shortcut.

[Average Software]

damn generic named classes conflicting with my own

That's what namespaces are for.

On a second note, am I gonna have to worry about this when I build in windows? Is it guaranteed to open in the directory the exe is in or do I have to do some win32 magic to find the folders I bundle with it

To the best of my knowledge it won't be a problem in Windows.  Linux is another story.  The working directory will vary based on whether you launched from a command line or some graphical window manager.  I use argv[0] to set the correct working directory over there.  There are some samples of this in an engine demo I posted a couple days ago.