Yeah, the volume was totally my fault on that. I tried using the new iOS 8 iPad capture to make that video and it ran me in to all kinds of stupid problems. I think I’ll stick to capping on Windows from now on, where I can easier control the volume and not have to deal with $@#@#$#ing iMovie for editing.
To answer your question, yes it can. When exporting, you select the file format, then check if you want to include the background or not.
IDraw post/video up now. Will do a companion piece of using Vectors in Codea, although it will probably be pretty short since it’s so simple.
http://www.gamefromscratch.com/post/2014/10/29/Creating-Vector-Game-Art-using-iDraw-on-iPad.aspx
Post is mostly just holding the video.
Ok, updated. Did a post on getting vectors into Codea and displaying them. Most importantly I look at benchmarking performance, with a slightly more accurate FPS counter and the results showed me a couple things.
TL;DR version. Vector and Raster performance in Codea is identical. Internally it must be rasterizing the vectors. So, from a performance perspective, which you choose to use really doesn’t matter.
I also learned that image size has a HUGE impact on sprite performance. This is why my earlier results showed such a performance difference as you add sprites to the seen. I did an Apples to Apples comparison, but… one Apple was a far bit larger than the other and that had a huge impact on performance.
Interesting post, thank you - I wonder if a neat way to deal with universal apps is to create your content as vectors and then render them to a surface (size depending on target hardware) and then blit the surfaces. A further optimisation (and I think linked to your performance issues 
) would be to create single tpage that is the max size the hardware can handle (I think it’s 4096x4096 on an retina ipad) and then render all the components and use the surface as a big sprite sheet.
I think you’ll find the slowdown will be down to changing the texture ready for blitting - state changes are about the slowest operation you can do on a GPU, minimising state changes by keeping as many images on a single surface as possible will usually have a massive impact on performance.
What type of game are you looking at creating?
@LaserGate_coder – I’m not entirely certain, nothing overly complicated. More so than anything, I’m letting the platform decide. So if the tech works, and it fits the iPad, I’m going with it. Trying to create something that generally hasn’t been covered all that much so that it’s of interest and use to other people.
There are some limiting factors, like the lack of tools that are going to lead me. For example, the lack of a tiled map editor is going to probably keep me away from doing a tiled game, 'cus frankly, I dont really feel like creating my own tiled map editor.
That said, if a tool is needed and makable, I’ll make it. I am actually finishing off a tool to solve a very specific problem… animation.
At the end of the day I am thinking its going to be a limited number of enemy single level non-tiled side scroller, like Prince of Persia… except using Mechs.
In fact, from this point on, I am going to refer to the project as Mech of Persia. I like that.
I’ve been playing around a tool for composing a sprite from subsprites, Ill post it shortly, at least the WIP it is. Truth of the matter is, the nature of Lua and iPad makes you take a “hmmm wonder if this works” approach to development. As an indirect result, I am having a hell of a lot of fun, but writing some horribad code as a result.
Then again, with self contained scripts like lua, you can actually get away with writing some fairly awful code. The joys of a sandbox. Granted, I have managed to crash Codea several time this weekend
@TechDojo In that particular example I dont think I’m actually incurring any state changes, due to reusing the same image over and over. In my particular case I dont think I am actually going to run into performance issues. One thing I am going to have to figure out though is rendering to off screen frame buffers… I have yet to see an example in Codea, and havent really looked into it yet, but if there is decent framebuffer support in there, I think I can get to the proper level of performance I need.
If there isn’t framebuffer support, I might be in for a bit of a performance challenge in the future!
@Serapth drawing to offscreen buffers is pretty simple
Buffer_Image = image(WIDTH, HEIGHT)
setContext(Buffer_Image)
--drawings from here go straight into the Buffer_Image
setContext()
-- drawings from here go back to the screen again
Yeah… That is pretty simple, thanks
I figured it’d be in there, but had guessed it would be a bit more difficult then that. Is the result inverted? I’m only really going down that road if I run into performance issues anyways.
@Serapth I’m highly interested in your animation tool so please share it. The game idea sounds pretty interesting. I’ve had success using iDraw to get cool art with relatively little work into Codea so thanks.
@Serapth - you literally just create an image of the size you want and then after the setContext() call it’s like your rendering to a little screen (0,0 in the bottom left etc). You can then use images just like sprites.
I put together an example to show how to render gradient text (see examples) and it was v.easy.
I haven’t yet tried rendering with a shader to an image - but I can’t think of a reason why it wouldn’t work.
I agree writing a tile map editor is a ballache - it would be cool for someone to create one that either syncs to dropbox or could actually output data directly in your project tab (like Spritely) it would make a fantastic edition to the examples at the top and starts to move Codea in to the same playfield as GameMaker studio with the extra tools.
Ok, some progress on the animation/posing tool. Essentially, I am attempting to recreate the workflow from iDraw, so I can compose and animate sprites in my game, dynamically. This allows me to use sprite body parts like Lego pieces.
Here is the composition and posing process in iDraw.
Now obviously this is less than ideal, as I would have to export the whole damn thing, once per frame to create an animation. So instead I have to recreate this process myself. This is VectorPoser, which recreates this functionality in Codea:
It’s nowhere near done, to be a functioning tool I still need to add/record keyframes and of course save to disk. I also want to add a few more features, like a functioning camera, scaling, selection modes and most importantly, parenting with pivoting mount points.
As this is something I’m working on well, when lounging around on my iPad, progress is slow and the code is sloppy as hell, but it’s been kinda fun. All of the code for the above is available at the link ( http://www.gamefromscratch.com/post/2014/11/05/Creating-a-Game-on-an-iPad-Building-an-Animation-Tool-in-Codea-Part-1.aspx ). It’s certainly not among the cleanest code I’ve written, but it is well commented. I also used the Cider library, will be a bit more useful in the future as I add more controls, but for now I’ve just used the IconButton class, which I had to modify.
Also as part of the process I needed an image selection control and couldn’t find one so I created it. The ImageList control is a scrollable rectangle with same sized images displayed. Should I share this as a separate code example on this site somewhere?
Hope it’s been somewhat interesting and may be useful to someone other than me.
Wow that’s impressive - iDraw just made it to the top of my “want” list
It looks like your code is trying to replicate the functionality of “Spine2D” on the ipad - now there WOULD be a tool that would be useful
Given that your coding this in lua - would it be possible to add some kind of lua scripting to actually generate parts of the animation?
Very nice, here’s an old thread that took a bone style approach to 2d sprite animation:
Consider it Spline2D Lite, Extremely Lite.
Spline is a full forward or inverse kinematic (IK) solver with deformation. Me, since I’m dealing with non organics, I’m just doing key framing with a bit of restraints. Makes the scope much more reasonable. It may still be somewhat useful for others when I’m done, who knows.
I am not sure about Lua scripting. In the past with iOS projects I’ve dealt with, Apple in their infinite ability to be annoying, denied any kind of on device compilation. So I wouldn’t be surprised that Codea doesn’t expose the Lua compiler in any way. So I doubt I could add such functionality. I would love to hear the I’m wrong and you can in fact run scripts on the device, but I think that would be against the iOS terms of service.
I still need to look into how to save the results AND actually get them out. I know I can save locally and to a project as a Lua key/value table, but not sure how I’d get the results out of this and into another project. I know worst case there are some hacks for packing data and such into images, but I don’t want to go this route.
Since Lua basically started life as a data definition language, it makes as much sense as any to export each character as a .lua file. That said, this may depend on the text exporting API that is coming in Codea 2.1 and I’m not sure how far away that is.
@spacemonkey. In a normal project, I would Totally use spline and the runtime you linked, but the premise here is to do the work 100% on the iPad ( and possibly a very small required bit in Xcode obviously ), so I don’t have access to Spline.
In all honesty, if I could use a computer I’d just do characters in fake 2D in Blender, unfortunately there are no good or even decent 3D modelling apps on IOS yet.
Then again, we set ourselves challenges to make things challenging, no?
As for exporting - I seem to recall some code floating around for exporting / importing to Dropbox.
I agree with you about Apple’s restrictions on running code - however surely by that argument Codea itself must fall foul of those restrictions (along with all the processing and python and js IDE’s that are now available).
I think you’d be ok - maybe coming up with your own scripting approach (like Hopscotch) if you were just adding extended behaviours to components, regardless of semantics it’s still pretty impressive what you have there.
Looking forward to seeing where this series goes.
@Seraph totally understand your goal, thought I’d just mention the Spline thing as outside of your goals on this project it seemed relevant to the bit you were building for others if they were interested in the output as well as your dev series. Good series by the way.
SM
@Serpath I think @Simeon made an IK solver a while back, you could try implementing that for more smooth animations.
I’ve decided that text asset feature of 2.1 is pretty essential to this project.
Since some of 2.1 seems to be iOS 8 related, I’m guessing it’s coming soon… Is it?
We can all but hope, but as usual @Simeon’s keeping quiet about that