Porting to which gaming platforms? [closed] - cross-platform

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I'm developing a pretty portable indie game engine and also a "demo" game to go with that. In the future I would however like to make a more comprehensive game to deploy on some different platforms. The details on the future game is less important, I'm more into the "how" than the "what" -- genre and content is irrelevant to me.
So what target platform would you recommend? And what cheap features (which rocked immensely) have you successfully developed for that platform? Please keep cost-effectiveness in mind, since my budget won't allow for purchasing SDKs with price tag of 10k U$.
Edit: I am really interested in what cheap features you have successfully developed for a certain platform. E.g. "I made this awesome two-finger-touch-input-control-method-for-a-retro-type-this-and-that-game for iPod in no time and it rocked -- I can really recommend that platform/approach!"

Since your budget doesn't allow purchasing mult-thousand dollar dev kits, your options are a bit limited - Playstation, Wii, and native XBox development are out.
I'd recommend Windows PC and XBox 360 using XNA Game Studio. XNA is free and runs on both of those platforms. It also has a good dev following, and there are lots of blogs and websites with info, tips and tricks, and samples. You can get started athttp://creators.xna.com.

PC - Free SDKs :)

PC, Linux, Mac, Iphone, XNA for Xbox 360, and Nintendo DS and Sony PSP homebrew are all very interesting targets. It's a fun challenge writing an engine that can work for all of those targets, but it's achievable.
If you abstract things well enough that you can hit all of those targets, extending it to something commercial like say... WiiWare in the future wouldn't be too big of a deal.

This doesn't help you but is worth mentioning: World of Goo made a big splash and was released for Mac, Windows, Linux and even Wii. Allegedly they used something called the Experimental Gameplay Project but it appears not to have been released yet.

you could also make your game engine cross platform that way you are able to develop for linux and windows at the same time. and if you are using your demo engine for a future position at a game company is a great achievement under your belt.

If you're wanting to consider development on the Wii/PS/etc. consoles that Michael notes are probably out of your price range, consider the homebrew development kits. They aren't supported or endorsed, but as far as getting to work with the technologies, they might help you decide whether you want to use those SDKs in future.
I hope that whatever project you are starting on works out well!

I think the question of "what" is VERY relevant in choosing a platform, since the platform has a major impact on who will be exposed to your game, and how it will be played.
Are you developing a game intended for multiple people sitting around the screen, ex. a trivia game, fighting game, sports game, etc? Then you probably want to be looking at a console like the 360. Are you looking for something a bit deeper? Dwarf Fortress, or the next great hex-based wargame? You probably want to go PC. A shooter? Something with a mouse. PC again. A flight sim that requires a thousand different buttons? Something with a keyboard, like the PC again. Are you building a simple Popcap-style puzzle game? you might look at an SDK for some kind of handheld device.
Tell us what you want to build and we can recommend a platform
edit: if it was me, PC would be my default platform no matter what

If you want to develop for PCs, may I suggest the Simple DirectMedia Layer (SDL)?
It is a cross-platform (Linux, Windows, Mac (we need more games, please!), BSD, and others that no one cares about) library for developing graphics that is well-tailored for games.
The best game of all time (at least, in my opinion) is written with it.
It is free and open-source, but released under a permissive license, so you can do whatever you want with code you write on top of it. You can even dig into its internals and see how you might go about porting it to a platform SDL doesn't support, should you choose to do so.

Related

