I'm trying to learn XNA game programming, now i would like to wait while a Key is Pressed
I have Test it with:
while (IsKeyPressed = Keyboard.GetState().IsKeyDown(key));
But IsKeyPressed is also true when the key was released
That code is effectively a spin lock. Don't use spin-locks.
The bug you are seeing is likely because you are using a spin-lock, its not getting a chance to update properly.
Instead, you should read the key being pressed, and set state in whatever class is relevant to stop processing (likely a simple if check in the Update function). Then, when you detect the release, you change the state so the if check will pass.
Something like:
//Main Update
if (Keyboard.GetState().IsKeyDown(key))
myObject.Wait();
else
myObject.Continue();
//Other object
public void Wait()
{
waiting = true;
}
public void Continue()
{
waiting = false;
}
public void Update()
{
if (!waiting)
{
//Update state
}
}
You could always check previous state to avoid calling Wait and Continue repeatedly, but thats going to be something of a micro-optimization with the code provided.
Related
I tried to hide a text in Unity after caps was pressed, but it doesn't work, it stops before "while".
I'm quite a not up to par programmer, so anyone more experienced?
private float TurnOffInfoText()
{
bool IsCapsPressed = Input.GetKeyDown(KeyCode.CapsLock);
while (IsCapsPressed == true)
{
EndOfGameText.enabled = false;
}
return 0;
}
Why does this even return a value?
Also your while loop would completely freeze the entire App and even the Unity Editor application! Within the loop the IsCapsPressed value is never ever changed!
I don't see where your method is called from but if you never experienced a freeze so far then "luckily" the key never went down in the same frame so far.
Usually you would rather poll the input every frame. By a simple look into the API for Input.GetKeyDown:
private void Update ()
{
if(Input.GetKeyDown(KeyCode.CapsLock))
{
EndOfGameText.enabled = false;
}
}
I've attempted to make a simple step mode for an algorithm I'm running, and here is how it looks like:
public async Task<bool> AStarAlgorithmAsync(PFSquare curr = null)
{
// some algorithm code here
foreach(var square in Sorroundings)
{
if (SteppedMode)
{
await Task.Run(Pause);
}
if (await AStarAlgorithmAsync(square))
{
return true;
}
}
}
In my application, I have a Boolean called SteppedMode that decides if the algorithm should run one iteration per click event.
Pause() looks like this:
private void Pause()
{
while (!ContinueStep) { }
ContinueStep = false;
return;
}
And in another part of my (GUI) application I have an event which sets the boolean ContinueStep to true which in theory should end the while loop and continue the algorithm function. Currently this bit of code locks my GUI thread up and I'm almost certain there is a better way to do this.
I'm trying to get my algorithm function to run one iteration, wait for a click from the user and only then continue running the algorithm. Is there an easier and cleaner way to do this?
(This is a GUI application, not a console application.)
Your property is moonlighting as a method.
It makes no sense to set a property, to then have that property revert back to its original state immediately. As a consumer, I would be majorly confused by that behavior. Think about this code:
var myObj = new MyObject();
myObj.MyBoolean = true;
Console.WriteLine(myObj.MyBoolean); // FALSE!?
It just doesn't make sense.
The only effect you want to trigger by setting this property is to execute some code. That's exactly what methods are supposed to be used for:
public void ContinueStep()
{
Console.WriteLine("I did some work");
}
So instead of this:
myObj.ContinueStep = true;
you should be doing this:
myObject.ContinueStep();
This doesn't lock up your UI thread, while also being a lot more sensical to your consumer. The method suggests that some action will be taken (which may or may not lead to state changes in the object - that's a contextual expectation).
Infinite recursion
As an aside; based on your code, AStarAlgorithmAsync is a recursive function, and seemingly infinitely so. There doesn't seem to be an ending condition.
Every recursive level will interate over the first surrounding and then trigger the next level, which again will interate over the first surrounding and then trigger the next level, which again ...
That can't be right, but it's unclear to me how to fix it as the bigger picture is not explained in your question
A simple implementation
What I'm trying to do is get my algorithm function to run one iteration, wait for a click from the user and only then continue running the algorithm, is there an easier and cleaner way to do this?
A simple example of such a thing:
private int _index = 0;
private List<object> _myList = ...; // assume this list contains some elements
public void ProcessNextObject()
{
if(_index < _myList.Length)
{
Process(_myList[_index]);
_index++;
}
}
private void Process(object o)
{
Console.WriteLine("Processing this object!");
}
You can then hook up your click event to call ProcessNextObject().
Note that in this example, the list is processed once and cannot be processed again. By manipulating the index value, you can change that behavior as you like.
some pretext of what I am doing ; I am currently locking down my skill buttons via setting interactable = false in coroutines. Showing text of remaning seconds via textmeshpro and setting them deactive when countdown is over. But I am having problem when home button is pressed/ returned main menu. I would like to refresh my buttons cooldowns and stop coroutines when its pressed. But it is staying in lock position.
this is my cooldown coroutine
static List<CancellationToken> cancelTokens = new List<CancellationToken>();
...
public IEnumerator StartCountdown(float countdownValue, CancellationToken cancellationToken)
{
try
{
this.currentCooldownDuration = countdownValue;
// Deactivate myButton
this.myButton.interactable = false;
//activate text to show remaining cooldown seconds
this.m_Text.SetActive(true);
while (this.currentCooldownDuration > 0 && !cancellationToken.IsCancellationRequested)
{
this.m_Text.GetComponent<TMPro.TextMeshProUGUI>().text = this.currentCooldownDuration.ToString(); //Showing the Score on the Canvas
yield return new WaitForSeconds(1.0f);
this.currentCooldownDuration--;
}
}
finally
{
// deactivate text and Reactivate myButton
// deactivate text
this.m_Text.SetActive(false);
// Reactivate myButton
this.myButton.interactable = true;
}
}
static public void cancelAllCoroutines()
{
Debug.Log("cancelling all coroutines with total of : " + cancelTokens.Count);
foreach (CancellationToken ca in cancelTokens)
{
ca.IsCancellationRequested = true;
}
}
void OnButtonClick()
{
CancellationToken cancelToken = new CancellationToken();
cancelTokens.Add(cancelToken);
Coroutine co;
co = StartCoroutine(StartCountdown(cooldownDuration, cancelToken));
myCoroutines.Add(co);
}
this is where I catch when home button pressed/returned main menu. when catch it and pop pauseMenu
public void PauseGame()
{
GameObject menu = Instantiate(PauseMenu);
menu.transform.SetParent(Canvas.transform, false);
gameManager.PauseGame();
EventManager.StartListening("ReturnMainMenu", (e) =>
{
Cooldown.cancelAllCoroutines();
Destroy(menu);
BackToMainMenu();
EventManager.StopListening("ReturnMainMenu");
});
...
I also stop time when game on the pause
public void PauseGame() {
Time.timeScale = 0.0001f;
}
You are using CancellationToken incorrectly in this case. CancellationToken is a struct that wraps a CancellationTokenSource like this:
public bool IsCancellationRequested
{
get
{
return source != null && source.IsCancellationRequested;
}
}
Because it's a struct, it gets passed around by value, meaning the one you store in your list is not the same instance as the one that your Coroutine has.
The typical way to handle cancellation is to create a CancellationTokenSource and pass its Token around. Whenever you want to cancel it, you simply call the .Cancel() method on the CancellationTokenSource. The reason for it being this way is so that the CancellationToken can only be cancelled through the 'source' reference and not by consumers of the token.
In your case, you are creating a token with no source at all so I would suggest making the following changes:
First of all, change your cancelTokens list to be a:
List<CancellationTokenSource>
Next, change your OnButtonClick() method to look like this:
public void OnButtonClick()
{
// You should probably call `cancelAllCoroutines()` here
cancelAllCoroutines();
var cancellationTokenSource = new CancellationTokenSource();
cancelTokens.Add(cancellationTokenSource);
Coroutine co = StartCoroutine(StartCountdown(cooldownDuration, cancellationTokenSource.Token));
myCoroutines.Add(co);
}
And lastly, change your cancelAllCoroutines() method to this:
public static void CancelAllCoroutines()
{
Debug.Log("cancelling all coroutines with total of : " + cancelTokens.Count);
foreach (CancellationTokenSource ca in cancelTokens)
{
ca.Cancel();
}
// Clear the list as #Jack Mariani mentioned
cancelTokens.Clear();
}
I would suggest reading the docs on Cancellation Tokens or alternatively, as #JLum suggested, use the StopCoroutine method that Unity provides.
EDIT:
I forgot to mention that it is recommended that CancallationTokenSources be disposed of when no longer in use so as to ensure no memory leaks occur. I would recommend doing this in an OnDestroy() hook for your MonoBehaviour like so:
private void OnDestroy()
{
foreach(var source in cancelTokens)
{
source.Dispose();
}
}
EDIT 2:
As #Jack Mariani mentioned in his answer, multiple CancellationTokenSources is overkill in this case. All it would really allow you to do is have more fine-grained control over which Coroutine gets cancelled. In this case, you are cancelling them all in one go, so yeah, an optimisation would be to only create one of them. There are multiple optimisations that could be made here, but they are beyond the scope of this question. I did not include them because I felt like it would bloat this answer out more than necessary.
However, I would argue his point about CancellationToken being 'mostly intended for Task'. Pulled straight from the first couple of lines in the MSDN docs:
Starting with the .NET Framework 4, the .NET Framework uses a unified model for cooperative cancellation of asynchronous or long-running synchronous operations. This model is based on a lightweight object called a cancellation token
CancellationTokens are lightweight objects. For the most part, they are just simple Structs that reference a CancellationTokenSource. The 'overhead' that is mentioned in his answer is negligible and, in my eyes, totally worth it when considering readability and intention.
You could pass a load of booleans around with indices or subscribe to events using string literals and those approaches would work.
But at what cost? Confusing and difficult-to-read code? I would say not worth it.
The choice is ultimately yours though.
MAIN ISSUE
In your question you just use the bool cancellationToken.IsCancellationRequested and no other functionalities of Cancellation Token.
So, following the logic of your method, you might just want to have a List<bool> cancellationRequests and pass them using ref keyword.
Still, I would not go ahead with that logic nor with the logic proposed by Darren Ruane, because they have one main flaw.
FLAW => these solutions keep adding things to 2 lists cancelTokens.Add(...) and myCoroutines.Add(co), without ever clearing them.
public void OnButtonClick()
{
...other code
//this never get cleared
cancelTokens.Add(cancelToken);
...other code
//this never get cleared
myCoroutines.Add(co);
}
If you want to go down this way you could remove them manually, but it's tricky, because you never know when they will be required (the Coroutine can be called many frames after CancelAllCoroutines method).
SOLUTION
Use a static event instead of a list
To remove the list and make the class even more decoupled you might use a static event, created and invoked in the script where you call the PauseGame method.
//the event somewhere in the script
public static event Action OnCancelCooldowns;
public void PauseGame()
{
...your code here, with no changes...
EventManager.StartListening("ReturnMainMenu", (e) =>
{
//---> Removed ->Cooldown.cancelAllCoroutines();
//replaced by the event
OnCancelCooldowns?.Invoke();
...your code here, with no changes...
});
...
You will listen to the static event in your coroutine.
public IEnumerator StartCountdown(float countdownValue, CancellationToken cancellationToken)
{
try
{
bool wantToStop = false;
//change YourGameManager with the name of the script with your PauseGame method.
YourGameManager.OnCancelCooldowns += () => wantToStop = true;
...your code here, with no changes...
while (this.currentCooldownDuration > 0 && !wantToStop)
{
...your code here, with no changes...
}
}
finally
{
...your code here, with no changes...
}
}
EASIER SOLUTION
Or you might just stay simple and use MEC Coroutines instead of Unity ones (they are also more performant ).
MEC Free offers the tag functionality that solves the problem entirely.
SINGLE COROUTINE START
void OnButtonClick() => Timing.RunCoroutine(CooldownCoroutine, "CooldownTag");
STOP ALL COROUTINE with a specific tag
public void PauseGame()
{
...your code here, with no changes...
EventManager.StartListening("ReturnMainMenu", (e) =>
{
//---> Removed ->Cooldown.cancelAllCoroutines();
//replaced by this
Timing.KillCoroutines("CooldownTag");
...your code here, with no changes...
});
...
Further notes on tags (please consider that MEC free has only tags and not layers, but you require just tags in your use case).
EDIT:
After some thought I just decided to remove the details of the bool solution, it might confuse the answer and it was going beyond the scope of this question.
Unity has StopCoroutine() specifically for ending Coroutines early.
You will want to create a function that you can call on every skill button object when you want to reset them all like this:
void resetButton()
{
StopCoroutine(StartCountdown);
this.currentCooldownDuration = 0;
this.m_Text.SetActive(false);
this.myButton.interactable = true;
}
We had a problem of some functions that need to be run against an API periodically to get information from a device and the solution I came up with uses a new object to run the thread and the object has some functions to tell the thread to terminate. The object needs to do some setup, run a periodic command and handle shutting down. It also needs to be able to run other commands interleaved with the periodic command. It has three functions that it needs when being setup (Startup, Shutdown and Periodic) and you can pass in a delegate to the command you want interleaved. The startup and periodic command, and the interleaved command, work well enough.
The problem is when trying to stop operation and terminate the thread.
The thread function that executes looks like
private void InterleaverThread()
{
if (this.StartupFunction != null)
{
this.StartupFunction();
}
this.startUpFinished = true;
while (!this.stop)
{
if (this.optCmd != null)
{
this.optCmdResult = this.optCmd();
this.optCmdFinished = true;
}
if (this.stop)
{
break;
}
this.lastPeriodicCmdResult = this.PeriodicFunction();
}
if (this.ShutdownFunction != null)
{
this.ShutdownFunction();
}
this.startUpFinished = false;
}
and the Stop command looks like
public void StopInterleaver()
{
if (!this.IsRunning())
{
return;
}
this.stop = true;
this.interleaverThread.Join();
// SpinWait.SpinUntil(this.IsRunning);
}
When the Thread.Join() command is used the thread never returns but if I used the SpinWait.SpinUntil() the StopInterleaver command returns in the time frame expected. The IsRunning() command just checks the thread IsAlive.
public bool IsRunning()
{
if (this.interleaverThread == null)
{
return false;
}
return this.interleaverThread.IsAlive;
}
The Thread is from System.Threading.
We can't figure out why .Join() doesn't return but SpinWait.WaitUntil does. It seems like they should be doing essentially the same thing.
I would suspect that the compiler is optimizing your loop and not actually checking the stop flag. That is, you have:
while (!this.stop)
{
// do stuff
}
Since the compiler sees that the value of stop can't change inside the function, it can just cache the value in a register.
One way to check if that's a problem is to mark the stop variable volatile, as in:
private volatile bool stop;
That's not a particularly robust way to do it, though. The typical way to handle things is with a CancellationToken. See Cancellation.
For a more detailed look at cancellation and an example, see Polling for Cancellation.
I have a C# desktop application.
In my code I am acquiring an image from a camera. I pass this image to a routine.
This is the 'syntax' of my code:
//in a routine
if (!isProcessingMotion)
{
try
{
isProcessingMotion = true;
//do stuff
}
finally
{
isProcessingMotion = false;
}
}
//////
//module variable:
private static bool isProcessingMotion = false;
The function is reached when an event is raised from the parent code.
The trouble is the 'isProcessingMotion = false is not always 'hit'. I have put a try-catch around the whole of the code but there is no error.
I do not want to use monitor or lock('a read only static object') as when I do the app grinds down to a slow process.
What should I be looking out for?
I presume what is happening is not that the finally block isn't reached, it is that a different thread might be changing the isProcessingMotion variable after that finally block has executed. That might happen when a second event is fired, but the first event hasn't finished processing the first request.
It seems that there are multiple accesses to your field at one.
Although you prefer not to use a lock, this seems like the perfect fix for your problem.
Either that or you'll have to change your application logic to not make multiple reads to that same variable.
Edit
Since you have to process them sequentially, i'd definitely go with a lock:
var processingLock = new object();
if (!isProcessingMotion)
{
lock (processingLock)
{
isProcessingMotion = true;
// Do stuff..
isProcessingMotion = false;
}
}