Jump to content
  • Advertisement
Josheir

C++ Portability and Resource Usage (SFML)

Recommended Posts

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

Edited by Josheir

Share this post


Link to post
Share on other sites
Advertisement

C++ is generic. If you're writing code using the window's APIs then that code will need to be modified to use platform agnostic APIs or separated out and rewritten per platform you desire to support.

Regarding resources: OS-X applications have a bundling method, and basically it just uses directories. that are hidden under an application folder. Installation is usually just copying said folder (whose name is usually the name of your application) into the applications folder.

For many games, resources are packaged up into binary bundles which are frequently compressed simply to shrink download sizes and or to "pretend-encrypt" the files. For general development purposes I wouldn't bother until you're actually deciding to ship, but you should definitely be able to use said code paths during development simply for testing. It is also useful as a means of providing demos during development, as you can bundle all of the assets necessary for the demo.

Share this post


Link to post
Share on other sites

But you will need a Linux and MacOS X box/VM to compile your code on for those platforms.  Though I've not played with it, Visual Studios apparently can do all 3 these days but you need a registered Mac machine (on your network) with an Apple Developers license to do so. 

You can also place your files inside a .zip file and use something like zlib (which works on all 3 platforms) to get your art/sound/model assets out of it.

Share this post


Link to post
Share on other sites

You might consider shipping your assets using a virtual file system.  There are readily available ones out there.

There is nothing unprofessional about shipping your assets with your game.  I've played a number of AAA games that do that.

Share this post


Link to post
Share on other sites

just picture?

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

Now, developing codec on different platforms.

Share this post


Link to post
Share on other sites
1 hour ago, dream rz said:

just picture?

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

Now, developing codec on different platforms.

Ummm... What?  Sorry, your post didn't make sense in English (which I assume is not your first language).

There are plenty of libraries available that are cross platform.  stb comes to mind: https://github.com/nothings/stb

But there are plenty of others.  You do not have to develop "codec"s on different platforms, codecs typically refer to video/movie decoding anyway.  Or just picking one format (easy enough to convert them to all to one) and use it's lib (libpng, libjpeg, etc).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!