TideSDK tutorial? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Is there an actual TideSDK tutorial that is not a remnant of the old Titanium Desktop? I can't seem to locate any clear tutorial that outlines coding to testing to building on TideSDK. Most of the things I've seen are intended to be used for the late Titanium Desktop. If anyone can outline the app creation process of TideSDK, it would be more than welcome. (E.g. Code, compile test? / Code, test, compile?)
Downloads from the TideSDK.org site currently provide Titanium Desktop 1.2.0.RC4 in the interim while the TideSDK Team continues to prepare for the upcoming 1.3.0-beta release (that is expected quite soon). Therefore, the legacy documentation from Appcelerator can still be used for getting you started on your desktop projects today. If you run into any issues there are friendly people on our mailing list to help. The only change in the API for 1.3.0 will be the change in the namespace from 'Titanium' to 'Ti'. Please consider joining the TideSDK mailing list https://groups.google.com/forum/#!forum/tidesdk for assistance or follow us on Twitter http://twitter.com/tidesdk to keep up to date on TideSDK news and announcements.
Keep in mind we've been working through a transition with the legacy code and materials. It is a significant effort to assemble a capable and dedicated team, work through the complex code base, set up continuous integration infrastructure and organize the efforts the team is currently engaged in. Our repository on Github has grown from a couple of repositories to 48 over the past few months. The team is continuing to clean and organize the code that we inherited from Appcelerator so that it is possible to build upon it for the future. We are also striving to become a non profit organization as funding to support the team of 16 programmers, developers and UI designers and for the infrastructure we need for such the project. This is an important key to our success for the future.
The TideSDK team has been putting substantial effort into high quality documentation under the direction of Christian Engel, our Developer Education Lead, in anticipation of the upcoming release. TideSDK's documentation consists of API docs together with a series of Guides. A Guide is focused on a particular topic. In some cases, Guides serve as focused tutorials. To view the documentation under development, visit the brand new tidesdk.org site (launched at the end of August 2012) and click on the docs button. In the short term, the effort has been on API docs and code examples. This effort will shift to Guides quite soon.
No new features will be added for the 1.3.0-beta release but it will provide updates to the underlying libraries. This will enable the SDK to compile and be used on OSX Lion, OSX Mountain Lion, Ubuntu 12.04 and Windows 7 and 8. Scripting language versions are being brought up to date also. Perhaps the most significant thing it will upgrade the WebKit to the lastest available. This will mean the most current HTML5 support available.
TideSDK-1.3.1-beta is available. Please use this the most recent version of TideSDK found here
http://tidesdk.org
and refer to the Getting Started Guide located at:
http://tidesdk.multipart.net/docs/user-dev/generated/#!/guide/getting_started

Rapid application development for Nokia E5 (Symbian S60 v3)

I often need simple personal apps on my phone and I'd like to make them. I know some programming (C++, Delphi, some Java, MATLAB, Visual Basic). I don't have any idea about where to start, what can I do, how the issue of "app signing" can impact on this.
One app should help to manage links between book pages, basically it has to handle a small database in which I can add books (title, ID) and linked pages (couples of numbers). The database must be obviously persistent.
The other app should let me program a number of time counters. I don't need persistence between app startups.
I tried Qt Creator, but let alone some problems about installation, it looks like it's made for S60 v5. I don't know where to start. I used to make small utilities for my computer in Delphi, which saved me much time; now that I have a small portable PC like the E5, it could be very useful to have, for example, a portable random number generator, or similar simple apps for personal use.
Someone please give me a kick-start!
Update: I've managed to make the timers application in J2ME, it took a week of investigation (1-2 hours a day)
I did software development for Symbian C++ for more then 6 years. I stopped it something like a year ago when Nokia declared that it is going to kill it. Symbian did not became never popular between application developers because it is EXTREMLY complicated to start developing on it. It will take long-long weeks, maybe months to get running something own for the first time. And that time maybe there will be no new Symbian devices sold... you better invest your time in something that has more future.
Qt is good, qt is MUCH easier to start with and the knowledge you gain you can use also for software development for desktop (Windows, OS-X, linux crossplatform) and other embedded (linux) devices. In one word it has some future.
Qt applications run also on 3.2 devices, just you will have to install the Qt runtime on your phone. You also don't have to use the latest SDK but 1.1.2, this has support for older platforms.
If you want to develop only for your own, you can create a "developer certificate" for free that you can use to sign your applications - they will install only on your phones (you have to specify the IMEI of the phone). You can find more info about signing at http://www.symbiansigned.com.
Take a look here: http://www.developer.nokia.com/Community/Wiki/Category:Symbian
There's a lot of information regarding development options available for S60.
I suggest you take a closer look at J2ME, reasons being:
J2ME is a mature & thriving language with a lot of documentation and examples available.
The midlets (apps) you produce can also be installed on S40 devices. S40 is currently the world's most widely used mobile phone platform.

