PrBoom-Plus, ver. 2.5.1.4

[emailking]

"[!] Updated to the latest prboom 2.4.8 (SVN build, revision 2355)."

Where can one find or at least see the changes for these 2.4.8 prBoom builds? I notice the most recent test build of pr+ contains reference to 2.4.8 too, but the highest version I can find of prBoom is 2.4.7.

[Schneelocke]

emailking said:

"[!] Updated to the latest prboom 2.4.8 (SVN build, revision 2355)."

Where can one find or at least see the changes for these 2.4.8 prBoom builds? I notice the most recent test build of pr+ contains reference to 2.4.8 too, but the highest version I can find of prBoom is 2.4.7.

http://www.crowproductions.de/repos/prboom/trunk/prboom2/

[emailking]

Thanks.

[Schneelocke]

emailking said:

Thanks.

You're welcome. :)

[Grazza]

You can also look here, to see a listing of recent (and older) commits. Those shown as "branches/prboom-plus-24" are specific to prboom-plus, while those given as "trunk/prboom2" are in the regular prboom. Every so often Andrey will incorporate a batch of changes from the trunk into prboom-plus. In the current test version he recently incorporated them up to r2420.

Personally, I use both this "browsing" method and an SVN tool (TortoiseSVN) to keep up-to-date with what has changed, and thus know what to test for.

[emailking]

Thanks guys.

[entryway]

emailking said:

"[!] Updated to the latest prboom 2.4.8 (SVN build, revision 2355)."

Where can one find or at least see the changes for these 2.4.8 prBoom builds? I notice the most recent test build of pr+ contains reference to 2.4.8 too, but the highest version I can find of prBoom is 2.4.7

there are no significant changes in current version 2.4.8 comparing to 2.4.7. Only this and b.m.

2340: Fix wrong clipping in emulated buggy clipping :P

