Mobile devices are not really up to it

Really? You mean not up to generating realtime sound? I don't see why not.

I can't remember if this is in here somewhere, but function overloading would be absolutely fantastic.

I can't remember if this is in here somewhere, but function overloading would be absolutely fantastic.

Ah yes, a brilliant suggestion!!

Overloading would be great +1

TGC proudly state \"code your game once and then deploy your game to multiple platforms\", but haven\'t really made this part simple.
Broadcasting/deployment needs a lot more simplification if they want to attract new users..
Because of AppGameKit evolvement, this part needs a whole new set of instruction/guide details, or a new thread for todays setup, but ideally the process needs to be integrated in to the editor.
Error details experienced by others, together with methods to correct are too spread out over thread(s) so are not of really much help. This is an important area, not getting very much attention.

@Juney...

but ideally the process needs to be integrated in to the editor.

It is... Assuming you have AppGameKit v2 and are using Tier 1, you can export an APK or an IPA directly from the IDE...

I used this feature (for Android) only yesterday and have successfully loaded an app to the Play Store.

@Funnel : IPA is only available if you compil with a mac, not windows .

@Funnel : IPA is only available if you compil with a mac, not windows .

Correct... But isn't the IDE available on Mac? Juney made no reference to whether he/she was using Windows or a Mac (and neither did I) So my statement is still correct

It's only possible to create an IPA on a mac. That is an Apple requirement for any development platform. Anyone developing for iOS has that bridge to cross and AppGameKit still makes it very simple in the new editor (on Mac)

It's only possible to create an IPA on a mac. That is an Apple requirement for any development platform. Anyone developing for iOS has that bridge to cross and AppGameKit still makes it very simple in the new editor (on Mac)

Maybe you shouuld tell this the guys from Ideaworks/Madewithmarmalade.com - because with their SDK you can create and sign iOS binaries on Windows (and what's even more impressive, with native C++ code).
But that's just meant as an information that it actually is possible - their SDK has a very different scope compared to AppGameKit and I'm happy both exist.

Resolution Support List-
Same as in DarkGDK you can ask the machine for a list of supported resolutions this is obviously for pc and mac apps.

Sprite Vertices Configuration
so that we could create a sprite but could change its vertices.

So you get a resolution support list (which is easy in T2) what are you going to do with it? If you are using DirectX it tells you what virtual scaling to use depending on the display capabilities.

Are you going to change the actual display? This is nowadays regarded as fairly hostile.

Knowing what the CURRENT setting is, however, can tell you your best bet is for setting the the virtual display.

Are you going to change the actual display? This is nowadays regarded as fairly hostile.

How do you mean?

I mean that altering the computer's display unless you do it in a managed way as DirectX does is nasty. But then you can't do that in T1 anyway, I guess.

I mean that altering the computer's display unless you do it in a managed way as DirectX does is nasty.

I clearly lack experience in this area as I have no idea what you mean.

We can't check if 2 UDTs are the exact same object that's disappointing. Ought to be a feature

@Nelvin & Juney
iOS is not possible without a Mac to access the keychain for signing the app. Marmalade can make test IPAs under Windows, but you can't distribute those IPAs on the App Store without a Mac:

ou can fully build, deploy and install standard Marmalade apps for iOS using a Windows PC, with no need for a Mac. This includes all stages of app signing for both development and app store submission (generating certificate requests, obtaining certificates/profiles, signing apps). However, a Mac is currently required to upload final app builds to the App Store due to the store's dependency on the Mac App Loader. A Mac is also required if you want to *build* EDK extensions for iOS. Note that a Mac is not required if you simply wish to include pre-compiled EDK extension libraries for iOS.

https://developer.madewithmarmalade.com/find-answers/faqs

AGK's new IDE packs everything up quite well, but to do final signing of an iOS or Mac app you need a Mac. Similar goes for Windows 8 / Windows store... you need Windows 8 to sign the app (though less people care because Windows apps are available via many channels).


@Clonkex, Jim & Haliop
A resolution list would be awesome. I'm not sure what Jim is talking about. Every game I've ever played on Windows has the ability to use multiple resolutions both in full screen and Windowed mode. If this is considered "hostile" the gaming industry disagrees. It doesn't seem to actually change the monitor resolution, but just the app's. I, for one, would not want to publish a Windows game without the ability to allow users to select the game's resolution. It's not cool to download an awesome game that only runs at 16x9 when your screen is 16x10 and it equally stinks when your CPU/GPU can't handle the game at a certain resolution. Users NEED to be able to alter this.

It doesn't seem to actually change the monitor resolution, but just the app's.

Actually most PC games DO change the monitor res, since most PC games run in fullscreen exclusive mode (which they do because it's the fastest mode). If you run in a window, however, it does only change the program's resolution.

Users NEED to be able to alter this.

Indeed!

I broke AppGameKit today it seems that passing a reference through a bunch of arrays then attempting to access a UDT's UDT array of UDTs (which came from an array of UDTs originally) crashes AppGameKit It reminded me though, I'd really like to see references available in every place possible (not just functions). They're immensely useful. When they work of course
Edit: Hold on, apparently the reference keyword was keeping errors from being reported. AppGameKit was crashing instead of reporting an array bounds error. (it's an impossible error though... something else must be wrong) This should probably go in a bug report somewhere but hey I had already mentioned it here

Offering different screen resolutions is obviously PC or Mac only. In windowed mode you can have anything you like that is <= the display width and height, so long as AppGameKit lets you set the window size, which it does. Since you can get the max width and height, and the aspect ratio it should be easy to provide a list and adjust the virtual resolution accordingly.

In full-screen mode AppGameKit uses the screen resolution, so you can scale accordingly.

Or am I missing the point?