Hot answers tagged

47

There are a number of reasons why a PC port can take a while. (I apologize if I seem to be repeating myself somewhere; this is sort of written on the fly.) Adapting controls and gameplay When you're playing on a console, this alone puts certain limitations on what you can do, since all the user has is a gamepad. Just creating 1:1 mappings between keyboard ...


13

You have to keep in mind that the Xbox360 has far poorer .NET performance than your average desktop PC (and a limited subset of it too!). There are two main reasons: the Load/Hit/Store penalty (due to the architecture of the CPU/RAM/GPU) and the non-generational Garbage Collector. For GC issues, which cause 'pauses' or 'freezes' in your game during runtime,...


9

The best way is to periodically test the game in a console to check for performance problems or problematic garbage collections; otherwise you will end with a lengthy debugging and optimization session before publishing the game. And when porting to Xbox 360, check all the cases specified in the peer review evil checklist.


9

Yes, porting games between platforms is a lot of work. Typically it involves writing an abstraction layer, so game-specific code never references a DirectX or other platform-specific code directly. Instead it will direct its request to this intermediate layer. When done right, the vast majority of the game code will have no idea if it's running on DirectX ...


7

Heres your problem notice I comment out the surface = SDL_Get... it was giving some weird results. Also you forgot to create the OpenGL context. Let me know if you have any other issues. SDLWindow::SDLWindow(int width, int height, double axisLen, const std::string &caption) :m_fov(axisLen) ,m_width(0) ,m_height(0) ,m_fps(0) ,m_idxSnapshot(0) ,m_camPos(...


6

A while back I did a GDC talk on how we built Source to be cross-platform, and best practices for cross-platform development generally: "How To Go From PC to Cross Platform Development Without Killing Your Studio."


6

A simple reason is that a console has a single set of hardware that is the same per console. Your XBox, PS3 and Wii all have the same hardware as your neighbours XBox, PS3 and Wii. However your computer has a different CPU, different graphics card, different amount of RAM, in fact the whole configuration and Operating system settings, installed drivers ...


5

Porting code to a new platform takes time. Creating a nanosecond timer for Xbox 360 (I've never developed in XNA) is going to need a different implementation than the same nanosecond timer in Linux, Mac, or Windows. Now imagine you have hundreds of these types of functions that need porting, thousands if the engine is massive enough. It can easily take a ...


5

Unity compiles your app into a bunch of assembly code with a thin Objective-C layer around it for OS calls and such. Assuming you're not doing any plugin work (e.g. needing to call OS level features for things) you can publish your game without any working knowledge of Objective C. Even if you do need OS level features, there's usually a plugin available ...


5

My standard advice to anyone who asks this question (or similar) is: DON'T. You're starting out, you want to make a first game, you're making the engine yourself, by definition you have no idea what you are doing. You need to learn so so much; how to structure a game loop, how to handle timing, how to handle input, networking, sound, display, possibly ...


4

SDL is a cross-platform library, so as long as your code is cross-platform(i.e. no OS specific calls, use '/' in directories instead of '\', etc.), yes you should be able to copy and paste without too many issues. If you end up using a different compiler, it might be more or less lenient about certain things, but they are probably minor.


4

You could also try Haxe and cross compile it as an executable. There is a AS3 converter and using OpenFL you can keep using the flash API. fixel is ported as well. You still might end up in some troubles here and there but the community is active and helpful and a good source to get some quick help is their IRC Channel and Google Group.


4

Probably the easiest answer: Don't bother, instead pick what works best for you to work with now (i.e. whatever you're more proficient with. If you think you should write an engine with portability in mind ("create games, not engines!"), create a renderer abstraction layer, so you're able to plug in any back end you'd need. While most desktop systems ...


3

Direct3D 10.x and Direct3D 11.x do not support the 'legacy fixed-function' pipeline that your Direct3D 9 code is using. Preparing to move to Direct3D 10 or 11 means eliminating all fixed-function usage and moving to programmable shaders. It is also apparent from your code snippet that you are not using the state objects correctly. In Direct3D 9, you set ...


3

Convenient? Unlikely. It may seem like just a file conversion, but it's much more than that. An apk file is an application package designed to run on the Android operating system. An swf file is an animation or applet designed to run in a flash player. They're completely different technologies. Similar to asking if there's a way to convert an .exe to a .swf. ...


3

It has almost nothing to do with being hard in many cases. It just isn't a priority. They're cranking to just barely get out the door in time. Every minute difference takes time to account for. If you can release on a few consoles or the PC by a deadline, do that first, then wrap up the ports. Release early, make more money. Generally the consoles have ...


3

No one seems to mention this, but be sure to, at the very least, compile your project for the X360 every day. The Xbox only features a subset of .NET (.NET Compact Framework 3.0), missing lots of interesting stuff like Tuples, some collections, optional parameters, etc., so you will get bitten if you rely on any of them and don't realize you shouldn't until ...


3

No need to hook to HTML5 or native iOS/Android graphics functions when you have native OpenGL ES support on both platforms. On android binding native graphics Java functions to your C++ code would give you horrendous results. I think your problem can be solved with a little help from a friend... I would safely bet cocos2d-x does what you need. It is mainly ...


2

Often you can "port" a web-based application to a mobile device by just providing a mobile version of the webpage. iOS and Android both provide various mechanisms to "install" a webpage (or portable site) onto the device; iOS supports HTML5 offline storage, and Android allows you to bundle up your pages into an application bundle that is then served by a ...


2

You'll need to recompile your DLL game library after changing all the XNA references to MonoGame references. MonoGame redefines the interfaces under the same namespace but in a different assembly. It makes things easier to port once you understand whats going on, but can make errors like this slightly confusing.


2

Since the customary language for ios is objective-c and android is java, you should add to your question that you need a kit that also supports C++ across those platforms. http://www.madewithmarmalade.com/ is one, it's probably stronger than what you're looking for and it's not free... but there is a trial version. I have not tried it personally, your ...


2

Steam is possible, as long as the game is packaged into an executable. Quality of course has to be pretty strong to get there. Steam Greenlight : http://steamcommunity.com/greenlight/faq/ Online platforms : https://stackoverflow.com/questions/8026503/popular-flash-games-on-stream


2

YES. If we put cross-platform aside, I think you should use a game engine just for the basic features that many game engines provide: Object/Layer management + Level loading A Renderer for either 2D or 3D Texture management (texture groups, texture sizing, texture-atlasing) Physics Animation engine (support opacity, rotation, position, etc.. with different ...


2

Which game specifically? What engine does it run on? Is the source available? If the source isn't available then you're SOL unless you REALLY like decompiling. Chances are good the code base is C or C++ (lets hope so). That means you have to compile with the Android NDK which isn't trivial. My experiences with it have been painful. You're right you have to ...


2

None of the consoles you list use OpenGL as their native rendering API. The PS3 used to support a proprietary variant of OpenGL called PSGL but it was never the preferred API and I'm not sure it's even supported any more. To my knowledge none of the others have any kind of official support for OpenGL although you could in theory use ANGLE on Xbox 360 and ...


1

I strongly recommend Haxe + OpenFL. Haxe is a language based on ActionScript. There are a few differences but its the closest to what you know. The language manual and API reference at http://haxe.org are great resources. OpenFL is the Haxe implementation of the Flash API, you can find info on OpenFL at http://openfl.org (this is the best place to start, ...


1

You're right, there is no lighting in D3D10 unless you implement it yourself in shaders.


1

As you mention that your current game is simple I assume you are learning, or at least expanding upon other non-game related knowledge. Game engines are useful tools in industry, the games you make will work more efficiently and turn around time will be faster. My opinion is that it is far better to create your own engine if not working on a commercial ...


1

Just to round out ScrambleRK's answer, there is a more recent, OpenFl compliant version of as3hx available. You can find it here: https://github.com/openfl/as3hx As3hx is essentially an command-line tool, but it's fairly simple to use. I recently ported an API using the tool. There was some post-editing that needed to be done on the generated hx files, but ...


Only top voted, non community-wiki answers of a minimum length are eligible