2343: Fix crash in network savegames when a sector soundtarget is
pointing to a corpse that is pending removal (PrBoom bug #1590350)

2419: Added missing clipping. Very noticeable in Doom2 Demo3 in Map 26 in the elevators when you remove the call to R_DrawPlanes.
Thanks to SoM for this!

2420: Flush column buffer before drawing planes.
Thanks to SoM!

[Lemonzest]

What do i need to do to compile this in ubuntu linux??

[fraggle]

Lemonzest said:

What do i need to do to compile this in ubuntu linux??

apt-get build-dep prboom

[ultdoomer]

I don't know if this is a bug or limitation, but GLBoom doesn't display a custom colormap (Demonized: Map 01, for example)

Also, if it isn't too much trouble, could you fix the problem with the text I mentioned earlier for the next version? I don't think resizing is necessary, since is it readable at 640x400.

[Grazza]

ultdoomer said:

I don't know if this is a bug or limitation, but GLBoom doesn't display a custom colormap (Demonized: Map 01, for example)

Are you using the current test version?

[entryway]

ultdoomer said:

Also, if it isn't too much trouble, could you fix the problem with the text I mentioned earlier for the next version? I don't think resizing is necessary, since is it readable at 640x400.

It will be fixed at least for 640x480 and 320x240

[Lemonzest]

prboom+ latest test build is not looking for bex/deh patches in DOOMWADDIR path

[entryway]

Lemonzest said:

prboom+ latest test build is not looking for bex/deh patches in DOOMWADDIR path

Should?

[Lemonzest]

well i dunp all my iwads/pwads/deh/bex files in the same folder and then use DOOMWADDIR to point to it so all source ports can find the files with out me having to have multipul copies all over the place, as you fixed looking for PWADS in that dir could you extend it to deh/bex patches also? thanks entryway.

[entryway]

ok

[emailking]

I noticed that for glboom-plus that the skies are shifted upwards relative to the skies in prboom-plus, glboom, and prboom. For a simple example, just go to map 02 of tnt in glboom-plus and prboom-plus. You can see the sky looks very different, and the difference is an upwards shift. But for prboom and glboom the sky is the same as for prboom-plus. Is this somehow intentional? Sorry, I had never heard of this if it is.

I was using the latest test version of glboom-plus.

[Grazza]

Are you using mouselook? That affects the sky. Turning it off should return the sky to normal.

[emailking]

Yeah, that does it. Might I ask why does mouselook shift the sky like that?

[Grazza]

It is stretched, rather than shifted.

The normal sky doesn't go right up to the top of the, er, sky, because it doesn't need to - without mouselook, the player can never see what is overhead.

However, if you use mouselook and the sky isn't stretched, then you see a great big gap overhead. Or something else needs to be done to extend the sky, such as it being repeated, but that can look very odd, depending on the type of sky that is in use.

[emailking]

Ahh, ok. Makes sense.

[Grazza]

Actually, one thing strikes me as odd about this. If mouselook is on, then the sky is always stretched fully, regardless of the "Max view pitch" setting - so even if you have this set to 10 degrees, it stretches the sky the same amount as it would if you had it set to 90. It would seem natural only to stretch the sky as much as is necessary, but I don't know if there is some technical problem with that.

[emailking]

Ok I need some help with the launcher. O n my laptop I have a directory called doom2 in which I have doom2.wad, doom.wad, tnt.wad, and plutonia.wad. Launcher displays all of these fine. On my PC I have a folder called doom which has doom.wad and prboom-plus.exe. If I put tnt.wad in this folder, the launcher displays both fine. Also on my PC I have a folder called doom2 that has doom2.wad, plutonia.wad, tnt.wad, and prboom-plus.exe. BUT the launcher absolutely will not display tnt.wad when launched in this folder. Only doom2.wad and plutonia.wad appear in the top drop down list. tnt.wad only displays in the pwad list. I have tried moving things around, recopying, etc. I can't figure it out. Any ideas? I am using the latest test version of pr+ everywhere.

[Grazza]

Sounds odd... the following questions occur to me as possibly relevant.

Is the copy of tnt.wad that it is failing to see as an iwad an entirely unmodified copy of the iwad, installed directly from the original disk?

Are you running the copy of prboom-plus that is in the same directory as these wads (i.e. do you have other copies in different locations, and running one of these)?

If you make this folder your %doomwaddir%, does that make any difference?

Does rebuilding the cache (in the drop-down list in "Commands") make any difference?

I should mention that I rarely use the launcher myself (it's too slow given that there are so many wads in my main Doom folder), so I am only dimly aware of changes that might have affected it or any subtle features in the way it works.

[emailking]

The tnt.wad file is straight off of the purchased CD from the good guys at ID. The same file (copied via windows copy function) shows up in the launcher in the other places. So if it's corrupt it should be corrupts everywhere. But even if I take it from a directory that works and then put it back in my doom2 directory, it won't show up in the launcher there.

Yes, I am running the copy of prboom-plus that is in the same directory as these wads. Each directory I have mentioned has the latest test version of prboom-plus in that directory.

I apologize for the ignorance, but I don't even know how to make a directory my %doomwaddir%. Is this explained somewhere? I've heard people talk about it.

Rebuilding the cache, however, fixed this issue. Thanks for the tip. But what did rebuilding the cache do?? I don't even know what that means.

I don't use the launcher much either, but it can be convenient sometimes if I can't remember a wad name or I'm too lazy to open the command prompt.

Thanks for helping.

[ultdoomer]

emailking said:

I apologize for the ignorance, but I don't even know how to make a directory my %doomwaddir%. Is this explained somewhere? I've heard people talk about it.

http://www.doomworld.com/vb/showthread.php?s=&threadid=15479&highlight=doomwaddir

[Grazza]

emailking said:

Rebuilding the cache, however, fixed this issue. Thanks for the tip. But what did rebuilding the cache do?? I don't even know what that means.

The cache is the listing (in text format) that the program makes of all the loadable files (iwads, pwads, dehs and bexs) that it finds in all the places it looks (current dir, exe dir and %doomwaddir%, if defined). Rebuilding it means replacing the existing list with a new one, created from scratch.

Why this helped in this case, I'm not sure. But possibly the cache had got corrupted in some way, or hit a limit of some sort (I have noticed that the cache increases in size each time the launcher is used). Possibly you had a file called tnt.wad that wasn't an iwad, and had been included in the list, marked as a pwad. Replacing this file with the tnt iwad wouldn't have removed it from the cache, and so the program might therefore have been regarding anything it found called tnt.wad as a pwad.

But Andrey is obviously better placed to say what the problem might have been.

[emailking]

Yeah I have no idea what happened. I do have a file tnt-1.wad in the directory (no idea why or what I was doing when I renamed this) but I took it out to see if that was causing the reading error somehow, and it made no difference. Although I had put tnt-1.wad back before rebuilding the cache; and now and it still finds tnt.wad as an iwad, so go figure. Anyway, thanks for the help/info guys.

[Searcher]

Maybe you renamed it as a back up copy.

Maybe it is the map "torment and torture" and you didn't want any conflict with the real tnt.wad

That is what I had to do in my system.

[emailking]

Yup, now that's coming back to me. That's it. I was just assuming it was the actual evilution wad.