v2.0: Transitions update « cocos2d for iPhone

cocos2d for iPhone » Programming » cocos2d internals

v2.0: Transitions update

(31 posts) (10 voices)

Started 7 months ago by riq
Latest reply from toadkick

Tags:

simon a

12 Next »

riq
Key Master
Hi,

I'm planning to update the transitions for v2.0

A) API update
I've been thinking of updating the Director's Transition API for v2.0:
```
// same as v1.0
- (void) pushScene:(CCScene*) scene;
- (void) popScene;
- (void) replaceScene: (CCScene*) scene;

// new in v2.0
- (void) pushScene:(CCScene*) scene withTransition:(CCTransition*)transition;
- (void) popSceneWithTransition:(CCTransition*)transition;
- (void) replaceScene: (CCScene*) scene withTransition:(CCTransition*)transition
```
And Transition can't be instantiated with a scene.
It will make the API easier to use and also popScene will support transitions

B) Logic update
in v1.0, while you transition from one scene to another, the scenes are still running, they are live.
The idea for v2.0 is that scenes won't be able to run while they are being transitioned. An screenshot of the scene will be used for the transition.
- It will make it easier to alloc/dealloc objects
- "Flip" transitions will work as expected with scenes larger than the screen size
- Possible logic conditions with onEnterTransitionDidFinsih will be fixed.

What do you think about it ? ideas ?
Posted 7 months ago #
Duckwit
Member

Thanks Riq! I definitely think this is a step in the right direction :) I'm going to like 'popScene' supporting transitions.
When switching scene with a transition are both scenes still going to have their data allocated at the same time for a brief period?

Posted 7 months ago #
riq
Key Master

@Duckwit: the outgoing scene will be released before the incoming scene is allocated. At least that is what I want to do.

Posted 7 months ago #
abitofcode
Moderator

+1 for both, especially B

Posted 7 months ago #
slycrel
Member

Sounds like a good plan on both sides.

Posted 7 months ago #
zaaroth
Member

@riq: If the CCScene is a parameter I am guessing it must be a valid pointer beforehand. Are you planning on getting an allocator in place so the scene knows which layer to instantiate? Not sure how that would work, but it is worth discussing.

Posted 7 months ago #
riq
Key Master

@zaaroth:

Good point. Lets think about it a bit more.

Posted 7 months ago #
toadkick
Member

@riq: IMO the simplest and most versatile solution would be to pass a block that acts as a scene creator as a parameter to the push/pop/replace scene functions, and the transitions. Since 2.0 already doesn't support iOS 3.x, there are no compatibility issues with using blocks, and any other solution I can conceive of would me much more complex and require a lot of boilerplate code.

Posted 7 months ago #
skyhawk
Member

if you choose to replace pop with popWithTransition, do allow passing nil transitions to prevent using any transition.

Posted 7 months ago #
zaaroth
Member

@toadkick: That sounds feasible, I myself am not a block friendly, but it sure seems to do the trick. Blocks cant return a value, but a pointer to the pointer in which the CCScene must be set should work.

In order to accomplish what @riq said I think a screenshot of the current scene must be taken (easily done through CCRenderScene), a new scene replacing the current scene must be called (one that displays that screenshot) and then scene allocator block is used to get a CCScene and so call the transition. This way the replaceScene will ensure the old scene is taken out and as such dealloc'ed.

Seems easy to do, despite a bit odd. We could come up with other easy going methods to avoid using blocks in order to make it easier for newbies.

