After looking through the documentation there are a lot of commands that might be interesting but I don't know how to use them or the documentation isn't as detailed and it would be interesting to see these commands in detail in some code.

For Example:

GetRawNextTouchEvent
GetRawTouchCount
GetRawTouchCurrentX
GetRawTouchCurrentY
GetRawTouchLastX
GetRawTouchLastY
GetRawTouchReleased
GetRawTouchStartX
GetRawTouchStartY
GetRawTouchTime
GetRawTouchType
GetRawTouchValue

or

Render
StepPhysics
Swap
Update

I know about Sync, but there are other commands that I have never explored and might be useful.

There are more commands, a lot more, but can TGC show us some of the tricks and commands that are not used that much?

If anyone writes more detail explanations / examples of any commands in the helpfile I would appreciate it if I could include it in the Community Guide?

They all seem pretty straight forward to me. All the commands above:

GetRawNextTouchEvent
GetRawTouchCount
GetRawTouchCurrentX
GetRawTouchCurrentY
GetRawTouchLastX
GetRawTouchLastY
GetRawTouchReleased
GetRawTouchStartX
GetRawTouchStartY
GetRawTouchTime
GetRawTouchType
GetRawTouchValue

Are related to the iOS platform, as the player for that isn't out yet you can't really test them at the moment. Once the player comes out of course it will be a different story.

Here you go nickydude,

StepPhysics() basically "steps" the physics calculations forward by a specified increment of time, said in the help file (and there's quite a lot of information there about it) that slice of time shouldn't exceed 0.1 because it basically creates problems inside the physics engine. Think of it like the step command in the for and next loop. The bigger the step the more frames you skip of the simulation. But at the same time, the less data goes into that simulation so the error gap increases.

Oh and the other three commands.

update()
render()
swap()

are all taken care of by sync()

Update(time) updates things like sprite animation and physics, it moves them along and a specified time, a bit like the stepphysics() command only with a more global and wider influence on AppGameKit objects beyond just the physics engine.

Render() is a pretty easy one, it's "rendering" the image to the backbuffer ready to be displayed to the user. The backbuffer is basically a bit of memory that stores all visual information you create. You'll come across this term a lot in 3D rendering programs as well.

Swap() brings that backbuffer to the screen so the user can see it on their monitor then destroys that data ready to be written again. This means you don't have to clear it yourself with a command like CLS which is "like, so yesteryear!" (sorry my inner Beverly Hills blonde came out there).

This is all covered in the documentation and written far better than I have here, so they are far from undocumented commands, but here's a quick example.

There's no sprites, it's just a counter and a print command so there's no need to use the Update() command at all.

do
count = count + 1
Print(count)
Render()
Swap()
loop

As you can see, it's basically just taken place of Sync().

To be honest these last 3 commands are not that useful to anyone but the most advanced coder, which goes well beyond my own abilities. I can kinda see how they would be useful in Tier 2 when pushing the engine to it's absolute limit and with specific platform SDK commands added into the mix. But all this is done for you by AppGameKit just by typing in Sync()

Do we have access to the Buffer in Tier2 so that we can draw in it before it renders?

In tier 2 you can draw sprites individually, for example



So you can combine them with "managed" sprites, ones created with agk::CreateSprite(), like so



This is really the only time you would need to use Update(), Render(), and Swap()

I'd like to see some documentation on using classes instead of wrapper functions. (like cSprite)

Is there any plan to do this?

Just as a heads up, if you have no preference I would urge the use of AppGameKit Tier 2 coding that mirrors the Tier 1 style, i.e:

agk::CreateText ( 1, "hello" );

Rather than:

agk::cText pMyText = new agk::cText;
pMyText->SetString ( "Hello" );

Not only is the first easier to read, if we added some clever auto-port system in the future to take your AppGameKit Tier 2 'orthodox' style and port it to c#, Java, e.t.c then the second style of coding would be pretty difficult to auto-port (cross-convert).

Nothing to worry about any time soon, just something to bear in mind if you are choosing which style to adopt and learn.