The "movieclip" library is a pure-Lua library using display.newImage(), so it's quite possible to do a version that uses display.newImageRect() instead.
The thing to keep in mind is that 2x image files use FOUR times the texture data (or more), so you can burn through texture memory much more quickly. Therefore, I think this would be useful as an optional feature, but it wouldn't be a good idea to make this mandatory.
Regarding the "sprite" library, it's one of the "built-in" libraries, which means that it's a Lua API to native C++ code, so there isn't a "sprite.lua" file, and it doesn't use display.newImage(). Using the "require" command for the built-in libraries simply means that the relevant native code is loaded at runtime. That's why you can't find the file :)
So: is it possible to have multi-resolution sprite sheets? That would require a modification to our sprite-sheet code, but the answer is "yes, in some cases".
The standard idea of a sprite-sheet is that you allocate the largest possible image area in device memory, and then pack sprite data onto it, using a lot of reference coordinates to pull data chunks from the sheet. Therefore, you can't just double the sheet, since it may already be at "maximum size" for the device.
However, there are specific hardware combinations where this could be useful. One example is that you could do a 1024x1024 sprite sheet on iPhone3GS, and a "2x" 2048x2048 sprite sheet on iPhone4 and iPad. That should actually work pretty well -- although, to be clear, this won't work today, since it's a code modification on our end. Also, results on Android may be mixed, since their hardware specs are all over the place; I don't have a comprehensive list here, but I don't think they universally support 2048 x 2048 textures in their current high-res devices.
The tradeoff with the above is, again, that you'd be using 4x the memory to get 2x the resolution. So if you try and do a sprite-intensive game entirely at "Retina Display" resolution, the amount of graphics you can use at one time will be reduced. But this is a basic limitation of mobile graphics hardware, and all developers have to deal with this, so I agree that it would be preferable for us to give our developers the choice either way.
uid: 3007 topic_id: 1361 reply_id: 5969