PrBoom-Plus, ver. 2.5.1.4

DaniJ said:

PWADs like Phobos: Anomaly Reborn can also be loaded in beta4 but due to most of the BOOM support not having been implemented yet - it isn't really playable.

How about frame rate on par.wad\e1m6? This map works much more slowly in risen3d (with all graphics features switched off) than in gzdom or glboom+.

Share this post


Link to post
ultdoomer said:

Finally, how does Alt Mouse Handling affect control?

Like ZDoom. Does It works better than the default handler? Much better for me.

Share this post


Link to post
Grazza said:

It seems that if -complevel 7 is used when attempting to play back a Doom2.exe-format demo, the behaviour is to some extent random.

Yes, as in this case PrBoom should take the random seed from the header of a demo but as it is not present there prboom uses a completely random number instead of it. I think it is necessary to clean opportunity of playing of demos not compatible in a binary format with the specified level of compatibility.

Share this post


Link to post
entryway said:

Does It works better than the default handler? Much better for me.


Yeah, me too. It makes turning a lot smoother.

Share this post


Link to post
myk said:

On the other hand, GLBoom is fast but has visual glitches, like stacking skies, and apparently some HOMs in a newer version of PrBoom+... no idea where those came from.

Have you tried adjusting the OpenGL settings in glboom.cfg? (Some information here - this is included in the prboom package as boom.cfg.html)

As for the new HOM issue, perhaps this is related to the fix for the MBF special skies, or for the glitches in MM map29 and map30 (I don't know why it would, but those are things that have changed recently). You can turn the latter off by setting test_sky1 and test_sky2 to 0 in the cfg.

Share this post


Link to post

How can I choose which game I want to play on net games? I'm trying to start an Ultimate Doom server but it always starts as a Doom2 server. I found no help on the documentations.

Share this post


Link to post

...

Funny, when we wanted to play PrBoom multiplayer we've found all we needed in the docs.

Use -iwad for the client. You don't specify the IWAD on the server.

Share this post


Link to post
Belial said:

...

Funny, when we wanted to play PrBoom multiplayer we've found all we needed in the docs.

Use -iwad for the client. You don't specify the IWAD on the server.

Thanks for helping me Belial ;-)

Share this post


Link to post

Two requests:

1. Make the engine not to grab the mouse when it's waiting for the net game to start. (Like Fraggle did in Chocolate Doom)

2. Fix the problem when you save the game while you are playing in net game, because you get an error if you try to load it later.

Thanks in advance ;-)

Share this post


Link to post
RazTK said:

Fix the problem when you save the game while you are playing in net game, because you get an error if you try to load it later.

How can I reproduce it?

prboom_server.exe -c glboom.cfg -N 2 -s 4 -l 1 // default_compatibility_level 2
glboom -net localhost -nofullscreen
glboom -net localhost -nofullscreen

Saving and loading work correctly for me

Share this post


Link to post
entryway said:

How can I reproduce it?

prboom_server.exe -c glboom.cfg -N 2 -s 4 -l 1 // default_compatibility_level 2
glboom -net localhost -nofullscreen
glboom -net localhost -nofullscreen

Saving and loading work correctly for me

Really? ^_^'
I'm loading the engine this way (to reproduce the problem):
1. prboom_server.exe -N 1 -s 4
2. prboom.exe -net localhost

Share this post


Link to post

An error I've got a couple of times when using saves is:

P_MapStart: tmthing set!
I haven't seen any pattern in when this appears - I've had it with normal SP mode, and also with net1 (normally saves work fine either way). However, I haven't tested the new saving feature too much, as I normally play without using saves.

If the error message doesn't give you an idea of what the problem is, then I'll try to provide an example or two.

Share this post


Link to post
Grazza said:

An error I've got a couple of times when using saves

From which version you have seen it the first time?

Share this post


Link to post

This is the exact error I get when I'm trying to load a network save game.

Share this post


Link to post

Grazza said:
Have you tried adjusting the OpenGL settings in glboom.cfg? (Some information here - this is included in the prboom package as boom.cfg.html)

