New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend to other resolutions #13

Closed
No-Kelvin opened this Issue Apr 15, 2014 · 16 comments

Comments

Projects
None yet
4 participants
@No-Kelvin

No-Kelvin commented Apr 15, 2014

I'm not talking about field of view nor screen scaling (as it happens in chocolate-doom), just support for more resolutions. User should have the option to keep the game's aspect ratio (resulting in black bars on the sides) or just stretch it to the whole screen.

@fabiangreffrath fabiangreffrath added enhancement and removed invalid labels Jul 8, 2014

@fabiangreffrath

This comment has been minimized.

Owner

fabiangreffrath commented Sep 8, 2014

To provide some rationale for the decision adding the "wontfix" tag, please refer to this discussion about how the software renderer is falling apart when extended far beyond its original resolution:
http://www.doomworld.com/vb/source-ports/69966-prboom-graphical-glitches/2/

@Danfun64

This comment has been minimized.

Danfun64 commented Apr 22, 2015

If this and #8 are considered wontfix, why are they still open?

@fabiangreffrath

This comment has been minimized.

Owner

fabiangreffrath commented Apr 25, 2015

I was expecting more requests to even higher display resolutions and wanted to keep this bug visible in order to answer these requests early on.

@Zodomaniac

This comment has been minimized.

Collaborator

Zodomaniac commented Mar 9, 2016

Is it possible to implement 16x10 widescreen resolutions (640x400, 960x600, 1280x800 etc.) in Windowed mode?

@fabiangreffrath

This comment has been minimized.

Owner

fabiangreffrath commented Mar 9, 2016

It would be a major pain in the ass to implement proper rendering in widescreen modes, because that changes the field of view, which is hard-coded to be 320:200 in a lot of places in the code.

Don't mix this up with DR's "widescreen" mode. It merely renders the part above the status bar and puts some HUD elements on it.

@Zodomaniac

This comment has been minimized.

Collaborator

Zodomaniac commented Mar 10, 2016

Well, if 640x480 and other 4:3 resolutions in windowed mode are possible,
why aren't 640x400 and other 16x10 possible?

2016-03-09 19:00 GMT+03:00 Fabian Greffrath notifications@github.com:

It would be a major pain in the ass to implement proper rendering in
widescreen modes, because that changes the field of view, which is
hard-coded to be 320:200 in a lot of places in the code.

Don't mix this up with DR's "widescreen" mode. It merely renders the part
above the status bar and puts some HUD elements on it.


Reply to this email directly or view it on GitHub
#13 (comment)
.

@fabiangreffrath

This comment has been minimized.

Owner

fabiangreffrath commented Mar 10, 2016

640x400 is a possible resolution if you disable "Aspect Ratio Correction" in the Video settings of crispy-doom-setup. It is even the framebuffer's native resolution.

However, Crispy Doom inherits Choco's rendering algorithm which stretches each pixel by factor 1.2 vertically before it is rendered to screen (if Aspect Ratio Correction is enabled, that is). This is all based on look-up tables and thus fixed to the original resolution, which I merely extended to 640x400 for Crispy.

Things will get more flexible with the switch to SDL2, but I am still unsure if Crispy will ever get native widescreen resolution support.

@Zodomaniac

This comment has been minimized.

Collaborator

Zodomaniac commented Mar 10, 2016

Thanks for explaining, I didn't know what this Fix Aspect Ratio was.
BTW, my display is 1920x1080, and when I tried 1600x1000 window it fell
back to 1280x800, why?
the task bar is narrower than 80 pixels of difference and I set window position to "center" as Fraggle told me.)

@fabiangreffrath

This comment has been minimized.

Owner

fabiangreffrath commented Mar 10, 2016

Well, because 1600x1200 isn't an integer multiple of 640x400, whereas 1280x800 is simply (640x400)*2.

You can only have integer multiples of 640x400 or -- with Aspect Ratio Correction enabled -- 640x480. In the latter case each pixel is stretched vertically by factor 1.2. These are all our choices with the software-based rendering of the SDL1.2 code base. There are no resolutions available in between.

@Zodomaniac

This comment has been minimized.

Collaborator

Zodomaniac commented Mar 11, 2016

Thus, it appears that 1600x1000 (not 1200, you've misread it ;)) and 960x600 window resolutions are selectable in the menu but impossible because they are not integer multiples of 640x400. Maybe remove them from the menu then?

Congrats on releasing Crispy 3.3 btw ;) was looking forward to it, thanx a lot!

@fabiangreffrath

This comment has been minimized.

Owner

fabiangreffrath commented Mar 11, 2016

No, wait, I was mistaken. There are some intermediate resolutions which get some interpolated pixels inserted in horizontal or vertical (or both) directions.

It is about two years ago that I adopted the software scaling routines for Crispy Doom. Somehow my brain must have retrospectively simplified matters as some kind of self-protection mechanism. ;)

All the resolutions that are shown in the Video settings menu are really available, though the offer is currently quite limited. With SDL2 the rendering area will be scaled to whatever dimensions your screen or window has and it will get stretched into the right aspect ratio on the fly.

@Zodomaniac

This comment has been minimized.

Collaborator

Zodomaniac commented Mar 12, 2016

Then I think I have to report a bug because in windowed mode 960x600 resolution falls back to 640x400 and 1600x1000 falls back to 1280x800.
Choco doesn't have this bug.

@fabiangreffrath

This comment has been minimized.

Owner

fabiangreffrath commented Mar 12, 2016

Hm, yes, you are right. If Aspect Ratio Correction is disabled, then only integer multiples of the original resolution are available. I should fix this in the setup program, thank you!

fabiangreffrath added a commit that referenced this issue Mar 18, 2016

@Zodomaniac

This comment has been minimized.

Collaborator

Zodomaniac commented Mar 25, 2016

Downloaded the Mar 25 daily build, looks like without 'fix aspect ratio' the 960x600 and 1600x1000 resolutions (not integer multiples of 640x400) are just removed. Could you make'em work instead of removing or is it impossible?

@fabiangreffrath

This comment has been minimized.

Owner

fabiangreffrath commented Mar 29, 2016

These two resolutions have never been available in Crispy Doom, because they aren't integer multiples of the native 640x400 resolution, so I removed them from the list. Selected intermediate resolutions are only available in the "fix aspect ratio" mode.

However, the two resolutions are natively available in Choco, because they are 320x200 times 3 or 5, respectively.

fabiangreffrath added a commit that referenced this issue Jan 27, 2017

implement two-pass reading of extended savegame data
Else, the fireflicker thinkers are restored from the extended savegame
data just before P_UnArchiveThinkers() is called which, you guessed
it, resets all thinkers.

This came to light through @JNechaevsky's suggestion #13.

@fabiangreffrath fabiangreffrath added the SDL2 label Mar 8, 2017

@fabiangreffrath

This comment has been minimized.

Owner

fabiangreffrath commented Nov 29, 2017

I think this is fixed with the switch to SDL2 in Crispy Doom 5.0 and onward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment