SFML is portable on windows Linux and Mac.  So a game created on Windows to be ported to Mac must be compiled on that computer using portable C++ code?

Another problem/question that is more specific:

I am writing a game using Windows C++ and SFML.  Using a resource for the image seems to be possible, but I will have to alter the code when porting because this 'belongs to' Window's Visual Studio C++?  

The other option is to keep the images in a folder that would be viewable and loadable.  This I think would run on Linux and Macintosh.  It just doesn't seem to be to professional.  Any advice?

Thank you,

Josheir

just picture?

I hope you use “RGB image”, get decoding data of coded images.

Now, developing codec on different platforms.

14 hours ago, Josheir said:

So a game created on Windows to be ported to Mac must be compiled on that computer using portable C++ code?

Yes or a compiler targeting for that system. The C++ source code is the portable bit and not the .o, .lib and .exe files the compiler generates.

As for loading image files.  Agree with what has already been said.  For portability, some kind of virtual file system will help. Either use someone else's or write your own, it doesn't have to be that complicated.

The point is, in your game code you must not make assumptions about where your resource (files) originate from. Keep your reading and writing wrapped in some class.

void LoadGameInfo()
{
	CMemoryBlock* myBlock = myVirtualFileSystem.LoadFile("mydata.dat");
	..

On your PC version of the virtual file system class, it would be loading the file via fopen() / fread() calls, and on Android it would look more like  AAssetManager_open() /  AAsset_read() etc.

Also on portability, PLEASE DO NOT end up with code littered like this

#ifdef _WIN32
...
#elif __APPLE__
...
#elif __linux__
..
#elif __ANDROID__
...
#elif __IOS__
...
#endif

The code will soon become a mess and in a years time you won't understand it.  If you design your game/engine properly you can cut this type of code down to virtually none, even in low level classes like virtual files systems.

8 hours ago, desiado said:

As for loading image files.  Agree with what has already been said.  For portability, some kind of virtual file system will help. Either use someone else's or write your own, it doesn't have to be that complicated.

Agreed. I have an engine written in C++ that uses a virtual file system that I created. I created a packing program in C# that generates a custom binary format which packs images, audio, XML, and shaders (really the packing program can pack any file type). The generated file contains blocks of data identifying the name of the file and source contents.

This file can then either be embedded in the EXE, IPA, APK, etc. or it can be included alongside the deliverable and loaded at runtime (I believe in my current implementation, it is loaded at runtime.