Sorry your browser is not supported!

Hi all,
since I'm not an AppGameKit user yet, I'm reading the docs and the forum to see if all my programming needs are satisfied by AGK.
So... I've some new questions that I haven't found an answer:

-getwritepath() returns the user directory where write to (i.e. ~Library/Application support, in OS X).
But what if I want to create a file for write, in a directory that doesn't exist yet in this path (i.e. ~Library/Application support/MyApp/dataStored.dat)... where MyApp dir doesn't exists?
How can I create? Giving all the path when I open the file to write: myFile=OpenToWrite(getwritepath()+"/myApp/dataStored.dat",0), will work?
I don't see any createDir() or similar command?

-How can I switch between fullscreen and windowed mode (in windows and mac platforms) during the game?

-Are the command key (on mac) and windows key (in... erm... windows) supported in tier 1?
I don't see the constant value for it in the keys scancodes guide...

Since apple "adverts" you to use "command+q" for quit the game, "command+f" to switch between fullscreen and window mode and store records and data in an application directory within the user's directory, I think that before points are needed in order to publish in the app store (for computers, I don't know what do you need to publish for iOS)

Thanks in advance and excuse my english and my... braindead questions
Regards

1. You cannot create directories. AppGameKit operates a sandbox to ensure it can run on any platform it encounters. When you start having access to the file system, you start opening a can of worms the more platforms you support. The first release keeps the file commands relatively simple, but if there is call for more 'safe' file commands we'll look closer at this.

2. AppGameKit apps do not target specific platform features, and instead takes a universal approach to what you want to create. To have full screen / windows mode implies you are running on a desktop, but you might be on a smart phone that has no concept of windows. We have had requests for platform specific 'raw' commands that can control platform specific elements which we're looking into. The downside to using one of these commands however is that your AppGameKit app no longer becomes universal and you cut down your potential market.

3. Command and Windows keys are supported in T2, but not T1. T1 is primarily interested in commands that are universal, so expecting a key press on a device that has no keyboard is a no no. We offer virtual buttons to act as key presses, with key stroke virtualisation where a keyboard is available.

4. Using "command+q" for quit the game and "command+f" to switch between fullscreen and window mode work on the Mac, but you have no control of this from within the AppGameKit app which remains universal code. AppGameKit apps you create will pass the Mac Store validation criteria, and we're working to ensure anything we've forgotten to deal with in this regard are remedied as a top priority. Watch out for Snake Snacker on the Mac Store soon (created entirely in AppGameKit T1).

Hi all,
If I understand correctly, is the player itself who manages switch between fullscreen/window if command+f are pressed? It's enough for me!
Regarding the file system, it's ok, the more simple and universal, the better.

Thanks for your answers, Lee.

In Windows we can play with the exposed code in Core.cpp and add full screen as default and even switch off maximise button to remove any undesired effect.

Which is GREAT!

How can we do the same on Mac, remove maximizing button and switch to fullscreen automatically?

I tried the code advocated by Mac know-how and full screen just bombed on me, so I commented out the full screen mode for the first version. If any one finds out how to get the window switching to full screen with a horrible crash and burn, let us know

can you if def out the calls to specific devices, so the same code can still be universal?

#ifdef windows then

#endif

ifdef macosx


etc etc

well i guess, though then youd have to have a output type to compile to diff devices, guess taht might be bad as well. same code but multiple output types instead of one all inclusive..