ZDoom

I forgot to mention, they also need to be the same size as the "foreground" bar image. That's the only other thing I know of that could cause this problem.

That's caused by a missing background image in a DrawBar. "HPBAREMPTY" and "MPBAREMPTY" have more than 8 characters in their filenames, so GZDoom won't find them unless you use their full path, or rename them so they fit the 8 character limit.

What the shit. So, that "verified by" thing doesn't mean Avira is "verifying" the site... It means the SSL encryption certificate was issued by that organization. It saying it's "verified by" Avira means Avira has installed some root certificate (a certificate that can issue other certificates), and ...

Much as I appreciate what NightDive et al does, I do wonder why they have a tendency to re-invent the wheel and introduce new systems to do the work of well-established standards with (as far as I can see it) little or no advantage, that simply increase the work for port authors and serve to ...

This is entirely out of scope for any sourceport.

That will work but then why not always just drop the texture if keep alive isn't called? shrug Doesn't really matter if it's only if the keep alive function is called, or if it also keeps its contents as long as it's being rendered, the point was that it's not all that hard to come up with a system ...

If the engine destroys a texture due to not having seen it for a while there's no bringing it back. It could recreate it next time zscript/game uses it, but its contents will be lost. Effectively this will just be the 1024 limit anyway, except now you will notice by the textures turning black if ...

I really don't get why this is such a concern. If it's tied to names like the OP suggested, it's not that easy to accidentally leak textures. You'd have to be deliberately using procedurally generated names to do that. Garbage collection isn't a problem, making Destroy mark the texture for release ...

Trucker wrote: ↑Tue Jul 29, 2025 2:56 pm Will the legacy version work on Zandronium?
Thanks

No, it still uses ZScript, which Zandronum doesn't have.

[snip] Nothing about what they said indicates they want RoR. From the sounds of it, they want UDB to "merge" one set of sectors' floors with another's ceilings, and make modifications where necessary to fit. Nothing about that should require 3D floors or portals, just new editor features. (It'd ...

So my comment previously, about having to replicate software rendering on each sprite anyway, in fact seems to be roughly what Forced Perspective (in essence) actually does. It's not really what the software renderer does. The software renderer occludes the sprites based on the lowers and uppers of ...

They're actually described in the wiki, just buried in an obscure page ( link ), except for Forced Perspective. "Smart" and "Smarter" both apply some checks so not all sprites are pushed up off the ground. "Forced Perspective" is a newer one that emulates the effect by, AFAIK, offsetting the sprite ...

Textured particles already exist through A_SpawnParticleEx and SpawnParticle.

That's just how GZDoom renders Doom-style skies. The only way to avoid it is to use a real skybox, whether a texture-based GLDEFS one, or an in-map one.

This looks awfully similar to this issue on the Github repo for Valve's "gamescope" . It's been seemingly fixed, but my guess would be that either this compositor can't handle GZDoom properly, or MangoHud is causing issues with GZDoom. (I'm pretty sure I've heard of this "MangoHud" causing issues ...