The Guncaster - 3.888b

[Metalworks41190]

I like the mod so far but I'm encountering a strange bug were my gold amount in the Stratocaster and Item tab get reset to 0 when I load a save but the Spell tab gold amount is correct did I do something wrong here by updating to the latest GZDoom engine?

[TGminer]

Just wondering, I have a very, very shitty computer* and can only run Software mode in QZDoom and GZDoom. (excluding Zandronum 2.1.2 and 3.0, for they use OpenGL 1.4)
When running Guncaster 2.8a on GZDoom, it runs fine. When starting a game on QZDoom, it hangs endlessly, while consuming a decent amount of RAM.



* - http://valid.x86.fr/ad4h91

[PillowBlaster]

I like the mod so far but I'm encountering a strange bug were my gold amount in the Stratocaster and Item tab get reset to 0 when I load a save but the Spell tab gold amount is correct did I do something wrong here by updating to the latest GZDoom engine?

Nah, you didn't. Still, something is probably going bonkers in new revisions thanks to this bug, which I've been trying to reproduce, but no avail.

Oh yeah, if you do have a save and what wads you used when this occured (and what gzdoom version you've been using), I wouldn't mind having that shared. That might be a big time helper to report it.

Just wondering, I have a very, very shitty computer* and can only run Software mode in QZDoom and GZDoom. (excluding Zandronum 2.1.2 and 3.0, for they use OpenGL 1.4)
When running Guncaster 2.8a on GZDoom, it runs fine. When starting a game on QZDoom, it hangs endlessly, while consuming a decent amount of RAM.

And this also seems to happen for me, and my computer isn't exactly shitty. Would be worth reporting, as much as I have no idea how to make both problems compact for testing. I'll get yelled at for including whole mod instead of a testing ground, but I can't even exactly nail the source of the problems here.

[Rachael]

Please do QZDoom +logfile log.txt +set developer 4 -file etc.wad

You'll have to remember to set your developer cvar to 0 later on.

Also - since you're using Process Hacker anyway, please right-click on QZDoom's process when it is frozen and find the command "Create Dump File" and post that.

[TGminer]

Phew, was lucky to get a dumpfile, almost ran out of memory and crashed.

Here are the files:
https://gist.githubusercontent.com/anon ... 82/log.txt
https://a.pomf.cat/bybjvs.7z -- The dump. WARNING: 300+MB when extracted!

[Rachael]

Thank you for that. That gives some clue as to what the problem may be, though the work-around I thought would fix it temporarily does not work - so I will have to talk to dpJudas to see what can be done.

I suspect, based on loading your dump file, that it's taking a long time to load the mipmaps and you may be running out of memory when it does.

[TGminer]

The thing I don't get, is that GZDoom runs it perfectly. No errors, just plays like it's supposed to be.

[Rachael]

GZDoom does not generate software mipmaps. It appears QZDoom does, even when the OpenGL renderer is activated. As such, newer versions of GZDoom (devbuilds) will be doing this, also.

The problem here is that the mod consumes 2 gigs of RAM after a level is fully loaded. If there are a lot of textures in this mod, that will contribute greatly to this problem.

Also - not knowing whether you have a 64-bit system or not, running a 64-bit build might help alleviate this issue. If you can't do that, though, then you're stuck with severe memory allocation issues that can't be immediately worked around at this time - so the solution will have to come from the code side.

In the meantime, I would suggest sticking with GZDoom 2.4.0 in Software mode - the mod seems to otherwise run fine. You won't have truecolor or dynamic lights, but at least it works.

[Rachael]

Sorry for the double-post but I do need to add one thing:

The number of texture definitions being loaded (not textures, themselves) is absolute murder. It kills GZDoom, itself, too, to load that much. Since GZDoom doesn't load mipmaps for each texture it's not as bad, but still - @PillowBlaster - you really could do with cutting down on the texture definitions, if possible. Are all of them even used?

[PillowBlaster]

Sorry for the double-post but I do need to add one thing:

The number of texture definitions being loaded (not textures, themselves) is absolute murder. It kills GZDoom, itself, too, to load that much. Since GZDoom doesn't load mipmaps for each texture it's not as bad, but still - @PillowBlaster - you really could do with cutting down on the texture definitions, if possible. Are all of them even used?

I use all of them, and so far gzdoom doesn't seem to complain. The fact that I commit such travesty I wasn't aware of is probably enough of a proof.

I really needed some sorting here for obvious reasons. Would it be possible to add some different handling for this, so I don't have to browse through slade's texture editor through a possible thousand of entries? I really despised that in wads.

[Rachael]

It's not a travesty, per se, but it's no wonder QZDoom doesn't like them. In my case, GZDoom 2.4.0 and QZDoom's latest devbuild both handle them about the same - but then again, I have the RAM to handle it. It's still a very very long load time for a single level, with both ports.

It doesn't matter if you pre-render the textures or leave them as definitions - what's happening is it's loading each definition as its own unique texture in RAM, and that's what's causing all these problems. It seems like loading G/QZDoom in OpenGL mode with "gl_precache false" makes the load times more tolerable, though. But software rendering in both ports makes it choke.

Would it be possible to add some different handling for this, so I don't have to browse through slade's texture editor through a possible thousand of entries? I really despised that in wads.

I'll bring it up but I can't make any promises. As I said, even if you export them all as flat textures it will make no real difference, though. It might speed up load times but it will not make a single dent in memory usage.

[Graf Zahl]

Just to post a small but costly example:

Code: Select all

Sprite BFGGA0, 450, 200
{
	Patch BFGGA, 105, 58
}

Sprite BF1GZ0, 450, 200
{
	Patch BFGGN, 105, 58
}

Sprite BF1GA0, 450, 200
{
	Patch BFGGN, 105, 58
}

Sprite BF1GB0, 450, 200
{
	Patch BFGGN, 105, 58
}

Sprite BF1GC0, 450, 200
{
	Patch BFGGN, 105, 58
}

Sprite BF1GD0, 450, 200
{
	Patch BFGGN, 105, 58
}

Sprite BFGGB0, 450, 200
{
	Patch BFGGB, 105, 58
}

Sprite BFGGC0, 450, 200
{
	Patch BFGGC, 105, 58
}

Sprite BFGGD0, 450, 200
{
	Patch BFGGD, 105, 58
}

Sprite BFGGE0, 450, 200
{
	Patch BFGFA, 105, 58
}

Sprite BFGGF0, 450, 200
{
	Patch BFGFD, 105, 58
}

Sprite BFGGG0, 450, 200
{
	Patch BFGFB, 105, 58
}

Sprite BFGGH0, 450, 200
{
	Patch BFGFC, 105, 58
}

Sprite BFGGN0, 450, 200
{
	Patch BFGGN, 105, 58
}

For some of these images, such a definition increases the texture size three times. Keep in mind that the size you define is what will be kept in memory!
So if the texture itself is, say 320x100 that is 32000 pixels, i.e. 128000 bytes of video RAM.

But what does get uploaded in this case is no 128000 bytes but the composited texture, which is 90000 pixels, i.e. 360000 bytes!
And this stuff just adds up in a horrible way. I can understand why compositing textures like this seemed to be convenient but it absolutely murders the hardware if done this widespread.

Wait: It gets even worse: Normally, multiple composite textures consisting of one patch will only load the patch once - if the composite size and the patch size are identical there will be a redirection set up that folds all such textures into one. But here each patch is used in multiple frames - and that cannot be optimized by the texture manager- so just in that small snippet I posted, instead of having one 128000 bytes upload of BFGGN, you have 7 uploads of identical textures with empty space added, each on of them being 360000 bytes in size - summing it up to 2520000 bytes - that's nearly 2.5 MB of texture uploads and video RAM totally wasted on redundancy! And that's only counting that one patch. Do something similar for 10 patches and you are at 20 MB waste - do it for 100 patches and you got maybe 150 MB of wasted space. And all this waste needs to be composited and uploaded to the GPU, and this is where the time is lost.


I am really sorry to say this, but this is a clear-cut case where the only workable action is to redesign the mod to use the system properly and use its assets more efficiently.

[PillowBlaster]

Hmm, I see now. The reason I have same patches designed a couple of times is that the same patch is used in the same chain of other sprites, to make the code a bit more compact at places, where I don't have to suddenly write a replacement chain for a single patch. Another reason is that I did most of the animation work through those patches, and making them occupy the particular space of 320x200 eased the offsetting, or making the brightmaps for them. Then I have like three variations of those animations, because of different hands for HUD graphics, depending on currently used item per weapon.

The obvious and huge problem of fixing this would require pretty much rewriting the very base that the mod stands on in terms of handling weapon animations, both code and animation-wise. I'll safely assume that the only good way to do it would be to minimize the amount of patchwork and lift the animation to weapon offsets. If so, I guess it wouldn't hurt to have some kind of similar editor for that like textures in slade, including the goodness that are weapon overlays - else the work to do so would take aeons, if I'd actually ever complete it, as I gave it a shot once or twice. There is Danimator, but it seems it got quite dead and buggy (and was designed for offsets, not a_weaponoffsets, as it's a bit older than that). The frustration was unreal.

So I guess I'll keep it in mind for the next time.

[Xaser]

At present, it may be worth reaching out to someone* (or go the DIY route) to write a script that will crop those single-patch texture definitions. It would need to read the dimensions of the patch and rewrite the TEXTURES defs, though, so it's not really a simple task either, but it'd likely save a good chunk of space and it's still easier than trying to rewrite everything.

[*I'd best not volunteer myself, unfortunately; I'm a busy dude these days.]

[Rachael]

I actually was going to suggest what Xaser suggested - until Xaser suggested it. (Great minds think alike, eh?)

Unfortunately the first thing I'd need is something that can read the input files and programatically (and, without error) determine their dimensions. I suppose I could swipe some ZDoom code, for that, but eh, lazy.