PrBoom-Plus, ver. 2.5.1.4

[entryway]

This version contains support for hires textures and flats. You should download, for example, this hires pack and extract its content in your prboom-plus folder. Resultant structure of folders should be similar to:

c:\prboom-plus\flats\*
c:\prboom-plus\textures\*

After that you should start glboom-plus.exe, allow hires textures from in-game menu: Options\General\sixth_page and restart glboom-plus. If no bugs will be found, I'll merge the latest sources with main branch

[Squonk]

I'll try the Grazza way, see if it works. But that could be a bug to fix, no?

[entryway]

Squonk said:

I'll try the Grazza way, see if it works. But that could be a bug to fix, no?

I can't reproduce it :( What should I do?

[Squonk]

For me, the "bug" happens because I simply told Windows to open all lmp files with glboom.exe (glboom plus).

[Grazza]

Squonk: What are the date-stamps of the exe and the sdl.dll that you are using?

[Squonk]

You mean the date of the last modification?
28/12/06 for both

[Grazza]

That is pretty old. The current version is here (links at the top of the page).

entryway said:

This version contains support for hires textures and flats. ... If no bugs will be found, I'll merge the latest sources with main branch

It works OK for me. One bug and one issue though:

Bug: In the menus, you can't choose hires textures without also turning off colormaps. (You also can't do so via the cfg.)

Issue: When using pwads that contain replacement textures, the hires version of the default texture is used instead of the replacement texture. Plenty of examples, such as Hacx and STRAIN. Might a simple solution be to (re)load anything texture-related from any pwads loaded after the hires textures have been loaded?

[entryway]

Bug: In the menus, you can't choose hires textures without also turning off colormaps. (You also can't do so via the cfg.)

This behaviour is by design at least currently. Colormaps eat a lot of memory. To avoid slowdowns in new areas I precache all hires textures at start even with level_precache=0. I don't wish to increase memory size twice (at least): for normal and for invul-effect textures. GZDoom do not load color-mapped textures during precaching and gets some freezing because of it if you get an invul.

Issue: When using pwads that contain replacement textures, the hires version of the default texture is used instead of the replacement texture. Plenty of examples, such as Hacx and STRAIN. Might a simple solution be to (re)load anything texture-related from any pwads loaded after the hires textures have been loaded?

Does GZDoom have a method for such situations? Something like NOHIRES lump for doom compatible wads in cases if authors has changed switches (and its size) and do not wish to see them in the broken state with hi-res textures pack.

[Squonk]

I don't know if it would fix the stdout problem, but it keeps "looking for network game", even if I want it to read a demo...

[entryway]

Squonk said:

I don't know if it would fix the stdout problem, but it keeps "looking for network game", even if I want it to read a demo...

PRBoom-Plus tried to build prboom-plus.cache file for launcher. You should wait if you have one billion wads in your doom2 folder. Also you can disable launcher in cfg

launcher_enable               0

[Lemonzest]

Small question, would it be possible for someone to make a codeblocks workspace for prboom-plus? i use mingw on windows and codeblocks to build a few other source ports and would love to be able to build this one also, thanks in advance

Lemonzest

[Squonk]

I have about 10 wads in the directory.
Thanks for the answer.

[entryway]

Squonk said:

Thanks for the answer.

the latest prboom+ still not work for you, right?

Lemonzest said:

would it be possible for someone to make a codeblocks workspace for prboom-plus?

maybe I'll make it

[Squonk]

the latest prboom+ still not work for you, right?

Well, I have either to wait a minute for each demo I wanna read (quite long), either to give him manually the wad (no more launcher ==> doom2.wad by default)

I still have to try the other method to read demos by double clicking on, though.

[entryway]

do you have something in prboom-plus.cache file? (in prboom-plus folder)

[Squonk]

About 2000 lines of wad paths, each line followed by = 3, 0, 1
As I said, I have only about 10 wads in the prboom directory, so most of the lines are identical.

[entryway]

do you have wads in %DOOMWADDIR%?

send me your prboom-plus.cache
andrey.budko gmail com

[Squonk]

prboom-plus.cache file deleted, and now it works fine. And stdout.txt file is created in the exe directory, so everything is ok now.
Thanks all

[andrewj]

Grazza said:

Issue: When using pwads that contain replacement textures, the hires version of the default texture is used instead of the replacement texture.

entryway said:

Does GZDoom have a method for such situations? Something like NOHIRES lump for doom compatible wads in cases if authors has changed switches (and its size) and do not wish to see them in the broken state with hi-res textures pack.

You need to define "where" in the list of add-ons the texture pack fits.

Let me explain some more: with EDGE the hires textures are loaded using DDF files. These DDF files will be part of the list of all files that the engine loads, for example:

gledge32.exe -file xxx.wad dhtp-doom2.ddf yyy.wad

