Bugzilla – Bug 134
Animated sprites with transparency are distorted on certain resolutions
Last modified: 2013-01-15 16:07:10 UTC
On the resolutions 320 x 240 and 400 x 300, the weapon sprites appear rather wavy and smudged, due to pixels being out of place and distorted. (The resolutions 512 x 384 and 320 x 200 have not been tested, since they go out of range -- on other resolutions the weapon sprites seem to appear normally.)
Created attachment 7 [details] Screenshot of the distortion of the weapon sprite.
(In reply to comment #0) > (The > resolutions 512 x 384 and 320 x 200 have not been tested, since they go out of > range -- on other resolutions the weapon sprites seem to appear normally.) Tried windowed?
(In reply to comment #0) > On the resolutions 320 x 240 and 400 x 300, the weapon sprites appear rather > wavy and smudged, due to pixels being out of place and distorted. (The > resolutions 512 x 384 and 320 x 200 have not been tested, since they go out of > range -- on other resolutions the weapon sprites seem to appear normally.) > (In reply to comment #2) > (In reply to comment #0) > > (The > > resolutions 512 x 384 and 320 x 200 have not been tested, since they go out of > > range -- on other resolutions the weapon sprites seem to appear normally.) > > Tried windowed? > Just tried it, so the resolutions now work. The weapons seem fine on 320 x 200, however are also distorted on 512 x 384.
I can't reproduce this on multiple resolutions windowed and fullscreen. I can't even tell what the problem is exactly based on your screenshot. Can you retest this please and paint arrows on the screenshot indicating the problem areas?
Created attachment 10 [details] Weapon sprites distorted at low resolutions
Created attachment 11 [details] Weapon sprites normal at higher resolutions
Comment on attachment 11 [details] Weapon sprites normal at higher resolutions Here are two screenshots. The first screenshot was taken when the resolution was set to 320 x 240. The arrows and circle point out the distorted parts of the weapon, which are a bit hard to see from a distance, yet upon close inspection one can take note of the "smudged" effect. This occurs on lower resolutions from 320 x 240 to 512 x 384, after which the higher resolutions from 640 x 400 and on are normal. 320 x 200 seems to be normal. This second screenshot was taken while the resolution was set to 640 x 400. The weapon sprites, as mentioned, are normal at such a resolution.
Created attachment 12 [details] Re-attachment of weapon sprite distortion image. Same as the first attached image showing the distortion of weapon sprites, but in PNG format, as JPEG tends to smudge and blur images.
Created attachment 13 [details] Re-attachment of weapon sprites at high resolution image Same as the first attached image showing how weapon sprites are normal at higher resolutions, but in PNG format, as JPEG tends to smudge and blur images.
I can confirm this. In most resolutions the weapon sprites are displayed distorted (while not moving). It is easier catched with weapon bob, while moving. Then, what's visible could be decribed as 'tearing'. The effect is most obvious at lover resolutions. Up to a resolution of 1600x1200 (could not test higher) only these resolutions are working correctly: 320x200 640x400 800x600 1600x1200 All other resloutions distort the weapon sprites.
would it be possible to get a doom2.exe screenshot of what they should be like?
Created attachment 15 [details] Odamex screenshots of all tested resolutions, up to 1600x1200 I somehow can't make doom2.exe screens. Anyhow, i attached the screens i made in Odamex. Compared to each other the distortions are more or less obvious, especially if compared to the working resolutions 320x200, 640x400, 800x600 and 1600x1200 (those look the same and look clean).
(In reply to comment #11) > would it be possible to get a doom2.exe screenshot of what they should be like? > A doom2.exe screenshot would be 320x200, which according to the previous comment is a resolution in which there is no issue, so they would most likely look identical. What is particularly curious is that 800x600 is fine. It's not the proper aspect ratio, while most if not all of the resolutions in which this bug creeps up are not.
also, bug that may be related... when starting to run in odamex, the weapon jerks quite a bit. in doom2 this is much more gentle/gradual.
No progress, reassigned to myself
fixed in r1686, please test
What was wrong?
Tested again. 1024 x 768 - No distortion 800 x 600 - No distortion 640 x 480 - There is distortion 640 x 400 - No distortion 400 x 300 - There is distortion 320 x 240 - Most distortion (Resolutions 320 x 200 & 512 x 384 are not listed, as they go out of range on my machine.)
(In reply to comment #18) > Tested again. > > 1024 x 768 - No distortion > 800 x 600 - No distortion > 640 x 480 - There is distortion > 640 x 400 - No distortion > 400 x 300 - There is distortion > 320 x 240 - Most distortion > > (Resolutions 320 x 200 & 512 x 384 are not listed, as they go out of range on > my machine.) > Disregard this, as this was tested on r1685. Sorry about that.
(In reply to comment #17) > What was wrong? Each column length of the weapon sprite was multiplied by the aspect ratio scale, but first the top of the sprite is calculated to work out where pixels go. To work out the top, take the bottom and subtract the length, right? Not quite, because as the length is multiplied by the aspect ratio, you end up starting at some proportion of a pixel (e.g. top = 123.4567). Drawing then proceeds based on a non-integer offset and everything is skewed (probably because transparent pixels are calculated slightly differently to filled ones). The simple fix is to round the "top" number to the nearest whole. It may be worth investigating the whole transparent/opaque pixel counting further, but a simple rounding stops the distortion.
I looked extremely carefully at the resolutions with issues and noticed no distortion windowed or fullscreen.
For me, distortions continue to appear when testing r1686 at the same resolutions that I had just previously listed.
Need Typone to check this
Tested revision: 1733 Changed behaviour as compared to previous tests: The weapons sprites don't 'tear' anymore while moving (weapon bob). This means if there is distortion now, it is a fixed distortion in the sprite which does not change when there is bobbing. The resolutions that were not displaying the sprites correctly still don't and the resolutions that were fine are still ok, as far as i can test (different video card, which gives me different resolutions to test with). Below are all resolutions that my card and my display can handle. Only the ones marked 'ok' are fine, all others are distorted. Turns out every resolution that has a height of 400, 600, 800 and 1200 is fine (as well as 200 from previous tests). I bet a keg of czech beer that if there would be a height 1000 available this one would be ok as well ;) Added screenies for reference as well. 320x240 400x300 480x360 512x384 640x400 ok 640x480 720x480 720x576 800x600 ok 848x480 960x600 ok 1024x768 1088x612 1152x864 1280x720 1280x768 1280x800 ok 1280x960 1280x1024 1360x768 1600x900 1600x1024 1600x1200 ok 1920x1080 1920x1200 ok
Created attachment 32 [details] Odamex screenshots of some tested resolutions, comment #24
This appears to be deeper than just a weapon sprite issue. Take a look at how flaming torches jiggle about. Anything with runs of transparent and non-transparent pixels has this problem. Problem is somewhere near R_DrawMaskedColumn
<Quasar`> EE had a similar problem with screen patches being off by a pixel in some places though <Quasar`> I fixed it by adding 1 to the fracstep variable in V_DrawPatchColumn <AlexMax> had? <Quasar`> it's a fixed-point value used to step through the pixels in a column <Quasar`> adding one causes it to round up, so if for example fracstep is 0.3332something when it should really be a perfect +0.333..., it steps to the next pixel when it should <AlexMax> hrm <AlexMax> damn <Quasar`> I'm not sure how much this might apply to odamex though <AlexMax> Thanks for stopping by anyway <AlexMax> =) <Quasar`> it's definitely to do with the vertical scaling only so that narrows it down drastically <Quasar`> the reason it's fine at 800x600 is because 600 is an even multiple of 200 :P <Quasar`> 960x600 is the corresponding correct aspect ratio resolution for that dimension <Quasar`> (my favorite res too)
denis@li3-251:~/odamex$ factor 200 200: 2 2 2 5 5
The following code in R_DrawVisSprite stabilises the pixel problem but leads to under-scaled sprites being rendered: vis->yscale -= vis->yscale%FRACUNIT; vis->yscale ++; dc_iscale = FixedDiv (FRACUNIT, vis->yscale); dc_texturemid = vis->texturemid; frac = vis->startfrac; spryscale = vis->yscale; sprtopscreen = centeryfrac - FixedMul (dc_texturemid, spryscale);
This is obviously a bug in the scaling code that is very appearent in this one spot. Since it is non-critical here, and this is my specialty, I'm going to experiment on this bug to familiarize myself with the Doom code. I'll likely do intial work on one of the ports that goes right off the Doom source code, since little has changed in the software render core, and then port it through the various changes to get to the csDoom, prBoom, and zDoom bases to ensure compatability.
It depends on the height, any height that is a multiple of 200 should work fine. It scales the sprites using values like 2.6 for example to fit into the odd sized height. You should probably make it so it draws to the closest 200 multiple or not do anything. If you draw to the closest multiple then you should always apply it to the width also because in some cases the guy's hand and gun will be kind of thin.
I sent in a partial fix
Created attachment 34 [details] GhostlyDeath's patch Uploaded the patch from comment 32, as it applies to odamex r2023
The fix referred to by comment 32 and comment 33 is basically an alternative way of tackling the problem from my r1686 fix mentioned in comment 16. The scaling is fudged to the nearest compatible aspect ratio. The fix in comment 16 was: + sprtopscreen -= sprtopscreen%FRACUNIT; // denis - do not attempt to position on a half or quarter pixel! That is a one line fix that also preserves scaling at any aspect ratio. However, neither of the two approaches tackle the core problem.
(In reply to comment #14) > also, bug that may be related... when starting to run in odamex, the weapon > jerks quite a bit. in doom2 this is much more gentle/gradual. removal of killough's 10/98 bobbing code should have fixed this in r2064
*** Bug 679 has been marked as a duplicate of this bug. ***
A fix for this was committed in r3608. It clearly stops the jiggling that happened on animated sprites like torches and the beating heart pedestal. However it's too early in the morning (before coffee) for my eyes to tell if it helps with the distortion of weapon sprites. Please test and confirm.