Out of Memory Error

[Kuskus]

So a few months ago I began a project and in order to complete said project I needed to get specific tile sets. Now initially those tilesets due to their extremely large size prompted the Editor to inform me of support issues for lower end machines. Regardless of those problems I was still able to load them up into Intersect and work on it. Now every single time I open Intersect this happens.

2021-07-28 18:20:44.931 [Error]
  Message: Out of memory.
    Stack:    at System.Drawing.Image.FromFile(String filename, Boolean useEmbeddedColorManagement)
   at System.Drawing.Image.FromFile(String filename)
   at Intersect.Editor.Content.GameContentManager.LoadTilesets() in C:\TeamCity\buildAgent\work\676c60f42f2551e6\Intersect.Editor\Content\ContentManager.cs:line 246
   at Intersect.Editor.Networking.PacketHandler.HandlePacket(GameDataPacket packet) in C:\TeamCity\buildAgent\work\676c60f42f2551e6\Intersect.Editor\Networking\PacketHandler.cs:line 213
   at CallSite.Target(Closure , CallSite , Type , Object )
   at System.Dynamic.UpdateDelegates.UpdateAndExecuteVoid2[T0,T1](CallSite site, T0 arg0, T1 arg1)
   at CallSite.Target(Closure , CallSite , Type , Object )
   at Intersect.Editor.Networking.PacketHandler.HandlePacket(IConnection connection, IPacket packet) in C:\TeamCity\buildAgent\work\676c60f42f2551e6\Intersect.Editor\Networking\PacketHandler.cs:line 35
   at Intersect.Network.AbstractNetwork.HandleInboundData(IBuffer buffer, IConnection connection) in C:\TeamCity\buildAgent\work\676c60f42f2551e6\Intersect (Core)\Network\AbstractNetwork.cs:line 261
   at Intersect.Network.AbstractNetwork.HandleInboundMessageAvailable(INetworkLayerInterface sender) in C:\TeamCity\buildAgent\work\676c60f42f2551e6\Intersect (Core)\Network\AbstractNetwork.cs:line 205
   at Intersect.Network.Lidgren.LidgrenInterface.<.ctor>b__9_0(Object peer) in C:\TeamCity\buildAgent\work\676c60f42f2551e6\Intersect.Network\Lidgren\LidgrenInterface.cs:line 129
   at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

A bit of context. I moved onto a new PC and simply copy pasted everything over. Something weird happened to my PC and erased basically all .exe files that existed after restoring the PC back to its former glory. Ok so I redownloaded the client and simply copy pasted the server and client files over so I could resume work. Didn't work, I got this error. Ok so I tried copying the entire Intersect folder over to the new one and just copying over what was needed. That didn't work. Still got this error. Aaaalright so I decided to start over, arguably I didn't get that far. I just copied over my assets over to this new installation and still this error! OK FINE So I tried removing the excessively large tilesets which I would later trim down (have yet to do that) and still this error. Starting to think it has nothing to do with the tilesets at all and it's just not going to work regardless.

[Cheshire]

How much memory is the editor using before it crashes?

That doesn't sound normal.

[Kuskus]

Like 35 megabytes?

[Oddly]

Are you editing the source at all? If you're running this through visual studio, do you think you can show debug data like how much memory you're using over time.
If you're not in visual studio and just running the client, Resource monitor can track resource usage of specific applications over time. This information can be helpful for debugging.

https://resource-monitor.en.softonic.com/

Even showing us some memory usage over time through the task manager might help.

 

[Kuskus]

After opening the performance tab of task manager and keeping an eye on the memory gauge. I saw that consistently due to various programs including Firefox especially are causing my RAM to be at 50%. Opening the editor changes nothing. It doesn't even go up by a full % when it crashes.

[jcsnider]

You have a corrupted tileset or a tileset that is way too big in resolution I'd bet. 

[Kuskus]

35 minutes ago, jcsnider said:

You have a corrupted tileset or a tileset that is way too big in resolution I'd bet. 

But it worked before with these tilesets how is it all of a sudden not working?

[Oddly]

18 hours ago, jcsnider said:

You have a corrupted tileset or a tileset that is way too big in resolution I'd bet. 

So I was looking up monogame's limitations to see if the texture size limitations, because after JC mentioned something, I remembered that GPU's sometimes have a maximum texture size permitted for objects. The max limit on the size of a texture being loaded can vary by the graphics card. Some graphics cards will support up to like 16384x16384 pixels, I've personally dealt with this when coding before where the graphics card I had at the time didn't allow 4096x4096 images. Do you have any sprites, tilesets, new graphics, even GUI that you've added recently that might be on the large size?
Here's a thread I found on monogame regarding the topic: https://community.monogame.net/t/does-monogame-not-allow-large-textures-like-20-000-x-1-000/7680/5

