cocos2d for iPhone

A fast, easy to use, free, and community supported 2D game engine

1. 

   mryan
   Member

   In this topic, for the purpose of clarity, the term "TouchBegan" will refer to the event caused by a user either touching a GUI element or depressing the mouse button over a GUI element. The term "TouchEnded" will likewise refer to the user ending the touch or releasing the mouse button.

   In most OSs (Windows, OS X, iPhone OS), a button's active or hover state is triggered with TouchBegan, but the button isn't actually activated until it also receives TouchEnded. Also, if the mouse or touch is moved off the button after TouchBegan, but before TouchEnded, the button's hover state is disabled, and the user can safely release the touch without activating either the button initially pressed or any other GUI element (TouchCancelled). Prior to TouchEnded, dragging over any GUI element other than the one originally pressed will do nothing, and no hover state will be triggered. Finally, the user can drag the touch back to the original button, which re-triggers hover, and when TouchEnded is received the button will be activated.

   This behavior can be demonstrated in Windows GUI applications, in OS X (such as the System Preferences panel), and on the iPhone by pressing down on the dock icons. On the iPhone, press down on Safari (or another dock icon), and quickly move back and forth between it and an adjacent icon. The Safari hover will be disabled when the touch is dragged off it, and the adjacent icon hover event never triggers. You can safely release the touch while over any other icon without activating it, or drag the touch back to the Safari icon and release to load Safari.

   This is the behavior I would like to use in my cocos2d application, but the current Menu system with the various MenuItem classes don't behave this way.

   The cocos2d-iphone MenuTest target can be used to demonstrate the current behavior. When you press down on one button, and then drag over adjacent buttons, the hover state of each button you drag over is enabled. When the touch is released, the button under the touch is activated, regardless of whether it was the button initially pressed. I don't know if this behavior is a bug or by design, but I personally would like to see the MenuItems have the behavior described at the top of this post instead.

   If this is considered a bug, I'll create a bug report. If not, how should I go about correcting this? I'm very new to cocos2d, Objective-C, and Xcode, but have some experience programming in other C-based languages (C++, C#). I haven't looked at the cocos2d code yet to see how the current system is setup, but at the very least, I assume it would need to keep track of the menu item initially pressed.

   EDIT: I'm using cocos2d 0.8.1

   Posted 2 years ago #
2. 

   mryan
   Member

   I updated cocos2d-iphone locally, and only a few changes were necessary to update the menu touch behavior as described in my initial post. The changes appear to work well in the Simulator and on an iPod Touch device, although they haven't been tested thoroughly.

   Does it look like they should negatively impact any other cocos2d functions?

   Menu.h
   

   @interface Menu : Layer <CocosNodeRGBA>
   {
   	MenuState state;
   	MenuItem *selectedItem;
   	BOOL isInitialItem;
   	GLubyte		opacity_;
   	ccColor3B	color_;
   }

   Menu.m
   

   -(BOOL) ccTouchBegan:(UITouch *)touch withEvent:(UIEvent *)event
   {
   	if( state != kMenuStateWaiting ) return NO;
   
   	selectedItem = [self itemForTouch:touch];
   	[selectedItem selected];
   
   	if( selectedItem ) {
   		state = kMenuStateTrackingTouch;
   		isInitialItem = YES;
   		return YES;
   	}
   	return NO;
   }
   
   -(void) ccTouchEnded:(UITouch *)touch withEvent:(UIEvent *)event
   {
   	NSAssert(state == kMenuStateTrackingTouch, @"[Menu ccTouchEnded] -- invalid state");
   
   	[selectedItem unselected];
   
   	MenuItem *currentItem = [self itemForTouch:touch];
   
   	if (currentItem == selectedItem)
   		[selectedItem activate];
   
   	state = kMenuStateWaiting;
   }
   
   -(void) ccTouchMoved:(UITouch *)touch withEvent:(UIEvent *)event
   {
   	NSAssert(state == kMenuStateTrackingTouch, @"[Menu ccTouchMoved] -- invalid state");
   
   	MenuItem *currentItem = [self itemForTouch:touch];
   
   	if (currentItem == selectedItem && isInitialItem == NO) {
   		isInitialItem = YES;
   		[selectedItem selected];
   	}
   
   	if (currentItem != selectedItem && isInitialItem == YES) {
   		isInitialItem = NO;
   		[selectedItem unselected];
   	}
   }

   Posted 2 years ago #
3. 

   mryan
   Member

   Are there no thoughts on this subject?

   Should such changes be integrated into future versions of cocos2d-iphone?

   Would they break existing apps?

   Since I'd prefer the Menus behave this way in my apps, should I simply update the local cocos2d-iphone class directly, or is there a better way to apply the changes to one or more apps?

   Posted 2 years ago #
4. 

   PhilM
   Member

   The length of your post might have scared a few people off ; )

   You could just subclass Menu, and overwrite the methods to get your custom effect. That way you can simply import your new class into all your apps to get the same functionality.

   Posted 2 years ago #
5. 

   Codemattic
   Moderator

   I think the reason for this behavior is bc they are considered menu items and not buttons. This may not make sense on the iPhone GUI. We should have a button class too - most people use menuitems mostly as buttons. Instead of changing the Menu code, maybe you can make a subclass of Menu called Buttons and a subclass of MenuItem called Button? That way its separate from the Menu code.

   Posted 2 years ago #
6. 

   nsxdavid
   Member

   Buttons or menus, what's being described here is the proper behavior. Touching, moving off and letting go is what the user expects to be able to "cancel" the selection.

   Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.