Preferred Software-Mode Resolution

[Spectre01]

@kb1 I've never liked using vsync in FPS games because it always felt like it added some form of input delay. Just tried it in PR/GLBoom+ and everything just felt less responsive.

[Graf Zahl]

8 hours ago, kb1 said:

 It got the job done, back in the day.

 

Yes, back in the day. But like somebody earlier posted, this was with 1993's level design and detailing.

Even modern vanilla-ish stuff like Back to Saturn X will show some issues with its texture set that simply needs a bit more pixels to render adequately.

(And no, I don't think it's sufficient. I stopped believing that 20 years ago when I got my first Voodoo graphics card. I've never played anything in 320x200 again since then.

[Optimus]

I just tend to max up things, even in software I would have good frame rate on 1080p and once I tried 4k and it was ok.

I mean, you'd say what's the point, Doom is retro. One good point is, in big areas it's really good, you can see in good detail far away enemies and try to shoot them from distance. It's really cool with Nuts for example :)

 

But if the point is retro, I think the sweet spot would be 480p for me.

[Diabolución]

640x480 for the “advanced” source ports I use: Odamex, PrBoom and PrBoom-Plus. And 320x200 upscaled to 640x480 for Chocolate Doom.

[Urthar]

320x200 Chocolate, Crispy and Doom Retro

480x270 ZDoom   (1080pp / 4)

640x360 QZDoom (1080pp / 3)

 

Are what I typically use, but ideally I'd prefer some version of widescreen that retains the 320x200 pixel shape.

 

 

[jval]

1366x768 using software renderer.

 

[VGamingJunkie]

720p, same as OpenGL. Mostly because of recording.

[Liberation]

640x480 for me

 

[kb1]

On 12/7/2017 at 3:47 AM, Spectre01 said:

@kb1 I've never liked using vsync in FPS games because it always felt like it added some form of input delay. Just tried it in PR/GLBoom+ and everything just felt less responsive.

Yeah, that's possible. It's an order of operations thing. Going from 35 fps to 60 fps is tricky. Input must be read at 35 fps for game sync, but the amount of time the game waits for v-sync is highly variable. With interpolation, the frame is an arbitrary distance away from the position where the input is read. If you're sensitive enough, I suppose you could detect that gap. (I hope that was clear - man, it's a difficult concept to describe!)

 

I believe that it is possible to alleviate most of that slightly-detectable delay, with a proper, deliberate implementation. I am not yet there with my code, but I intend to study this phenomenon, as I find it interesting.