ZDoom

[url=https://forum.zdoom.org/viewtopic.php?f=59&t=74149]Here we go.[/url] I added an option for both inside and out of a sprite definition.

Agreed. I don't want to have to redefine the whole thing when a simple "NoTrim <name>" can suffice. So that's what I'm shooting for. Like how "remap" or "define" is used. Simplicity without going through the headache of having to jot down all the image sizes for the canvas, etc.

As long as the entire image doesn't have to be redefined in the process, because that's a massive pain in the backside.

NoTrim ASDFA0

Hmmm. The only thing I could think of without expanding the images directly is to set an option via TEXTURES lump. Something as simple as:

[code]NoTrim ASDFA0[/code]

...could suffice, if Graf doesn't have a problem with it.

[quote="Major Cooke"][url=https://forum.zdoom.org/viewtopic.php?f=59&t=74071]And it's done.[/url]

Addressing both Graf and Rachael, I took what you two said and combined it into one. There's an option in the menus, and by default, the trimmer is now disabled.[/quote]

Hey. While I really appreciate the effort, this really isn't what I had in mind at all. I fail to see how a menu option be useful to mod authors.

The point of my original suggestion was that the author should be allowed to force no trimming on *specific* sprites, so that *specific* sprites would be 100% guaranteed to be correctly positioned when rotated/scaled. Like in the example I posted, where it was just 1 weapon in a whole mod.

Having an option to do this to *all* sprites, and to have the player change that option, seems like a fun debug feature, maybe, but it doesn't address the original issue at all.

[url=https://forum.zdoom.org/viewtopic.php?f=59&t=74071]And it's done.[/url]

Addressing both Graf and Rachael, I took what you two said and combined it into one. There's an option in the menus, and by default, the trimmer is now disabled.

No. Cropping occurs when rendering them by narrowing the part of the texture that gets mapped. The texture itself is never altered.

Correct me if I'm wrong, Graf:
Cropping occurs when loading the resources only for the first time. So it'd have to be something that might require a restart.

[quote="Rachael"]It should be an option, in my opinion. There's still good reasons for having it. Further, the optimization can still happen if the image has an "anchor point" (similar to the offset) that can either be defined or automatically assumed by GZDoom.[/quote]

It could be a flag. Something like DONTCULLCANVAS or DONTCROPCANVAS, maybe. The optimization may not be needed, but I guess disabling the crop unconditionally would probably mess with some of the existing mods, because there's probably a couple out there that used A_OverlayPivot acounting for the crop.

Maybe an extra argument of A_OverlayPivot could work too.

I'd love to see this implemented.

In the mean time Jekyll, what you can do as a workaround is use cvars to align parts of your weapon so you don't have to restart the game over and over again.

Another case is pendulum-like world objects (for example, in my case it's hanging bodies that will sway when shot). But that case could be solved but adding a feature that allows setting a pivot point for world sprites.

For HUD sprites the optimization is not really needed anymore. When I implemented this stuff my graphics card was a Geforce 6800 which was choking under some mods that had two layers of huge weapon sprites. None of this ever was an issue anymore on the Geforce 8600 I got afterward. Where it is an issue is mostly empty sprites in the world. These can get close enough to the camera that you don't have just two of them, but enough to cause 10-20x overdraw of the entire screen with nothing. And that's still something that's not to be taken lightly on today's lower spec hardware.

It should be an option, in my opinion. There's still good reasons for having it. Further, the optimization can still happen if the image has an "anchor point" (similar to the offset) that can either be defined or automatically assumed by GZDoom.

I think for HUD weapons this can be disabled these days.
That code was written at a time where all that empty space being rendered really hurt performance quite badly. But even the weakest graphics cards around these days tend to run circles around the hardware this was meant for.

Similar optimizations for in-game sprites and two sided walls still make sense, though, but those are far less critical.

There are several applications for this, but the most common one is when it comes to A_OverlayRotate.

At the moment it's literally impossible to sync rotationof a multi-layer weapon, since even if you try to make all of its sprite use the same canvas size, GZDoom will ignore that and just crop them (I have no idea at which stage it happens or whether it can be controlled in any way). This shifts pivot points in such a way that I can't imagine how they could be synced, which leads to a lot of frustration.

Here's an example of a weapon that can't be rotated due to this:
[imgur]https://imgur.com/W6IeBiz[/imgur]