Out of Memory error

[thebackup]

I'm new to these boards, and I've been using using Ren'Py for several months for my final art project.

However, I'm running into an "out of memory" error:

Code: Select all

I'm sorry, but an exception occured while executing your Ren'Py
script.

error: Out of memory

While running game code:
 - script at line 89 of C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\Final_Week/game/story_may_15.rpy

-- Full Traceback ------------------------------------------------------------

  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\bootstrap.py", line 247, in bootstrap
  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\main.py", line 309, in main
  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\main.py", line 92, in run
  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\execution.py", line 199, in run
  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\ast.py", line 343, in execute
  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\exports.py", line 496, in say
  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\character.py", line 544, in __call__
  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\character.py", line 503, in do_display
  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\character.py", line 318, in display_say
  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\ui.py", line 58, in interact
  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\display\core.py", line 1327, in interact
  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\display\core.py", line 1470, in interact_core
  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\display\core.py", line 242, in predict
  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\display\core.py", line 216, in visit_all
  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\display\core.py", line 242, in <lambda>
  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\display\im.py", line 428, in predict_one
  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\display\im.py", line 188, in get
  File "C:\Users\xxxx xxxxx\Desktop\renpy-6.8.1\renpy\display\im.py", line 457, in load
error: Out of memory

While running game code:

Ren'Py Version: Ren'Py 6.8.1a

My game runs fine, until inside "story_may_15.rpy," lines 87 or 89 are where the error occurs.

Code: Select all

87    scene bg school ex with fade
88    play music "music/hc_bgm22a.ogg"
89    "And so we have the capstone exhibition. My peers created videos such as movies and documentaries, as well as paintings. You know, the traditional media."
90    "One dude created a videogame, and this chick created artwork consisting of nude photographs. As for me?"
91    "Well, I created an anime visual novel using Ren’Py. It’s a love story. My peers and everyone in my class loved it. "
92    "It took me the whole semester to create it. Original artwork, voices, music, story, yeah. I’m really proud of my work."

And to consider, I have 2GB of RAM on my machine. Any ideas?

Edit: I commented out line 87 and I get no errors... but putting it back in would throw an "out of memory" error.

[Guest]

is bg school ex a regular-sized image?

[PyTom]

It would help if we could see the image, since this is certainly happening when trying to load the image into memory.

[thebackup]

Well, the background image is an 800 x 600 BMP; all of my other backgrounds are BMPs and they work fine. See attachment.

(I zipped the BMP because it won't let me upload BMPs)

[EvilDragon]

Perhaps try using PNGs?

[mikey]

It should work with this fixed bitmap - this isn't a renpy problem I would say.
Good luck!

[PyTom]

What was the fix?

[mikey]

I don't know - my image viewer kept saying out of memory when it tried to load the bitmap, so I used the viewer function in Total Commander to see the bitmap, took a screenshot, saved as... and now the bitmap is ok, loads in my viewer without problems. So I guess that was the problem, the bitmap was badly saved or corrupt or something. Luckily that viewer bypassed that error and let me view the picture. It's a bit of a neanderthal fix, but if if works...

[Jake]

What was the fix?

In the bitmap metadata header, the height is given as an unsigned value of 4294966696 pixels - it's got a value of FFFFFDA8h, where it should have 00000258h.

No idea how that kind of thing might happen, but my guess is that the image will load or not load depending on whether the thing reading it reads in the whole bitmap data and thinks "hey, there's only 800x600 pixels worth of data, it must be that big", or whether it tries to allocate a large enough chunk of memory to store all that data before looking to see how much is actually contained in the file...

(The weird thing is that the bitmap file format I was looking at just now notes that the height and width should be signed ints, so off the top of my head that means it's asking for a height of... -2147483049? But I can't see any reason you'd ever want to describe a bitmap with a negative height or width - either way, the header's screwy.)

[Wintermoon]

4294966696 is -600, which means the image has 600 rows stored in correct (top-to-bottom) order.

[Jake]

4294966696 is -600, which means the image has 600 rows stored in correct (top-to-bottom) order.

Huh - so it is, I managed to do the subtraction for two's complement completely the wrong way around.

And that is what's happened, but that's not the 'correct' order at all - BMPs are specified from the bottom up. It's an option, and given this is the first time I've ever seen a BMP use it, I guess it's an uncommon enough one for most bitmap-loading code to not bother supporting it. There's also very little point to it, which I imagine is probably why nobody bothers supporting it.


(I mean, the short version is still "don't use BMP files", there's really zero reason to store an image in that format these days.)

[Wintermoon]

Top down is "correct" because that's the way images are laid out in video memory and non-braindead file formats. As far as the bmp file format is concerned, both directions are equally valid.

[Jake]

Top down is "correct" because that's the way images are laid out in video memory and non-braindead file formats.

Numbers are written backwards, as well, with the least significant byte first, for a pretty good reason in most internal representations. Is it more 'correct' for me to write them that way on paper as well? 'Correctness' is a property of context, and in the context of BMP file formats, bottom-up is the default; suggesting top-down is somehow more 'correct' is simply wrong. Particularly since some ridiculously large proportion of BMP files - to near-exclusion of anything else, in my experience - store the rows bottom-up.

Upon a more-careful reading of the spec it definitely seems to be Ren'Py (or maybe SDL or PyGame?) doing something wrong in this case. I'm not arguing that it's invalid to store them top-down - although it's a pretty bizarre inclusion in an already-kind-of-odd file format - but it's definitely not more 'correct'.

[thebackup]

It should work with this fixed bitmap - this isn't a renpy problem I would say.
Good luck!

Thanks! It works fine!

(I mean, the short version is still "don't use BMP files", there's really zero reason to store an image in that format these days.)

Well, I found that BMP in a CG set, and saw no need to convert since my other BMPs work... but yeah, I should convert them to something like PNGs.