ID:94325
 
This issue has been marked as a duplicate of id:97186
BYOND Version:465
Operating System:Windows Vista Business
Web Browser:Chrome 5.0.342.9
Applies to:Dream Daemon
Status: Duplicate

This issue has been marked as a duplicate of id:97186
Descriptive Problem Summary:

Numbered Steps to Reproduce Problem:
1. Make 1024x1024 PNG file
2. Attempt to use the code snippet a couple times in a loop
3. Get unexpected results

Code Snippet (if applicable) to Reproduce Problem:
    var/icon/Tile = icon(file("mapbase.png"))
if (Tile.Width() != 1024|| Tile.Height() != 1024)
world.log << "<B>BASE IMAGE DIMENSIONS ARE NOT 1024x1024</B>"

NOTE: "mapbase.png" is a PNG file created with Macromedia Fireworks CS4 Educational. It is 1024x1024 pixels, all solid white. I used the normal save mode, not "Flattened PNG."

Expected Results:
1024x1024 icon to be created from 1024x1024 PNG

Actual Results:
Sporadic erroneous returns of a 32x32 icon instead

Does the problem occur:
Every time? Or how often?
Sporadically, but never the first time the icon(...) line is called
In other games?
Unknown
In other user accounts?
Unknown
On other computers?
Unknown

When does the problem NOT occur?
The first time (since closing and reopening Dream Daemon) that this line executes.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
This problem has been present since at least 464, when the DM code was written

Workarounds:
Restart server, try again.

If it is relevant, I can post the entire code file that the problem manifests in.
The code you posted won't even work because you're not assigning the value of icon() to a var, and the Tile var is never defined at all. If that can be assumed to be var/icon/Tile, the question is then if "mapbase.png" is a file on the server that is being read correctly. I definitely would need to see more of the code for this, possibly even a demo project.
Lummox JR wrote:
The code you posted won't even work because you're not assigning the value of icon() to a var, and the Tile var is never defined at all. If that can be assumed to be var/icon/Tile, the question is then if "mapbase.png" is a file on the server that is being read correctly. I definitely would need to see more of the code for this, possibly even a demo project.

Whoops, I'd missed that I didn't copy that quite right.

Here's the *proper* first line:

var/icon/Tile = icon(file("mapbase.png"))

Also, I'm pretty sure the file is being read right, because I generally get 3-4 "good" exports before either I get a "cannot write to rsc" error, or this error where the base icon is 32x32 instead of 1024x1024.

also, http://sukasa.kicks-ass.org/takepicture.dm
The code provided was inadequate to confirm the issue on its own, since it had no context. Testing similar code in a test project of my own showed no problems. A demo project will be required.
Lummox JR wrote:
The code provided was inadequate to confirm the issue on its own, since it had no context. Testing similar code in a test project of my own showed no problems. A demo project will be required.

Since this is a closed-source project, is there somewhere I can send this to you privately?
You can send me source at [email protected]. Please send the files in a .zip and be sure to label your e-mail so I know what it is and who it's from.
Sent.
Your game is too big to be able to catch this in the debugger. All I managed to do was have the debugger hemorrhage so much memory that it nearly took out the whole system. I wouldn't be terribly surprised if the root problem is just that you're running out of memory. However if you can get this to happen in a smaller demo, I can re-investigate that.
I'm not sure why the game would run out of memory, as it should be discarding the in-memory reference to the 1024x1024 icon after sending it to the client, shouldn't it? Also, correct me if I'm wrong but shouldn't the proc always fail after the first use of it after restarting the server if it's memory issue, not just after taking a picture of a more crowded part of the map?

I'll try and make a smaller project, but if I remove too many objects I don't know if it'll accurately recreate the issue.
Also, on a whim I checked dream daemon's memory usage when it's running that game after starting a round.

Dream Daemon was using just over 96 MBytes of RAM, and my system RAM was 60% used. After dumping a map tile, usage spiked to 125 then settled at 116 MBytes.
Topkasa wrote:
I'm not sure why the game would run out of memory, as it should be discarding the in-memory reference to the 1024x1024 icon after sending it to the client, shouldn't it?

Not necessarily. The /icon datum's internal code keeps a small cache of loaded icons. The original mapbase.png you load is often going to remain in that cache.

Also, correct me if I'm wrong but shouldn't the proc always fail after the first use of it after restarting the server if it's memory issue, not just after taking a picture of a more crowded part of the map?

The greater number of icon operations in the more crowded parts of the map seems quite relevant to the problem. I can't really say more than that because this problem is impossible to reproduce in the debugger.
You mention it keeps a small cache. Is it possible to clear that cache from within DM code? It's not a fix, but it might be a workaround if it's possible.
Issue 1599 turned out to be a cache problem that only showed up after a certain point and only affected big icons. I believe this is the same issue, so please retest this in version 471 once that is released.
Lummox JR wrote:
... please retest this in version 471 once that is released.

Will do.
Confirming that as of 471 the issue is no longer present and the map export process runs unhindered. Much appreciated!