Bug 134 - Animated sprites with transparency are distorted on certain resolutions
: Animated sprites with transparency are distorted on certain resolutions
Status: ASSIGNED
Product: Odamex
Classification: Unclassified
Component: Client
: (old) 0.0.1
: x86 (Windows, Linux, etc) Windows (Any)
: P3 minor
Assigned To: Odamex Bug Reporter
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-26 13:39 UTC by Nautilus
Modified: 2014-03-20 00:19 UTC (History)
4 users (show)

See Also:


Attachments
Screenshot of the distortion of the weapon sprite. (76.72 KB, application/octet-stream)
2006-02-26 13:42 UTC, Nautilus
Details
Weapon sprites distorted at low resolutions (21.77 KB, image/jpeg)
2006-03-11 11:04 UTC, Nautilus
Details
Weapon sprites normal at higher resolutions (55.79 KB, image/jpeg)
2006-03-11 11:05 UTC, Nautilus
Details
Re-attachment of weapon sprite distortion image. (29.26 KB, image/png)
2006-03-11 12:25 UTC, Nautilus
Details
Re-attachment of weapon sprites at high resolution image (52.01 KB, image/png)
2006-03-11 12:26 UTC, Nautilus
Details
Odamex screenshots of all tested resolutions, up to 1600x1200 (755.16 KB, image/pcx)
2006-03-17 14:52 UTC, Tom J.
Details
Odamex screenshots of some tested resolutions, comment #24 (848.74 KB, application/zip)
2006-10-09 18:40 UTC, Tom J.
Details
GhostlyDeath's patch (3.86 KB, patch)
2006-11-14 19:59 UTC, Denis Lukianov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nautilus 2006-02-26 13:39:02 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.)
Comment 1 Nautilus 2006-02-26 13:42:50 UTC
Created attachment 7 [details]
Screenshot of the distortion of the weapon sprite.
Comment 2 Denis Lukianov 2006-02-26 15:14:17 UTC
(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?
Comment 3 Nautilus 2006-02-26 15:58:56 UTC
(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. 
Comment 4 Mike Lightner 2006-03-04 11:27:21 UTC
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?
Comment 5 Nautilus 2006-03-11 11:04:27 UTC
Created attachment 10 [details]
Weapon sprites distorted at low resolutions
Comment 6 Nautilus 2006-03-11 11:05:12 UTC
Created attachment 11 [details]
Weapon sprites normal at higher resolutions
Comment 7 Nautilus 2006-03-11 11:06:20 UTC
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.
Comment 8 Nautilus 2006-03-11 12:25:12 UTC
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.
Comment 9 Nautilus 2006-03-11 12:26:15 UTC
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.
Comment 10 Tom J. 2006-03-11 14:16:14 UTC
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.
Comment 11 Denis Lukianov 2006-03-12 14:59:42 UTC
would it be possible to get a doom2.exe screenshot of what they should be like?
Comment 12 Tom J. 2006-03-17 14:52:27 UTC
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).
Comment 13 Mike Lightner 2006-03-20 12:49:34 UTC
(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.
Comment 14 Denis Lukianov 2006-04-11 18:33:06 UTC
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.
Comment 15 Denis Lukianov 2006-10-01 17:59:16 UTC
No progress, reassigned to myself
Comment 16 Denis Lukianov 2006-10-01 18:00:02 UTC
fixed in r1686, please test
Comment 17 Mike Lightner 2006-10-01 18:02:02 UTC
What was wrong?
Comment 18 Nautilus 2006-10-01 19:02:42 UTC
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.)
Comment 19 Nautilus 2006-10-01 19:15:05 UTC
(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.

Comment 20 Denis Lukianov 2006-10-01 19:20:32 UTC
(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.
Comment 21 Mike Lightner 2006-10-01 21:14:58 UTC
I looked extremely carefully at the resolutions with issues and noticed no distortion windowed or fullscreen.
Comment 22 Nautilus 2006-10-02 21:44:01 UTC
For me, distortions continue to appear when testing r1686 at the same resolutions that I had just previously listed.
Comment 23 Denis Lukianov 2006-10-06 04:09:34 UTC
Need Typone to check this
Comment 24 Tom J. 2006-10-09 18:32:37 UTC
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
Comment 25 Tom J. 2006-10-09 18:40:12 UTC
Created attachment 32 [details]
Odamex screenshots of some tested resolutions, comment #24
Comment 26 Denis Lukianov 2006-10-18 13:02:30 UTC
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
Comment 27 Denis Lukianov 2006-10-20 04:02:28 UTC
<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)
Comment 28 Denis Lukianov 2006-10-20 09:36:12 UTC
denis@li3-251:~/odamex$ factor 200
200: 2 2 2 5 5
Comment 29 Denis Lukianov 2006-10-23 20:16:32 UTC
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);
Comment 30 esd45 2006-11-10 14:40:15 UTC
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.
Comment 31 GhostlyDeath 2006-11-13 17:37:03 UTC
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.
Comment 32 GhostlyDeath 2006-11-14 19:29:50 UTC
I sent in a partial fix
Comment 33 Denis Lukianov 2006-11-14 19:59:47 UTC
Created attachment 34 [details]
GhostlyDeath's patch

Uploaded the patch from comment 32, as it applies to odamex r2023
Comment 34 Denis Lukianov 2006-11-14 20:08:08 UTC
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.
Comment 35 Denis Lukianov 2006-11-23 12:07:48 UTC
(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
Comment 36 Mike Lightner 2010-12-14 14:50:01 UTC
*** Bug 679 has been marked as a duplicate of this bug. ***
Comment 37 Dr. Sean 2013-01-15 16:07:10 UTC
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.