fraggle
Filled with the code of Doom
Posts: 9128
Registered: 12-99 |
I'd encourage people to skim through the entire release notes as there are a whole bunch of things that have been changed and improved. They're mostly small things, but I hope that some of them, like the fixes to the OPL MIDI playback, which was clearly a pain point to a lot of people, should make a big difference.
One other thing I'm including in this version for the first time is the philosophy document, which attempts to describe the design philosophy behind Chocolate Doom. I get a lot of requests for features to add to Chocolate Doom, many of which I end up rejecting, and I hope that this helps explain the reasoning and arguments that I use to decide whether to accept or reject feature requests. It also might just be interesting if you're a user.
One thing I should note: chungy's post mentions the PNG screenshot and substitute music pack support. The Windows binaries on the website don't actually have this compiled in, so if you're using Windows you might be disappointed. These two features require some extra libraries (for PNG, FLAC and Ogg Vorbis support) and there have been some teething problems getting the libraries to compile and work on Windows. Hopefully I can supply some updated binaries in the future.
Doom_user said:
I have a question/complaint about Chocolate Doom. When running a screen resolution of 1920x1080, why is the game rendered at 1280x1000 instead of 1280x960? 1280x1000 isn't a 4:3 aspect ratio and as a result everything gets vertically stretched and looks wrong.
So first of all, the context here is that Chocolate Doom can only scale up to certain predefined sizes (640x480, 960x720, etc.). The simple answer is that 1280x1000 is closer to your actual screen size than 1280x960 is. When you're using a mode like 1920x1080, for which there is no "perfect" scale-up algorithm, it tries to pick one that's as close as possible, to minimize the amount of black border that you get at the screen edges.
You ask another good question, which is: why is there 1280x1000 in addition to 1280x960? The answer is complicated so bear with me.
When scaling up the screen and doing aspect ratio correction, there are two possible ways to adjust to the desired 4:3 aspect ratio. The first is to scale up and stretch the screen vertically. This is what you get when you're using 640x480 for example. 640x400 is a pixel-doubled 320x200, which is then stretched to the desired aspect ratio of 640x480.
The other option is that you can squash the screen horizontally. When you're using 800x600 this is what's happening: 320x200 is tripled up to 960x600 and then squashed horizontally to 800x600.
These are essentially two different algorithms that achieve the same thing, though they each can reach different sets of resolutions. Without the squashing algorithm it wouldn't be able to do 800x600, which is (or was) a very common resolution.
When you're using 1280x960 you're getting the stretched version (320x200->1280x800->1280x960) whereas 1280x1000 is the squashed version (320x200->1600x1000->1280x1000). Note that the squashed resolution is actually the wrong aspect ratio (1.28 rather than 1.33). In your case that's what you get because it's slightly closer to the ideal 1920x1080.
Several of the squashing aspect ratios are actually at this wrong 1.28 aspect ratio. Even though it's not exactly right, it's closer to 1.33 than the "uncorrected" 1.6 that you get from simple pixel doubling. However, after considering this more I do think you're right to bring it up. It's better to use the right aspect ratio in this case and I don't think that 1280x1000 adds anything. I've filed a bug to remove 1280x1000.
In the future I hope these issues should go away as Chocolate Doom will be able to use hardware scaling to efficiently reach any resolution. There's an experimental branch called gl-branch that adds this, or you can check out the bug to add it.
|
Oct 25 2014 06:18 
