ID:89648
 
Not a bug
BYOND Version:461
Operating System:Windows Vista Home Premium 64-bit
Web Browser:Firefox 3.0.17
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:
I noticed some odd behavior while working with LARGE icons. Large, as in, 512 x 416 pixel icons. I was prototyping a combat system that made use of these large images as sprites. The project includes 175 512 x 416 frames, and a smaller set of images that comprise an enemy's animations. Altogether the .rsc is 434KB. However, when the prototype is ran and just the enemy and player sprites are added to the screen the memory usage jumps to 80MB, and then to 275MB when equipment overlays are added. I find this strange when the resource is just half a megabyte and the game runs at over a quarter-gigabyte. It makes me wonder if there isn't something wonky going on. This is also accompanied by a CPU spike, which I suspect is caused by the loading of the images when they are about to be used.

Now, I'm not sure if this is caused by the techniques involved in the prototype. The combat animations are displayed as /image's. The equipment (equip-right, equip-left, etc., verbs if you try the demo below) are image overlays that are added to the player image.

I've uploaded the prototype demo: Prototype.zip

No icon procs are used during the demo.

Numbered Steps to Reproduce Problem:
Use a bunch of really large icons in your game and watch the memory usage sky-rocket.

Code Snippet (if applicable) to Reproduce Problem:

// Just Demonstrating how simple the code is when displaying the images. I'm not doing anything complex here.
New()
..()
image = new(image, layer = LAYER_EQUIP)

/*
Shows this mob to a list of viewers.
*/

display(var/list/viewers)
viewers << src.image


Expected Results: A 434KB resource might blimp up to a megabyte or two one would think.

Actual Results: A 434KB resource blimps up to 275MB.

Does the problem occur:
Every time? Or how often? Everytime.

In other games? ProShogun tried to help by demonstrating a different technique to no avail. His version can be found here.

In other user accounts? Yes.

On other computers? Yes.

When does the problem NOT occur?
To my experience, it always occurs with large images.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
This is a newer project, as it uses the larger icon capabilities of BYOND. The earliest version I've tried it with is 461.1054, the version installed on this machine.

Workarounds: None, yet.

Finally, we've been discussing this on the Efencea blog. Which can be found here if you think you might extract something I forgot to mention from the first portion of the blog and the comments.
I'm not sure we can rule out a bug, but keep in mind the memory usage will definitely outstrip the .rsc size because the icons in the .rsc are using PNG compression, whereas to display those images the client has to use uncompressed forms. A back-of-the-envelope calculation says that 175 sprites at 512x416 size, each pixel taking up 4 bytes for 32-bit color, adds up to over 142 MB alone. I'll give your prototype project a test run to see what I can find, but I think with that many images at that big a size you have to expect some pretty serious memory usage.
Excellent. Well at least we've got an answer if you find nothing. I don't suspect this project would've worked even with the back-of-the-envelope calculations. Thank you.
Metamorphman wrote:
This is definitely a memory leak issue cause the dreamseeker.exe process lingers around after you close the game down.

Copied that from the Efencea Blog.

I don't have this issue on my machine. Thought it might be of concern.
It might simply be taking DS longer to close down in those cases, since it's trying to release memory gracefully. I've noticed some apps simply take a while to close, but if it stays around for a long time that's obviously something to be concerned about.

However it seems like that would be best suited for a separate bug report, detailing the circumstances under which DS doesn't shut down normally (including if it eventually closes on its own and if so, how long it takes).