Easy Screen Transitions (Director Alternative)

Solar2D General Questions/Discussion
#1

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
[import]uid: 10504 topic_id: 6548 reply_id: 306548[/import]

#2

Your link doesn’t appear to work! [import]uid: 2646 topic_id: 6548 reply_id: 22700[/import]

#3

Working link, please? Sounds really cool, would like to try it. [import]uid: 8782 topic_id: 6548 reply_id: 22709[/import]

#4

Thanks, got that OK now! [import]uid: 2646 topic_id: 6548 reply_id: 22729[/import]

#5

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? [import]uid: 2646 topic_id: 6548 reply_id: 22767[/import]

#6

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? [import]uid: 10504 topic_id: 6548 reply_id: 22803[/import]

#7

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) [import]uid: 8782 topic_id: 6548 reply_id: 22805[/import]

#8

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. [import]uid: 9422 topic_id: 6548 reply_id: 22907[/import]

#9

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. :slight_smile:

-John [import]uid: 29170 topic_id: 6548 reply_id: 22947[/import]

#10

Checked this out last night and it is sweet… Great job x-pressive, you guys rock! :smiley: [import]uid: 7143 topic_id: 6548 reply_id: 23234[/import]

#11

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. [import]uid: 12529 topic_id: 6548 reply_id: 23306[/import]

#12

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.

[import]uid: 10504 topic_id: 6548 reply_id: 23315[/import]

#13

Works great in Build 300, I think I’m going to use this in my next project. Thanks x-pressive! [import]uid: 8782 topic_id: 6548 reply_id: 23333[/import]

#14

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? [import]uid: 9422 topic_id: 6548 reply_id: 23395[/import]

#15

Add this to the “ChangeScene” function (or use download link above to download an updated version):

[lua] – 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[/lua]

This should give the same result on all devices (at least in the simulator). There is only a little difference when viewed as iPad, though (couldn’t figure out why yet) but it seems to be minor only.

Note that the content scale mode in your config.lua should be set to “letterBox”.
[import]uid: 10504 topic_id: 6548 reply_id: 23413[/import]

#16

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. [import]uid: 9422 topic_id: 6548 reply_id: 23474[/import]

#17

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. [import]uid: 9422 topic_id: 6548 reply_id: 23483[/import]

#18

“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.
[import]uid: 10504 topic_id: 6548 reply_id: 23609[/import]

#19

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. [import]uid: 9422 topic_id: 6548 reply_id: 23623[/import]

#20

Edit:

Ignore… i see Carlos is working on a fix hopefully.

Thanks! [import]uid: 13522 topic_id: 6548 reply_id: 23689[/import]