GZDoom likes RAM...a lot of RAM

[DoomerMrT]

Ok so here is the deal: I am making a mod that contains true color high resolution weapon sprites at 35FPS. The complete weapon from the set has roughly 600 sprites including all kind of reloading and shooting animations. All of the sprites are 578x550. Each weapon is in a separate WAD file and these wad files are in a pk3 file. The pk3 file is right now ~105MB. Here comes the problem: Each time I load up the mod and start using the complete weapon, GZDoom eats up my whole 2 gigabytes of ram, and the animation is still laggy from time to time because I suppose the ram cant store all of the stuff at once.

My specs:

-CPU: Intel Core2Duo E6850 3.0GhZ
-Graphics: Nvidia Geforce 8800GTX 768MB
-RAM: Kingston 2GB 800Mhz
-OS: MS Win XP

Tested with these settings:

-GZDoom
-OpenGL
-1280x960 resolution (later lowered it to 640x480 but it didn't seem to have any effect)
-Rendering: Speed

Result: All of my RAM was eaten.
-----------------------------------------------

-Zdoom
-Software(obviously)
-1280x960 resolution

Result: 300 MB RAM needed
------------------------------------------------


Any ideas how this could be improved outside "ripping out unecessary sprites" or making it 8bit?

[Rachael]

I don't think much can be done about this, as Graf isn't heavily into developing GZDoom anymore. That being said, it's rather unfortunate that you're experiencing this.

All I can say is, I do wish someone with coding experience (more so than me) would be able to help with this. I don't know if it's a memory leak, or if it is using a lot of different structures with the same textures loaded, or if it's just keeping them uncompressed, or what.

Outside of that, I don't know what to tell you about how you can fix it on your end. I've not had to fight that particular fight, myself.

My main computer is down (STILL) - otherwise I'd try and look at the code and see if I can find something.

[NeuralStunner]

Each weapon is in a separate WAD file and these wad files are in a pk3 file.

This sounds like one of your biggest foes. You saw the replies to your PK3 question on ZDoom forum, correct?

If you pack WADs into a PK3 they'll have to be fully loaded upon start.

Not to mention, a lot of memory. IIRC data stored in the PK3 folder structure is loaded somewhat "on demand". The access is a little slower, but the memory overhead is smaller - Especially when working with true-color images (which take a few times more memory space to begin with). Short of vanilla Doom GFX/sound formats, I don't see a lot of use in storing things in WADs (besides skins, but that's another matter).

[DoomerMrT]

Tried the pk3 method with sprites but eats up the memory too.

[Gez]

AEOD5 had to switch to the PK3 structure (rather than the "bunch of wads" pseudo structure) during development, or it simply failed to load. If you have many high-res trucolor sprites, they will eat up memory, but using PK3 correctly is not a negligible difference.

[Major Cooke]

AEOD5 had to switch to the PK3 structure (rather than the "bunch of wads" pseudo structure) during development, or it simply failed to load. If you have many high-res trucolor sprites, they will eat up memory, but using PK3 correctly is not a negligible difference.

It loaded alright, it just crashed about several maps in due to memory chomping.

But yes, you're pretty much spot on. I pushed this issue to DBT and we completely reorganized the entire thing so now it only follows the .pk3 structure. Even if the file sizes are still huge, the amount of internal memory being used has been greatly reduced indeed.

Even my home-made hand cannon PNGs and effects didn't hurt thanks to the .pk3 structure.

Anyway, I've made it a habit to convert all my .wads into .pk3 files because it works like a charm. I haven't had any memory allocation errors since then, and I doubt I will anytime soon.

[DoomerMrT]

I don't know how you guys did that, but I didn't notice any difference between using the pk3 structure or the wad method. Both ended up killing my RAM. Don't forget that it makes things even worse that my sprites are called in every tic of the game, because they are for 35FPS framerate weapons. Anyway, I can use the pk3 structure only correctly, otherwise it does nothing

[Graf Zahl]

Your hi-res sprites are too large. They are all cached as GL textures in RAM if the weapon is used. It's unavoidable that it eats all your memory. Each single such sprite is approx. 1.2 MB of texture data. You can do the rest of the math yourself I think...

[Rachael]

And to add to Graf's comment, the only way you can properly load textures into your video card (which is required for OpenGL rendering) is to keep them uncompressed. That means a regular PNG file will dramatically increase in size after it is loaded - and with so many sprites at such a high resolution... well...

If you tried this with any other game, you probably might be looking at the same result, I am sorry to say. However, I will say this... just because your computer can't handle it well now, doesn't mean computers in the future never will. So don't lose hope in your project just yet! Just use a stripped down version and save the smooth and fluidic sprites for that eventuality.

You might ask why it works so much better in ZDoom - well the answer to that might be that ZDoom is rendering the sprites on-demand and does not have to keep all the sprites cached in memory as uncompressed. (but I thought HUD elements were changed to use Direct3D? Maybe I'm wrong? Or maybe you have Direct3D disabled?)

[Gez]

Actually video card are generally able to use compressed textures (in the proper format).

[Rachael]

I see...

[DaMan]

Compressonator can easily batch convert to S3TC. Use DXT1.

[Graf Zahl]

That won't help with GZDoom. The only place where you can set which texture format to use is in the menu. DDS graphics get decoded to RGB before use.

[DaMan]

You think enabling large address aware would help or would it be crashing if it was out of memory. I know its not a practical solution and the OP wouldn't be able to test.

[Firebrand]

Why use so big images? Scale them down a bit, or make them palletted images, it should make them smaller for avoiding problems.