Qt4.5 vs Cocoa for native Mac UI

I've been developing for Windows and *nix platforms for quite some time, and am looking to move into Mac development. I am tossing up between using ObjC/Cocoa and C++/Qt4.5.
The C++/moc semantics make more sense to me, and improving knowledge in Qt seems like a sensible thing to do given that you end up with a skill set that covers more platforms.
Am I likely to handicap my applications by skipping Cocoa?
The sample Qt applications look pretty Mac-native to me, but they are quite simple so potentially don't tell the whole story. Are there other pros to the Xcode way that Qt doesn't have, such as packaging, deployment, etc.?
Here's an easy way to answer it:
If you were developing a Windows app with .NET or MFC, would you handicap your applications by using Qt? If the answer to that is yes, then the situation is likely to be the same on the Mac.
A few negatives I can think of off the top of my head:
Licensing
Qt apps, while good, are not completely a native UI experience and there's things a native UI designer can do in Cocoa which boggle the mind. While I can't be sure that all the same functionality isn't available in Qt, I doubt it.
Qt is always a little behind. If Microsoft or Apple come out with a great new technology, you have to wait for the Qt developers to update Qt.
However, with all that said, only you can determine the business value of using Qt. If you think cross-platform development is going to be a major part of your development, then Qt might be worth it, despite the issues mentioned.
Ask yourself: how many of the best Mac applications that you know of use Qt instead of native Cocoa?
For our robotic systems, we originally wrote our control software in C++ using the cross-platform wxWidgets library (we avoided Qt due to some licensing concerns), because we felt that we had to target Windows, Linux, and Mac platforms for our end users. This is what we shipped for over a year until I started tinkering with Cocoa.
Right away, the thing that most impressed me was how quickly you could develop using Cocoa. Eventually, we decided to drop support for Linux and Windows and rewrite our entire control applications in Cocoa. What had taken us years to put together in C++ required only three months to completely reimplement in Cocoa.
Aside from the "lowest common denominator" interface issues that others have pointed out, the rapid development allowed by Cocoa has become a competitive advantage for our company. Our software has advanced far more quickly since our conversion to Cocoa, and it has allowed us as a new company with one developer to pull even with 10-year-old competitors that have 20-man development teams. This appears to be a common story in the Mac development space, where you see a lot of small teams who are able to create products that compete with those of much larger companies.
As a final note, using Cocoa gives you the ability to stay on top of the new APIs Apple is continually rolling out. We're now working on a new control interface that will make heavy use of Core Animation, something that would be painful to deal with using Qt.
I'm currently developing both with QT (actually PyQT, but it makes no difference to your question) and native Cocoa app. For me it's no brainer, I'd chose Cocoa. It's really worth time to explore Cocoa in general, there are many great concepts within the Cocoa framework, and Objective-C 2.0 as well.
I'd use Qt if you want this to be a crossplatform application.
You can have a look at the QMacCocoaViewContainer class. It acts as some kind of wrapper for generic Cocoa views, so you can also have Cocoa elements which are not officially supported by Qt.
Of course this means learning a little about Cocoa and Objective C and how a Cocoa UI would need to look like. But if you already know Qt well and if it’s not like your application is all and only about the GUI this could be a good way to go.
And don’t forget about the QMacStyle::WidgetSizePolicy or you won’t understand why your tables come out so huge.
Obviously, the best option is to use a cross platform suite that supports native widgets.
With QT4 you can build your base user interface. Then just add native support for your specific target platform.
Sure, Cocoa has a lot of fancy stuff (and you can still use them trough QT4), but let me be clear. I see a lot of fancy Apps on the AppStore, pretty ones, but most of then are just crap, expensive.. what ever. I really missed my Kate text editor, my okular viewer, my krita drawing software... those are just better than the commercial and expensive alternatives and are free. so i just tweak the source code a little bit too have a REAL native and great experience.
What if i have to use a linux app on my main computer with is a mac os x? or windows? or whatever? only?
For example, why on earth i have to buy a expensive ,fancy but far less featured image editor software for my mac like pixelmator when i can use a full featured real image manipulation software like Gimp? YES Gimp is gtk2 based which is a pain on any platform, specially on Mac because is really ugly. Gimp should be ported to QT4. Inkscape should be ported to QT4 too, and it would feel so great.
Is so simple to do.. gosh!
http://doc.qt.nokia.com/4.7-snapshot/demos-macmainwindow.html
Even you can add support for the the new native lion fullscreen feature, unified title and toolbar menus, etc
I , as a user, i really care about efficient, featured, good and cross platform apps, i don't really care about developer's convenience or laziness .
I do a lot of cross-platform development (Mac, Windows, Linux), and for some projects use Qt. It is a fine framework, and provides a rich class library. If you need to deploy on multiple platforms, cannot afford to spend the time/effort on platform-specific front-ends, or the "generic" support for each platform is sufficiently good, then use Qt.
However, Qt inevitably suffers in some ways from the lowest common denominator syndrome, and sometimes does not feel quite native enough. There are also certain features that are either difficult to support, or are simply not provided in the Qt libraries. So if you can afford the time and effort, or your app really demands the attention to detail and fit & finish, then developing separate front-ends may be worth it.
In either case, you ought to be writing your back-end (aka domain) code in a platform-neutral and front-end neutral manner. This way, the front-end is easily replaced, or modified between platforms.
You could always start with a Qt front-end and go for a quick time to market, then develop a native front-end down the line.
In practice, I've noticed that a Qt app on Windows looks most "native", while on Mac there are certain subtle telltale signs that make it look/feel not quite right. And Mac users tend to have much higher expectations when it comes to UI/UX!
Since posting this, i've been learning the Cocoa / Objective-C way, and have been quite impressed. Despite what I initially thought was quite a quirky syntax, Objc appears to be a very effective language for implementing UI code, and the XCode sugar - things like Core Data and bindings - make short work of all of the boring bits.
I spent a while with the QT examples and documentation before digging into cocoa, and tend to agree with what has been said above w.r.t being slightly behind the curve and less 'aqua-ish' - albeit from a fairly trivial inspection. If I absolutely had to be build a cross-platform app i'd probably use QT rather than trying to separate out the UI code, as it seems like it would provide close-enough visuals, but for mac only purposes, Cocoa seems like a definite win.
Thanks all for your responses, they've all been very helpful!
DO NOT use Qt for a Mac app. You will get no hardware acceleration for 2D rendering, and you will not be able to deliver ADA compliance.
Depending on what kind of apps you want to write, another contender is REALbasic now called Xojo.
The move from C++ is pretty easy (I have 15 years C++ experience) and the framework and IDE extremely productive. You have the added bonus of being able to deploy to Linux and Windows with trivial effort. Their framework compiles to native code and uses native widgets so you don't have an emulated look and feel.
The big reason for learning Cocoa and coding in Objective-C is if you want to hone your iPhone skills or are chasing a really fancy user experience. If you wanted to rival the cutting edge of WPF development then I'd recommend Cocoa.

