summaryrefslogtreecommitdiff
path: root/src/i_video.h
diff options
context:
space:
mode:
authorSimon Howard2014-02-20 05:28:20 +0000
committerSimon Howard2014-02-20 05:28:20 +0000
commit2ec58cfa8becc461bf749e0009f150b1841aba6b (patch)
tree140bc5784880440e1263e744b0e08dbccad414ce /src/i_video.h
parent95ef264ebab11e76adf523f8196b3f3ad5ae34ae (diff)
downloadchocolate-doom-2ec58cfa8becc461bf749e0009f150b1841aba6b.tar.gz
chocolate-doom-2ec58cfa8becc461bf749e0009f150b1841aba6b.tar.bz2
chocolate-doom-2ec58cfa8becc461bf749e0009f150b1841aba6b.zip
Mark 512x400 mode as decent quality.
I originally flagged this as a poor quality mode because it doesn't include every original pixel at least once (ie. its dimensions are not >= 640x400 - twice the original resolution). In practise, it's actually okay though. Add long comment adapted from my comment on #339 explaining what the definition of a poor quality mode is.
Diffstat (limited to 'src/i_video.h')
-rw-r--r--src/i_video.h30
1 files changed, 28 insertions, 2 deletions
diff --git a/src/i_video.h b/src/i_video.h
index ff720922..4a85f93e 100644
--- a/src/i_video.h
+++ b/src/i_video.h
@@ -64,9 +64,35 @@ typedef struct
boolean (*DrawScreen)(int x1, int y1, int x2, int y2);
- // If true, this is a "poor quality" mode. The autoadjust
- // code should always attempt to use a different mode to this
+ // If true, this is a "poor quality" mode. The autoadjust
+ // code should always attempt to use a different mode to this
// mode in fullscreen.
+ //
+ // Some notes about what "poor quality" means in this context:
+ //
+ // The aspect ratio correction works by scaling up to the larger
+ // screen size and then drawing pixels on the edges between the
+ // "virtual" pixels so that an authentic blocky look-and-feel is
+ // achieved.
+ //
+ // For a mode like 640x480, you can imagine the grid of the
+ // "original" pixels spaced out, with extra "blurry" pixels added
+ // in the space between them to fill it out. However, when you're
+ // running at a resolution like 320x240, this is not the case. In
+ // the small screen case, every single pixel has to be a blurry
+ // interpolation of two pixels from the original image.
+ //
+ // If you run in 320x240 and put your face up close to the screen
+ // you can see this: it's particularly visible in the small yellow
+ // status bar numbers for example. Overall it still looks "okay"
+ // but there's an obvious - albeit small - deterioration in
+ // quality.
+ //
+ // Once you get to 640x480, all the original pixels are there at
+ // least once and it's okay (the higher the resolution, the more
+ // accurate it is). When I first wrote the code I was expecting
+ // that even higher resolutions would be needed before it would
+ // look acceptable, but it turned out to be okay even at 640x480.
boolean poor_quality;
} screen_mode_t;