next »

[ProgramGamer]

On Windows, Program Files is read only unless otherwise specified by the user. It sucks pretty bad, especially when you consider applications that auto-update. I know this because I tried to make an installer for a game and it kept telling me that I couldn't have things in Program Files or something.

[Cheesegrater]

Has windows changed their policy in win10? Because I've never heard of not having write access to the directory your game is installed in previous versions.

I believe it was Windows 7. Haven't checked on Vista, though.

The 'official' way to get the data files path is to use the SHGetFolderPath call (or SHGetKnownFolderPath in Vista or later). If you pass in CSIDL_COMMON_APPDATA you'll get the path to app data. That said, I don't see them breaking the getenv method any time soon.

I know this because I tried to make an installer for a game and it kept telling me that I couldn't have things in Program Files or something.

You can put files there at install time if you sign the installer and set up privilege escalation (PITA to do yourself, so use an installer building application), but even if you do your game will still not be allowed to write there with default security settings. If you want to do updates later the 'right way' is to package them as .msp files, again signed and with privelege escalation.

[InfiniteStateMachine]

Ah so this is an issue only when deployed to program files? I always don't install to program files whenever possible except for some developer tools like visual studio.

Ultimately I guess this is a battle I'm going to lose

[Dacke]

The *nix solution isn't primarily a security thing, it comes from *nix being built with a multi-user paradigm. Everything that belongs to you (documents, settings, saves, caches) goes in your private home folder. Making it super easy to bring all your stuff (including OS settings and saves) with you.

[InfiniteStateMachine]

That's a fair argument in favor for that method. Especially when considering how in the old days computer labs were dumb nodes that just essentially got feeds from a master computer.

Sounds like part of the problem is I've lived in a world where I'm usually the only user of my computer and therefore haven't been able to see why that scheme is advantageous. I'm too selfish in my thought process.

I do really like portable stuff that doesn't rely on environment variables though. It makes setting up a highly specialized workspace much easier for large software projects when setting up a new developer.

[oahda]

In this modern day and age I guess you're supposed to offer cloud services to synchronise your game data between different machines and devices.

[InfiniteStateMachine]

I think this may be appropriate on my behalf :D

[Dacke]

Especially when considering how in the old days computer labs were dumb nodes that just essentially got feeds from a master computer.

Doesn't it make even more sense with smart nodes? Every user has their own account. When logging in their home folder is downloaded to the local computer, so that they get their personalized account. But you don't want every user to have their own copy of every program (difficult to keep updated, too much data to copy) so you have the relevant software installed on every computer and only copy settings and documents.

I do really like portable stuff that doesn't rely on environment variables though. It makes setting up a highly specialized workspace much easier for large software projects when setting up a new developer.

Hm. But doesn't the *nix approach solve that perfectly? Install vanilla version of software on the computer. Add config files (found in a standardized location) to your home folder. No "registry" or other BS like that.

Separating the software from the config/saves like that also works great when you're a single user. When I want to move to a new computer, I just move my home folder to a new install. No need to dig through different installation directories, hunting for save folders.

[Sik]

Similar thing on Linux with ~/.config as the base directory.

It's ~/.local/share/<yourdir> these days. At least you can retrieve ~ using getenv("HOME") (and if not, chances are you probably may not want to try saving those files...)

In this modern day and age I guess you're supposed to offer cloud services to synchronise your game data between different machines and devices.

Unless you want to require on-line access and on-line accounts just to be able to run the program, you're going to have to keep a copy of those files somewhere in the computer anyway. And that means going back to this issue.

[InfiniteStateMachine]

Especially when considering how in the old days computer labs were dumb nodes that just essentially got feeds from a master computer.

Doesn't it make even more sense with smart nodes? Every user has their own account. When logging in their home folder is downloaded to the local computer, so that they get their personalized account. But you don't want every user to have their own copy of every program (difficult to keep updated, too much data to copy) so you have the relevant software installed on every computer and only copy settings and documents.

It most likely does. See my previous answer on why I haven't been privy to that revelation.

By smart node you mean a single computer with multiple logins right?

I do really like portable stuff that doesn't rely on environment variables though. It makes setting up a highly specialized workspace much easier for large software projects when setting up a new developer.

Hm. But doesn't the *nix approach solve that perfectly? Install vanilla version of software on the computer. Add config files (found in a standardized location) to your home folder. No "registry" or other BS like that.

Separating the software from the config/saves like that also works great when you're a single user. When I want to move to a new computer, I just move my home folder to a new install. No need to dig through different installation directories, hunting for save folders.

[/quote]

90% of the time this is ok. On some larger projects these folders need be re-targeted depending on the project in context. If I can have pre-configured local versions of an application for the project it works a lot better than having to write scripts to update the state of those config files every time I want to change contexts.

I suppose you could try to have an account per context but that sounds like miuse of the concept and I have my doubts that would actually work in practice.

[Dacke]

By smart node you mean a single computer with multiple logins right?

