Alternative / homage to Director (early code included) = maybe of interest?

Director Class
#1

UPDATE: Find the code here: http://pastebin.com/Gv0rqMaF (thanks to chinmay.patil for doing that!).

New features in the lastest version (0.2):

  • External custom transition libraries.

  • Custom transitions are easier to write now.

  • Major internal re-jigging of how it all works (more as an exercise than anything else!).

  • Far too much disorganised help text!

I’ve spent the last week writing my own routines to duplicate (and for my needs, improve) code libraries already available - mostly as a learning exercise.
In the case of scene/module changing, although I wrote my code from scratch, it was based heavily on Director for many areas.
Although my own code isn’t finished, I’m posting it here firstly as a way of saying ‘thank you’ to whoever wrote Director, and also to show some additional features / transitions I’ve put / am putting in, in case someone wants to roll these ideas into the director code.
Despite the thread title, I’m not setting myself up in competition with director, I just thought it might be fun to see what people think of my early efforts.

How to use:

scenes = require("scenes")

Is the minimum, but it also has an initialise() routine, which you can use to alter most of the default properties. This is the easiest way of setting the default transition time, for example, and also returns the top-level display group used by the module. For example:

scenesGroup = scenes.initialise{ fadeBG = true, transitionTime = 500, defaultTransition = "zoomBothHide" }

