Tue Aug 17, 2021 1:45 am
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:
Tue Aug 17, 2021 2:18 am
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.
Tue Aug 17, 2021 5:01 am
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.
Tue Aug 17, 2021 5:54 am
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.
Tue Aug 17, 2021 11:35 am
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.
Wed Aug 18, 2021 9:33 am
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.
Tue Aug 24, 2021 7:36 am
Rachael wrote: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.
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.
Last edited by Jekyll Grim Payne on Thu Aug 26, 2021 8:27 am, edited 1 time in total.
Tue Aug 24, 2021 3:14 pm
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.
Tue Aug 24, 2021 3:16 pm
No. Cropping occurs when rendering them by narrowing the part of the texture that gets mapped. The texture itself is never altered.
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.