When I test my game with the Visual Studio it works perfectly, but when I try to test it through the .exe it crashes and I don’t have any clue about what’s happening.
The error always happens instantly when I switch to the map screen, but sometimes it takes 1, 2 or 3 seconds to crash the game, it’s random. Here is the window that appears:
When I click to debug the program, I chose the instance of the VS that is with the code open and this window appears:
I have no idea to solve it, does anyone know what to do? I already had this exactly problem on an earlier project. Basicaly, on the screen map of both projects I create some “characters”, and this characters have some properties such as textures. Every time that I create a new character on the update this crash comes. The solution on the earlier game was creating pre-characters on the load of the screen (where the crash doesn’t happens) and when I need a new character, I just clone the pre-created. This solution was very bad but worked (I was on a jam so I had very little time), but for the actual project this doesn’t seems correct and the project is too big to do that.
The base of all the characters on the game is here, both the projects use this file (with some changes). What should I do?
Well, I’m kind of shooting from the hip, but since you said the crash could occur any number of seconds into the game, could it be linked to some subtle event like a sound effect? These can be triggered at seemingly random times.
Do you load values from a txt file, or content from a custom folder?
If I remove the code that creates the enemies the error doesn’t happen, so I think it is related to the characters (actually, the crash still happens, but is delayed for a good time).
I load the textures from a folder that is inside a folder that is in the same level of the Content.mgcb.
I tried this solutions but almost all the problems related are C/C++, so this doesn’t helps a lot.
Yes, the game runs fine on my friend’s machine. I will try to reinstall Windows if this problem takes too much time.
I see: Code may or may not work on different machines…
And think: Are you using the same cultural settings / do you use a clock, calender, currency or decimal numbers etc which are culture sensitive? I’ve seen this be a problem in more than one instance…
I don’t think this is the issue, everything is normal here.
C:\Windows\system32>sfc /scannow
Beginning system scan. This process will take some time.
Beginning verification phase of system scan.
Verification 100% complete.
Windows Resource Protection did not find any integrity violations.
No issue here. I distributed the game and a lot of people played it without problem, but two people could not play. I think I will rewrite the game and see if I find the problem, it even doesn’t open anymore.
I don’t think this is the issue, everything is normal here.
[/quote]
Ok, and don’t mean to argue that this is the case, but that’s why it tricks a lot of people… Everything would appear normal, and there would be no bugs in the code, because the code itself is correct… It has to do with individual user settings in windows, the so called cultural settings…
Volume settings might load values over 1 even if the value you entered in txt file is a decimal value between 0 and 1; and the game would crash on sound play-back…
You might go outside the bounds of an array if you get days counted as months…
and the game would crash…
Certainly keep this in mind of you are reading data or loading stuff from files.
-You can overcome it by using the “Invariant Culture”, just overload your reading methods…
Relying on the garbage collector to dispose of unmanaged resources such as OpenGL resources is very unreliable, and I’m not surprised it leads to this. This is shown by the Texture2D.Dispose being called by the GraphicsResource's finalizer. The reason it happens on some PCs and not others is due to the different OpenGL drivers on the machines. Some are better than others.
If an object owns references to IDisposable objects, then that object itself should implement the Dispose pattern. In this case, your CharacterSprite class creates two Texture2D instances. These textures are not managed by the ContentManager, so CharacterSprite must implement the IDisposable interface, and the code that manages the CharacterSprite instances must call Dispose on these instances when they are finished. The MonoGame.Extended.Sprites.Sprite class takes a Texture2D reference in its constructor, but it didn’t create the texture and doesn’t know how it is managed, so it does not implement IDisposable.
To expand on this, the reason it is unreliable is because the finalizer is called on a different thread by the garbage collector, and OpenGL drivers do not play nicely with resources being accessed by different threads.
Thank you so much, it worked! Ironically, I was about to post a topic asking when to dispose the textures, because I never was doing that
Lesson learned, now I will create a method to dispose everything as soon as I create it so I will never forget. Just one more question: why didn’t the issue happen while testing on Visual Studio? I had read about some things tha the debugger include on the code to facilitate the tests, maybe it is related?
Some things can run slightly differently under the debugger. Timing, memory use, CPU utilization, any number of things. It’s something that no-one can really explain.
