PrBoom-Plus, ver. 2.5.1.4

[myk]

In such a case I'd double check both use_doublebuffer and render_fov. I tried FOV 100 and sprites were disappearing oddly (though it was on software mode), and when I changed it to 90 it was fine.

[ultdoomer]

entryway said:

Do you see this problem in the previous versions of prboom+ or in classic glboom?

Yes, it's the same in every version.

[entryway]

myk said:

In such a case I'd double check both use_doublebuffer and render_fov. I tried FOV 100 and sprites were disappearing oddly (though it was on software mode), and when I changed it to 90 it was fine.

FOV should not have any effects on software mode at all. I shall look into

[myk]

It would be better if the new PrBoom+ entries in the CFG were preceded by a title, instead of being in the HUD section, like this:

...
hud_active                    2
hud_displayed                 0
hud_nosecrets                 0

# PrBoom-plus settings
mouse_acceleration            0
mouse_sensitivity_mlook      10
speed_step                    0
...

[entryway]

VinceDSS said:

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+.

Can Dash's prboom capture sound? If yes, I would like to receive a sources of it. Yesterday I've coded capture of a video stream, but I could not make capture of an audio.

[entryway]

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

2.2.6.29

[+] Detection and emulation of spechit overflow for dosdoom and tasdoom compatibility. There are no more desyncs in the following dosdoom demos: flsofdth.wad\fod3uv.lmp, hr.wad\hf181430.lmp, hr.wad\hr181329.lmp, icarus.wad\ic09uv.lmp
[+] Support for comp_666 and comp_maskedanim
[!] Update to newest SDL libraries. SDL.dll ver.1.2.10.0, SDL_mixer.dll ver.1.2.7.0, SDL_net.dll ver.1.2.6.0
[!] Some variables specific to OpenGL have been removed from the list of variables meant for prboom.cfg
[!] The launcher will not be displayed if IWAD or PWADs are specified in a command-line.
[!] The new PrBoom-plus entries in the configs are preceded by a title.
[-] PrBoom bug: The sky in the third episode of Requiem was not drawn. It did not work correctly because the SKY3 has a zero index in the TEXTURE1 table. Textures with a zero (FALSE) index are not displayed in vanilla - AASHITTY in doom2.wad for example. But the sky textures are processed by different code, which does not have this bug. This bug is also present in the current GZDoom, but it only draws the wrong sky instead of drawing no sky at all.
[-] PrBoom bug: The "Show coordinates of automap pointer" setting has no effect.
[-] FOV had side effect on software rendering.
[-] Alt mouse handling: Eternal rotation of the player at non-standard modes on software mode. Example:
prboom.exe -geom 1025x768 -nowindow

Links for the demos referred to above:
http://www.doomworld.com/sda/flsofdth.htm
http://www.doomworld.com/tas/hf181430.zip
http://www.doomworld.com/tas/hr181329.zip
http://competn.doom2.net/pub/sda/i-o/icuvlmps.zip

[myk]

Version 2.2.6.29 doesn't let me set non-standard Windows resolutions. 320x200, 320x240 and 640x400 all failed, while 640x480 and 1024x768 worked.

[entryway]

It works correctly for me

EDIT: try to change use_doublebuffer

[myk]

entryway said:
It works correctly for me

You have to have changed something in the way the video resolution is loaded or detected. Recently fraggle dealt with similar issues in Chocolate Doom, where some cards reported some modes were not supported, when they were.

[entryway]

try it

[myk]

entryway said:
try it

Unfortunately the same issue occurs.

[entryway]

Surprisingly. Try it
I have removed this line
if(SDL_VideoModeOK(w, h, 8, init_flags))
before
screen = SDL_SetVideoMode(w, h, 8, init_flags);

[myk]

It runs, but now it generates a small DOOM screen surrounded by a thick black border (it's not resizing it to fill the entire screen.)

[entryway]

You deceive me! :)
It should work in the same way as in the previous version.

[myk]

Heh, it's not April fool's day. I just restarted my computer just in case; release 29c still gives that smallish screen, while release 28 works fine (proper full screen scaling).

[entryway]

Are you using different versions of SDL in these two cases?

[myk]

Yes; each version has its own folder with its own SDL files.

[entryway]

Try new PrBoom with old SLD, but I don't think that it will help :)

[myk]

entryway said:
Try new PrBoom with old SLD, but I don't think that it will help :)

With the old SDL.dll file all of them, 29, 29b, and 29c, work properly.

[entryway]

My mistake. I built new version with old headers.

[entryway]

Last check. Please inform me if it works correctly (with included SDL)

[myk]

entryway said:
Last check. Please inform me if it works correctly (with included SDL)

No, it gives me the small screen over black. Might it be something worth reporting to the SDL dev team?

[myk]

I updated the DOOM v1.9 config file, for release 29.

[VinceDSS]

entryway said:

Can Dash's prboom capture sound? If yes, I would like to receive a sources of it. Yesterday I've coded capture of a video stream, but I could not make capture of an audio.

Unfortunately it doesnt record sound. And also, I went back to fraps as I don't have to synch sound.

[Belial]

I'm getting crashes in 28 when loading games saved with a complevel (9 and 2/3 to be exact). The errors are 'I_Signalhandler: Exit on signal: signal 11' and 'P_Mapstart: tmthing set!'.

Edit: The shift key doesn't work at all in 29. (fixed by replacing new SDL with the one from 28, it also fixed some mouse sensitivity issues)

[entryway]

Belial said:

Edit: The shift key doesn't work at all in 29

???

[Belial]

I can't bind it in-game, and when I pasted the bind from an old config it didn't work.

The new SDL breaks a few things on my comp.

[Andy Olivera]

Three bugs in the Strafe50 implementation:

* The code only checks the mousex value for turning, so if you're using keyboard or joystick it uses strafe50 on turns no matter what that option is set to. Can be fixed by checking cmd->angleturn instead.

* Since Strafe On uses the same speed as forwardmove, the slow speed for strafe50 should be 0x19.

* For some reason, strafe50 deactivates during any mouse movement, not just x-axis.


Also, how did you get rid of that sudden turn-right jolt that occurred when using the -warp parameter?

[entryway]

Andy Olivera said:

Also, how did you get rid of that sudden turn-right jolt that occurred when using the -warp parameter?

SDL_WarpMouse((unsigned short)(SCREENWIDTH/2), (unsigned short)(SCREENHEIGHT/2));
in void I_InitInputs(void)

[Andy Olivera]

* Since Strafe On uses the same speed as forwardmove, the slow speed for strafe50 should be 0x19.

Turns out I was grossly wrong about this. The walking speed when using strafe50 should be 0x30(48). My mistake for not understanding just how the bug worked...