Also, what graphics card are you using?

[jcsnider]

This is the editor loading up the graphic via GDI+. Monogame limitations are not involved in this specific case. 

[panda]

From the GDI+ documentation for the failing call:
 

Quote

If the file does not have a valid image format or if GDI+ does not support the pixel format of the file, this method throws an OutOfMemoryException exception.

 

[Oddly]

4 hours ago, jcsnider said:

This is the editor loading up the graphic via GDI+. Monogame limitations are not involved in this specific case. 

Technically what I posted is a GPU limitation and can apply to all graphics rendering libraries, not just monogame. I've dealt with the same issue in OpenGL.
That being said, what panda shared is likely possible too. Ensure all your tilesets are in the acceptable image format (I think its PNG), and ensure you're able to view all the resource files in a normal image viewing program. If they don't open they're probably corrupted.

Can you list for me the following information:
What processor is in your machine,
What graphics card you're using,

Give me the dimensions (in pixels) of one of the larger texture files you're trying to load. I can tell you if this is a GPU limitation

[Kuskus]

On 7/29/2021 at 10:05 AM, Oddly said:

So I was looking up monogame's limitations to see if the texture size limitations, because after JC mentioned something, I remembered that GPU's sometimes have a maximum texture size permitted for objects. The max limit on the size of a texture being loaded can vary by the graphics card. Some graphics cards will support up to like 16384x16384 pixels, I've personally dealt with this when coding before where the graphics card I had at the time didn't allow 4096x4096 images. Do you have any sprites, tilesets, new graphics, even GUI that you've added recently that might be on the large size?
Here's a thread I found on monogame regarding the topic: https://community.monogame.net/t/does-monogame-not-allow-large-textures-like-20-000-x-1-000/7680/5

Also, what graphics card are you using?

I'm using a RTX 3060
I'm also using some map files that are about 2300x2800

I may have been using a different version of this engine and it allowed me to use these huge map files. Granted they're not nearly as big as some tilesets I found that need to be broke down but even THOSE were showing up in the tile lists just fine before and despite the size warning the editor loaded right up without a problem. I have since removed those gigantic tilesets.

[Oddly]

9 hours ago, Kuskus said:

I'm using a RTX 3060
I'm also using some map files that are about 2300x2800

I may have been using a different version of this engine and it allowed me to use these huge map files. Granted they're not nearly as big as some tilesets I found that need to be broke down but even THOSE were showing up in the tile lists just fine before and despite the size warning the editor loaded right up without a problem. I have since removed those gigantic tilesets.

I wanna say an RTX 3060 should be able to handle resolutions of up to 4k. I see people using the card for NVidia CUDA with 8k x 8k resolution, but will say 16kx16k resolutions are too big. Of course, I don't know if those CUDA limits are gonna be the same for rendering limitations. It appears to be loading an image from file last before It crashes, so I doubt its your Map's texture size. If the map's surfaces gets created just fine, even if there's no data in it, its likely not the size of your map's texture here, because the space for the texture would likely already be stored in memory at this point, or not created yet. If no one's able to resolve this by tomorrow night, Hit me up on discord and maybe I can help you figure out what file is causing issues OddlyDoddly#2354

[jcsnider]

@Kuskuscan you zip up your tilesets and PM them to me?

 

@Oddlykeep in mind that the error he is experiencing is a GDI+ error (before it even gets to Monogame). The graphic card and it's capabilities/vram capacity has no impact on this error. It's simply trying to read the image file into normal ram. 

[Oddly]

2 hours ago, jcsnider said:

@Kuskuscan you zip up your tilesets and PM them to me?

 

@Oddlykeep in mind that the error he is experiencing is a GDI+ error (before it even gets to Monogame). The graphic card and it's capabilities/vram capacity has no impact on this error. It's simply trying to read the image file into normal ram. 

I know, but the thought also came to mind that, If the end user is using a machine with processor that doesn't support on board graphics, the GPU may take care of the drawing in GDI+. And if not the APU may have similar limitations as well. I wasn't sold it was the texture size issue, I was just trying to ensure it wasn't.

 

[panda]

7 hours ago, Oddly said:

I know, but the thought also came to mind that, If the end user is using a machine with processor that doesn't support on board graphics, the GPU may take care of the drawing in GDI+. And if not the APU may have similar limitations as well. I wasn't sold it was the texture size issue, I was just trying to ensure it wasn't.

 

 

On 7/29/2021 at 12:49 PM, panda said:

 From the GDI+ documentation for the failing call:
 

Quote

If the file does not have a valid image format or if GDI+ does not support the pixel format of the file, this method throws an OutOfMemoryException exception.

 

Like I quoted from the actual documentation (not speculation), it's image/pixel format.

 

We should add a try-catch to find out what the specific files are blowing up.