Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

vadrig4r

Members
  • Content count

    336
  • Joined

  • Last visited

3 Followers

About vadrig4r

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. vadrig4r

    How to get started with PrBoom?

    Welcome mate, it's a great community, happy Dooming.
  2. I was wondering this. I will get a recording setup and see if it's able to be captured.
  3. I tested disabling Smooth Scaling, it didn't seem to affect either the warping effect or VSync input delay. So it seems whatever this is, it is related to some point in the process of converting the SDL canvas to an OpenGL texture? If any port dev wants more spec or setup details let me know I'm happy to help.
  4. vadrig4r

    Crispy Doom 5.9.2 (Update: Sep 22, 2020)

    After some testing, on my machine the significant input lag associated with VSync was introduced between 5.5 and 5.6 (input lag not present in 5.4/5.5 and present in 5.6), which as might be expected is concomitant with when this warping seems to have been introduced.
  5. vadrig4r

    Crispy Doom 5.9.2 (Update: Sep 22, 2020)

    This seems to reference the exact issue I encountered as described in my thread here: As you stated, setting force_software_renderer to 1 fixes the extreme warping/tearing that Linguica likened to a reverse rolling shutter effect. As I mentioned in the OP of that thread, this particular behavior seemed to been introduced between 5.5 and 5.6 (at least on my machine). I'm glad there's at least a temporary fix in Crispy Doom, but I'm curious as to why it seems to have been introduced in multiple SDL2 ports having not been present in past versions (or in other games), and if there's any possibility of solving the problem at the source (which seems to be related to SDL's use of hardware rendering). As always thanks for the excellent work on this important port, fabian et al.
  6. Ah I see, you're correct I did think you were referring to the rendering effect. I have the same issue with significant input lag as a result of VSync in most ports and so tend to avoid it at all costs. Incidentally, I browsed the Crispy Doom thread and came across this recent post by maxmanium, in response to another post that seems to mention the rendering issue: Setting 'force_software_renderer' to 1 in Crispy Doom 5.7.2 does indeed fix the leaning/rolling shutter bug! With the software renderer enabled (and presumably the hardware/OpenGL renderer disabled) and VSync still disabled, tearing is minimal and unobtrusive, and the extreme leaning/warping is solved. Doing so also doesn't introduce any input lag as in the case of enabling VSync. Perhaps this information might help developers understand what is causing this behavior? I'm also curious if similar options exist for other ports.
  7. Very interesting, that seems to describe the 'leaning' effect well. I wonder what change could have introduced this behavior, and why it seems only to affect some SDL2 ports after a certain point in time. Yes, glad to see I'm not alone. As I stated it is far more noticeable/distorting to the rendered output than any usual tearing, and that I've pinpointed the patch that introduced this behavior (as exhibited on this machine at any rate). In prior patches with VSync disabled, any tearing is minor to scarcely noticeable, and does not create this clear 'leaning' effect as mentioned in Linguica's post. Do you also experience this problem in SDL1-based ports (you can quickly tell by the .dll names in the port directory)? I could not find a single SDL1 port that produces this behavior on my machine, so that's an interesting datum. That VSync doesn't mitigate the effect for you is also very curious, thanks for your input. I will test out-of-game frame rate limiters to see if it has any effect on the warping. Again, if it is purely a form of screen tearing, it is an *extremely* exaggerated instance of it, and one that was not present in past versions of these SDL2 ports (at least, on my machine), or frankly like anything that I've experienced in years of computer gaming without VSync/Swap Interval.
  8. In multiple SDL2 ports, enabling uncapped frame rate/interpolation without VSync results in a bending/warping/skewing of rendered vertical objects when the player's view moves quickly from either physical motion or mouse turning. The warping happens in the direction of motion (move left, top of vertical object leans left and vice versa), and results in a kind of 'leaning tower of Pisa' effect. It is most noticeable when closely facing a wall (such as the first corridor after the starting stairs in MAP01) and strafing side to side whilst running. It is also very noticeable when circle strafing near pillars. The effect *only* occurs in full screen for the ports I've tested, it does not occur in windowed modes. It is much more pronounced than any usual tearing that might occur. The ports I have tested are: - Crispy Doom (5.6 to today's daily build of 5.7.2), 5.5 and every version prior does not feature the bug - PRBoom+ (2.5.1.5.r4526), the SDL1-based 2.5.1.4 does not feature the bug - Eternity Engine (4.00.00 Völuspá to 4.01.00-pre-918-g981220d0) - Doom Retro (3.5.3) interestingly does not appear to have this problem, much like Crispy 5.5 - GZDoom (4.3.3) similarly functions normally with rendering interpolation enabled and VSync disabled, though it does not use SDL on Windows as far as I am aware The problem does not occur in these ports without using uncapped frame rate/interpolation. It also does not occur when using uncapped frame rate/interpolation in combination with VSync. The issue is that on most of these ports VSync introduces unplayable input delay or other issues. This seems to be a somewhat recent introduction as I didn't come across it a few years ago; also, as I mentioned it doesn't seem to be present in Crispy 5.5 or PRBoom+ 2.5.1.4. All testing performed on a 64 bit Windows 7 SP1 machine with fully updated drivers using a 60 Hz 1920x1080 LCD monitor. Is anyone else experiencing this behavior? Some other posts referencing either the warping or VSync input lag: - These two seem to reference the warping effect - These reference input lag with VSync enabled
  9. vadrig4r

    The story of Linux Heretic (And uh, ggiDoom)

    Love these historical posts, thank you for documenting this gamelore.
  10. vadrig4r

    Chocolate Doom

    If it works, it's all good. Out of interest, is it running smoothly?
  11. vadrig4r

    DOS box for doom is trash,change my mind.

    I thought I was the only one who found the Build Engine's mouse input off-putting.
  12. vadrig4r

    DOS box for doom is trash,change my mind.

    With the right dosbox version, config file, a reasonably powerful machine, and the novert TSR—it's actually quite serviceable, particularly for the original games. Without Chocolate/Crispy I would probably use it more. The default experience is pretty rough, though.
  13. vadrig4r

    LZDoom 3.86a released

    Take care of yourself @drfrag, best wishes.
  14. Crouching is not in the games mentioned in your OP, and only Hexen and Strife have jumping, so: Doom, Doom II, Final Doom, Heretic: sv_jump 1, sv_crouch 1 Hexen, Strife: sv_jump 2, sv_crouch 1
  15. Just in case you missed it OP, this was the solution that came to my mind too when reading this thread. If there's no integrated menu option within the port you're using, this solution should allow you to launch the IWADs you desire and execute a config file that sets the correct parameters for that IWAD. I personally already use such files to launch IWADs and custom WADs for convenience. If you are on a Unix-like OS you can use shell scripts for the same purpose.
×