PrBoom-Plus, ver. 2.5.1.4

entryway said:

Surprisingly. Desync at viewing this demo with DOS EXE has been found only after fixing of Boom's bug. In a two years.

Actually, Opulent noted the desync here (scroll down to the entry for 11/09/03):

It desynced for me on Map10, but played back correctly with Prboom2.3.0 (failed with all other prboom versions) and Eternity3.3.1beta3.

I recollect..., but

(failed with all other prboom versions) and Eternity3.3.1beta3

I am trying to work on converting Vile's TNT 55 mins speedrun into AVI.
I gave up on dash's prboom because it crashes too much and is too slow (slow is not an issue but beiong slow *AND* crashy makes it very annoying). So I went back to prboom+.

But I am experiencing problems too. I started a whole 640x480 35fps screen dump with glboom and all options maxed out. In the middle of map08 I started to get screwed screen dumps (random blocks + messed up palette). So I stopped and decided to keep the dumps up to map07 and restart on map08 (using -warp 08). But the dumb thing will dump black screens until it gets to map08 (imagine 20,000x 901k blank screens on your HD).

It would be neat to *NOT* dump screens when using the -warp command until you get to the map specified by the -warp parameter. That would really help.

Now I am stuck with using Fraps again.

suggestion : allow it to make BMPs, that would really be nice for using avisynth.

VinceDSS said:
suggestion : allow it to make BMPs, that would really be nice for using avisynth.

Weren't they BMPs with a different extension? If so, ren *.tga *.bmp from the files' location should do the trick.

VinceDSS said:

But the dumb thing will dump black screens until it gets to map08 (imagine 20,000x 901k blank screens on your HD).

fix

Well, Dashiva's prboom may be buggy and slow but it takes screenshots of the game even when it is reduced in the taskbar and running in the background.

glboom+ takes screen both windowed and fullscreen, but when I reduce the glboom window into the taskbar and go do something else, it actually takes screens of my desktop where the glboom window was...
So I cannot dump screens and do something else.

Can you fix it so it takes real screens from the game when it is running in the background?

VinceDSS said:

Well, Dashiva's prboom may be buggy and slow but it takes screenshots of the game even when it is reduced in the taskbar and running in the background.

glboom+ takes screen both windowed and fullscreen, but when I reduce the glboom window into the taskbar and go do something else, it actually takes screens of my desktop where the glboom window was...
So I cannot dump screens and do something else.

Can you fix it so it takes real screens from the game when it is running in the background?

