search

ZDoom / gzdoom

GZDoom is a feature centric port for all Doom engine games, based on ZDoom, adding an OpenGL renderer and powerful scripting capabilities
http://zdoom.org
GNU General Public License v3.0
2.47k stars 540 forks source link

[BUG] 4.13pre: ROLLSPRITE disables pixelstretch #2700

Closed jekyllgrim closed 3 weeks ago

jekyllgrim commented 3 weeks ago

GZDoom version

g4.13pre-122-g76c8b6da5

Which game are you running with GZDoom?

Doom

What Operating System are you using?

Windows 10

Please describe your specific OS version

No response

Relevant hardware info

No response

Have you checked that no other similar issue already exists?

A clear and concise description of what the bug is.

The ROLLSPRITE flag in 4.13pre disables the effect of pixelstretch on an actor.

Steps to reproduce the behaviour.

Explain how to reproduce

  1. Add rollsprite_pixelstretch.zip to your load order
  2. Run it with a Doom iwad
  3. Type summon test in the console to summon an actor (it'll use Cacodemon sprites)
  4. Observe an actor who toggles its bROLLSPRITE flag every second: it'll squish and stretch based on the value.

Your configuration

https://gist.github.com/jekyllgrim/14f5678b651aa9ef58a3b5a34d9bfc46

Provide a Log

No response

MajorCooke commented 3 weeks ago

Intentional because it was causing very weird behaviors otherwise.

jekyllgrim commented 3 weeks ago

This presents a compatibility problem, if so.

I have actors that I want to always keep aspect ratio in my mod (because they're round or square), even if the mod is combined with maps that use pixelratio of 1.0 or 1.2. So, these actors call scale.y = scale.x / level.pixelstretch on spawn. But they also have ROLLSPRITE, and as a result they look right in 4.12.2 but wrong in 4.13, and I don't see a way I could make them work in both. I would rather not require a dev build to play it without issues.

MajorCooke commented 3 weeks ago

scale.y = scale.x / level.pixelstretch

Which I think was a huge mistake because this means that every single modder is going to have to implement this and it'll break older mods visually.

I personally think this whole thing needs to be undone and not left to the modder, but done on the engine side with an option.

MajorCooke commented 3 weeks ago

Oh and lets not forget, if this comes down to any sort of independent checking of sprite scaling based on pixel stretching, the whole thing will cause desyncs.

jekyllgrim commented 3 weeks ago

Can this behavior be gated behind zscript version being set to 4.13, perhaps?

Also, a new actor flag, NOPIXELSTRETCH, could be a good option too. Custom actors in gameplay-only mods should not be tied to the pixelratio of whatever map the user may be playing them with.

MajorCooke commented 3 weeks ago

Can this behavior be gated behind zscript version being set to 4.13, perhaps?

Also, a new actor flag, NOPIXELSTRETCH, could be a good option too. Custom actors in gameplay-only mods should not be tied to the pixelratio of whatever map the user may be playing them with.

@madame-rachelle A NOPIXELSTRETCH flag would be nice.

EDIT: Thinking about it more, I'm not even sure if that's going to do it any justice. Worth a shot but I'm having doubts.

madame-rachelle commented 3 weeks ago

After extensive discussion +ROLLSPRITE now transforms the sprite pixels into square. This was a decision that happened because of repeated reports about the corrected roll system (which was broken before 4.12) being "bugged" when it really was not. 4.13 is correct behavior, 4.12 and previous versions are not.