Yeah, but I didn't get any improvements, just that mipmapping isn't properly supported by my card, and that GL_RGBA8 is a convenient choice for me. I can use gl_drawskys 0, but the sky just looks uniformly pale gray (there is no sky.) And that option may have been added for cards like mine (too bad a fix option wasn't possible, though.)

As for the new HOM issue, perhaps this is related to the fix for the MBF special skies, or for the glitches in MM map29 and map30 (I don't know why it would, but those are things that have changed recently). You can turn the latter off by setting test_sky1 and test_sky2 to 0 in the cfg.

Actually I was mistaken there and the issue goes back to the standard GLBoom; I just hadn't noted it because I had tried only some newer PWADs in the past (I remember testing GLBoom with Scythe) and this glitch occurs in Map01, as shown here (Warning: 751KB BMP.)

One thing that seems ridiculous to me in GL engines is the transparency applied to missiles and energy. Disabling translucency won't get rid of that (I guess that applies only to textures) but setting the translucency filter to 100 will. That affects the translucency set to textures as well (which should be appropriate for Boom maps that use glass-like textures or stuff like that.) There should be a setting for missiles in general (lame), and another for wad-specific translucency (possibly good.)

Share this post


Link to post
RazTK said:

This is the exact error I get when I'm trying to load a network save game.

If you are saved while using a complevel [7..13] - you have this problem (2.2.6.24)

Share this post


Link to post
myk said:

this glitch occurs in Map01, as shown here

I've never had anything like in that screenshot, and certainly not in that part of map01. An issue with your card perhaps?

Regarding translucency, this isn't just with GL. Boom itself made fireballs (and other stuff) translucent. See BOOMDEH.TXT.

Share this post


Link to post
entryway said:

From which version you have seen it the first time?

I think it was with 2.2.6.24, running ic2005 with -complevel 9 (the map uses Boom stuff). OK, your post above explains that. Though the error didn't occur every time - just on one occasion.

More recently (using 2.2.6.25), I got it in icarus map18 playing in net1 style. I hadn't specifically pointed it to my cfg, but according to stdout.txt it used my standard glboom.cfg (which has default_compatibility_level 2). I'll see if I can get the error again.

Edit: I see. If you don't actually specify a cfg, it will ignore the default_compatibility_level, even though it takes other information from the cfg. If I include -c glboom.cfg in the command line, it works OK.

BTW: Quick way to see if it is using a vanilla complevel (even if your comp settings are as close as possible to vanilla): the sleeping sergeant in Doom map02.

Share this post


Link to post

Grazza said:
An issue with your card perhaps?

Perhaps. I'm pretty sure that if I redo the nodes it'll disappear.

Regarding translucency, this isn't just with GL. Boom itself made fireballs (and other stuff) translucent. See BOOMDEH.TXT.

Right, it's a Boom feature (and badly implemented from there, both in applying it to energy and fire, and in tying those sprite effects to texture applications in the settings.) But in GLBoom the translucency setting is ignored (at least on my computer) while with PrBoom it toggles transparency (instead in GLBoom one has to mess with the tran_filter_pct setting to get rid of the effect.)

Share this post


Link to post
myk said:

Perhaps. I'm pretty sure that if I redo the nodes it'll disappear.

One thing you could check: are you using -complevel -1, and is it finding a doom2.gwa file? That could lead to problems if the gwa file is of low quality. (Don't know if it could lead to this problem, but it would mean it was using different nodes from the normal ones.)

myk said:

But in GLBoom the translucency setting is ignored (at least on my computer)

Yes, it is for me too, and so is the TNTTRAN cheat. I agree these changes seem rather obtrusive and should at least have been made optional. After all, in Boom you can make any thing translucent via a bex/deh, but for this stuff you can't even turn it off in that way - it's all or nothing.

Share this post


Link to post

I was wondering if you could do something about glBoom's level starts. Whenever I play a demo in that port, I don't see anything until about three seconds because it starts "drawing" the movements before it enters graphics mode. I'm not sure if you could add a melting screen to glBoom, but I was wondering if you could do something that causes your movements not to be drawn until after the graphics can be seen.

Share this post


Link to post
ultdoomer said:

Whenever I play a demo in that port, you don't see anything until about three seconds because it starts "drawing" your movements before it enters graphics mode.

I don't find this at all. Maybe the first few tics, but that's all (similar to doom2.exe and prboom.exe). What's your processor/graphics card?

Maybe there is a current setting that would improve things for you: try changing level_precache in the cfg to 1. Unfortunately, I can't easily test stuff like this - my next computer down from the ones that run glboom well is an old notebook with an 8MB graphics card that won't run it at all.

Share this post


Link to post
Grazza said:

I don't find this at all.

I don't know if I worded that well, so let me ask you this so I know you understand: Do you first see the graphics when Andrey opens the first door of E1M1 (about 2 seconds in) in his e1uv-404.lmp demo? It's a little less noticeable in subsequent levels, but it's still there (for me).

Grazza said:

try changing level_precache in the cfg to 1.


It's still the same.

Grazza said:

What's your processor/graphics card?

Processor: Intel Pentium 4 CPU 2.80Ghz

Graphics card: RADEON X300

Share this post


Link to post

Grazza said:
One thing you could check: are you using -complevel -1, and is it finding a doom2.gwa file? That could lead to problems if the gwa file is of low quality. (Don't know if it could lead to this problem, but it would mean it was using different nodes from the normal ones.)

It's set to 1 and there aren't any such nodes for the map anywhere. It's odd though, as it seems to have nothing to do with the nodes build; I loaded the v1.666 IWAD and nothing changed, then I redid the nodes with ZenNode and got the same effect.

Share this post


Link to post
ultdoomer said:

I don't know if I worded that well, so let me ask you this so I know you understand: Do you first see the graphics when Andrey opens the first door of E1M1 (about 2 seconds in) in his e1uv-404.lmp demo?

No, I see the graphics from a much earlier stage than that (at 100% gamespeed). Given that it's hard to judge just from watching it (I would have guessed at something earlier than 0.30s), I filmed it with my videocamera. The first frame displayed is 0.20s. It's still got the desktop superimposed with it (at least that's how the camera sees it), so perhaps 0.22s is the first "real" frame.

ultdoomer said:

Processor: Intel Pentium 4 CPU 2.80Ghz
Graphics card: RADEON X300

Hmmm. Mine is a nearly 4-year-old P4 2.2GHz with a 128MB GeForce 4. So it seems something is clogging up your system somehow. You could try setting your resolution to match that of your desktop - perhaps the resizing is a problem, but I'm just guessing randomly here. Perhaps someone else has some better ideas.

Share this post


Link to post
ultdoomer said:

I was wondering if you could do something about glBoom's level starts. Whenever I play a demo in that port, I don't see anything until about three seconds because it starts "drawing" the movements before it enters graphics mode.

Strange issues.
Do you have any anti-virus programs on your computer?
Try to disable theirs.

Share this post


Link to post
Grazza said:

After all, in Boom you can make any thing translucent via a bex/deh, but for this stuff you can't even turn it off in that way - it's all or nothing.

I've looked into this a bit more. I still can't see how to disable this in Boom, but I've found a way to do it in Prboom-plus (and presumably the official Prboom too - I haven't checked):

notransl.zip

This contains a simple dehacked file. It seems the translucency bit is interpreted as "disable translucency".

I don't know if this will work with Prboom-plus 2.2.6.26 though, as that will feature a bug fix that might impact this.

Obviously, a better solution would be to have a compat option to remove the MF_TRANSLUCENT flag from the 17 entries that have it set in info.c in the source code.

Share this post


Link to post

Grazza said:
I've looked into this a bit more. I still can't see how to disable this in Boom, but I've found a way to do it in Prboom-plus

Yes, the patch might come in handy to play wads that do contain wad-specific translucency (P:AR, etc.)

And it's not that the translucency bit is a toggle (on and off depending on whether the sprite was translucent in the first place.)

Share this post


Link to post
myk said:

And it's not that the translucency bit is a toggle (on and off depending on whether the sprite was translucent in the first place.)

No, doesn't seem that way (deh/bex stuff aren't toggles). I think I've pinned down what's going on:

  • Boom made 17 of the things translucent by default.
  • In Boom, the translucency bit makes things translucent. For the 17 things that are translucent by default, there is no way to make them non-translucent (apart from disabling translucency altogether).
  • In PrBoom, the translucency bit makes things non-translucent. For the things that are not translucent by default, there is no way to make them translucent.
Unless I'm missing something, to give users and mappers full control over which things are translucent, changes in the code are needed.

Share this post


Link to post

Ah, I wasn't aware it worked differently (and as documented or intended) in Boom. I guess it broke somewhere along the way for PrBoom (although that is beneficial in one way.)

The code should allow the translucency bit to add the effect, and translucent fire and missiles should be optionally either translucent, or not. Not translucent by default, in my opinion (or maybe the translucency of said sprites should be removed entirely, since it's just wrong.)

Eternity seems to behave like Boom.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now