6677

do you know how to program? if so what language?
what are you aiming to accomplish? if its your first game then you want pong or snake or something.

web languages but they won't be of any help

HTML5 + javascript are beginning to appear here and there for game development now thanks to canvas elements.

random necro post, does no-one check thread dates anymore.

/thread

I'm yet to see one that can do it outside of OSX, even marmalade I believe needs to be running on OSX in order to get the iOS button, same for unity3d.

There are ways of developing for jailbroken iphones on windows but then your losing the app store and cutting off your market substantially plus you run the risk of bricking your phone.

Random vote down for stating a fact, wtf...

With their native code push I don't think its entirely infeasible to suggest that the "XNA Replacement" on the next gen console could well support native code with a few restrictions, maybe still requiring the indie license and using the same distribution methods, if this is the case it would also be theoretically possible for a monogame port I guess. I wonder if monogame on WP8 is possible

NVIDIA provides UDK for free and other their libraries.

NVidia have zero relation to UDK. UDK is made by Epic.




Monogame is more or less an exact clone of XNA. Porting between the 2 is usually a case of switching your using statements and your references. Plus you gain mac and linux support (and more). On supported hardware it uses SharpDX as its backend, this is a DirectX wrapper (supporting 11), otherwise it uses OpenTK as its backend which is an OpenGL wrapper.





There are excellent VB.net > C# converters out there. Any library that works with C# usually works fine with VB.net.

The XNA resources are all there, it still works. Its just they haven't updated or commented on it in eons.

Monogame is an excellent alternative (it is infact a clone)

I would no longer recommend XNA. Excellent as it is support for it seems to be slowly phasing out and platforms are limited.

Instead I would recommend monogame which is a clone of XNA (most of the classes have the exact same names, parameters and usage etc) but intended for running on the mono runtime (which again is an open source version of .net) but it runs perfectly fine on .net. Monogame under the hood is actually built using both SharpDX (very similar to slimDX, its just an alternative option) or OpenTK and can switch between the 2 without you ever noticing. As a result you gain access to every platform mono can run on:

• Windows (with either .net or mono, it really doesnt care)
• OSX (both powerPC and x86)
• Linux (all architectures with some limitations. x86 is very well supported anyway. Others may need OpenTK to be ported over, usually platforms requiring OpenGL ES)
• Android (monodroid is required)
• iOS (monotouch license required)
• Playstation VIta (some sort of license required yet again)
• BSD although I think that is an unofficial port
• Googles Native Client on any x86 system (browser technology, again its an unofficial port).

Porting between XNA and monogame is fairly seamless. Of course by backporting your project from monogame to XNA you then get windows phone 7 and xbox 360. I think windows phone 8 has been ignored by microsoft in XNA but who knows, maybe monogame will go there too?




Choosing between OpenTK/SlimDX/SharpDX and XNA/Monogame is just a case of how low level do you want to go? The prior 3 options are just direct wrappers around either OpenGL or DirectX enabling their usage from .net or mono. XNA/Monogame are much more "engine like" and already have sprite batchers etc implemented aswell as simpler sound API's, mouse and keyboard input and so on.

Google would have answered your questions here.

Unity can be programmed in either of the following:

• Unityscript. Modified form of javascript. Infact it is more or less javascript running on mono/.net. Javascript is usually used alongside HTML for writing extra functionality into web pages like rollover buttons and this very text box that I am typing this post in.
• C#. General purpose language. Increasingly popular for desktop based software.
• Boo. Pretty cool .net language with python-like syntax. Incredibly simple description would be a mix of C# and python. Also has a few features from some other languages.

Of the 3 your best off with either unityscript or C#. Most docs are in one or the other. Which you choose is upto you. If you prefer the idea of web technologies over the desktop then maybe unityscript is for you seeming as it is close to javascript. If you have interest in writing desktop programs as well though then C# might be the way forwards.

Unity is more orientated towards working in 3d. 2d can be done but they don't really offer any support for it.

Writing a game is a bad idea for a complete programming newcomer though.

Google app engine might be worth a quick glance over for cloud purposes but will limit your language choices a little. I believe the actual cloud hosted software can only be java 1.6, python 2.5 or a somewhat experimental implementation of google go.

