Show Posts
76
General / Re: Making a game playble on other computers
« on: January 17, 2019, 01:29:51 am »
https://stackoverflow.com/questions/5101458/why-is-a-bad-practice-to-distribute-the-debug-version-of-the-application-in-net
Specific dlls and where to find them (other than anything you use like SFML dlls) depend on your specific compiler. With certain compilers and/or compiler setting there might be nothing (that's often called 'fully statically linked standalone executable' or similar and depends only on built in stuff in C:/Windows/). You need to be careful not to include wrong ones, like wrong architecture (32 bit vs 64 bit) and so on. Many commercial games made in VS include an installer of VS redistributable runtime instead and run it at first launch or something.
You can pack your files into zip or 7z or something and then load them using some library like PhysicsFS (be sure to get latest version from Mercurical, latest stable version is badly busted, you need to buil dit yourself either way). PhysicsFS is meant for this (gamedev) purpose and support many formats (but it's best to stick to zip or 7z).
This is only zipping up into a single file, if you want encryption you need something else (zip encryption works with PhysicsFS but is very bad/tedious to use in your code). Any encryption (even proper AES) you do will be eventually be broken by a determined hacker who finds where the key is in the exe or game files though (even commercial real games get pirated and DRM broken all the time) so you might just not bother or go with just a xor with some hardcoded key (this is horrible and unsecure encryption but it's easy and quick to do and you're just trying to demotivate the most common attacker anyway) and set it to all 0s during development to work on plain files and use 7z instead of zip and a different extension than .7z to try confuse/demotivate most people (just changing the extension without any encryption/scrambling of the contents will only makes the simplest hacker go away).
If you want to embed files into the exe there are a few way too. There are OS specific ways to do it (I know nothing about them), there is embedding them in the code as const char[] = { data-here } (there are tools to generate these files or you can write one yourself, it's like 20-30 lines of code) or another funny/easy way is to concatenate an archive onto an exe and then open it in the right way in your program. Or you can just not bother with it and have: your exe, your dlls, an archive file or few, and maybe some config and a save directory. That's not that much stuff to have (the archiving of all your game resources into a single file is your biggest win for decluttering and performance).
Specific dlls and where to find them (other than anything you use like SFML dlls) depend on your specific compiler. With certain compilers and/or compiler setting there might be nothing (that's often called 'fully statically linked standalone executable' or similar and depends only on built in stuff in C:/Windows/). You need to be careful not to include wrong ones, like wrong architecture (32 bit vs 64 bit) and so on. Many commercial games made in VS include an installer of VS redistributable runtime instead and run it at first launch or something.
You can pack your files into zip or 7z or something and then load them using some library like PhysicsFS (be sure to get latest version from Mercurical, latest stable version is badly busted, you need to buil dit yourself either way). PhysicsFS is meant for this (gamedev) purpose and support many formats (but it's best to stick to zip or 7z).
This is only zipping up into a single file, if you want encryption you need something else (zip encryption works with PhysicsFS but is very bad/tedious to use in your code). Any encryption (even proper AES) you do will be eventually be broken by a determined hacker who finds where the key is in the exe or game files though (even commercial real games get pirated and DRM broken all the time) so you might just not bother or go with just a xor with some hardcoded key (this is horrible and unsecure encryption but it's easy and quick to do and you're just trying to demotivate the most common attacker anyway) and set it to all 0s during development to work on plain files and use 7z instead of zip and a different extension than .7z to try confuse/demotivate most people (just changing the extension without any encryption/scrambling of the contents will only makes the simplest hacker go away).
If you want to embed files into the exe there are a few way too. There are OS specific ways to do it (I know nothing about them), there is embedding them in the code as const char[] = { data-here } (there are tools to generate these files or you can write one yourself, it's like 20-30 lines of code) or another funny/easy way is to concatenate an archive onto an exe and then open it in the right way in your program. Or you can just not bother with it and have: your exe, your dlls, an archive file or few, and maybe some config and a save directory. That's not that much stuff to have (the archiving of all your game resources into a single file is your biggest win for decluttering and performance).
And the fact this one unused function in image write was saving us...
was for, are you agreeing or not? Reason as to why not would be if more files included those two headers but they don't (unless I missed something) so it's not an issue at all.