No, I meant computer labs (like in a university) where you have a single login that works on tons of different computers. Your account data and settings aren't stored on any of the terminal computers, but on a central server. So no matter what computer you login to, you get your full program and OS configs, documents, etc downloaded to that node from the central server. Which wouldn't work very well if saves/settings/etc. were stored in the installation directories, but works great if it only needs to download your home folder.

90% of the time this is ok. On some larger projects these folders need be re-targeted depending on the project in context.

Ah, right. That makes sense. I actually do run some programs as standalone packages in some cases, so I'm not generally opposed to that either.

[Cheezmeister]

Add config files (found in a standardized location) to your home folder. No "registry" or other BS like that.

Uh, Windows Registry is basically a bunch of config files, following the same structure, in a standardized location that happens to not be on the file system. Only difference is, it has "hives" instead of /etc, /share, /home and so forth. To be fair, the "standardized" locations of things changes frequently and different bits of the Registry are documented to wildly varying extents...but that's true of *nix dotfiles as well!

On another note, the trend towards cloud services accessed by smartphones really is eerily similar to the shared mainframe+terminal paradigm of old. The notion of a "personal computer" is steadily going back out of style. I still haven't decided whether that's a good thing =P

[DragonDePlatino]

With SDL 2.0, what is the best practice for loading textures that can be used throughout the program? What do you guys do? Right now, I load my textures inside a render.cpp like so:

Code:

void loadTextures()
{
	spriteSheet monstersheet(screen, "../img/monsters.png");
	spriteSheet tilesheet(screen, "../img/tiles.png");
	std::cout << "Textures loaded." << std::endl;
}

(spriteSheet is just a wrapper with a single SDL_Texture inside, screen is my renderer)

Only problem is, if I go back to main and create a player object using monstersheet, it's already gone out of scope. I'm considering creating a big global array of all my loaded textures, but I'm hesitant to introduce more global variables. Any suggestions?

[insaneinside]

With SDL 2.0, what is the best practice for loading textures that can be used throughout the program?
I'm considering creating a big global array of all my loaded textures, but I'm hesitant to introduce more global variables. Any suggestions?

Typically what I do is create some GlobalValues class or structure with member variables that contain such textures, instantiate it in main, and pass around a reference to that as needed.  Note that this approach works fine and is much better than simply using global variables in terms of principled design, but eventually you may wish to, say, have a dedicated TextureManager class instantiated as a member of GlobalValues once your code base gets large enough.

[DragonDePlatino]

Thanks for the reply. I was a bit hesitant to add such widely-scoped variables since I recently restarted my project because of scope issues, but that sounds pretty safe. In retrospect, putting my globals into a dedicated header is probably overkill anyways. I'll just add them to a GlobalValues class in main.

[zilluss]

In retrospect, putting my globals into a dedicated header is probably overkill anyways. I'll just add them to a GlobalValues class in main.

The best way to achieve this would be what GPP describes as a ServiceLocator (http://gameprogrammingpatterns.com/service-locator.html).
The ultimate goal would be a ResourceManager that you pass a string and that knows where to load what kind of resouce and when to free it.

[InfiniteStateMachine]

Thanks for the reply. I was a bit hesitant to add such widely-scoped variables since I recently restarted my project because of scope issues, but that sounds pretty safe. In retrospect, putting my globals into a dedicated header is probably overkill anyways. I'll just add them to a GlobalValues class in main.

Do you mean design scope or literally you had issues with too much stuff in global scope?

[Dacke]

Uh, Windows Registry is basically a bunch of config files, following the same structure, in a standardized location that happens to not be on the file system. Only difference is, it has "hives" instead of /etc, /share, /home and so forth. To be fair, the "standardized" locations of things changes frequently and different bits of the Registry are documented to wildly varying extents...but that's true of *nix dotfiles as well!

I haven't used Windows in ages, but that doesn't sound right.

A cursory reading on Wikipedia tells me that the registry is a database stored in the system root (similar to /bin, /etc, etc.). So if programs put things in the registry it's stored on a system-level, it's specific to that install.

Which is the complete opposite of storing system settings in user's home folders (i.e. /home/dacke/.somesetting). In which case the setting is unique to that user and gets moved along if the home folder is copied to another install.

[DragonDePlatino]

Do you mean design scope or literally you had issues with too much stuff in global scope?

Design scope? You mean having so many features I can't possibly keep maintaining them all? Ha! I wish. In reality, my game completely fell apart and refused to compile once I moved everything into it's own header. This time around I'm using headers from the start instead of building in main and then moving things to headers.

[Cheesegrater]

A cursory reading on Wikipedia tells me that the registry is a database stored in the system root (similar to /bin, /etc, etc.). So if programs put things in the registry it's stored on a system-level, it's specific to that install.

Which is the complete opposite of storing system settings in user's home folders (i.e. /home/dacke/.somesetting). In which case the setting is unique to that user and gets moved along if the home folder is copied to another install.

The registry is actually a set of databases, one of which is user-account specific (Usually called HKEY_CURRENT_USER). Roaming user profiles will copy the user specific registry DB around like the home directory.