PRBoom 2.2.1

Proff sent news that the new version of PRBoom, 2.2.1, is ready. Here's a list of the changes from 2.2.0 to 2.2.1:

• improved fix for demo sync problems with lost souls bouncing off floors
  
• fixed bug where loading a -fast or -respawn savegame failed to restore those options properly
  
• fixed demo sync bug with doors also tagged to lift triggers
  
• fix some endianness problems in the OpenGL renderer
  
• hopefully fixed some problems compiling for Linux/ARM
  
• fix multi-level demo time totals to agree with compet-n
  
• linux rpm is now a bit more standardised

Unfortunately, according to Proff, SourceForge is having some problems, so the new version of PRBoom is not yet available for download.

I heard OSDN (which runs SF) was having router problems earlier in the day, that probably had something to do with it.

arioch why do you always have these comments in the comment threads instead of your actual post

To me, PRBoom is still the definite port for DOOM. In my opinion, this is the final final final version of the original DOOM.

Because it's not actually a part of the news update but rather some hearsay and speculation on my part.

Doesn't OSDN run /. as well?

Also, Arioch, why didn't you mention that it's up at http://cacodemon.despayre.ath.cx/? Did cph take it down?

Indeed. It's available from http://cacodemon.despayre.ath.cx/ for linux, there's a tarball and a RPM.

It's been awhile since I last used PRBOOM, but is it possible to disable the stuff like being moved backwards when you fire the rocket launcher, etc...?

oh yeah. that stuff has always been toggle-able.
Proff has done a good job ironing out the smallest of details -- I couldn't imagine they have too much left to add to it.
(perhaps I should read their todo list...)

ACS and FraggleScript were possiblities, last I checked.



They're pretty close to full demo compatibility with all compet-n demos, as of 2.2.1 ... only the new ns30 demos are still not totally working afaik.

I've now removed the copies on despayre, I didn't intend that to be a major distribution point (don't want to abuse arioch's bandwidth too much :) ; the files are available from sourceforge's download server they just aren't linked from the broken sourceforge file page:

http://prdownloads.sourceforge.net/prboom/prboom-2.2.1-1.i386.rpm
http://prdownloads.sourceforge.net/prboom/prboom-2.2.1.tar.gz
http://prdownloads.sourceforge.net/prboom/prboom-2.2.1.zip
http://prdownloads.sourceforge.net/prboom/prboom-2.2.1-win32.zip

IMO, I think PRboom is what doom3 should have/would have been if id did an immediate follow up to Doom2. A great port that's more concerned with stability and flexibility over feature creep. Even though the port is stable and appears done two areas I hope they touch up are music and GL.

It'd be nice if they could scrap the GL engine they have for (something like) Jdoom 1.00. But somebody (Mdenham?) told me that incorporating the Jdoom codebase into prboom would be impossible. hmmph.

in my opinion video enhancements in a basically genuine DOOM port should not add stange lighting effects, it should simply allow users to use higher resolutions without problems. this is especially pertinent for people using large monitors or machines with setups that don't work with a low video resolution

The point being that JDoom's 3D renderer is a technically superior solution for win32, especially for rendering high res, since all the fancy lighting effects and such can be disabled.

as i see it, the prboom team looks for a rendering method that will optimize high resolotion modes, but that will not warp the gaming environment (will play as closely as possible to DOOM), and will be fully compatible with the non-gl version of the executable. i do not know how possible that would be with the more advanced gl rendering methods.

I fail to see how a different rendering engine would affect gameplay.

Please, I thought we'd gotten past the "I don't want blah blah blah to be there even though I can disable it" crap years ago.