Posted 7 months ago #
toadkick
Member
@zaaroth: Actually, blocks can return a value. You can do anything with a block that you can do with a normal c function, and then some. Even for newcomers, in this case, it shouldn't be too hard to grok. I envision something like this:
```
CCScene* (^createScene)() = ^CCScene*()
{
	return [SomeScene scene];
};

[[CCDirector sharedDirector] replaceScene:createScene];
```
Since the syntax is a little confusing, you could even typedef the block definition, to make it a little easier to understand:
```
typedef CCScene* (^SceneCreator)(void);

SceneCreator createScene = ^CCScene*()
{
	return [SomeScene scene];
};

[[CCDirector sharedDirector] replaceScene:createScene];
```
Or of course you could just create an anonymous block inline with the function call to replaceScene, which I think is by far the easiest way:
```
[[CCDirector sharedDirector] replaceScene:^CCScene*() {
	return [SomeScene scene];
}];
```
XCode 4 provides code completion for blocks as function parameters now, so that should also alleviate some of the confusion for beginners. Not to mention that presumably there would be at least one example of it in the cocos2d tests.

Also, one huge advantage that I think I should mention to using blocks over any other approach is that it makes it trivial to create scenes with initializers that take parameters. For example:
```
[[CCDirector sharedDirector] replaceScene:^CCScene*() {
	return [SomeScene sceneWithParameter:someParameter parameter2:someOtherParameter];
}];
```
Posted 7 months ago #
riq
Key Master

@toadkick: interesting approach.

@zaaroth: Yes, we should use CCRenderTexture for the transitions. There is already one transition (CCTransitionFade) that is already using it.

Posted 7 months ago #
slycrel
Member

My first thought to zaaroth's response was "oh, you're right, we need scene pushes/pops and transitions to be wrapped in actions so we can create a CCSequence to do this". Then we could do this both at the director level as well as custom piecemeal solutions where needed.

I do like the block approach though. I'm still finding it hard to think in blocks all the time. The syntax for blocks in general seems sometimes a bit more messy than needed.

Posted 7 months ago #
zaaroth
Member

@toadkick: You are absolutely right. I guess I am one of the "newbies" that would have problems with blocks. I have never used them to return values, and didnt pay attention to examples on the block documentation to keep that possibility in mind.

@slycrel: Agreed. The syntax doesnt help at all.

Posted 7 months ago #
toadkick
Member
@zaaroth: Admittedly, the syntax for blocks can be intimidating at first. While sometimes I do wish they had chosen a less esoteric syntax, because I think it frightens people away from a very powerful concept, I understand why they did it...if you've ever used function pointers in c/c++/obj-c, you might notice that the block syntax is almost identical, except that blocks use a ^ instead of a *, for example:
```
typedef void (*aFunctionPointer)(void);
typedef void (^aBlock)(void);
```
After working in c/c++ for most of my career I guess it just seems like a natural extension, though some might consider function pointers to be somewhat advanced and esoteric as well.

I've been trying to come up with another way to implement a scene factory, and unfortunately nothing else I can come up with would be anywhere near as elegant. In this case I think it would definitely be worthwhile to use blocks, in spite of how scary they look. Using them in this way might also help people who are disinclined to use them because of their syntax become more familiar with them, to the point where they are able to "think in blocks" as @slycrel put it.

For what it's worth, in the past I've boost::function to do pretty much the same thing in c++ that is being proposed here (switch scenes/context in a game without the need for both scenes to exist at the same time). In spite of the god-awful template syntax, it actually proved to be a very elegant design pattern. And I'll say without flinching that the syntax for blocks is beautiful compared to the syntax for using templates.
Posted 7 months ago #
slycrel
Member

"I'll say without flinching that the syntax for blocks is beautiful compared to the syntax for using templates."

Hear hear! =) The best thing about obj-c is that it leaves all the compiler-time typing behind so you don't have to deal with templates and base class pointers. Blocks are far better than that, though they still have their gotchas (like block memory management). I expect that apple will try to do away with some of the more odd pieces over time (i.e. __block and the like).

Posted 7 months ago #
CJ
Moderator

@toadkick I love the idea to use a creation block for passing in the next scene :)

@riq I am actively working on a pretty big refactor of the View/Viewcontroller/Director so that we will be able to work with multiple gl views for things like external displays. I do have a question as I'm cleaning and reorganizing things... Do we need to keep this push/pop scene stack? does anyone use that?

