If you are interested, here is a quick and very straightforward way to switch between scenes in your game, including animated transitions.
It does not store any of your game objects and does not create any additional references to them (which is what confused some of our users when using Particle Candy together with Director Class).
The approach is very simple: it creates a screenshot image from your current scene. This allows your current scene to be deleted instantly (no need to keep any references to it while moving out of the screen).
The screenshot can then be animated in any way you like (flying out, zooming away, fading out etc.). The screenshot removes itself automatically once it's animation has been completed. It's really simple -check out the sample code below.
This approach should also result in a better transition performance, no matter how many objects you are using in your scene (because everything is rendered to an image, so we only need to move a single object then).
Unfortunately, screen capture is not available in the Windows Beta of the SDK yet (or is it?), but I hope it will be soon.
If you want to give it a try:
DOWNLOAD VERSION 1.0
Your link doesn't appear to work!
Working link, please? Sounds really cool, would like to try it.
Strange -here's the link again:
DOWNLOAD
When I run this with the current daily build (296) it crashes the simulator with a bus error. If I go back to the last public release (build 268) it works just fine. Very strange. Any ideas why?
We do not use the daily builds here, we're always using the latest stable release.
But since the code sample is quite short, you could comment out one code part after another to nail down whatever causes this issue.
Are you using the Mac or Windows version?
It doesn't work in Build 296 Mac, don't know about windows, although I don't think there even are daily builds for Windows (or I don't have access if there are)
This is great! Much as I've liked and used the Director class, switching over to this simpler scene transition system actually solved a couple major issues in my game that would have been a headache to deal with under Director.
I do see the same crash in the daily build, but as tempting as it is I'm trying to stay away from that beast until someone at Ansca says it's getting close to stable.
FYI...Just a cautionary note on build 296...there are some issues with it. App Store submission appears to be broken, as well as sqlite. (According to Ewing.)
See the other thread in this forum "App Store Deployment Problems". I had to use the latest stable...which is of course fine. :-)
-John
Checked this out last night and it is sweet.. Great job x-pressive, you guys rock! :D
There are a couple of issues to fix to really make this work properly:
1) calling:
CurrScene:removeSelf()
does NOT recursively remove all of the children components. If CurrScene is a complex group with lots of sub elements, you end up with memory leaks. Notice in Director that they have a function to properly recursively remove a group and it's children
2) You need a mechanism to "clean up" previous scenes before you call removeSelf. The scene might have it's own timers and stuff to remove. Again, this is something the newest version (1.2) of Director addressed that you would need to add here to make this generally useful.
Note the comment in the scene's tap listener. This is where you can call your clean up stuff before switching scene, for example. Those functions can be placed wherever you like to and can then be called before switching scenes. But this is something a developer shoud care for himself to know what's really going on then.
This is just a sample code to demonstrate another approach that does not touch any of the developer's custom objects (which is what any extension basically should try to avoid).
This is by no means a library, it's just a hint how you can use animated scene transitions in an easy and extendable way. You are free to add your own functions or tweak it in any way you like to make it fit your project. It's quite simple and can be changed or extended in no time.
You can use this sample as a quick framework to start a project, and as your project grows, this framwork can be extended in any way you like.
Works great in Build 300, I think I'm going to use this in my next project. Thanks x-pressive!
I'm integrating a scene transition system into my game based on this, and I've run into some odd behavior on devices of different resolutions, as well as in the simulator.
For example, simply run the example provided in the simulator and view as iPhone4. The image saved as a screenshot is obviously not being scaled or centered correctly for devices other than original iPhone.
In my own version everything looked great on the simulator no matter which simulated device I used, but when I tested it on real phones it only looked good on iPhone 3. On an iphone4 all the screenshots were scaled up 2x too big.
I was able to fix those problems on the devices using display.contentScaleX to get the screen pixel ratio and then scaling the screenshot by that. So now the transitions work great on both phones, but they look wrong on the simulator when viewed as an iPhone 4 (screenshots are on 50% the size they need to be.)
So, is there a bug in Corona with display.captureScreen or am I missing something? x-pressive, have you checked your example in the simulator viewed as iphone 4?
Add this to the "ChangeScene" function (or use download link above to download an updated version):
1
2
3
4
5
6
7
| -- MAKE A SCREENSHOT OF THE SCENE TO REMOVE,
-- CENTER & SCALE SCREENSHOT TO CORRECT SIZE
local Screenshot = display.captureScreen( false )
Screenshot.yScale = (display.contentHeight/ Screenshot.height)
Screenshot.xScale = Screenshot.yScale
Screenshot.x = display.contentWidth *.5
Screenshot.y = display.contentHeight*.5 |
x-pressive, your update (the link in the original post is broken, btw) looks fine on the simulator, but no good on actual iPhone 3 and 4 devices. Something is messed up with display.captureScreen.
I found the cause of at least one of the problems. Your build.settings file has orientation default set to "landscape", but config.lua has width = 320, height = 480, which is portrait. No idea why this works fine in the simulator, but it doesn't work correctly on a real phone. Setting orientation to "portrait" fixes your demo on devices.
In terms of it not looking right on Ipad it seems like the scaling of the screen capture is not taking into account the aspect ratio squeezing and stretching the occurs when setting the scale in config.lua to, say, "letterbox". I don't know how to correct for that, though. It seems like something that should be taken care of under the hood and just work, but currently doesn't. Maybe that's one for Ansca.
Testing this is all complicated by the fact that things can look fine in the simulator but not function identically on actual devices. Once again, I put my plea in to Ansca to test features fully on REAL devices they purport to support.
"Your build.settings file has orientation default set to "landscape", but config.lua has width = 320, height = 480, which is portrait."
No, this should be correct. According to the docs, content width and height in config.lua are the original width and height in *portrait orientation*, so it shouldn't be neccessary to change this.
@ANSCA: could you please review this code (see link above)? The screenshot created should, when put to the center of the screen, look *exactly* like the screen's current content. The results should be the same on both, simulator and all supported devices.
This is what any application (take a drawing app, for example) assumes when using the generated graphic on screen.
I saw in another thread that there's a known bug where the screenshot always generates a portrait image on a device even if the screen is in landscape. Obviously not desired behavior, and Carlos himself is apparently on the case.
The images not being quite right even in portrait mode if the device is, say, an iPad is probably another bug. I hope they both get fixed soon, as well as the anomalies between the simulator vs. the actual devices.
Edit:
Ignore.. i see Carlos is working on a fix hopefully.
Thanks!
Excellent!
Now this is what I'm talking about.
Excellent out-of-the-box thinking x-pressive!
EDIT:
Recursive cleaning is no longer needed in your code. This was added to the SDK
http://developer.anscamobile.com/release/2011/318
Question though, why do you have to make the Scenes global? They can't be local?
@x-pressive.com .. Thank you nice & clean code.
Can you help me to build clean approach for physics uses with screen transitions?
Especially when each scenes include there own physics and animations.
Thank you in advanced.
Admin6
Yes, this is fantastic just like their Particle Candy and Text Candy! I tested the texture memory in my code and it looks like this methods removes everything after each scene. And it's so easy to work with multiple scenes.
To clean physics and animations like sprite sheets and bodies, just be sure to add then to a group (the code uses "sceneGroup"). If they are in sceneGroup they will be removed "automatically" by the code when you change scenes. (I've also made other groups with physics and animation and then simply added those groups to sceneGroup right before the change screen code.) Also be sure to remove all listeners and kill particles before changing scenes.
Do you have specific physics and animations that aren't getting cleaned when sceneGroup is passed back to main?
views:1894 update：2011/10/1 9:04:19