PrBoom 2.4.4 released

Changes from v2.4.3 to v2.4.4
- Don't fail when a texture name can't be looked up
- Increased several limits - Thanks to entryway and RjY
- Increased number of sidedef limit to 65534
- Increased number of vertexes limit to 65535
- Fixed crash when crossing sectors with very big height differences
- fix crash on E4M8
- New command-line options for setting a window (-window) or fullscreen
(-nowindow) mode temporarily.
- The maximal supported resolution is increased from 1600x1200 to 2048x1536
- GLBoom will use the closest supported resolution when running fullscreen
- The "RUN" key inverts the autorun state
- Live monsters are highlighted in a different colour on the iddt-automap
- Fixed OpenGL sky rendering in Requiem and Memento Mori
- The "Show coordinates of automap pointer" setting works now
- merged many cleanups and fixes from PrBoom 2.3
- fix translucency map file handle leak
- fix consistency failures in netgames
- prevent crashes at 800x600 caused by rounding errors with naive clipping
- fixed slowdown at 1024x768 on some systems
- ability to play tasdoom demos directly
- -solo-net option is a shortcut for one-player network games
- emulate spechit overflows for dosdoom and tasdoom compatibility
- made several cleanups and fixes

Three versions in a couple of weeks? You guys are on fire :)

proff_fs said:
- Increased several limits - Thanks to entryway and RjY

Thank Quasar, he actually wrote the renderer overflow fix, I just worked it into PrBoom :)

- Live monsters are highlighted in a different colour on the iddt-automap

Haha, maybe I should update the overdetailed map cheat and submit it properly...

Anyway, excellent, thanks to all.

RjY said:
Three versions in a couple of weeks? You guys are on fire :)

Hehe, this time we didn't want to make the same mistakes as with 2.3.x :) So we release quite often. This also lead to a bit more motivation. I mostly worked on getting things imported from 2.3.x. Almost everything which is worth merging got merged, the next part is the improved software renderer, but that is quite a bit of work, as I would like to make it more clean than in 2.3.x. Colin Phipps did great work on compatibility, savegames and general cleanup. Entryway helped porting bits and pieces from PrBoom+ and pestered me to fix some things (hi-res speedups). And Neil approached me exactly at the time I got my Mac — absolutly perfect timing.

Thank Quasar, he actually wrote the renderer overflow fix, I just worked it into PrBoom :)

So here it goes: Thanks Quasar!

Haha, maybe I should update the overdetailed map cheat and submit it properly...

This would fit better to PrBoom+, which is now regulary updated to the latest PrBoom version as well.

Anyway, excellent, thanks to all.

Thanks to everyone! I often thought about abandoning PrBoom, but I stayed with it and it finally pays off. The last few weeks I got more feedback than all the years before. This alone was worth it.

Thank you (all of you) for the new version!

I have a question:
The GL-version is always too dark for me (not only in this latest version), even, when i go to the fouth level with the F11 -key. how can this be solved?

Greetings
Funduke

I plan to add support for Gamma correction for OpenGL which uses the hardware color correction. For now you may be able to set this in your graphics card settings. Generally the lighting in OpenGL is not as in software mode, this is because the lighting is not varying by distance like it does in software mode, I plan to work on this, but have no estimate to when or if at all it will be fixed.

proff_fs said:
Entryway pestered me to fix some things (hi-res speedups).

Yeah, entryway played very important part there

So here it goes: Thanks Quasar!

But entryway found this patch in patches section on sf.net! Who knows, maybe that would be never found by proff_fs :)

proff_fs said:

I plan to add support for Gamma correction for OpenGL which uses the hardware color correction.

It has some lacks: it slows down the exits (switching of gamma) and leaves a bright desktop after crashes for example.

proff_fs said:

I plan to add support for Gamma correction for OpenGL which uses the hardware color correction. For now you may be able to set this in your graphics card settings. Generally the lighting in OpenGL is not as in software mode, this is because the lighting is not varying by distance like it does in software mode, I plan to work on this, but have no estimate to when or if at all it will be fixed.

That's nice to know. Thank you for the response.

Greetings
FunDuke

The Spire 2 still puts prboom 2.4.4 in a world of hurt (even more so with prboom-plus 2.4.3.1) is it a problem with the map itself? It claims compatibility with Boom but it most likeley hasn't been tested with it since it crashed previous versions of prboom....

Here are the problems I found in the first minutes of the map....
This light fixture looks normal
http://img434.imageshack.us/img434/2079/doom15vp0.png
but when you go into it this happens
http://img335.imageshack.us/img335/9403/doom17ij7.png
There is a similar light fixture on the other side of that wall that does the exact same thing.

It also happens on this little light fixture here.
http://img372.imageshack.us/img372/9665/doom19nx6.png
http://img372.imageshack.us/img372/5754/doom20fz8.png

All these errors ONLY occur in the software rending version of prboom, none of these occur when run in OpenGL mode.

Also a unique problem which occurs in both software and opengl mode on prboom plus 2.4.3.1 is this.....
http://img372.imageshack.us/img372/3228/doom18hv1.png
The berserker pack is meant to be on the ground.....


EDIT: Forgot to add a thankyou for continuing to work on this GREAT port! Keep up the good work!

Phil1984 said:

The Spire 2 still puts prboom 2.4.4 in a world of hurt (even more so with prboom-plus 2.4.3.1)

Known bug of Quasar/RjY fix. I'll continue to pester proff_fs

The beserk pak might be a mapper bug. I have been able to suspend stuff in the air before (don't ask how) in all ports so I wouldn't think it a Pr bug.

Maybe, but it seems odd that it occurs in prboom-plus and not prboom.

Possibly due to differences in the default cfg settings. Try varying the complevel or (with complevel -1) twiddling with the "Use exactly Doom's ..." compat settings (e.g. linedef trigger model or floor motion).

Remember that both Prboom and Prboom-plus are effectively a dozen or more exes in one. Depending on the settings used, you'll get widely differing behaviour. If you want to set the behaviour to a particular standard in the most simple way, always use a complevel (though even then there are plenty of things you can twiddle with, especially visual effects). If the level in question is for Boom, set the complevel to 9 to get it to support Boom features in the way that Boom 2.02 does.

Yes. It depends from comp_floors in both.

/* cph - make more compatible with original Doom, by      
 *  reintroducing this code. This means floors can't lower
 *  if objects are stuck in the ceiling */

Ahhh yes silly me! Don't I feel like a right old fool!