Anyway, here’s the things it does, possibly differently to Director:

  • Windowed usage. Pass a rectangle table { x=, y=, width=, height= } etc when you initialise and it should treat that rectangle as the visible area. Note you’ll have to manually clip the area if you plan on using transitions that go outside this area (which is most of 'em!).
  • Ability to not need a static background on each scene. This is what the fadeBG value is for. When set to true, whichever scene is behind during the transition will fade its alpha out to zero at the same time.
  • Ability to hook into 4 function calls automatically within your modules - new() which is required and must return the scene’s local group, but also wake(), sleep() and destroy(). Wake is called in the new scene when the transition has finished. Sleep() is called in the old scene when the transition begins, and destroy is called in the old scene when the transition finishes
  • Ability to not unload a scene when its finished being used. To achieve this, you must return false from the destroy() routine in the scene - this tells the code to not do anything. However, this means you are now responsible for cleaning up the group. What I do is in the destroy() function is move that scene’s local group to another, storage group (that is offscreen and invisible).
  • Prevents touch events from triggering during the transition itself. IE you can’t touch buttons etc while they are mid-transition. It does this by having a visible (but with alpha = 0) rectangle that covers the window, that swallows these events.
  • Custom transitions. You can pass a function instead of a transition name. This function will be called at the appropriate time, along with a params table containing all the information you need from the scenes module. There’s an example in the help text of the module itself.
  • Passing parameters to new(). If you do scenes.useScene(“blah”, “fade”, { wib="wob }) then the table will be passed to new() as a parameter.
  • Random parameters. Choose from any random, or just random within a group. Look in the useScene() function for individual transition names and random groups.
  • my own slight tweak to cleanGroups() (I read the thread about its problems the other day!).

There’s likely a few other things I forgot, but the code isn’t really long, and those of you familiar with director will likely have no problems getting to grips with it.

Again - this isn’t a competitor to Director, its more a homage.
Enjoy!

Barry

PS Oooh finally found the first post edit button, now why isn’t it in the same place as for all the other posts? :s

[import]uid: 46639 topic_id: 9362 reply_id: 309362[/import]

#2

I have a quick question…

Is it possible to just take the new transition types you have created in scenes, and drop them in to director?

Have you tried this? [import]uid: 5317 topic_id: 9362 reply_id: 34332[/import]

#3

Certainly its possible, and in fact shouldn’t take more than a few seconds once you work out the difference between how our code is laid out. The only problem I see immediately is that director doesn’t have the reverseSceneOrder() function my code does, so many of them won’t look right.
But, ignoring that slight issue (you could always make a director version of that function anyway), here’s how the two compare (I’ll use identical transitions - Director calls it moveFromLeft, while mine calls it scrollRight):

My code:

nextGroup.x = window.left - window.width transition.to ( currentGroup, { x = window.left + window.width, time = transitionTime } ) transition.to ( nextGroup, { x = window.left, time = transitionTime } )

And in Director:

[code]nextView.x = display.contentWidth*-1
nextView.y = 0

loadScene (newScene)

showFx = transition.to ( nextView, { x=0, time=fxTime } )
showFx = transition.to ( currView, { x=display.contentWidth, time=fxTime } )

timer.performWithDelay( fxTime+safeDelay, fxEnded )[/code]From this you can see there are several differences:

  1. My groups are called currentGroup and nextGroup. Director calls these currView and nextView respectively. What director calls fxTime I call transitionTime.
  2. Mine doesn’t need the loadScene within the transition (it is still there in my code, just elsewhere to avoid redundancy).
  3. Mine doesn’t need the timerperformWithDelay - same reason as the loadScene, it’s elsewhere.
  4. Instead of the positions being fixed values, I use my window table. However, since Director doesn’t support this, you can easily swap my window values for the director hard-coded values.
  5. Mine doesn’t need the explicit y = 0 (I set all values to defaults then within the individual transition code only over-write those that differ from these defaults).

Or to put it another way, to convert one of my transitions to director, you’d likely have to do the following:

  1. Change currentGroup to currView, nextGroup to nextView and transitionTime to fxTime.
  2. Explicitly set both x and y.
  3. Stick the loadScene( newScene ) line in.
  4. Remove window. references to hard coded values.
  5. Add the timer.perform() line.

Here’s how to convert the window. values:

window.left becomes 0
window.right and window.width become display.contentWidth
window.top becomes 0
window.bottom and window.height become display.contentHeight

I can’t say any of my transitions are particularly exciting, with the possible exception of the zoom ones. Just don’t forget that you can’t put any of the transitions into director that use reverseSceneOrder() since unless you code it in, there’s no version of this in director.

Anyway, here’s an example, that should work - its my zoomHide transition:

[code] elseif transitionType == “zoomHide” then
nextGroup.x = window.left - window.width * 1.5
nextGroup.y = window.top - window.height * 1.5
nextGroup.xScale = 4.0
nextGroup.yScale = 4.0
nextGroup.alpha = 0

transition.to( nextGroup, { x = window.left, time = transitionTime } )
transition.to( nextGroup, { y = window.top, time = transitionTime } )
transition.to( nextGroup, { xScale = 1, time = transitionTime } )
transition.to( nextGroup, { yScale = 1, time = transitionTime } )
transition.to( nextGroup, { alpha = 1, time = transitionTime } )

if fadeBG then
transition.to( currentGroup, { alpha = 0, time = transitionTime } )
end[/code]

And here it is in director:

[code]elseif effect == “zoomHide” then
nextView.x = -display.contentWidth * 1.5
nextView.y = -display.contentHeight * 1.5
nextView.xScale = 4
nextView.yScale = 4
nextView.alpha = 0

loadScene( newScene )

showFx = transition.to( nextView, { x = 0, time = fxTime } )
showFx = transition.to( nextView, { y = 0, time = fxTime } )
showFx = transition.to( nextView, { xScale = 1, time = fxTime } )
showFx = transition.to( nextView, { yScale = 1, time = fxTime } )
showFx = transition.to( nextView, { alpha = 1, time = fxTime } )

timer.performWithDelay( fxTime+safeDelay, fxEnded )[/code]which I just tested and works. Also, director has no fadeBG equivalent, so you can just ignore that bit :slight_smile: [import]uid: 46639 topic_id: 9362 reply_id: 34339[/import]

#4

Thanks rakoonic.

That might be something I will look at. [import]uid: 5317 topic_id: 9362 reply_id: 34379[/import]

#5

It’s made me think I might change how my code works into supporting external transition modules in some manner, might make porting them easier generally. [import]uid: 46639 topic_id: 9362 reply_id: 34414[/import]

#6

WOw big post…

put it in paste bin for you
http://pastebin.com/Gv0rqMaF [import]uid: 48521 topic_id: 9362 reply_id: 34545[/import]

#7

OK v0.2 of my scenes library is out. Find in this post the comments section which should detail fairly clearly how to use the more complex bits of it, and the actual code in the post after it, since I appear to have hit some sort of post-size limit.

New features are:

  • External custom transition libraries.
  • Custom transitions are easier to write now.
  • Major internal re-jigging of how it all works (more as an exercise than anything else!).
  • Far too much disorganised help text!

Find the code here: http://pastebin.com/Gv0rqMaF (thanks to chinmay.patil for doing that!).

It still works the same, IE:

scenes = require("scenes") scenes.useScene("myNextScene")

will get it up and running as long as “myNextScene” contains a new() handler that returns the display group. [import]uid: 46639 topic_id: 9362 reply_id: 34540[/import]

#8

Find the code here: http://pastebin.com/Gv0rqMaF (thanks to chinmay.patil for doing that!).

And here is a sample external transitions library:

[code]--------------------------------------------------------------
– INITIALISATION --------------------------------------------

module(…, package.seeall)

– TRANSITION DEFINITIONS ------------------------------------

– Set up custom transition (simple diagonal slide)
function diagonalSlide( currentGroup, nextGroup, transitionTime, reverseSceneOrder, window, fadeBGGroup )

nextGroup.x = window.right – Must set the nextGroup to its starting position
nextGroup.y = window.bottom – (and state if for example it must start rotated or alpha-ed)

transition.to ( currentGroup, { x = window.left - window.width, time = transitionTime } )
transition.to ( currentGroup, { y = window.bottom, time = transitionTime } )
transition.to ( nextGroup, { x = window.left, time = transitionTime } )
transition.to ( nextGroup, { y = window.top, time = transitionTime } )

end[/code]

If the above file was called myTransitions.lua, you could load it either in the initialise() function a la:

scenes.initialise{ transitionsFiles = "myTransitions" }

or do a direct load with:

scenes.loadTransitions("myTransitions")

Note that unlike loadTransitions(), initialise can accept a table instead of a single file, and it will load each one in turn, eg:

scenes.initialise{ transitionsFiles = { "transitions1", "transitions2", "transitions3" } }

[import]uid: 46639 topic_id: 9362 reply_id: 34542[/import]

#9

Not so big now, thanks to you - much appreciated!
Just wish I could remove the code from the first post now though :frowning: [import]uid: 46639 topic_id: 9362 reply_id: 34589[/import]

#10

This looks like a pretty neat alternative to director. I’m having a little trouble implementing it though. The old scene isn’t removing when a new scene is called. I tried created a destroy() function to do it but am not having any success.

Any ideas?

Thanks! [import]uid: 49205 topic_id: 9362 reply_id: 35796[/import]

#11

Could you post a simple case that replicates the problem? I’m seeing no issues here, with memory getting freed after changing scenes etc.

Of the four functions (new, wake, sleep and destroy) only new() is needed, because its what gets called to return the display group.

Once I get organised in my current project, I might try to knock up a few basic examples to see if you have problems with them.

The latest change (transitions in external files etc) aren’t rolled into my game, so I haven’t been as thorough with the bug checking as what I’m using. I’ll try to get it in in case I did something silly. [import]uid: 46639 topic_id: 9362 reply_id: 35803[/import]

#12

Ah! I found the solution. It was a pretty stupid mistake actually. I was loading my first scene with director and only changed my buttons to use scenes. It’s working perfectly now! Thanks! [import]uid: 49205 topic_id: 9362 reply_id: 35814[/import]

#13

Glad to hear it!

I’d also be interested to hear any suggestions / recommendations, and what (if anything!) made you want to try it as an alternative to Riccardo’s code. I’m sure he’d be happy to hear about ideas for improvement to Director (and we are in his sub-forum after all!).

Barry [import]uid: 46639 topic_id: 9362 reply_id: 35828[/import]

#14

Really my primary reason for checking out scenes is that I’m trying to locate a REALLY strange bug I’m having (http://developer.anscamobile.com/forum/2011/05/06/physics-body-adding-problems-video-included). I was wondering if the problem was with director.

Now that I found scenes, though, I really like the idea of custom transitions (I’ll get to that as I wrap up my game.)

Thanks again!
Awinograd [import]uid: 49205 topic_id: 9362 reply_id: 35910[/import]

#15

Ah that’s a good idea actually, swapping out between our libraries to test for bugs.

I’m using physics with transitions too, but am not going from one physics scene to another, I must admit.

One thing that strikes me as a possible problem is how and when you are creating the physics in one scene and destroying them in the other.

My suggestion at this stage would be to utilise my wake() and sleep() functions to see if this helps.

Basically, I’d make sure you pause the physics both in the new() functions of the incoming scene, and in the sleep() functions of the outgoing scene (sure it duplicates at times, but you can guarantee it gets called!).

Set up your scene and physics in new() as usual, then only unpause the physics in the wake() function (and delete the previous physics in destroy().

An alternative (or extension) might be to do the same, but instead of setting up the visuals and physics in new(), just set up the visuals, and only build the physics information in wake(), followed by unpausing the physics.

Going through my code, in a given change of scene, the functions get called in the following order:

  1. sleep() in the outgoing scene

  2. new() in the incoming scene

  3. destroy() in the outgoing scene

  4. wake() in the incoming scene

which should be the most useful order and let you track what happens and when. The first two are called within changeScene() and the last two in transitionEnd() when, naturally enough, the transitions end :slight_smile:

PS like the idea of your game, and nice mouse control to hit that jump button so quickly in the simulator!
[import]uid: 46639 topic_id: 9362 reply_id: 35925[/import]

#16

I tried implementing your other methods (wake, sleep and destroy) but they didn’t work either. I had the same issues popping up!

Well, the good (read GREAT) news is that I managed to get rid of the bug because of your help (two weeks after the fact :frowning: )! I added a transition screen so that levels aren’t being loaded one after the other. That seems to be fixing my spontaneous physics failures.

Sorry for hijacking the thread a little! But I’m sticking with scenes!
Awinograd
EDIT: Oh! And thanks for the compliments! [import]uid: 49205 topic_id: 9362 reply_id: 35941[/import]

#17

Do you have a complete example, with a few scenes, showing how you use your code?

Beyond the technical aspects, which seem to be useful, I would like to understand the impact of your approach on application structure and workflow.

Keep up the good work! [import]uid: 59054 topic_id: 9362 reply_id: 36127[/import]

#18

I was actually working on a set of simple example files, and realised I could replicate a bug* within Corona, so I’m trying to narrow that down to a very simple case that I can send to Ansca

I’ll continue with the samples after that, hopefully today.

* The bug being I can get a transition to go outside the start / end range. You may have seen print outs in the terminal window where it says it clipped a transition at the end - I’m managing it to start wrong :frowning: [import]uid: 46639 topic_id: 9362 reply_id: 36678[/import]