The front end choices will probably just be the usual HTML5 + JS combo. In the google theme again I love the look of the Google Chrome Native Client but that will limit your market to those running google chrome on windows, OSX (x86/x86-64 only, not powerPC) and linux (again, x86 and x86-64 only).

Google is a programmers best friend

Does anyone know if Angrybirds used a cross-platform engine or was it native?

On android C++ and the NDK with SDL for drawing and Box2D for physics. I am not sure for other platforms. I assume the same again as C++, SDL and Box2d are all available. Only exception would be windows phone 7 which because of market restrictions must have been a C# rewrite using XNA (I believe there is also a pure C# port of Box2d somewhere which they could have used). Lua I can't find much reference to its usage but it would certainly be a quick way of defining locations of the pigs and blocks in levels and the score needed to pass a level with a certain star rating although that could also be done as part of the main C++ code.

Basically it used its own engine.

Just because it uses an engine does not mean it isn't native though. Ultimately an engine might well just be the framework and the game still compiles to 1 native executable.

Monogame is free but on iOS and android requires the respective mono licenses (monodroid and monotouch) which are $399 per year EACH.

Chances are as a game developer you will never have to touch either CUDA or OpenCL in your life.

PhysX is just NVidias physics engine. Usually it is run on the CPU unless a CUDA capable product is present (NVidia GPU's, Aeigx PPU's [later manufactured by NVidia] and the NVidia Tesla lineup). The bullet physics library can also do this with both CUDA products and OpenCL products (Again, all NVidia products with CUDA are supported under OpenCL although I think bullet puts priority on CUDA on NVidia hardware).

CUDA and OpenCL themselves are just libraries for running parallel code and maths. It just happens to be that a graphics card is the perfect environment for this although there are other options (physics processors, rare now but they are also perfect, thats just one alternate). OpenCL can run on a much broader range of hardware than CUDA but CUDA can be faster (some things OpenCL still manages to do quicker though). OpenCL can also software emulate most of the functionality it would use a GPU for but I dont think its advisable to do so.

Compute shaders I don't know much about but I believe they are just used for programming extra graphics effects in.

May I ask why you wish to program onto the GPU directly? Chances are if you have an actual reason (and know this reason etc) then you already have knowledge of the GPU surpassing most of us here which (no offense intended here) it is obvious you do do not.


The actual lettering GPU stands for Graphics Processing Unit. This shows what its intended for pretty well.
Usually it has many many many cores (hundreds on several gaming cards, my own has over 300), these cores are capable of floating point maths natively (many CPU's are not and instead have additional circuitry for that). 1 processor core can only run a single task at a time, any code you ever write will also only ever use 1 core at a time (even GPU programming I believe) unless you specifically program it to make use of all the cores.
Something like a program that just takes 2 numbers, adds them together and spits the result back out will have no benefit to being parallelised. Something like graphics where you need to be doing a million things at once will see a huge benefit.
A single GPU core isn't actually very powerful with the exception of its floating point abilities, infact it wouldn't surprise me if the primary core of some of the higher end smart phones is more powerful (although I admit, I did not go online and check that). In theory as a GPU is what is referred to as turing complete it can do anything a CPU can, in practice a GPU has no way of interfacing with things like your keyboard etc, it can only spit out video data and only when its told to. In theory linux or something could be compiled to run on a GTX560, in practise though it would be running on just one of its several hundred cores with a ridiculous amount of limitations.

Some other tasks now done on the GPU are physics/biology/chemistry simulations and certain mathematical problems on large amounts of data although per core may be slower to do on the GPU than the CPU can of course be done on 100 or more pieces of data at once unlike your CPU where you can hope to do it on 4 at most maybe.


OpenCL can be hardware accelerated on both AMD and NVidia GPU's (aswell as some other more obsure hardware) or it can be run in pure CPU mode. NVidia have their CUDA library which works on NVidia GPU's and PPU's only (PPU's are rare and I don't think NVidia actually make them any more), for some things CUDA is faster, some OpenCL is faster, NVidia's PhysX physics library can use CUDA when present. The Bullet physics library can optionally use OpenCL or CUDA when possible too. OpenCV can use OpenCL aswell.

Generally any purpose you will need hardware acceleration from yourself will have a library available. GPU programming is a highly specialised field. For the majority of this post I am ignoring programmable shader pipelines because although they are still technically programming on a GPU it isn't what you appear to be after.