I’ve discovered that if I move the mouse too quickly around the edge of the game screen (my game is smaller than my entire screen)
It can crash out with this error:
I suspect I’m triggering a false draw command of some sort.
Anybody else ever experience this? And is there a fix? I can reproduce it pretty easily so I definitely have to fix it before shipping.
Do you have a conditional End somewhere? It’s kinda too late in your case, but generally, you want to abstract away begins and ends and simply have DrawSprite() methods so that things like this don’t happen since everything is being managed internally.
Look at all the places you have batch.End() and track if any of them are not executing.
I found it. You wouldn’t believe it. I removed
because Visual Studio was complaining it wasn’t being used. See:
I put it back and the problem ended. CLEARLY MONOGAME USES THIS VARIABLE!
This is… really weird. I suggest digging deeper. Maybe cleaning your cache?
Out of curiosity, when you create a new MonoGame project, is this where the
came from? Do you have it at the top of your Draw(), too?
It’s not. It’s just a local variable, it shouldn’t influence anything.
I am sorry but you said you have doctorate in computer science, please, could you explain us what leads you to think that local variable influences anything in this context. How exactly monogame “uses it” or has access to it to begin with?
I think you may be using ID somewhere else as a class variable , and somewhere you are using it to initiate a spritebatch.begin.
So by adding int ID there, you are creating a local variable that will replace the class one so the value will not apply and your spritebach.begin doesn’t trigger somewhere else.
Your problem didn’t end. You just removed something which somehow helped triggering a general flaw in your code. Remove it again and investigate the error properly, otherwise you will find players experiencing crashes and you have no idea why.
Your error is that you are calling “begin” without calling “end” before. In Monogame that’s basically a simple boolean check, so nothing crazy, if it says so, you do so.
Is any if statement exiting the function before you call end or is there any condition where end would not be called in that function?
I’ve seen something like this before a long time ago. It was with an Atari ST compiler and it had to do with memory segmentation. I don’t think that this is the case here.
I’ve not put in any spriteBatch.Begin(); or spriteBatch.End(); calls.
I think MysticRiverGames might have it.There is almost certainly a class variable ID in one of our DLLs. It could very well be a local variable replacing the class variable.
I was going to make a video to demonstrate it, but I just don’t have the time. For now, removing the declaration solves the problem and I’m pushing on.
I think MysticRiverGames probably has the right idea: a class variable with the same name being confused for a local variable. Obviously, compilers handle scope, but…
This, worse yet he doesn’t understand it at all and didn’t properly investigate, then jumps to two incorrect conclusions in row. By the way, if that local value would be overwriting class variable it wouldn’t complain about not being used in given local scope. Also memory segmentation story is irrelevant in this context. Most likely issue persist however was conditioned by rare state that wasn’t reproduced during later testing.
I don’t have access to code so I will make a long shot here:
it happens only when window is inactive, in one case while moving mouse outside he also clicked something else and got window out of focus, that also might be combined with state of game during which that happened
he is using fixed step and game has performance issues, it happens only when draw get skipped for sake of update catching up as draw is setting something to state that is expected to be reset by update, which by the way would also most likely trigger by inactive window.
It only happens when Visual Studio is running in the background and that line is missing. Your #2 suggestion is probably the most likely. Still, there’s absolutely nothing going on in the game when this error occurs. And, it can be reproduced. Moving the mouse around rapidly is required.
Here’s a video clip I just made of it happening:
Youtube link to video
I can’t make it happen if that one declaration is in place. I’m not going to worry about it for now. Yes, it probably has to do with ‘fixed step’. I’ll deal with that later.
Just to put an end to this thread
I found my screw up. There was a return in Draw() and it was exiting without calling
It was legacy code from before the port to MonoGame and got called only when an index exceeded the length of an array (probably caused by wildly waving the mouse around and getting weird ms.x, ms.y values. I really don’t know. The problem may been exacerbated by Windows losing focus when the mouse was rapidly crossing over many different apps.
As I used to say when teaching: The greatest ability a programmer can have is the ability to say, “I screwed up” fifty times a day because the only way you can fix your problem is to first admit you caused it.
Thanks for all the suggestions. If I had been more familiar with MonoGame I would seized on exiting Draw() without those two calls earlier.