entryway

Use windowed mode for resolutions which are not supported by drivers. I've noticed that the newest SDL doesn't allow low resolutions even in windowed mode, so you need SDL.dll from 2.5.1.3 release -geom 80x50w Also you can resize prboom's window with mouse (hold shift for any resolutions)

it is random it does not depend from iwad/pwad it happens only in software mode, probably in R_DrawColumn [/vanga mode off]

Thanks. http://pastebin.com/0QfimPHn

IIRC, SDL_mixer causes crashes even without SIGSEGV message. If he got "signal 11", then something is wrong with prboom-plus, and I need adress of crash (-devparm) and used exe+map

Sometimes it makes sense: IIRC, old versions of prboom run faster at 1600x1200 than at 1024x768. PrBoom has simple checkif (!(SCREENPITCH % 1024)) SCREENPITCH += 32; PrBoom+ uses test function, because not only 1024 is noticeable slower on some old hardware.

It would be nice to fix it, but without rewriting too much of code. If you already know how to do it, send me a patch, please.

Can you reproduce the crash with -devparm?

I knew z-shiftting mlook should not be hard for implementing, but never thought that full implementation is about 10 lines of code. I added mlook to software mode to prboom-plus this night. Sky stretching code was taken from ZDoom.

For skipping empty lines? You are welcome.

I've checked Eternity and Risen3D. Risen3D is able to handle it, but Eternity does not.

http://prboom-plus.sf.net/Jptr_fix2.bex.zip More tolerant parser will be a reason of increasing incompatible dehs

Thanks. It's formatted wrongly. MBF.EXE disallows it too.

Does any other port process it correctly? In any case I don't know what is unofficial Ultimate Doom patch.

Thanks. Fixed?

Can't reproduce. Just tried: glboom-plus -iwad doom.wad -file pwads/DTWID.wad -deh pwads/DTWID.deh

You need only ffmpeg.exe (static version) in your prboom-plus's folder http://ffmpeg.zeranoe.com/builds/ Also, you can check following output files if something is wrong with command lines: mux_stderr.txt, sound_stderr.txt, video_stderr.txt I've tried Andy's command lines with the latest ffmpeg and got: in video_stderr.txt Works fine after removing "-cqp 0". I think "-cqp 0" meant max quality. Check ffmpeg documentation for details.

http://www.doomworld.com/vb/post/1038882 http://www.doomworld.com/vb/post/1065690 http://www.doomworld.com/vb/post/968123

You are not limited with mkv. Try to use ffmpeg as cap_videocommand (there is example in usage.txt) with corresponding options like "-vcodec msmpeg4" instead of "-vcodec libx264" or something.

no. use external tools for video editing

doomtype.h#ifdef __cplusplus typedef bool dboolean; #else typedef enum {false, true} dboolean; #endif

That's because of Fluidsynth MIDI player Try this: http://prboom-plus.sf.net/prboom-plus-2.5.1.4.test-win95.zip

did you try prboom-plus?

Hi. I have increased some limits in original EXE's to reduce the risk of crashes, premature program exits and certain visual problems. This is done without loss of compatibility - in other respects, Doom(2)-plus behaves exactly like the original DOS EXEs. Dehacked patches can be applied as normal, for instance, and any demo that plays back correctly with Doom(2).exe will also play back with Doom(2)-plus.limit : old * k = new ------------------------------------------------------- visplanes[MAXVISPLANES] : 128 * 8 = 1024 drawsegs[MAXDRAWSEGS] : 256 * 8 = 2048 SAVEGAMESIZE : 180224 * 16 = 2883584 activeplats[MAXPLATS] : 30 * 256 = 7680 vissprites[MAXVISSPRITE] : 128 * 8 = 1024 linespeciallist[MAXLINEANIMS] : 64 * 256 = 16384 openings[MAXOPENINGS] : 16384 * 4 = 65536The patched EXEs with crk files can be found here. Is it interesting for you?

soft/gl?

Current prboom/-plus does not use (does not require) these m_* lumps http://prboom-plus.sf.net/clip/2013-04-13_18.18.11.png