One of my students was getting an XNA call to TouchPanel.IsGestureAvailable always returning null, even though EnabledGestures was being correctly used in the game Initialize() method.
The call was being done inside an input-handling object created in the game constructor.
Just for curiosity's sake, he decided to create the input-handling object in the game Initialize() method also, rather than in the game constructor. And behold, the problem disappeared! Now IsGestureAvailable works as it should.
Does anyone know or have an idea of why this should matter? TouchPanel is a static class, so even though GraphicsDevice is created after the Game constructor but before Initialize, I can't see how the location of creation of the input-handling object should impact the result of a call to TouchPanel. Any guesses?
Thanks!
Related
I cant get my head around this. I was looking at the lynda.com ActionScript 3.0 in Flash Professional CS5 Essential Training. I understand all the other stuff, but this guy places a skater on the stage he has this code on the first frame on the main timeline:
import flash.display.MovieClip;
import flash.events.MouseEvent;
var boarder:MovieClip = boarder_mc;
boarder.stop();
boarder.x = 0;
boarder.y = 0;
boarder.addEventListener(MouseEvent.CLICK, clickedBoarder);
function clickedBoarder(evt:MouseEvent):void
{
boarder.gotoAndPlay(2);
}
function restart():void
{
boarder_mc.gotoAndStop(1);
boarder_mc.x = 0;
}
then on the skater he has a Display Object Container (Movie Clip) in it he has a Display Object a bitmap image of a skater and then an animation on the timeline in the skater where at the end the skater falls. On that last frame he has:
stop();
parent.restart();
He explains that this may not work and it doesnt he gets an error:
1061: Call to a possibly undefined method restart through a reference with static type flash.display:DisplayObjectContainer.
He explains that it knows there is a stop() function on the main timeline, and that it knows there is a restart function on the main timeline, but the datatype is different. He also says that the parent is the main timeline.
He says that we need to put Object(parent).restart();
My question is of what datatype and what is the main timeline (Movieclip, DisplayObject, Display Object Container)?
Why would it be a different datatype?
Thanks
The main timeline is a MovieClip, or if you have a DocumentClass, then probably a custom type that at least extends MovieClip.
However when you ask for "parent" of your skater MovieClip, you are really using the parent property that MovieClip inherits from DisplayObject (ActionScript Docs Here). This property returns the parent as type DisplayObjectContainer, regardless of the type that it actually is. Since it is the parent of a DisplayObject, it doesn't matter type it is it has to extend DisplayObjectContainer, so this is how it is returned.
So when you compile your ActionScript, the compiler looks at "parent" and sees it as type DisplayObjectContainer, looks at its definition of DisplayObjectContainer and errors because DisplayObjectContainer doesn't have a function called "restart".
What you said about the "stop" function is not really correct, since you are not calling stop on the main timeline, your are calling stop on the Skater's timeline. If you wanted to call stop on the main timeline you would need to call parent.stop(), and this would give you the same error, since DisplayObjectContainer doesn't have a method called stop.
These are both compiler errors, and are caused because the compiler is following a set of rules, and it can't make assumptions about what might actually happen when your program is running. It just knows that when you call parent.restart() it might receive a DisplayObjectContainer that won't have the method restart on it, and a run-time error will occur.
Now, by casting parent as type object, you are effectively telling that compiler that this thing can have any method or property on it, since Object is a dynamic class. So the compiler will now assume that you as the developer know that the method "restart" will exists on the "Object" that is given to that bit of code, and therefor will not error any more.
Thank you very much for you reply. This is really confusing. I thought that DisplayObjectContainer is a subclass of Display Object and it extends it? I know that Display Object Container is a Display Object and it can contain other Display objects and Display Object Containers. So the way I understand it, the maintimeline is a movieclip and therefore a DisplayObejctContainer, which can contain other Display objects (that you create in you application) and that is why parent returns Display Object Container, but that it is also a abstract class which means that it cannot have methods such as .restart and goToAndPlay() because it cannot actually be instantiated. However if its a MovieClip as you say then it can..... I dont get it.Does it mean that it is an abstract Class?
I am using Adobe Flash Pro CC, AS3 & scaleform.
I create an instance of an object which contains AS Linkage and a use class definition.
Regardless I can visually identify the object is loaded, the constructor class of this object never gets called.
I tried re-creating the object in the scene, renaming, etc... but it still produces the same error.
When running the GfxMediaPlayer, I can see an 1009 error is displayed; a common mistake when the AS Linkage is missing.
Is there any other option for this kind of objects that is restricting how it gets instantiated?
My scene contains several objects that use similar layout and scaleform.clik libraries, but they work as expected an they do get instantiated.
I also have tested this on Flash CS6 with same results, any help appreciated.
I found that the library path for the object was missing. The strange thing, is that same path was used by the rest of the objects that were working fine, no idea how they would be working.
I'm updating a game from single player to multiplayer. In this case the game was originally written with most classes being single instanced. e.g. there was a single Player object, a single GameState object, etc. That is, each of these objects lived as long as the application.
Now that more than one player can play at once I obviously need to support creating more than one Player object, GameState object, etc. Over the course of working on this I have come to realize that most objects have one of three lifespans:
App's lifespan, e.g. a Conductor to handle navigation
Player's lifespan, e.g. the SettingsViewModel for the current player
Game's lifespan, e.g. the GameState for the current game
I'm curious how others deal with the creation of these different objects using an IoC container. I want to avoid creating factory classes for each class with a player or game lifespan.
Here is an example of IOC that may help. The project is called IOC-with-Ninject. It uses Ninject plus an IOC container class to manage all object life spans. You will need to do a little research on Ninject to customize it to your specific needs, but this is your IOC container solution (IMHO) if you are using .NET and will help you organize your code base. This is a personal choice, but I swear by it. If you are not using .NET it will still give you an easy pattern to follow. Cheers.
Many IoC containers have custom life-cycle scopes which you can manage as your wish. For example in Ninject you can define your custom life cycle scope as follows:
kernel.Bind<IService>().To<Service>().InScope((c, o) => yourCustomeScope);
As long as the yourCustomeScope variable has not changed, one single instance of the Service object is returned each time the kernel receives a request for IService. As soon as the yourCustomeScope variable changes, a new instance of Service will be created on the next request for IService. yourCustomeScope can be the current player instance, the game object or anything that you want to change the lifetime of the Service object, based on its reference change.
However, the objects that you just mentioned are more likely to be entities rather than services for which I don't think injection is a good idea.
From my experience the factories approach works the best.
Controlling lifespan of instance is clunky for support and requires efforts, knowledge of all of the classes lifespan requirements and dependencies, time for configuration and management of the configuration. In same time the use of factories is natural and code specific.
Factories (implementation) creation might be avoided by using proxy factories . You can also have factories returning generic arguments to further decrease the needs of factories (interfaces) creation.
If still too many factories are required I suggest reviewing the code flow.
I think this is in part a rehash of some of the comments of the previous answers but I have tried to exemplify expand a little on some of the reasoning.
Once you get into the domain of managing injected objects lifespan, you probably should be creating factories for these objects.
The underlying problem is that the composition root is not aware of what the environmental context of the call will be that needs to create the object.
I think I should take a step back and explain at this point.
Received wisdom on dependancy injection is to have a composition root some where near the entry point of the code. There are many good reasons for this that are not difficult to find on the web so I won't go into that here.
The composition root is where you map your interfaces (usually, but possibly objects) to their implmentations. You can pass in information that is available at this point to the constructor. So you can pass in a reference to an object whose lifetime is current at the time of execution of the composition root.
However, if the lifetime of the composition root does not overlap with the life time of the object you want to create you have to defer the execution of the constructor until the object needs to be created. This is why you need to have a factory. You can pass a factory method in to your mapping at this point and thus pass in the information needed to generate the object, but allow the creation to happen at the time it is required not when the composition root is executed.
You do not need a factory class to do this factory methods are fine, moreover the factory method can be inlined and so the code overhead is not much more than if we were creating the objects in the composition route.
If we have a project with 2 services where the first service is dependant on the first and we only want the lifetime of the second service to start when we create the first service we might have something like the following. (I am using ninject to give a code example, but I expect that other IOC containers work similarly in this respect.)
`
public class Service1:IService
{
private Func<IService>serviceFactoryMethod _Service2Factory;
public Service1(Func<IService>service2FactoryMethod)
{
_Service2Factory=service2FactoryMethod;
}
public void DoSomethingUsingService2()
{
var service2=_Service2Factory();
service2.DoSomething();
}
}
public class MainClass
{
public void CompositionRoot()
{
var kernel= new StandardKernel();
kernel.Bind.ToMethod(m=>
{
return new Service1(m.Kernel.Get<IService2>());
}
}
}
`
This example does not address how you would manage the lifetime of the App, players and games lifespans, but hopefully it gives sufficient clues as to how to remove lifetime issues related to dependancy injection.
Side note: that using Ninject you would be able to change the scope of Service2 in order to manage its lifetime to go beoynd the lifetime of Service1. For example, if you knew each instance of a game were to happen on its own thread (OK, this maybe somewhat unlikely), you might use InThreadScope for the game.
I an confused about how to pass values of variables from 1 gamecomponent to another.
I am using xna 4.0.
I created two gamecomponents, the drawstring and the inputmanager.
I want to read the keyboard input of the user and pass it onto drawstring where it will update the position.
I cant add components on drawstring(drawablegamecomponent).
I can do it on class but not on gamecomponent.
Can you guys post some examples here. For beginners.
Use GameComponent for something that you would want to have Update called on every frame, and use DrawableGameComponent for something that you would want to have Draw called on every frame and LoadContent called when appropriate (at the start of the program, as well as whenever the device is lost, like when the user pressed Ctrl-Alt-Del on Windows).
For InputManager you might want an Update method, so that you can keep user input updated, so InputManager could be a GameComponent. DrawString doesn't sound like it needs to be. Both classes sound like they could be services. In the constructor or Initialize method of your game class, do something like the following:
Components.Add(mInputManager = new InputManager(this));
Services.AddService(typeof(InputManager), mInputManager);
Services.AddService(typeof(DrawString), mDrawString = new DrawString(this))
(DrawString and any other class that you want to get game services from will need a reference to the Game object.)
(Note that GameComponents do not necessarily need to be services, and services do not need necessarily need to be GameComponents. To get Update and/or Draw to be called, you must call Components.Add(...); separately, to get an object to be retrievable as a service, you must call Services.AddService(...)).
Then, when you would like to use the InputManager or DrawString service in some other game component (or any class that you have passed a reference to your game object), you can do this:
InputManager input = (InputManager)Game.Services.GetService(typeof(InputManager));
Personally, I write an extension method to make that more concise:
using XNAGame = Microsoft.XNA.Framework.Game;
...
public static T GetService<T>(this XNAGame pXNAGame)
{
return (T)pXNAGame.Services.GetService(typeof(T));
}
The line to get the input service then becomes:
InputManager input = Game.GetService<InputManager>();
I have created a separate class (let's call it class2.cs for example) and want to use it as a level, in that when I call it, it will draw everything in one level for me. I'm having trouble getting contentmanager to work in class2. In the given Game1.cs, you can easily just go texture2d= Content.Load<Texture2D>("photo"); but I can't in class2.
I realize I have to create a new Content Manager, but it's constructor requires a game service, in which I'm not sure what I'm suppose to plug in. I currently have: ContentManager content = new ContentManager(); but I need an overload for ContentManager.
Pass Content to the constructor of your second class from the game, or you can create a Globals.cs class with static variables for your ContentManager or spriteBatch or any common resources.