I’m sure this has been thought of before, but just in case.
How about a simple port of Codea to Mac desktop? I’d hope the restrictions would be lesser there, and that sync between iPad and desktop could be an end run around import/export restraints. Maybe.
Meh… Right now we all use LoveCodify (soon to be LoveCodea). I think most of us want to keep this iPad only for now. The Mac version would be a little different and TTL would have to manage 2 versions of the app.
I’m still in favor of an iTouch version or at a minimum and iTouch screen size so that we could publish apps to that environment.
Kids have iTouch not iPads.
@Ipda41001: It’s actually quite simple to simulate that at the moment with translate() and clip().
Though with many games you could probably respond to WIDTH and HEIGHT and adjust accordingly. Given the similar aspect ratios of iPad and iPod touch, it should be fairly straight forward to make a project that runs well on both (as long as you don’t hard-code your positions, or as long as you scale your scene to fit).
As @Simeon said before, he’s almost down with the Codea viewer app. You might be intrested in that.
Wow. We answered at the exact same time.
Lightbulb moment, thanks. I’ll have to dwell on it.
touch 960-by-640-pixel resolution at 326 pixels per inch
Pad 1024-by-768-pixel resolution at 132 pixels per inch
hmm, I’ll have to dwell on it.
@Simeon mentioned it in another thread, just to taunt me. 
Love2d is the PC (cross-platform, mac win linux) equivalent for now. You can use LoveCodify to emulate some of the stuff on the ipad, so it kinda sorta works to let you run Codea code. Or you can just write programs using the Love2D API and that’s fun as well. The event loop on both is very similar - there’s a setup() and a draw() loop. Lots of example code.
I suspect - TLL correct me if I’m wrong - that the primary goal of a PC version of Codea would be to maintain 100% compatibility with the ipad version. Otherwise - well, I’m not sure the point of it when Love2D is available and free and unrestricted - but poorly suited as a desktop environment for Codea code (and getting worse as they add features)
And - if you aren’t using WIDTH and HEIGHT to scale your display in general, you run the very real risk of not working right down the line - not just with an eventual iphone/ipod player, but with the ipad3, rumored to have double the resolution in each direction (because it lets you scale old stuff at 2x and look pretty).
@Ipda41001 for the purposes of coding apps will treat an iPod touch as a 480x320 screen. Support for retina display comes from the higher resolution art assets, and while drawing actually takes place on a 960x640 buffer, to the code it looks like a 480x320 buffer.
clip(100,100,480,320)
print(HEIGHT)
This is working as intended (like for the sniper game).
And translate (100,0) keeps the HEIGHT value but draws it at with the translation.
Again, working as intended.
There are ways around it if you use a 0,0 anchor point or a WIDTH/2, HIEGHT2 anchor point but no mix and match.
BackingMode(HANDHELD) would be nice. I don’t think it has the broad need as many if the other items your been working on.
@Ipda41001 our last iOS game, Pilot Winds, is universal for iPad and iPod/iPhone. We didn’t use any hard-coded dimensions and instead simply used percentages along the width and height to layout graphical elements. It runs on both device types.
One of the main things is that you tend to have to use smaller graphical elements when designing for a small screen (buttons and indicators and font sizes are usually smaller). But in that case you can simply design for WIDTH and HEIGHT with appropriate sized elements and it will just look better when displayed on an iPod, but still work properly on an iPad.
I guess the key is you would want to preview what it looks like on iPhone? If we do it, it will probably be something like displaySize( width, height ). But I haven’t thought about the details yet.
That’s good.
@Bortels
If you did make a fully computer compatible codea, most computers don’t have a touch screen (but I guess they do have a mouse x and y), so some things would be different.
Certainly - the goal is code compatibility. Some things have mapping - a touch and a mouse click might substitute for each other. Some maybe do - the accelerometer is available on some macs (all? dunno).
the accelerometer is available on some macs (all? dunno)
AFAIK an accelerometer is used to park the hard drive heads in case of a fall in recent MacBooks but I don’t know if it is the same chip that is used in the iOS devices or accessible to developers.
Edit: Note to self- Google before you type. The accelerometer IS used in various Mac apps.
It may not be the same - but we don’t care, we don’t talk to any of that directly. I know it’s available to programs because I have a screensaver that “sloshes” the screen when you move your Mac.