prboomX 2.7.0 (Nov 3, 2023)

1 hour ago, invictius said:

I'm just having issues binding mdk to a mouse button.  Works fine for a keyboard key.  I've tried clearing the original bind in the options menu as well as the console.  That unbinds it but the rebind to mdk is what's not working.

Ah, sure. Are you by chance binding the MOUSE1/2/3 virtual buttons? Those might be missing a mapping. I think mousewheel up/down should work.

3 hours ago, JadingTsunami said:

 

Ah, sure. Are you by chance binding the MOUSE1/2/3 virtual buttons? Those might be missing a mapping. I think mousewheel up/down should work.

Mouse3.  Mousewheel is a bit cumbersome to fire a "weapon", but I can hardly complain when you've added so much for me.  I can live with it being a keyboard key.

6 hours ago, invictius said:

 

Mouse3.  Mousewheel is a bit cumbersome to fire a "weapon", but I can hardly complain when you've added so much for me.  I can live with it being a keyboard key.

Sure, I will add mouse binds soon. I need a separate system for them because the virtual mouse buttons already defined in prboom don't work (as we just learned).

10 hours ago, invictius said:

 

Mouse3.  Mousewheel is a bit cumbersome to fire a "weapon", but I can hardly complain when you've added so much for me.  I can live with it being a keyboard key.

The ability to bind mouse buttons has been added. The latest development builds should have it. If you run into any issues, let me know.

On 9/15/2023 at 10:13 AM, JadingTsunami said:

 

You might try running from a console; there could be an error printed out in the terminal but not as a pop-up window.

 

Otherwise, the Windows builds are done on Windows Server 2019; I'm not familiar with Vista backward-compatibility issues there.

"I_signalhandler: exiting on signal: signal 11"

Also happening on windows 7 where the latest prboom+ works fine.  Not trying to load any pwads.

11 hours ago, invictius said:

"I_signalhandler: exiting on signal: signal 11"

Also happening on windows 7 where the latest prboom+ works fine.  Not trying to load any pwads.

Thanks. Could you paste the entire console output? Seeing what occurred in/around the error would help.

EDIT: Also, if you are reproducing on the latest development build, that would help to know also.

On 9/20/2023 at 11:59 PM, JadingTsunami said:

 

Thanks. Could you paste the entire console output? Seeing what occurred in/around the error would help.

 

EDIT: Also, if you are reproducing on the latest development build, that would help to know also.

I've been unable to replicate it, in fact I've been unable to get your port running on 7 again.  I'm probably not going to touch that machine again for a long time, but when I do, I'll look into it again.

5 hours ago, invictius said:

 

I've been unable to replicate it, in fact I've been unable to get your port running on 7 again.  I'm probably not going to touch that machine again for a long time, but when I do, I'll look into it again.

Hmm, that's very strange. I asked for some testing on Windows machines and no one's been able to replicate the failure either. If you do find anything I would be interested to know.

This is great! And it's really handy that you can keep it in the same directory as regular PrBoom+ without the overlapping or otherwise affecting each others settings.

I just wanted to ask if this fork is still\ already capable of the viddump stuff? I have a bat file for it that works perfectly for regular PrBoom+ but didn't with X (even though I edited the file so the program's name would match, of course).

Also, the demo was recorded with X (though I doubt that that would make a difference).

7 hours ago, adamastor said:

This is great! And it's really handy that you can keep it in the same directory as regular PrBoom+ without the overlapping or otherwise affecting each others settings.

 

I just wanted to ask if this fork is still\ already capable of the viddump stuff? I have a bat file for it that works perfectly for regular PrBoom+ but didn't with X (even though I edited the file so the program's name would match, of course).

 

Also, the demo was recorded with X (though I doubt that that would make a difference).

Should be, I did not change any viddump settings at all. In fact a few of my videos I generated using the port. If you have more details on what you tried, I can try to replicate the issue.

3 hours ago, JadingTsunami said:

If you have more details on what you tried, I can try to replicate the issue.

Sure.

The bat file I use in PrBoom+ is this:

@echo off
setlocal
cd /d "%~dp0"
prboom-plus.exe -timedemo %1 -viddump %~n1.mp4

I just tried the same for this fork (changing "prboom-plus.exe" to "prboomx.exe") and it didn't work.