Posted 7 months ago #
riq
Key Master

@CJ: cool!

Yes, I think many users are using the stack.

Posted 7 months ago #
CJ
Moderator

@riq can you explain a little about what people are doing with it because I've never ran into a use case for it.

Also, I'm hitting some pretty big hurdles with my refactor because you have a lot of calls to CC_CONTENT_SCALE_FACTOR() but that often has no context to report the correct scale because if you have more than one view then you don't know which scale factor to use. So I am forced to remove some of the retina display stuff you did in things like CCFileUtils and we'll have to figure out a different approach to get the files loaded appropriately.

Posted 7 months ago #
CJ
Moderator

Hmm... actually there is a fundamental flaw in the way the content scale is being used if you accept that there could be multiple views at different scales... Internally a node will never know implicitly what the destination view will be or what scale it will be at. So that complicates file loading, node creation, reparenting and probably a few more areas as well. What this means is that sizeInPixels remains constant for a given asset while the sizeInPoints will be dependent upon the view it is being displayed in.

Posted 7 months ago #
riq
Key Master

@CJ: The use case of push/pop is more or less this: users might want to push a scene (lets say the Settings scene) from different scenes (main menu, game scene, pause scene) without adding additional flow control to their games.

Regarding the multiple views: I guess that you are thinking of multiple views on iOS. Because if we support multiple views on OS X (that is the idea I was thinking of), then we don't need the CC_CONTENT_SCALE_FACTOR().
If you are thinking of iOS, what can of Application do you have in mind ? I think it would be OK to assume that all GLViews support the same resolution

Posted 7 months ago #
CJ
Moderator

I am working on iOS to support an external display with a different node hierarchy than the device.

The external screen almost always has a different resolution from the device, and a given screen can support multiple resolutions from VGA up to HD.

Some others were interested in doing this since everyone saw the new four player wireless multiplayer mode of Real Racing HD playing via airplay on an external screen from an iPad 2. http://firemint.com/real-racing-hd-for-ipad/

Posted 7 months ago #
riq
Key Master

@CJ: Ah... very interesting use case!

Posted 7 months ago #
jordo
Member

+1 for support for multiple displays... I would love to do this with our racing game...

Posted 7 months ago #
CJ
Moderator

@riq and others, can you take a look at my fork/branch of cocos2d here:
https://github.com/cjhanson/cocos2d-iphone/tree/gles20_director_viewcontroller

Please note that it is a significant departure from the past conventions. So we need to discuss how to proceed whether to continue in the new course I propose or not.
These are some issues that we need to address in order to support multiple views:
1. Use of singletons
2. Use of globals
3. Use of macros that assume a single view
4. Use of utilities that assume a single view
5. The entire approach to asset switching for retina and ipad needs to be rethought

Posted 7 months ago #
riq
Key Master

@CJ: Nice. I will play with it during the weekend.

Posted 7 months ago #
riq
Key Master

@CJ: I had almost no time to play with it during the weekend :( I will try to play with it during this week.

Posted 6 months ago #
andrew
Member

looks interesting, CJ, this will be very helpful for cocoshop and similar tools.

Posted 6 months ago #
riq
Key Master

@CJ: I played a bit during the weekend. I would need to play it a bit more to give you feedback.
BTW, Is there any "test" that compiles on your director_viewport branch ? Thanks.

Posted 6 months ago #
riq
Key Master

@CJ: Yesterday, I started a similar approach.

The funny thing is that I was working on improving the integration with UIKit, and ended doing something similar to yours.
The idea is that CCDirector is a subclass of UIViewController.
Also, TouchDispatcher, ActionManager and Scheduler are no longer singletons.

In the future, CCDirector won't be a singleton too.

https://github.com/cocos2d/cocos2d-iphone/commits/gles20-viewcontroller

Once I finish the migrating all the tests, I will merge these changes into "gles20"

Posted 5 months ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.