It is obvious that the hires textures loaded by dhtp-doom2.ddf should behave the same as a normal pwad containing normal textures, i.e. yyy textures can override them. (I must admit that EDGE probably does not work that way right now, it is something I'm going to fix soon).

If that is too complex for PrBoom-Plus, maybe you could have an option like: load hires textures either BEFORE or AFTER all pwads.

[entryway]

In case of "BEFORE": no hires textures will be loaded if I start tnt.wad as PWAD, because tnt has most of doom2 textures

In case of "AFTER": textures from pwad with the same names as in iwad (switches for exanles) will be replaced with hires textures

[Grazza]

I would suggest "BEFORE" as the default and an ability to override it with "AFTER" behaviour (via command-line option and/or cfg setting).

After all, it is rare to need to load tnt or plutonia as a pwad - for playback of demos recorded using them as a pwad is the only time I can think of, and even then, there is the alternative option of loading them as the iwad and forcing -complevel 2 (i.e. removing the need to load them as a pwad).

[hawkwind]

Grazza said:

Issue: When using pwads that contain replacement textures, the hires version of the default texture is used instead of the replacement texture. Plenty of examples, such as Hacx and STRAIN. Might a simple solution be to (re)load anything texture-related from any pwads loaded after the hires textures have been loaded?

Both Doomsday and Risen3D have overcome this issue. Without going into details, if a lores texture which has the same name as the iwad texture is in a pwad, the lores texture takes precedence and this is rendered instead of the hires texture.

Might be worth checking the source codes for either port.

[Grazza]

hawkwind: yes, that's pretty much how it does work, by default, in the new test version.

entryway: just been trying it out, and all seems to be well. One little thing: "override" is the correct spelling, not "owerride". Do you plan at some point to make it possible to have colormaps and hires textures at the same time? I would at least like to see how the performance is in that case. Personally, I'm quite reluctant to lose colormaps in favour of hires textures.

One other tiny point: the wrong date is given on this page.

[entryway]

Grazza said:

hawkwind: yes, that's pretty much how it does work, by default, in the new test version.

Also you can specify any static path to your hires textures in gl_texture_hires_dir variable in config. For example:
gl_texture_hires_dir "d:\games\doom2\hires\risen3d"
Leave it empty for search in the standard dirs (exedir, current dir, doomwaddir for windows)

Grazza said:

Do you plan at some point to make it possible to have colormaps and hires textures at the same time? I would at least like to see how the performance is in that case.

Later. Performance issue will be as in gzdoom after getting an invul I think. Or I should precache invul textures at the start (~+60% to used memory)

BTW, hires texture pack from risen3d site is better (for me) and more fullest than KuriKan's. But I did not see any other packs except for these two

[jval]

entryway said:

This version contains support for hires textures and flats.

The link does not work:

An error has been encountered in accessing this page.

1. Server: prboom-plus.sourceforge.net
2. URL path: /prboom-plus-2.4.8.2.test2-win32.zip
3. Error notes: File does not exist: /home/groups/p/pr/prboom-plus/htdocs/prboom-plus-2.4.8.2.test2-win32.zip
4. Error type: 404
5. Request method: GET
6. Request query string:
7. Time: 2007-09-05 22:04:03 PDT (1189055043)

Reporting this problem: The problem you have encountered is with a project web site hosted by SourceForge.net. This issue should be reported to the SourceForge.net-hosted project (not to SourceForge.net).

If this is a severe or recurring/persistent problem, please do one of the following, and provide the error text (numbered 1 through 7, above):

   1. Contact the project via their designated support resources.
   2. Contact the project administrators of this project via email (see the upper right-hand corner of the Project Summary page for their usernames) at user-name@users.sourceforge.net

If you are a member of the project that maintains this web content, please refer to the Site Documentation regarding the project web service for further assistance. 

Where did you hide it ??? :)

[entryway]

jval said:

Where did you hide it ??? :)

no. you can download it here
http://prboom-plus.sourceforge.net/history.html

btw, the latest (non-public) version has support for hi-res patches

[jval]

OK, thanks, downloading ...

[myk]

I'm not sure if I'm missing something but the demo camera mode could be improved, in my opinion, with the following changes:

• Allow the camera to move up and down (needs 2 keys to bind)
  
• Give the camera its own hearing point instead of using the Player's
  
• Don't apply the gunflash effects to the camera, but to the Player's area
  
• Don't apply the palette (pain, pickup, etc) effects to the camera

In other words, you could make it behave like F12 does, where the perspective is changed fully. Currently it seems very hacky and doesn't provide optimal clarity.

Can't mouselook be applied? Is it only possible in GL accelerated modes?

EDIT: Maybe also make its movement behave more like the Player's, with a bit of momentum when you stop.

EDIT 2: Perhaps it could have a clipping mode that is easily toggled on and off, because it's easy to run into a wall or such and get something in the way of what you're observing when full noclipping is applied.

EDIT 3: The clunkiest thing about it is that when you move across areas of different heights you immediately fall or rise. When moving to lower areas your should retain your height, and when moving to higher ones, rise perhaps at walking (or running) speed if you press against the wall, more or less like a Cacodemon would. All this in the "clipping enabled" mode, but not when there is no clipping, where it could still behave as it does currently.

[Quasar]

entryway said:
[-] PrBoom bug: The behaviour with comp_666 was that the death of all barons on E2M8 or E3M8 ends the level, heh. This is incorrect; it should have no effect. The bug was introduced in 2.4.x by cph. After some tests and disassembling I conclude that the implementation of A_BossDeath() in all compatible ports (PrBoom, Eternity, Chocolate-Doom) is totally wrong for doom2 compatibility. This version should fix the buggy behaviour. There is no more desync (premature exit) on episode3.lmp@doom.wad
[/B]

Wrong in what way exactly? 666 is triggered by Arachnotrons and 667 by Mancubi on MAP07. Are there supposed to be other available BossDeath effects in Doom 2?

[entryway]

Quasar said:

Wrong in what way exactly?

http://prboom-plus.sourceforge.net/generator.php.htm
http://www.crowproductions.de/repos/prboom/branches/prboom-plus-24/prboom2/src/p_enemy.c

void G_Compatibility(void)
{
  static const struct {
    complevel_t fix; // level at which fix/change was introduced
    complevel_t opt; // level at which fix/change was made optional
  } levels[] = {
    // comp_666 - emulate pre-Ultimate BossDeath behaviour
    { ultdoom_compatibility, prboom_4_compatibility },
...
  for (i = 0; i < sizeof(levels)/sizeof(*levels); i++)
    if (compatibility_level < levels[i].opt)
      comp[i] = (compatibility_level < levels[i].fix);

I am lazy to explain it in English.