kler Posted June 10, 2020 (edited) 5 hours ago, Da Werecat said: Do you have the same problem with other games running in 4:3 modes? Stretching is the defaut behavior. Some displays can center or stretch without distortion depending on the mode set in their settings, and it also should be adjustable driver-side. Unless you have to use one of the numerous AMD video drivers where the feature is broken. You can always try to set a widescreen resolution if everything else fails. I don't think restarting a level works for recording. Last time someone asked about the best way to restart recording, restarting the game was the only option presented. Hopefully, I will be corrected if I'm wrong. Additional HUD options are all for the fullscreen HUD, which is accessible by pressing + enough times, or by pressing F5 (keep pressing it to switch layouts). I Just tried to use the version compiled by seed and the aspect ratio now works without issue! :) Thank you for the HUD tip! It now correctly displays the time Regarding the level restart - the bind is there so I assume that there must be a way although it is not working (Also I think I've seen people do it on twitch). I can't possibly believe that the only way is to close the program and restart the bat with the demo being overwritten every time (that would really be a dealbreaker for me) 4 hours ago, ReaperAA said: In my case, I get mouse lag in both Crispy and PrBoom+ when Vsync is on and this goes away when Vsync is off. I just tried with both and couldn't find any noticeable difference on my end - It's also hard to tell if I'm not imagining things because my steelseries broke and right now I'm using a super cheap noname mouse with a HORRIBLE sensor. So I can't really trust my baseline but it still feels like it's "slightly" better on prboom+. Right now, I think that If I manage to find a way to restart the level and have a new demo record start every time like on crispy - I'd be all set and happy :) Thanks for trying to help guys! 1 Share this post Link to post
Da Werecat Posted June 10, 2020 I think Choco 3.x got significantly worse mouse input, and ports based on it followed. Too lazy to check, but it's probably that. Maybe disabling enhanced pointer precision in Windows could help, but it's not ideal to turn it on and off every time you play. Coincidentally, PrBoom had this problem in the past, but it was fixed (in -Plus) roughly around the same time Choco got worse. 1 Share this post Link to post
seed Posted June 10, 2020 3 hours ago, Da Werecat said: I think Choco 3.x got significantly worse mouse input, and ports based on it followed. Too lazy to check, but it's probably that. Maybe disabling enhanced pointer precision in Windows could help, but it's not ideal to turn it on and off every time you play. Coincidentally, PrBoom had this problem in the past, but it was fixed (in -Plus) roughly around the same time Choco got worse. Choco 3.x is quite snappy for me, so I don't think that's the case. I think the problem is simply SDL since it's the one constant between all ports that suffer from input lag. Even ports such as vkQuake do for me. SDL's nput handling simply isn't great, and when you turn VSync ON, especially if the framerate is capped to 60 rather than 35 or so, it becomes very obvious. Disabling that setting in Windoze likely does nothing since the ports use raw input anyway. 1 Share this post Link to post
Fonze Posted June 10, 2020 13 minutes ago, seed said: Disabling that setting in Windoze likely does nothing since the ports use raw input anyway. Enhanced pointer precision in windows affects mouse control while playing doom. 0 Share this post Link to post
kler Posted June 10, 2020 (edited) 4 hours ago, Da Werecat said: Maybe disabling enhanced pointer precision in Windows could help Oh, I'd rather have someone shoot me in the groin than playing with that horrible nonlinear accel. Always turned off for me. That option doesn't affect input lag though. Honestly, It might very well be my mouse - I think that it's making up for its terrible polling rate and IPS by implementing some hardware accel. Only way to be sure would be to either try with my click broken rival 110 or wait until I save enough for a logitech g pro hero wired. CBA to get down there and plug the rival just to test that so it'll have to be the second option. About the level restart during demo recording and separate demo files, anyone has an idea? :( 0 Share this post Link to post
seed Posted June 10, 2020 (edited) 28 minutes ago, Fonze said: Enhanced pointer precision in windows affects mouse control while playing doom. Not if the ports already implement raw input and use it by default/the user toggles it on, where it gets completely bypassed... Pretty sure all existing - and actively maintained - Doom ports have it enabled by default. 0 Share this post Link to post
wallabra Posted June 10, 2020 3 hours ago, seed said: Choco 3.x is quite snappy for me, so I don't think that's the case. I think the problem is simply SDL since it's the one constant between all ports that suffer from input lag. Even ports such as vkQuake do for me. SDL's nput handling simply isn't great, and when you turn VSync ON, especially if the framerate is capped to 60 rather than 35 or so, it becomes very obvious. Disabling that setting in Windoze likely does nothing since the ports use raw input anyway. I think it is possible to use SDL to "grab" and "ungrab" the mouse, and listening to mouse events if (and only if) the mouse is grabbed. Unreal Tournament's community native patch type thing, XC_Engine, has a Raw Input option, and it is usually the preferred way to play. You do, of course, need to write some code to convert platform-specific mouse events into either a common format, or into a format that is already read by code above (like X11 mouse events). 2 Share this post Link to post
Bob9001 Posted June 16, 2020 May have been asked before, but is it possible for the new fork of PRBOOM to get an auto-restart button like crispy? Sorry if this has already been asked/answered. 0 Share this post Link to post
fabian Posted June 16, 2020 1 hour ago, Bob9001 said: May have been asked before, but is it possible for the new fork of PRBOOM to get an auto-restart button like crispy? Sorry if this has already been asked/answered. Somebody is working on this: https://github.com/coelckers/prboom-plus/issues/88 2 Share this post Link to post
Bob9001 Posted June 18, 2020 On 6/16/2020 at 8:44 PM, fabian said: Somebody is working on this: https://github.com/coelckers/prboom-plus/issues/88 Awesome thank you, I reliased I posted in wrong thread when I made the above post so apologies :) 0 Share this post Link to post
plums Posted June 18, 2020 So PrBoom+ no longer compiles for me on Linux, and I think it's due to my distro moving to GCC 10. Has anyone else encountered this? 0 Share this post Link to post
fabian Posted June 18, 2020 1 hour ago, plums said: So PrBoom+ no longer compiles for me on Linux, and I think it's due to my distro moving to GCC 10. Has anyone else encountered this? This has already been fixed in GIT: https://github.com/coelckers/prboom-plus/commit/8a390a16853aef9348d714eb3b0b4e15f39ff217 2 Share this post Link to post
plums Posted June 18, 2020 @fabian Thanks! That's the UMAPINFO fork/continuation right? For some reason I was under the impression it still didn't build on Linux. I'll have to give it a shot. 0 Share this post Link to post
zaichikred Posted June 30, 2020 (edited) I just decided to try out prboom-plus, downloaded and compiled it from sourceforge today. I'm running on ubuntu 18 at 1920x1080 fullscreen with doom2.wad, and I have just noticed the guns seem very inaccurate, like I will miss enemies right in front of me. Is this a known behavior/bug, or something with a fix I just don't know about? I mention resolution because maybe that's it? I tried playing the game in gzdoom ( also on this linux box ) just to see if it was my imagination but no it's very obvious when I come back to prboom-plus 0 Share this post Link to post
seed Posted June 30, 2020 1 hour ago, zaichikred said: I just decided to try out prboom-plus, downloaded and compiled it from sourceforge today. I'm running on ubuntu 18 at 1920x1080 fullscreen with doom2.wad, and I have just noticed the guns seem very inaccurate, like I will miss enemies right in front of me. Is this a known behavior/bug, or something with a fix I just don't know about? I mention resolution because maybe that's it? I tried playing the game in gzdoom ( also on this linux box ) just to see if it was my imagination but no it's very obvious when I come back to prboom-plus That's normal, the blockmap bug says hi. You're probably playing with the Default preset in GZDoom as it preserves the blockmap bug too, and quite well I dare say. BTW I would also point you to the UMAPINFO fork instead, the original PrBoom Plus has ceased development after the transition to SDL2 and the maintainer considers it "complete" since. There will be no further support and updates for it. Development has since moved here: 0 Share this post Link to post
zaichikred Posted June 30, 2020 20 minutes ago, seed said: That's normal, the blockmap bug says hi. You're probably playing with the Default preset in GZDoom as it preserves the blockmap bug too, and quite well I dare say. BTW I would also point you to the UMAPINFO fork instead, the original PrBoom Plus has ceased development after the transition to SDL2 and the maintainer considers it "complete" since. There will be no further support and updates for it. Development has since moved here: Oh so it's actually a bug in the original game that PrBoom+ replicates, but I've gotten so used to Zdoom over the last decade+ where its fixed that I didn't know it's the original behavior. Thanks 0 Share this post Link to post
drfrag Posted July 1, 2020 But that's a very rare bug. Could it be a compiler related problem instead? PRBoom did not fix the bug AFAIK, ZDoom did but unless i'm wrong it's a partial fix for hitscans and monsters. The old code can be used via a compatibility option but the fix is on by default. Then both ZDoom and PRBoom use a real PRNG instead of the original Doom fixed table but the results should be pretty much the same for both ports despite being different algorithms. Comparing with original Doom would be another thing. 0 Share this post Link to post
rehelekretep Posted July 4, 2020 currently playing through valiant (in line with decino's playthrough on Youtube). i got to map07 and its really strange but i cant see the things (viles or barrels) through the transparent windows. any idea why this is happening? im playing with glboom+ 2.5.1.4 when i play in prboom+ 2.5.1.4 i can see them. 0 Share this post Link to post
rehelekretep Posted July 4, 2020 7 minutes ago, rehelekretep said: currently playing through valiant (in line with decino's playthrough on Youtube). i got to map07 and its really strange but i cant see the things (viles or barrels) through the transparent windows. any idea why this is happening? im playing with glboom+ 2.5.1.4 when i play in prboom+ 2.5.1.4 i can see them. ok i found the culprit: if you have Smooth Sprite Edges to YES, the viles and barrels disappear. does anyone know why? 0 Share this post Link to post
seed Posted July 4, 2020 Are you sure you have transparency enabled on the first page? Not seeing things through otherwise transparent objects means that it's turned off. Why are you still using 2.5.1.4 BTW? 0 Share this post Link to post
rehelekretep Posted July 4, 2020 (edited) yeah transparency is enabled. im going to take a picture in the exact same space with Smooth Sprite Edges on and off. a mixture of SDL2 and changes i cant work out makes prboom+ 2.5.1.5 and up feel and look laggy, both to the eyes and my mouse movement. whereas 2.5.1.4 looks and feels much better. 0 Share this post Link to post
rehelekretep Posted July 4, 2020 note the lights through the force-field in the background (transparency on in both shots) Smooth Sprite Edges ON Smooth Sprite Edges OFF 3 Share this post Link to post
dmslr Posted July 4, 2020 That's interesting. How does this option even work? 0 Share this post Link to post
Gradius Posted August 1, 2020 On 7/4/2020 at 7:31 PM, dmslr said: That's interesting. How does this option even work? Smooth texture filtering will cause the edges of transparent objects to have a gradient from opaque to transparent, which can cause sorting issues (presumably pictured above). There's also a speed penalty to semi-transparency. So turning it off simply sets a hard cut off threshold for transparent edges (i.e. any edge >0.5 transparency is fully opaque, any pixels below that threshold are discarded entirely), which won't cause depth sorting issues or create graphically taxing overdraw but may look worse. 2 Share this post Link to post
rehelekretep Posted August 3, 2020 cheers Gradius - i understood about 50% of that (my fault, not yours :D ) but appreciate you explaining it! 1 Share this post Link to post
BigBoy91 Posted August 5, 2020 I hate to be that guy, but is a restart demo key ever going to be implemented? That would be awesome. 0 Share this post Link to post
seed Posted August 5, 2020 2 hours ago, lazy91geek said: I hate to be that guy, but is a restart demo key ever going to be implemented? That would be awesome. Someone's trying to achieve that in the UMAPINFO fork, that would be your best bet. This one is dead. 0 Share this post Link to post
BigBoy91 Posted August 5, 2020 Ah, yeah. I need to get in the habit of using that thread. 0 Share this post Link to post
maxmanium Posted August 5, 2020 8 hours ago, seed said: Someone's trying to achieve that in the UMAPINFO fork, that would be your best bet. This one is dead. It's dead? I was under the impression Andrey was making very, very slow additions, but maybe not. 2 Share this post Link to post
Andromeda Posted August 5, 2020 2 hours ago, maxmanium said: It's dead? I was under the impression Andrey was making very, very slow additions, but maybe not. That was my understanding as well, at least according to this comment by Proff. 2 Share this post Link to post