kaleb. Posted September 25, 2020 i dunno if anyone has reported this issue, but with this version of prboom+ only, if i move my mouse very slowly it just doesnt move at all for some reason 0 Share this post Link to post
GoneAway Posted September 25, 2020 That's every version of prboom+ that I'm aware of. It's possible you didn't hit the low threshold on versions before the sdl2 switch though. But actually if you use the dev build there is a new option to use updated mouse code that doesn't do that. 0 Share this post Link to post
Da Werecat Posted September 25, 2020 Sounds like -shorttics though? I recall there were issues with that, but I don't remember when/if they were resolved. 0 Share this post Link to post
kaleb. Posted September 26, 2020 (edited) its definitely not an issue on PrBoom-Plus_2.5.1.5.r4526, for me at least 0 Share this post Link to post
GoneAway Posted September 26, 2020 Are you playing with longtics or shorttics? With shorttics this is just how mouse movement is handled in prboom+...it doesn't "store" partial turns so if you don't turn enough to click to the next notch, it won't turn. 0 Share this post Link to post
maratnugmanov Posted September 27, 2020 (edited) This applies to glboom-plus.exe, not tested software mode: Running both prboom-plus-2.5.1.4 and prboom-plus-2.5.1.7um and I can surely say that the latter is messing with mouse support. It has input lag, also in-game slider position is differ, i.e. I have sensitivity set at 8 (i mean 8 times pushing arrow right from zero position) and in 2.5.1.7um I should set 21 to get the same result. But still it doesn't fix input lag. BTW I have mouse acceleration disabled in Windows 10 and 2.5.1.4 doesn't suffer from anything like that, I am checking myself running it back to back. UPDATE: I checked all versions from the very first 2.5.1.4um test and the behavior is the same - input lag and different mouse sensitivity slider. Edited September 28, 2020 by maratnugmanov 0 Share this post Link to post
Valboom Posted October 9, 2020 (edited) On 6/27/2020 at 9:20 PM, maxmanium said: News on the release of the next version? 4 Share this post Link to post
seed Posted October 9, 2020 (edited) 2 hours ago, Valboom said: Not happening at any point in the near future, so do not expect any change for the time being. Graf is busy with other projects, and so am I, for that matter. Your best bet is to compile it yourself from source or use the builds me and Never_Again post here periodically. A version bump is a long way off. 1 Share this post Link to post
Altazimuth Posted October 12, 2020 On 10/9/2020 at 12:27 PM, seed said: Graf is busy with other projects This reminds me. How do folks feel about having the main repo be on a new organisation or similar set up for this? Given this is primarily a community effort it seems like having it hosted by something in the vein of chocolate-doom or team-eternity would be suitable. 6 Share this post Link to post
seed Posted October 12, 2020 I've got nothing against that, but I'm not sure I understand what you mean by having it "under new organization". Someone else taking over or? 0 Share this post Link to post
Altazimuth Posted October 12, 2020 Organisations are a Github feature that are over a decade old now. https://github.blog/2010-06-29-introducing-organizations/ 0 Share this post Link to post
seed Posted October 12, 2020 (edited) Ah, that kind of organization, I see now. Same thing, got no problems with it, especially if it will help speeding up development even more. 0 Share this post Link to post
TheNoob_Gamer Posted November 11, 2020 Sorry for the bump - has the demo desyncing issue got sorted out? 0 Share this post Link to post
JadingTsunami Posted November 14, 2020 On 11/11/2020 at 2:07 AM, TheNoob_Gamer said: Sorry for the bump - has the demo desyncing issue got sorted out? I'm not aware of any unresolved demo de-sync issues. Could you be more specific if you know of one? Note that access the menus (via pressing "esc") during the intermission screen will de-sync, but this is a known behavior. I think there are some proposed enhancements that may fix it, but nothing is implemented. I'm sure a tested PR addressing it would be welcomed. 0 Share this post Link to post
LexiMax Posted November 14, 2020 On 10/12/2020 at 10:25 AM, Altazimuth said: This reminds me. How do folks feel about having the main repo be on a new organisation or similar set up for this? Given this is primarily a community effort it seems like having it hosted by something in the vein of chocolate-doom or team-eternity would be suitable. I actually have a doomtech organization leftover from when I used to mirror old SVN repositories on github, named after the old IRC channel. Would that work? 1 Share this post Link to post
4shockblast Posted November 23, 2020 I'm not sure if this is related to the above issue for desyncs with esc on intermissions, but there's a couple Chex Quest series demos that I found that desync in PrBoom+ 2.5.1.5 and 2.5.1.7 based on my testing: https://www.dsdarchive.com/files/demos/chex/50443/cq-410.zip for Chex 1, https://www.dsdarchive.com/files/demos/chex2/50359/cq2-446.zip for Chex 2. Both were recorded in Crispy Doom, and Crispy plays them back, as well as vanilla, but PrBoom+ desyncs at the start of map 2. In both cases, there are pause tics on the map 1 intermission for some reason, so that might be part of the reason. 0 Share this post Link to post
GoneAway Posted November 30, 2020 (edited) https://github.com/coelckers/prboom-plus/issues/143 fyi If anyone runs in to this before it is fixed, the workaround is to change to opengl and close the program, then change the resolution after reopening it. 0 Share this post Link to post
Shadow Hog Posted November 30, 2020 Weird, I'd always figured GlBoom+ didn't let you use the non-OpenGL renderer - which was why PrBoom+ was supplied alongside it. Thus I'd never have thought to try this. 0 Share this post Link to post
seed Posted November 30, 2020 28 minutes ago, Shadow Hog said: Weird, I'd always figured GlBoom+ didn't let you use the non-OpenGL renderer - which was why PrBoom+ was supplied alongside it. Thus I'd never have thought to try this. No, the render can be changed in both executables, and both have their features and limitations. GlBoom has bugged transparent projectiles and a textured automap. PrBoom doesn't have it, but has working transparent projectiles. 0 Share this post Link to post
Da Werecat Posted November 30, 2020 I thought OpenGL in software exe is just for output? Changing mode can affect translucency, but that's about it; most of the things are still software-rendered. 0 Share this post Link to post
seed Posted November 30, 2020 (edited) 31 minutes ago, Da Werecat said: I thought OpenGL in software exe is just for output? Changing mode can affect translucency, but that's about it; most of the things are still software-rendered. This prompted me to recheck, and you are indeed right, dang. Seems I've (we?) been misinformed all this time. Changing the video mode to GL in the software exe does indeed change just the output. It's otherwise still Software. This is different from the GL exe, where it actually changes between the modes. 0 Share this post Link to post
VoanHead Posted December 2, 2020 (edited) I, uhh, been meaning to ask: (Note: I'm not trying to derail or lose focus of this thread, just wanted a few answers) Is this fork of PrBoom+ that good ol' Le No Chicken has made and that you wonderful geniuses have improved upon more faithful and better than the Eternity Engine when it comes to running wads that require Boom or MBF? This fork is fucking amazing b/c the latest 2.5.1.5 test version of PrBoom+ is buggy af on my laptop, so I had to use EE, and then I gave this thing a shot, right? Anyways, I just wish to know if this fork is better suited than EE is? 0 Share this post Link to post
seed Posted December 2, 2020 (edited) Uh... yes, this is Graf's fork. And whether it is better suited than Eternity depends on what you are looking fork. For MBF/Boom wads they should be the same, unless you want to record demos, not sure if Eternity can record them yet, just play back. There is no competition with Eternity here. 0 Share this post Link to post
VoanHead Posted December 2, 2020 5 hours ago, seed said: Uh... yes, this is Graf's fork. And whether it is better suited than Eternity depends on what you are looking fork. For MBF/Boom wads they should be the same, unless you want to record demos, not sure if Eternity can record them yet, just play back. There is no competition with Eternity here. Aight, thanks, if I was making it look like there’s competition between the two SPs, I wasn’t really, and my apologies for doing so. I just had a tiny bit of confusion between the two when it came to MBF/Boom custom monsters and seeing how they do on each SP. It all boils down to preference at the end of the day. 0 Share this post Link to post
kaleb. Posted December 4, 2020 On 11/30/2020 at 1:43 PM, seed said: No, the render can be changed in both executables, and both have their features and limitations. i just wish the software renderer let you change the FOV too 0 Share this post Link to post
GoneAway Posted December 7, 2020 https://github.com/coelckers/prboom-plus/issues/145 FYI 0 Share this post Link to post
Linuxmaster1992 Posted December 11, 2020 Question: How come the latest source code does not come with the bootstrap file? I am interested in compiling this version, since it has been updated much more recently compared to anything else. 0 Share this post Link to post
fabian Posted December 11, 2020 20 minutes ago, Commodore Forever! said: Question: How come the latest source code does not come with the bootstrap file? I am interested in compiling this version, since it has been updated much more recently compared to anything else. We switched from Automake to CMake. 0 Share this post Link to post
Linuxmaster1992 Posted December 11, 2020 Cool! So I guess I point cmake to where the source code is, generate a makefile, and go from there? 0 Share this post Link to post