I have not changed the video capture settings in either Plus or X.

3 minutes ago, adamastor said:

Sure.

 

The bat file I use in PrBoom+ is this:

 

@echo off
setlocal
cd /d "%~dp0"
prboom-plus.exe -timedemo %1 -viddump %~n1.mp4

 

I just tried the same for this fork (changing "prboom-plus.exe" to "prboomx.exe") and it didn't work.

 

I have not changed the video capture settings in either Plus or X.

Did you check your prboomX.cfg contains the same settings as your prboom-plus.cfg for viddump? They're "cap_*" in the config file.

They appear to be the same yes.

Here's a screenshot:

2 minutes ago, adamastor said:

They appear to be the same yes.

 

Here's a screenshot:

 

 

Looks good; and when you say it "didn't work", could you describe what happened? The demo played, but no video was produced?

And, just verifying, the exact same batch file with the same demo works with the latest prboom-plus (2.6.66)?

13 minutes ago, JadingTsunami said:

Looks good; and when you say it "didn't work", could you describe what happened? The demo played, but no video was produced?

It didn't play the demo, actually, which was weird. As if it was starting to but crashed, somehow.
I think it produced two files named temp_a.nut and temp_v.nut. Maybe it has to do with the dependencies you linked? I only got the ones that X warned me it was missing.

17 minutes ago, JadingTsunami said:

And, just verifying, the exact same batch file with the same demo works with the latest prboom-plus (2.6.66)?

Exactly right.

19 minutes ago, adamastor said:

It didn't play the demo, actually, which was weird. As if it was starting to but crashed, somehow.
I think it produced two files named temp_a.nut and temp_v.nut. Maybe it has to do with the dependencies you linked? I only got the ones that X warned me it was missing.

 

Exactly right.

Strange. I am not able to reproduce the issue; replaying a timedemo and recording video is working fine for me.

A few things to try:

1. Unzip all the Windows dependencies rather than just the missing ones

2. See if there is terminal output (try running the batch file from a Command Prompt or PowerShell and pasting the output here)

3. If none of that helps, if you send me the exact demo I'll try to reproduce locally on my machine

Do you have ffmpeg.exe installed in the same directory as prboomx.exe?

1 hour ago, JadingTsunami said:

A few things to try:

1. Unzip all the Windows dependencies rather than just the missing ones

2. See if there is terminal output (try running the batch file from a Command Prompt or PowerShell and pasting the output here)

3. If none of that helps, if you send me the exact demo I'll try to reproduce locally on my machine

I'll try those once I get the chance and let you know.

44 minutes ago, fabian said:

Do you have ffmpeg.exe installed in the same directory as prboomx.exe?

I do, yeah. I have both PrBoom versions in the same directory.

Does the demo play back fine without -viddump?

You might also want to check if there are files called sound_stdout.txt, sound_stderr.txt, video_stdout.txt, and video_stderr.txt, and if there are, whether there are any error messages in those.

Yeah, it really had to do with those Windows dependencies. It works perfectly fine now!

Do I need the pdb files, or are just the dlls fine?

50 minutes ago, adamastor said:

Do I need the pdb files, or are just the dlls fine?

PDB files are for debugging purposes, so you only need them if the program crashes and you want to help find the cause of the crash.

Thanks a lot for all the help guys!

Please keep downloading latest versions of FFMPEG from this website :

https://www.gyan.dev/ffmpeg/builds/

I've been using this as my main port driver for a bit. It's really nice. The console is a dream come true for a PRBoom port.

That being said, there are a couple of requests I'd have to make my own enjoyment better, and possibly others' as well.

-The tag finder is brilliant and a lifesaver when looking around for the last couple secrets, but I'd like for it to activate while using IDDT as well as having Allmap.

-I'd also particularly like to have an internal resolution setting, so I can have my window be in 1080p while still giving the game a crispier look. Currently I have to choose between fullscreen, fullscreen with crispy but life becomes difficult if you want to tab out, or windowed in which it's either fullscreen with input delay, or the screen is tiny, and there's probably still input delay.

Excellent work on this port either way. I'm going to continue to use it whether or not either of these are submitted.

1 hour ago, Pickles said:

I've been using this as my main port driver for a bit. It's really nice. The console is a dream come true for a PRBoom port.

 

That being said, there are a couple of requests I'd have to make my own enjoyment better, and possibly others' as well.

 

-The tag finder is brilliant and a lifesaver when looking around for the last couple secrets, but I'd like for it to activate while using IDDT as well as having Allmap.

-I'd also particularly like to have an internal resolution setting, so I can have my window be in 1080p while still giving the game a crispier look. Currently I have to choose between fullscreen, fullscreen with crispy but life becomes difficult if you want to tab out, or windowed in which it's either fullscreen with input delay, or the screen is tiny, and there's probably still input delay.

 

Excellent work on this port either way. I'm going to continue to use it whether or not either of these are submitted.

Thanks, I'm really glad you're enjoying it.

On the tag finder: Sure, I implemented the iddt cheating idea. It's in the latest developer build.

On the internal resolution setting, I'm not sure I understood. There is an "exclusive_fullscreen" parameter which, when set to 0, should allow tabbing out. Are there other ports that implement the idea you're talking about that I might refer to?

4 hours ago, JadingTsunami said:

 

On the internal resolution setting, I'm not sure I understood. There is an "exclusive_fullscreen" parameter which, when set to 0, should allow tabbing out. Are there other ports that implement the idea you're talking about that I might refer to?

Typically, the internal resolution is the renderer resolution, which is then scaled by the GPU to the desktop/window size. By default SDL2 fullscreen is a borderless window with forced vsync. I assume the user wants exclusive fullscreen mode with scaling and vsync disabled (less input delay). I think DSDA-Doom has it with an OpenGL renderer, we have it in Woof.

17 hours ago, Pickles said:

-I'd also particularly like to have an internal resolution setting, so I can have my window be in 1080p while still giving the game a crispier look. Currently I have to choose between fullscreen, fullscreen with crispy but life becomes difficult if you want to tab out, or windowed in which it's either fullscreen with input delay, or the screen is tiny, and there's probably still input delay.

12 hours ago, rfomin said:

Typically, the internal resolution is the renderer resolution, which is then scaled by the GPU to the desktop/window size. By default SDL2 fullscreen is a borderless window with forced vsync. I assume the user wants exclusive fullscreen mode with scaling and vsync disabled (less input delay). I think DSDA-Doom has it with an OpenGL renderer, we have it in Woof.

Ah, thanks, this is helpful. If I'm understanding correctly: prboomX supports exclusive and non-exclusive software renderer modes (via the exclusive_fullscreen config file setting), but only supports exclusive fullscreen in OpenGL mode. The user is asking for non-exclusive fullscreen in OpenGL mode as well.

@Pickles - are you specifically asking about OpenGL mode for the full screen request? There is an "exclusive_fullscreen" parameter in the config file (~/.prboomX/prboomX.cfg or %APPDATA%/Local/prboomX/prboomX.cfg) which can be toggled to 1 vs. 0 to control exclusive fullscreen in software renderer modes (but not OpenGL).

5 hours ago, JadingTsunami said:

 

@Pickles - are you specifically asking about OpenGL mode for the full screen request? There is an "exclusive_fullscreen" parameter in the config file (~/.prboomX/prboomX.cfg or %APPDATA%/Local/prboomX/prboomX.cfg) which can be toggled to 1 vs. 0 to control exclusive fullscreen in software renderer modes (but not OpenGL).

I'm more wondering if it's possible to have the game render at a lower resolution than the window. Like have the game render at something like 480p in fullscreen, but the actual game window is 1080p so my monitor doesn't have to change resolution whenever I tab out.

11 minutes ago, Pickles said:

 

I'm more wondering if it's possible to have the game render at a lower resolution than the window. Like have the game render at something like 480p in fullscreen, but the actual game window is 1080p so my monitor doesn't have to change resolution whenever I tab out.

Hm, that just sounds like non-exclusive fullscreen which you can enable in settings. Set exclusive_fullscreen to 0. This doesn't work with OpenGL specifically though.

32 minutes ago, JadingTsunami said:

 

Hm, that just sounds like non-exclusive fullscreen which you can enable in settings. Set exclusive_fullscreen to 0. This doesn't work with OpenGL specifically though.

Ah. Goes to show what I know about ports.