I read the wiki but it's very confusing for me. Can someone explain it in easy language? There are few doubts I have
1. Is capture listener and normal listener are also one of the many listeners provided by scene2D like InputListener, ClickListener etc
What is the difference between target and listener actor?
No, these terms describe whether you've assigned one of the types of listeners as a capture listener or not. Capture listeners allow an actor a chance to reject an event on one of its descendents. For example, some kind of group widget can decide whether to reject presses on a button that is in it based on some criteria. I think the built-in ScrollPane class uses this to prevent buttons and sliders from being manipulated while the view is being scrolled. Most people will not have a reason to use this, as it is for custom widgets that have very particular behavior.
Target and listener actors are usually the same. The listener actor is the actor you attached the listener to, and by default it will also be the target. But you can change the target actor to something else. This is just a feature to allow you to create listeners with custom behavior. Most people will not have a use for this. I don't even think it is used by any of the built-in classes.
The complexities of the listener system were designed to get button and widgets to react to input like a traditional UI. Unless you are designing widgets with customized input behavior, you only need
ChangeListener for the UI widgets (buttons and sliders).
If you're using Scene2D for stuff other than UI (the game scene) you'll subclass InputListener to react to touches. Or maybe GestureListener.
I built a small game using Scene2D and found that it is a bit clumsy for non-UI stuff. I wouldn't do it again, personally. So I would say 99% of people making simple games should only ever use ChangeListener.
The action system is nice for tweening stuff, but you can just add actions to the stage root and react to them externally with your own non-actor classes.
Related
I see that in an ide like FlashDevelop, when I add an event listener to certain objects, it'll auto-populate with the event strings that this object will dispatch (I'm assuming, anyway). I'd love to do this with my custom objects (esp. when it comes to sharing this code with co-workers), to clear up possible confusion as to what to listen for.
Does anyone know how to discern which events will be dispatched?
Thanks,
I don't think there is a way to link suggestions to a method call as strictly as exists with the inbuilt stuff like addEventListener(), but that shouldn't stop you from producing perfectly readable code for you and your colleagues (especially if you are using FlashDevelop).
For starters, using your own event class with static properties representing the event strings you can use will provide a useful code hint by default:
From here, you can add code comments that work with FlashDevelop to produce a very precise tooltip:
I have a menu with five buttons. Menu is visible all the time. there is click event for each menu item. which slides corresponding movie clip from left to right. each movie clip has different nature events and respective animation and activity. for example tab 1 brings the video page. and within that movie clip I have video events like play pause volume and on complete etc. events and code. tab 2 has button group for Time and another button group Features. depending on user selection code will calculate and show value on a animated counter. tab 3 has button group for Time and button group Source. as per the user selection it will calculate and show the values as animated graph. and so on.
Right now I have all the individual tab movie clip has its own time line code for its own events. and some crossover variables and references with other tabs. Everything is working as expected. No problem. I know time line code is not the best way to do any complex project.
So, I would like to get the entire coding as one class or more classes if that is the correct way.
I am beginner as far as class logic. I have already created Main as document class and could control the general navigation of tabs and their initial look. But stuck at tab specific button events and other such unique events for the specific tab.
Any help is greatly appreciated. Thanks in advance.
any similar example or suggestions.
First of all, thanks a lot for a prompt response. It seems like I am not even a beginner. I need to read a lot and probalbly grasp all fundamental concepts thoroughly. I have gone through both the links suggested in your comments. I am trying to digest the stuff slowly. I do not have any formal informal education regarding OOP or any sort of programming. To be honest, I have hard time understanding the code you have suggeted. Not because of your code but because of my level of caliber. I will have to spend some time to make myself clearer regarding events and sequence etc. different tab contents are as movieclips to main timeline and already placed on stage. It comes and goes to its corresponding tab button click event. I am not marking your answer as yes because I still need to my own homework based on your suggestion. Thanks a lot once again. I am sure I will ask few more questions later.
This is how I would design it:
I'd have a Menu Class, which only contains the buttons and "converts" clicks on them into more specific events. That might look something like this:
public Class Menu extends Sprite {
protected var buttons:Vector. = new Vector.();
public function Menu() {
super();
var loops:int = numChildren;
for (var i:int=0; i<loops; i++) {
var button:SimpleButton = getChildAt(i) as SimpleButton;
if (button) {
buttons[buttons.length] = button;
button.addEventListener(MouseEvent.CLICK, broadcastMenuEvent);
}
}
}
public function broadcastMenuEvent(e:Event):void {
var button:DisplayObject = e.currentTarget as DisplayObject;
dispatchEvent(new Event(button.name, true));//bubbling, can catch at any level
}
}
The way this is built, you can change the events that are being dispatched simply by changing the name you give the instance of the button on stage. Note that you need to apply Menu as the Base Class and not the Class for this to work if you have "declare instances automatically" unchecked, because doing it that way allows the compiler to generate those instance names for you in a way your base Class doesn't have to know about.
At this point, you can then deal with those events in another place--whether it's your main document Class or whether you have a separate Controller.
I would define each of the Views you described as a separate Class as well. If you have objects coming and going on the stage, you can use one of the techniques described here to handle that. Otherwise, it's fairly straightforward to address your timeline instances from the base Class instead of timeline code. Again, you can listen for those events in the main document Class or a dedicated Controller--the main point is to make sure your Views are not making any important decisions and usually they should not be editing data.
You can choose to have your Main Document orchestrate how the tabs get added and removed (I'm a big fan of using the timeline with goToAndStop, but not everyone shares this preference), or, again, you can separate this logic out to a dedicated Controller. I would suggest that if it's possible to generalize how your Views work to have them implement a single Interface. That way, you can give them a single instance name and manage them all with the same getter/setter pair (assuming you go the timeline route).
Note the Flash compiler isn't terribly sophisticated in this regard, so if you do this and your Views extend different parent Classes, you'll get compiler warnings. Just ignore these--they don't mean anything.
The thing you shoud try to root out of your code completely is the part where Views are referencing each other. The only time it's acceptable for one View to know about another is when it's a parent knowing about its child. Even then, try to have as little specific knowledge as possible. Notice in the Menu View I wrote as an example, the parent only knows there may be some SimpleButtons, but it has no specific knowledge of where they are on stage, what, specifically, is in them, or even what there instance names are.
Instead of having your Views know about one another, have a third party (which, again, you can choose to use the main Document Class for or not) that transfers requests for state changes (in the form of events) from one to another.
I'm working on game made with libgdx that needs some GUI above my game screen. Something like FrameLayout in Android.
I have GameScreen where everything is happening.
What I want now is to add a "pause" button, highscore information etc.
I've tried to combine a Stage object with regular sprite drawing.
But I had some problems with handling inputs: how to manage if user clicked pause button in stage, or clicked game area (where I should add some bullets)...
You should be able to use a Stage to manage your UI. To get input working correctly, you'll need to add an InputMultiplexer
so that the Stage and then your current input scheme will both get the inputs.
To set it up, you'll do something like this:
InputMultiplexer multiplexer = new InputMultiplexer();
multiplexer.addProcessor(stage);
multiplexer.addProcessor(gameScreenInputProcessor);
Gdx.input.setInputProcessor(multiplexer);
(Code sample based on code from https://code.google.com/p/libgdx/wiki/InputEvent)
Note that the order is important (I'm guessing you'll want the stage to get events first to see if the UI is being touched or not). Also, the boolean return value from input event handlers are more important with a multiplexer, as "handled" events will not be propagated by the mutliplexer. UI events inside the Stage have their own "handled" flag (mostly it does the right thing but there are some subtle differences).
One alternative to the InputMultiplexer would be to create a "GameScreenActor" (a new subclass of Actor) that contains your current game screen that you plug into the global Stage. You'd have to move your input processing to the scene2d approach, though. This probably isn't the right choice for you, but it is a viable one.
I just started to study the Model View Controller pattern. I now understand the basic usage of MVC, but when i tried to implement MVC in a simple test, i ran into a problem. Ofcoarse I could easily adjust the code so it works, but I wish to learn how to correctly implement the MVC pattern.
The test:
I used actionscript 3 to make a simple program. It consist of a turret, and a mouseclick. The turret is in the middle of the screen. When I click anywhere the turret rotates towards the point where I clicked. Both the mouse and the turret have their own model,view and controller. When I click, the MouseModel changes correctly. But for the actual TurretView to respond, the TurretModel must change its rotation variable and send out an event.
The question is who responds to the MouseModel event?
/------->MouseControl------\
/ \
MouseView ?<---MouseModel
TurretView <------------------TurretModel
TurretControl
I figured its best not to have MouseModel directly influence TurretModel or TurretControl, because this would require them to be an eventListener. Making TurretView listen to the MouseModel, and then tell TurretControl to adjust TurretModel, after wich TurretView can update trough a TurretModel event looks like a lot of extra code for a simple task. Also I'd rather not have MouseControl affect TurretModel, this would break the flexibility of the mouse as input for future classes.
Ow, also in which class do I put the code for the angle calculation?
Thanks in advance
Remember that the goal with MVC is primarily the separation of Model and View, and the Controller can serve as the communicator between the two.
Unless you are planning on storing each action that occurs (clicking, rotating, etc.), there is no real need for an action (in this situation) to send data to the Model. Everything you'd like to do should be easily handled with the Controller. So the flow would be:
Mouse click
Event is fired to trigger a command (in the Controller), passing along the mouse location
The command calculates the turret's rotation
The command tells the View to rotate the turret
This is, of course, my suggestion based off of your example. In truth, depending on the project, the above flow could easily change (for instance, in this situation it seems good to do rotation calculation in the command, but in other situations that may not make as much sense). Look at MVC as a goal - you're trying to separate these elements as much as possible, but there is no 100% "works-every-time" way to do it.
Robotlegs, a popular MVC framework, has a great diagram on their site showing how they tackled MVC:
http://www.robotlegs.org/diagram/
I'm not advertising that you NEED to use Robotlegs (it's good, but there's plenty of other alternatives), but they definitely made a pretty diagram :)
You should have one model, which then has pieces in it that you are currently calling MouseModel and TurretModel. You can either keep those names and breakdowns, or do something else once you have a better "handle" on what needs to be done.
The View that is tracking the mouse clicks should dispatch an event that your Controller component catches to update the TurretModel (at this point, there's probably no need for a MouseModel). Your TurretView can then update itself based on the TurretModel, or the Controller can update the TurretView based on the new value. This will depend on how you have it wired.
Usin a Framework such as Robotlegs can help you figure out all the ins and outs of this process, and I've heard that this book http://shop.oreilly.com/product/0636920021216.do provides a great explanation of MVC, even if you don't choose to use Robotlegs after you read it.
I'm building a flash app (just AS3 with FlashDevelop) and I'm having some trouble keeping things loosely coupled around the event system. I've done a lot of reading about central event systems and static eventdispatchers but they don't quite fit the bill for me.
What I'm building is similar to a video player. I have a Player class which is the parent of all the other little parts of the app. The Player class extends Sprite and I've currently designed it so that you could instantiate multiple Player's and put them on the stage. I also have a Controller class which extends EventDispatcher and I dispatch all my events through this class. It's a central event class.
The problem is that I need to pass around a reference to this class so that all the other classes can dispatch and listen through it. Passing around the reference works but it's the exact opposite of loose coupling. I know I could make a static EventDispatcher that all the classes could see but then if I had two or three Player's on the stage they would all hear each others events.
How can I create a type of sandbox that will allow all the child classes of a Player instance to be aware of the central dispatcher without passing a reference or making it static?
I'd suggest to use my static dispatcher, this one has an ID mechanism that allows to tell which Player instance dispatches an event.
It turns out what I was really trying to understand was loose-coupling using something like dependency injection.
I never ended up doing this in any AS3 projects as I don't do much of it anyway. Having done more C# recently I more easily grasped this concept using libraries such as StructureMap and Ninject.
For AS3 you could use a framework like Robotlegs. This will probably change the way you code AS3 and may not be for all developers/situations.