I am going to start a game in about 3 weeks and I would really like the game to run at least on another platform (linux, MacOS) but my team thinks that's a lot of work. I am up for it but wanted to know what are the things I should watch out for that won't port to linux (apart from Windows specific APIs like DirectXsound)?
我将在大约3周后开始游戏,我真的希望游戏至少在另一个平台(Linux,MacOS)上运行,但我的团队认为这是很多工作。我很乐意,但想知道我应该注意哪些东西不会移植到linux(除了特定于Windows的特定API,如DirectXsound)?
I've been reading online and Windows "_s" functions like sprintf_s appear to exist only on Windows; is this correct or are they implemented on linux also?
我一直在线阅读和Windows“_s”函数如sprintf_s似乎只存在于Windows上;这是正确的还是在Linux上实现的?
10 个解决方案
#1
No, the _s functions are NOT implemented in the standard gcc library. (At least, grepping the include files for 'sprintf_s' turns up nothing at all.)
不,_s函数未在标准gcc库中实现。 (至少,对'sprintf_s'的包含文件进行grepping一点都没有。)
It might be worth looking at cross platform libraries like boost and apr to do some of the heavy lifting work.
可能值得研究像boost和apr这样的跨平台库来完成一些繁重的工作。
A sample of specific things to look for:
要查找的具体事项的示例:
- Input/Output (DirectX / SDL / OpenGL)
- Win32/windows.h functionality (CreateThread, etc)
- Using windows controls on the UI
- Synchronization primitives (critical sections, events)
- Filepaths (directory separators, root names)
- Wide char implementations (16 bit on windows, 32bit on linux)
- No MFC support on linux (CString, etc)
输入/输出(DirectX / SDL / OpenGL)
Win32 / windows.h功能(CreateThread等)
在UI上使用Windows控件
同步原语(关键部分,事件)
文件路径(目录分隔符,根名称)
宽字符实现(Windows上为16位,Linux上为32位)
Linux上没有MFC支持(CString等)
#2
If I were you I would use some of the available Frameworks out there, that handle Platform independence.
如果我是你,我会使用一些可用的框架来处理平*立性。
I wrote a 3D-Game as a hobby project with a friend of mine, the server being in Java and the clients running on Windows and Linux. We ended up using Ogre as 3D-Engine and OpenAL as Sound-Engine, both platform independent and available under LGPL.
我和我的一个朋友写了一个3D游戏作为一个爱好项目,服务器是Java,客户端运行在Windows和Linux上。我们最终使用Ogre作为3D-Engine和OpenAL作为Sound-Engine,两者都是平*立的,并且可以在LGPL下使用。
The only things I really had to write separately were the whole Socket-handling, reading the config from file system and the initialization of the System. Compared to the rest of the Program, that was almost nothing.
我真正需要分别编写的唯一内容是整个Socket处理,从文件系统读取配置和系统初始化。与该计划的其他部分相比,这几乎没有。
The most time consuming will be to set up the entire project to compile under Windows and Linux (or Mac), especially if you're concentrating on one and only occasionally check the other for problems. If you have one in your team who checks regularly for these problems while they're being produced you won't have that much overhead from that as well.
最耗时的是将整个项目设置为在Windows和Linux(或Mac)下进行编译,特别是如果您专注于一个并且偶尔检查另一个问题。如果您的团队中有一个人在生产这些问题时会定期检查这些问题,那么您也不会有那么多开销。
All in all compared to the programming of the game itself, adapting it to different platforms is almost no effort, if all frameworks used are well written, platform independent systems.
总而言之,与游戏本身的编程相比,如果所有使用的框架都是编写良好的平*立系统,那么将其适应不同的平台几乎是不费力的。
#3
Try to encapsulate any non-standard extentions like DirectX, OpenGL, SDL, etc. Then you only have to rewrite those parts based on platform.
尝试封装任何非标准扩展,如DirectX,OpenGL,SDL等。然后您只需要基于平台重写这些部分。
I also would make it playable on one OS before even thinking of porting.
在考虑移植之前,我也会在一个操作系统上播放它。
#4
For the 'safe' functions: they are non-standard, and almost safe :)
对于'安全'功能:它们是非标准的,几乎是安全的:)
#5
Endianess is something look out for.
Endianess值得关注。
Endianess is the order of the bits in a byte. Some platforms are big endian while some are little endian.
Endianess是一个字节中位的顺序。有些平台是大端,有些是小端。
This can affect how cross-platform your program is. But the biggest impact this would have would be in network communications. You have to convert from one endian to another before sending or receiving a network message.
这可能会影响您的程序跨平台的方式。但这可能会对网络通信产生最大的影响。在发送或接收网络消息之前,您必须从一个端口转换为另一个端点。
#6
If you focus on gameplay, design a game, and them implement that porting should not be especially onerous. If you implement it simultaneous on several platforms it should be straight forward.
如果你专注于游戏玩法,设计游戏,他们实现移植不应该特别繁重。如果你在几个平台上同时实现它,它应该是直截了当的。
But if you focus on effects, design something that you feel is going to "blow the others out of the water," and try to paste a game idea onto them, you are doomed.
但是如果你专注于效果,设计一些你认为会“将其他人从水中吹出来”的东西,并尝试将游戏创意粘贴到它们上面,那你注定要失败。
So really it is up to you.
所以真的由你决定。
#7
Don't know much about windows-apis, but I set up a daily (or on-commit) fully automatic build-system on all platforms you want to support. If you develop something on your windows-box that doesn't work on the others, your build-system should notify you of "failed build on platform x, see logfile/attachment/whatnot for details". It'll catch a lot of cross-paltform issues. Unittests will help as well.
不太了解windows-apis,但我在你想要支持的所有平台上设置了每日(或提交)全自动构建系统。如果你在windows-box上开发了一些对其他东西不起作用的东西,你的构建系统应该通知你“在平台x上构建失败,请参阅logfile / attachment / whatnot了解详细信息”。它会遇到很多交叉问题。 Unittests也会有所帮助。
Whether or not to target multiple platforms from the start is a good idea is another question.
是否从一开始就针对多个平台是一个好主意是另一个问题。
Personally I'd start developing on another platform and then see about porting it to windows at a later time ;-)
就个人而言,我开始在另一个平台上开发,然后看看稍后将它移植到Windows上;-)
#8
Just remember that you are creating a model of game that does not depend on the details of any operating system. Your game depends on state management and algorithms which don't depend on the OS. The key is to write your game logic without dependencies to specific libraries which means a lot of encapsulation.
请记住,您正在创建一个不依赖于任何操作系统细节的游戏模型。您的游戏取决于状态管理和不依赖于操作系统的算法。关键是将您的游戏逻辑编写成没有依赖性的特定库,这意味着需要进行大量的封装。
You shouldn't call sprintf_s directly you should write an routine, class, or MACRO that can be changed based on the platform, Don't use DWORD when you can use a class or typedef that can be tailored to different platforms.
您不应该直接调用sprintf_s,您应该编写可以根据平台更改的例程,类或MACRO,当您可以使用可以针对不同平台定制的类或typedef时,请不要使用DWORD。
For instance if you where making a football game, then algorithms for throwing the ball, running, tackling, positions of the players could be done completely in standard C++ without platform dependencies. If your encapsulation was good you could dump the state of you game to a file and display it separately with a rendering program.
例如,如果你在制作足球比赛的地方,那么投球,运行,抢断,球员位置的算法可以完全用标准C ++完成,而不需要平台依赖。如果您的封装很好,您可以将游戏状态转储到文件中并使用渲染程序单独显示。
#9
If you truly want to do cross platform development easily I would suggest using one of the already built cross-platform engines like Unity or one of the Garage Games stuff like Torque Game Builder (2D).
如果您真的想轻松地进行跨平台开发,我建议使用已经构建的Unity之类的跨平台引擎之一或者像Torque Game Builder(2D)这样的Garage Games之一。
I have virtually zero experience in either so can't tell you which is better but the Torque Game builder demo couldn't get through the first tutorial without having problems and they don't answer tech support questions in their forums like they claim to do so I can say avoid them if you are a novice in game design like myself. The big thing about Garage Games was supposed to be their great support, I saw zero support and in fact only saw a bunch of, "Hey, anybody here?" posts with no answers so I guess they are pretty much giving up on supporting their products.
我几乎没有任何经验,所以不能告诉你哪个更好,但Torque Game构建器演示无法解决第一个教程而没有问题,他们没有像他们声称的那样在他们的论坛中回答技术支持问题所以如果你是像我这样的游戏设计的新手,我可以说避免它们。关于Garage Games的重要事情应该是他们的大力支持,我看到零支持,事实上只看到了一堆,“嘿,这里有人吗?”没有答案的帖子所以我猜他们几乎放弃了支持他们的产品。
#10
I'm surprised nobody mentions libSDL and OpenGL because most cross platform games were written using those libraries.
我很惊讶没有人提到libSDL和OpenGL,因为大多数跨平台游戏是使用这些库编写的。
If your game is 2D, you can use libSDL. A good example of game written using it is The Battle of Wesnoth. SDL uses DirectX on Windows, it's just a thin wrapper on it.
如果您的游戏是2D,则可以使用libSDL。使用它的游戏的一个很好的例子是Wesnoth之战。 SDL在Windows上使用DirectX,它只是一个薄的包装器。
If your game is 3D, use OpenGL. For example, Quake 3 uses that library. You can find tons of examples and documentation on it. Of course, there are many libraries that wrap OpenGL, so you don't have to do low-level stuff. Look into OGRE, Crystal Space, etc.
如果您的游戏是3D,请使用OpenGL。例如,Quake 3使用该库。你可以找到大量的例子和文档。当然,有许多包装OpenGL的库,所以你不必做低级的东西。看看OGRE,水晶空间等
As for the basic C/C++ libraries and functions compatibility, it's best you install some Linux and simply run man page for the function to see if it exists. Of you can look it up on the Internet.
至于基本的C / C ++库和函数兼容性,最好安装一些Linux并简单地运行该函数的手册页以查看它是否存在。你可以在互联网上查找。
#1
No, the _s functions are NOT implemented in the standard gcc library. (At least, grepping the include files for 'sprintf_s' turns up nothing at all.)
不,_s函数未在标准gcc库中实现。 (至少,对'sprintf_s'的包含文件进行grepping一点都没有。)
It might be worth looking at cross platform libraries like boost and apr to do some of the heavy lifting work.
可能值得研究像boost和apr这样的跨平台库来完成一些繁重的工作。
A sample of specific things to look for:
要查找的具体事项的示例:
- Input/Output (DirectX / SDL / OpenGL)
- Win32/windows.h functionality (CreateThread, etc)
- Using windows controls on the UI
- Synchronization primitives (critical sections, events)
- Filepaths (directory separators, root names)
- Wide char implementations (16 bit on windows, 32bit on linux)
- No MFC support on linux (CString, etc)
输入/输出(DirectX / SDL / OpenGL)
Win32 / windows.h功能(CreateThread等)
在UI上使用Windows控件
同步原语(关键部分,事件)
文件路径(目录分隔符,根名称)
宽字符实现(Windows上为16位,Linux上为32位)
Linux上没有MFC支持(CString等)
#2
If I were you I would use some of the available Frameworks out there, that handle Platform independence.
如果我是你,我会使用一些可用的框架来处理平*立性。
I wrote a 3D-Game as a hobby project with a friend of mine, the server being in Java and the clients running on Windows and Linux. We ended up using Ogre as 3D-Engine and OpenAL as Sound-Engine, both platform independent and available under LGPL.
我和我的一个朋友写了一个3D游戏作为一个爱好项目,服务器是Java,客户端运行在Windows和Linux上。我们最终使用Ogre作为3D-Engine和OpenAL作为Sound-Engine,两者都是平*立的,并且可以在LGPL下使用。
The only things I really had to write separately were the whole Socket-handling, reading the config from file system and the initialization of the System. Compared to the rest of the Program, that was almost nothing.
我真正需要分别编写的唯一内容是整个Socket处理,从文件系统读取配置和系统初始化。与该计划的其他部分相比,这几乎没有。
The most time consuming will be to set up the entire project to compile under Windows and Linux (or Mac), especially if you're concentrating on one and only occasionally check the other for problems. If you have one in your team who checks regularly for these problems while they're being produced you won't have that much overhead from that as well.
最耗时的是将整个项目设置为在Windows和Linux(或Mac)下进行编译,特别是如果您专注于一个并且偶尔检查另一个问题。如果您的团队中有一个人在生产这些问题时会定期检查这些问题,那么您也不会有那么多开销。
All in all compared to the programming of the game itself, adapting it to different platforms is almost no effort, if all frameworks used are well written, platform independent systems.
总而言之,与游戏本身的编程相比,如果所有使用的框架都是编写良好的平*立系统,那么将其适应不同的平台几乎是不费力的。
#3
Try to encapsulate any non-standard extentions like DirectX, OpenGL, SDL, etc. Then you only have to rewrite those parts based on platform.
尝试封装任何非标准扩展,如DirectX,OpenGL,SDL等。然后您只需要基于平台重写这些部分。
I also would make it playable on one OS before even thinking of porting.
在考虑移植之前,我也会在一个操作系统上播放它。
#4
For the 'safe' functions: they are non-standard, and almost safe :)
对于'安全'功能:它们是非标准的,几乎是安全的:)
#5
Endianess is something look out for.
Endianess值得关注。
Endianess is the order of the bits in a byte. Some platforms are big endian while some are little endian.
Endianess是一个字节中位的顺序。有些平台是大端,有些是小端。
This can affect how cross-platform your program is. But the biggest impact this would have would be in network communications. You have to convert from one endian to another before sending or receiving a network message.
这可能会影响您的程序跨平台的方式。但这可能会对网络通信产生最大的影响。在发送或接收网络消息之前,您必须从一个端口转换为另一个端点。
#6
If you focus on gameplay, design a game, and them implement that porting should not be especially onerous. If you implement it simultaneous on several platforms it should be straight forward.
如果你专注于游戏玩法,设计游戏,他们实现移植不应该特别繁重。如果你在几个平台上同时实现它,它应该是直截了当的。
But if you focus on effects, design something that you feel is going to "blow the others out of the water," and try to paste a game idea onto them, you are doomed.
但是如果你专注于效果,设计一些你认为会“将其他人从水中吹出来”的东西,并尝试将游戏创意粘贴到它们上面,那你注定要失败。
So really it is up to you.
所以真的由你决定。
#7
Don't know much about windows-apis, but I set up a daily (or on-commit) fully automatic build-system on all platforms you want to support. If you develop something on your windows-box that doesn't work on the others, your build-system should notify you of "failed build on platform x, see logfile/attachment/whatnot for details". It'll catch a lot of cross-paltform issues. Unittests will help as well.
不太了解windows-apis,但我在你想要支持的所有平台上设置了每日(或提交)全自动构建系统。如果你在windows-box上开发了一些对其他东西不起作用的东西,你的构建系统应该通知你“在平台x上构建失败,请参阅logfile / attachment / whatnot了解详细信息”。它会遇到很多交叉问题。 Unittests也会有所帮助。
Whether or not to target multiple platforms from the start is a good idea is another question.
是否从一开始就针对多个平台是一个好主意是另一个问题。
Personally I'd start developing on another platform and then see about porting it to windows at a later time ;-)
就个人而言,我开始在另一个平台上开发,然后看看稍后将它移植到Windows上;-)
#8
Just remember that you are creating a model of game that does not depend on the details of any operating system. Your game depends on state management and algorithms which don't depend on the OS. The key is to write your game logic without dependencies to specific libraries which means a lot of encapsulation.
请记住,您正在创建一个不依赖于任何操作系统细节的游戏模型。您的游戏取决于状态管理和不依赖于操作系统的算法。关键是将您的游戏逻辑编写成没有依赖性的特定库,这意味着需要进行大量的封装。
You shouldn't call sprintf_s directly you should write an routine, class, or MACRO that can be changed based on the platform, Don't use DWORD when you can use a class or typedef that can be tailored to different platforms.
您不应该直接调用sprintf_s,您应该编写可以根据平台更改的例程,类或MACRO,当您可以使用可以针对不同平台定制的类或typedef时,请不要使用DWORD。
For instance if you where making a football game, then algorithms for throwing the ball, running, tackling, positions of the players could be done completely in standard C++ without platform dependencies. If your encapsulation was good you could dump the state of you game to a file and display it separately with a rendering program.
例如,如果你在制作足球比赛的地方,那么投球,运行,抢断,球员位置的算法可以完全用标准C ++完成,而不需要平台依赖。如果您的封装很好,您可以将游戏状态转储到文件中并使用渲染程序单独显示。
#9
If you truly want to do cross platform development easily I would suggest using one of the already built cross-platform engines like Unity or one of the Garage Games stuff like Torque Game Builder (2D).
如果您真的想轻松地进行跨平台开发,我建议使用已经构建的Unity之类的跨平台引擎之一或者像Torque Game Builder(2D)这样的Garage Games之一。
I have virtually zero experience in either so can't tell you which is better but the Torque Game builder demo couldn't get through the first tutorial without having problems and they don't answer tech support questions in their forums like they claim to do so I can say avoid them if you are a novice in game design like myself. The big thing about Garage Games was supposed to be their great support, I saw zero support and in fact only saw a bunch of, "Hey, anybody here?" posts with no answers so I guess they are pretty much giving up on supporting their products.
我几乎没有任何经验,所以不能告诉你哪个更好,但Torque Game构建器演示无法解决第一个教程而没有问题,他们没有像他们声称的那样在他们的论坛中回答技术支持问题所以如果你是像我这样的游戏设计的新手,我可以说避免它们。关于Garage Games的重要事情应该是他们的大力支持,我看到零支持,事实上只看到了一堆,“嘿,这里有人吗?”没有答案的帖子所以我猜他们几乎放弃了支持他们的产品。
#10
I'm surprised nobody mentions libSDL and OpenGL because most cross platform games were written using those libraries.
我很惊讶没有人提到libSDL和OpenGL,因为大多数跨平台游戏是使用这些库编写的。
If your game is 2D, you can use libSDL. A good example of game written using it is The Battle of Wesnoth. SDL uses DirectX on Windows, it's just a thin wrapper on it.
如果您的游戏是2D,则可以使用libSDL。使用它的游戏的一个很好的例子是Wesnoth之战。 SDL在Windows上使用DirectX,它只是一个薄的包装器。
If your game is 3D, use OpenGL. For example, Quake 3 uses that library. You can find tons of examples and documentation on it. Of course, there are many libraries that wrap OpenGL, so you don't have to do low-level stuff. Look into OGRE, Crystal Space, etc.
如果您的游戏是3D,请使用OpenGL。例如,Quake 3使用该库。你可以找到大量的例子和文档。当然,有许多包装OpenGL的库,所以你不必做低级的东西。看看OGRE,水晶空间等
As for the basic C/C++ libraries and functions compatibility, it's best you install some Linux and simply run man page for the function to see if it exists. Of you can look it up on the Internet.
至于基本的C / C ++库和函数兼容性,最好安装一些Linux并简单地运行该函数的手册页以查看它是否存在。你可以在互联网上查找。