It is and it isn't.
Sprites are most likely handled as OpenGL quads using a simple array of vertices, so the vertices are hard coded when creating the GL mesh. It would be possible to add a separate function for custom vertex coordinates, but how that ties in with the way AppGameKit already works is another matter.
So possible, but not supported - I'd be very happy to get some more advanced GL sprite features, custom vertex coordinates, more vertices, more dynamic features like that. For example I made a water effect a while ago that uses a simple 2D array to store the height of points then modifies or generates a mesh to suit that data. In native iOS code it was efficient and clean and pretty damn fast too - in DBPro it was achieved with vertex modification of a pre-built mesh, still fast and efficient... but in AppGameKit it would require sprite scissors, would be slow, inefficient, and probably wouldn't be able to look as nice as it does in DBPro and iOS.
So please Paul and TGC - add in support for dynamic GL sprite arrays, triangle lists hopefully and we'll show you all some cool tricks and effects and even some AppGameKit projects that don't look like every other AppGameKit project. We'd be able to make vapour trails from space ships, dynamic wave effects for water etc, wobbly sprites - heck if we could have per-vertex colouring as well then that's a whole other realm of possibilities too!
Plus the optimizations we'd be able to make to sprite draw calls would be a great help for slower devices. A whole particle system could use a single texture source and single sprite draw call - like just add to the sprites vertex array then draw it for however many indices are needed. This was one part of OpenGL that I enjoyed experimenting with, it would be a great addition to AGK/AGKv2 to allow advanced sprites like that I think. AppGameKit needs to be more than just a game centric script language with a minimal sprite engine and lackluster sound replay features.
Seriously, long-toothed TGC users are dragging AppGameKit around by the scruff of the neck, let us push the language and support us by allowing access to more internal GL stuff that is probably in place already. Less abstraction please! - OpenGL doesn't scare us one bit, give us enough access to internal data and we'll soon show it who's boss.
I am the one who knocks...