cross platform development [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have questions on true cross platform development and if it is possible to use ONE platform to develop software.
I have a few applications that I write that work on OS X, Windows and Linux. They all use native platform toolkits with some shared source across platforms. I have to boot to each platform, checkout, compile, etc.
I have in the past tried GUI toolkits like QT (I bought a commercial license for Win, mac, Linus, but very expensive and paying it year after year became hard). I have tried WxWidgets, development moves slow.
So what I am thinking about is there a way to run a single platform and cross compile for other platforms so I can build my products from a single platform.
I favor OS X, is there a way to write apps for OS X, Windows, Linux from OS X where I just need to test on each platform respectively. I have found information on cross compilers, stub compiling, etc, etc.
Does anyone have any thoughts? Is this even possible? Would someone make a killing creating such a beast?
In my company, we use the Mozilla Framework to develop cross platform dictionary products. These applications are based on the Gecko/Necko Browser and most of the development is done via Javascript, HTML, CSS, XSL, XUL,... Of course, our homebrew Search engine had to be cross compiled to the three platforms (with some other code which was first done in JS and then ported to moz' C++ for speed reasons).
In the end, we have a reasonnably cross-platform solution: Our developers mostly work like power web-developers (think client and server side at the same time). Because the Gecko is the same on the three platform, we know it will predictably look and behave the same way (except when there are bugs, but the platform is now quite mature on this point of view).
Our R&D knows how to port slow javascript code to rather quick portable C++ code (you do Mozilla code using the NSPR library, a cross-platform lib). Testing has always to be done on the three platform however, although with time and experience, you get to know what will break where (Font support, Audio support, Flash Support)...
Today, you should probably have a look at XULRunner which is really the Mozilla without any real browser interface (in 2002, we had to dismantle the Mozilla Browser to repaint it in our first product colour). Of course, it works well for simple applications but if you wish to make OpenGL, 3D Audio and other nifty things, XULRunner will appear too limited.
I believe Blizzard has some cross-platform framework for that kind of thing... :)
Good luck!
Pierre.
Trying to develop applications on a single platform that will be used on many platforms isn't a good approach. At best you'll make applications which feel alien to users of the platforms that you didn't develop for.
More likely, you'll run into subtle compatibility problems in areas which you never forsaw. Java is probably the best way to go if you want to go down this route. Cross compiling will lead to autogenerated code that will be a nightmare to debug and maintain.
Certainly, you may be able to use tools for porting in some cases, but I don't think that this is a problem that you can just provide an automated solution for in general.
Well, to be honest, the only guaranteed way to build an app to be cross platform in one go is to use Java, but it requires a rather large runtime to be installed first.
However, if that's not an option, I would recommend keeping an eye on recent developments in Qt - it is now available (or should be soon) under the LGPL, which presumably means you don't need to pay for it anymore. Using GCC with Qt, I've found, works perfectly when cross-compiling on different platforms, as long as you only use Qt's classes/code/objects and make sure that any non-Qt code you create or use is capable of being compiled cross-platform.
You don't mention any specific programming language (but I'm guessing C or C++ because of the GUI toolkits), so it's kinda hard to give a good answer to what you are actually asking.
If you want "true" cross platform, I would first consider if it is possible to solve your problem using a language that is less platform bound. Python, Java and plenty of others allow you to write on one platform, and run on many.
If you still want to use C/C++, GCC gives you the option of cross-compiling, and if you combine that with QT (which will soon be available under the LGPL) you should be able to get something working.
Java has tried to do the write once, run anywhere. It works well in some situations, but there are too many "unique" things in an OS. GCC provided the ability to cross-compile applications, but you run into the same sort of problems. The code will just have better performance. The RIA approach seems to work, but it doesn't feel like a native application.
Even using a cross platform GUI toolkit will not remove all your cross platform problems. There's more to an app than GUI, after all. Cross compiling will never be able to catch all the issues that a native build will catch, either. If you're going to support multiple platforms, you're going to have to at least test on each platform. But hopefully you can perform native builds with all warnings turned on, in addition to testing.
In the past few months, I found a few great videos exploring this topic of cross platform development. I hope you find them useful as well.
QTCreator
http://www.youtube.com/watch?v=aYiPvM7ZRHA&feature=channel
FlexBuilder
http://www.youtube.com/watch?v=_O_xDXRsh3Y&feature=channel
Mono / MonoDevelop
http://www.youtube.com/watch?v=U6VG_Z0aRek
I've personally had success using Silverlight / MacOS X
http://screencast.com/t/if8xenkt
RealBasic
http://www.youtube.com/watch?v=GWipoBeKSRk
For Cross Platform Development you can use Phone Gap, Appcelerator (Titanium), Corona... This all provides a framework based on JavaScript and finally able to run on different platforms. What I am using is Titanium for Mobile Development which allows us to develop applications with Native Codes.... (which is very good advantage). Phone Gap is giving a web app which is not native in general... This softwares are used for development of cross platform supports... with support on Windows, Linux and Mac OS.
Based upon my personal experience, I believe you should adopt Java: you will avoid many headaches.
You develop in whatever platform you like and you deploy in all other platforms with no need of compiling for each target platform, as you mentioned.
For example, I develop under linux, I hit "compile" only once and the resulting file is ready to be run anywhere (windows, mac, solaris, z/OS, you name it). A double click will run it on any platform (Java runtime must me installed, but most users have it installed already and if not, it's a matter of downloading, installing, "Next>", "Next>", "OK").
If you choose the "Java Web Start" deployment method, it gets even easier: the user just clicks the launch button on a webpage and the application runs (if the proper JVM is installed according to what specified in the JNLP descriptor) or the user gets redirected to the Java download page (if no suitable JVM is found).
GUI development (with Swing toolkit) is easy and powerful, especially if you use the right tool (i.e. Netbeans IDE).

Developing for iPhone on a PC? [duplicate]

This question already exists:
Closed 11 years ago.
Possible Duplicate:
iPhone development on Windows
Is it possible to create iPhone apps using a PC? I'm running windows vista and I want to learn objective-c, what better way can you be motivated then the potential to create something that someone, somewhere might use.
Are there any hacks that allow would allow me to make the apps?
Unfortunately this is not supported. Developing for the iPhone requires Xcode and Apple's gcc tool chain, and it is only supported on Intel Mac OS X (although some have gotten it to work on PPC Mac OS X).
NilObject is right that you can only develop for the iPhone officially on a recent (last few years) Mac with OS X.
That said, Objective-C isn't tied to the iPhone. You can write programs for your PC in Objective-C, which would give you experience without needing the iPhone and Mac. Objective-C is a standard part of the GNU Compiler Collection (GCC). It's rather easy to install with Cygwin.
If you really want to make iPhone applications, you should consider a Mac. You'll get all sorts of experience and can also program for OS X then. Since laptops were just released, many people are selling their previous models because they have upgraded. If you can find an old Intel chip based Mac Mini, it won't cost you much at all (a few hundred), but it won't be fast. The recent Minis haven't been updated in a very long time and are not a very good value anymore for their new price (in my opinion), but they may be available cheap too.
actually, there's an unofficial toolchain that works in windows and linux. you'll need cygwin installed on your pc to be able to work with it in windows.
here's a link to the basic setup: link
though this will not allow you to publish to the AppStore, it's just a good way to mess around with the SDK. Also, whenever Apple updates the iPhone firmware, you'll need to find/wait for the updated toolchain or do some hacking of your own to get the updates headers, etc...
Don't bother. I had a hackintosh and while it worked, Apple can (and does) regularly update the SDK's minimum platform requirement, which means your hackintosh won't be able to keep pace with the new cool features in the SDK, since Kalyway and whoever else need time to reverse engineer kexts or whatever to figure out the new OS.
If you're serious about iPhone, get a Mac. You could probably find a first gen Mac mini (intel) for a couple hundred bucks. Or spring for a macbook and be psyched. The new ones are awfully nice.
Lucas Aardvark wrote:
I am going to get a mac. Just gotta save up a little money ;-)
Although I thoroughly agree with the consensus: get a Mac, I just wanted to add a little based on this comment you left:
If you are planning to enter the iPhone arena to do one of those Cinderella ten-million downloads at a buck a pop stories you hear about, you'll need a killer app, something new and exciting. Good luck with that; I'm not gonna share my ideas with you, 'cause I'm trying to do the same. :)
That said, I'm in the same boat as you -- I don't have the extra green to buy a Mac -- so I will share some general advice that might help.
Rather than enter the iPhone arena, I've been looking into leveraging my Java skills on the Android phone first. Once I make a few bucks doing that, I'll buy a Mac and learn Objective-C and port my program(s) over. Since Android uses Java and is free/open source, I'm only out the twenty-five bucks to create a publisher account; I can do the rest with Eclipse on any platform I have.
I don't know if it will help you much, but it might be a more cost-effective way to write your Cinderella story. :)