I assume this is related to the problem that when you 'prboom -timedemo' any prboom2.2.6 demo it displays nothing.
Prboom2.2.4 keeps it visually displayed in fastforward. (however, prboom2.2.4 doesn't have the skipsec(etc) features :)

Opulent said:

I assume this is related to the problem that when you 'prboom -timedemo' any prboom2.2.6 demo it displays nothing.

Works fine for me. Which version (number) are you using? I vaguely recall that there had been a clash of some sort between -timedemo and uncapped framerate (not surprising when you consider their functions), but that seems to be gone now.

BTW, are you aware that you can vary the gamespeed ingame (Num+, Num- and Num* by default)? This largely takes the place of -timedemo and -fastdemo, and provides a lot more flexibility too.

btw, I would need some info on how -framescapture work.

If I use capped FPS, it's easy, I get 35 fps.

But if I want uncapped with smooth playback, how will framescapture work? does it have a max fps? or will fps vary vary depending on CPU usage/map complexity?

I would like to get my vids a little less choppy, because the capped 35 fps is making slightly choppy vids (just like normal doom looks).

Dash's prboom doesnt have this choppyness because it interpolates several frames between each tic and blends them together, making the video ultra smooth.

what is your command line?
glboom.exe -window -geom 640x480 -timedemo 30uv1437.lmp -framescapture 1 a

If I use capped FPS, it's easy, I get 35 fps.
But if I want uncapped with smooth playback, how will framescapture work?

There is no dependence on movement_smooth

because it interpolates several frames between each tic

I suggest to use:
demo_smoothturns 1
demo_smoothturnsfactor 6

glboom -timedemo cp1v0452 -iwad doom.wad -framescapture 1 1 -nosound -nomusic

with 640x480, capped FPS, smooth turns on and factor 6

If I use uncapped framerate ? what will be the rate of the screen capture ?

VinceDSS said:

If I use uncapped framerate ? what will be the rate of the screen capture ?

same

P.S. What program are you using for compression? I tried only bmp2avi.exe

I use avisynth, virtualdub, and the following codecs : HUFFyuv, DivX, xvid and x264

avisynth scripting is quite interesting and powerful. And it's faster than virtualdub filters for most things (change fps, resize, brighten...). In combination with virtualdub, tt can compress the tga/bmp right into your final AVI (xvid or whatever), no need to have a step with a huge AVI in between.

Grazza said:

Works fine for me. Which version (number) are you using? I vaguely recall that there had been a clash of some sort between -timedemo and uncapped framerate (not surprising when you consider their functions), but that seems to be gone now.

BTW, are you aware that you can vary the gamespeed ingame (Num+, Num- and Num* by default)? This largely takes the place of -timedemo and -fastdemo, and provides a lot more flexibility too.

any 226 does this for me. (could be a windows issue, I'm still using win98 - directx, etc is different)
yes, I have used the gamespeed features, too slow to change in-demo (unless the demo is large).
really, this isn't important. I can either in-demo gamespeed it or play it back with 224. thanks!

Opulent said:

I have used the gamespeed features, too slow to change in-demo (unless the demo is large).

You can give the step of change a larger value (e.g. 900 if your main use of this feature is for fast-forward), or use the variable step (the default behaviour in recent versions), in which case it only takes a few presses on Num+ to change it from normal to very high speed playback. And I'm sure you know about <End> and <Page Down> in multi-level demos.

I guess I must've been blind all that time.

I can't get sr50 to work with PrBoom+, not with the recent versions and not with 226_16 which is the oldest one I have.

Everything works fine with regular 2.2.6 and vanilla.

All I can suggest is checking your key and mouse bindings - I have no problems at all getting S50. Perhaps at some point you replaced your cfg with that supplied in the zip?

Nope, every bind is the same as in 2.2.6.

DomRem can't get it to work either.

Maybe a SDL issue? Are you using the newer ones with Prboom-plus and the older ones with 2.2.6 - i.e. the ones that were supplied with each of them? If so, you could try reverting to the older ones and see if that helps at all (I don't have a specific reason to think it will though).

Didn't help.

Alternate mouse handling doesn't work for me at all.

I've checked all the binds in 16, 20, 24, 25 and 27, they are the same as in regular 2.2.6, yet I can't get sr50 to work in any of those versions.

:)
I can't get it too!

Belial said:

Alternate mouse handling doesn't work for me at all.

This reminded me of a question I had for a while: How exactly does Alt Mouse Handling make your movements smoother?

I don't understand code, so I can't check myself. Could someone tell me, event by event, what happens when you move the mouse with it off and with it on?

The new code uses a win32 api directly instead of through SDL library for processing of the WM_MOUSEMOVE events

Congratulations with Victory Day

http://sourceforge.net/projects/prboom-plus/

2.2.6.28

[+] Option to turn off "Paper Sprites". It works only with mouselook, and is only for non-solid sprites.
[!] The command-line parameter "-screenscapture" is renamed to "-avidemo". Also syntax has changed.
[!] Reconfigurations in settings.
[-] Screenshots now use correct palette in software mode.
[-] Screens capturing: do not dump black screens while in skip mode.
[-] Respawned monsters on nightmare do not have countable flag.
[-] Mouse-induced Strafe50 couldn't be achieved.

r0x

You are a busy son of a gun. :)

I just downloaded prboom+ and like all the other versions I have, it has the kaleidoscope effect on the sky flats. I know I read the FAQ and dont feel like downloading new drivers. All other ports Ive tried dont have this, I dont see why this cant be worked out in the code.

I think it would be good feature for it to act exactly like the original doom. Have and option in a menu to do this. When I play it just doesnt feel right, a little too smooth maybe.

Also have a menu option for different configurations. At least one to set all controls, stat and other settings to make it play and look like original dos doom.
I know I could copy the config file and keep replacing it when someone else wants to play and keeps changing my controls, but it would be nice to pick an already saved config.

abysmal said:

I just downloaded prboom+ and like all the other versions I have, it has the kaleidoscope effect on the sky flats.

Sky flats work fine for me. Post your screenshot with "kaleidoscope effect"

I think it would be good feature for it to act exactly like the original doom. Have and option in a menu to do this. When I play it just doesnt feel right, a little too smooth maybe.

I don't understand that you mean. You can disable smooth movement through menu.

I know I could copy the config file and keep replacing it when someone else wants to play and keeps changing my controls, but it would be nice to pick an already saved config.

glboom.exe -config yourconfig.cfg
It's more than enough

abysmal said:
I just downloaded prboom+ and like all the other versions I have, it has the kaleidoscope effect on the sky flats. I know I read the FAQ and dont feel like downloading new drivers. All other ports Ive tried dont have this, I dont see why this cant be worked out in the code.

How is that? On the PrBooms what I get is little stacked skies in GL mode (GLBoom) instead of one big sky (some issue with SiS cards that hasn't been tackled... at least till last time I checked). But they are fine on software mode (PrBoom).

I think it would be good feature for it to act exactly like the original doom. Have and option in a menu to do this. When I play it just doesnt feel right, a little too smooth maybe.

Heh, you're not the first to ask for this. But then the engine is a Boom port, so you can't go as far as setting complevel 2 (exact Doom2 behavior) as the default.

Also have a menu option for different configurations. At least one to set all controls, stat and other settings to make it play and look like original dos doom.

As far as the behavior of the game goes, complevel does this, though it won't change other hud/interface stuff. A -default switch to revert everything to Doom appearance and behavior (flagging all compatibilities and removing anything from Boom) would be cool, though. I bet it could even be made to do it without touching the user's CFG.

I know I could copy the config file and keep replacing it when someone else wants to play and keeps changing my controls, but it would be nice to pick an already saved config.

Not just a copy; you can use -config [configname].cfg to make it read a CFG not named prboom.cfg.

For example prboom -config oldschool.cfg typed in the command line (a CMD box, batch, run prompt, or shortcut) would read an alternate (pre-saved) CFG (presumably with Doom-like settings in this or that respect).

myk said:

As far as the behavior of the game goes, complevel does this, though it won't change other hud/interface stuff. A -default switch to revert everything to Doom appearance and behavior (flagging all compatibilities and removing anything from Boom) would be cool, though. I bet it could even be made to do it without touching the user's CFG.

If somebody write such cfgs I'll put them with batch files in .zip