Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
entryway

PrBoom-Plus, ver. 2.5.1.4

Recommended Posts

VinceDSS said:
I dont want to use glboom, it doesnt look right...

Doom does the same thing; I always take my screen shots (for reviews) with the Print Screen key plus paste instead of -devparm and F1, because of this. To get every thing on software mode you'll have to use an external frame capturing application.

Share this post


Link to post

I tried fraps but it lags with software capture (for GL / D3D, it's really good).

I have to get hold of dash, I know he modified a prboom just fro screen capture.

Share this post


Link to post

I don't know why function which does a screenshot, loads the default palette. It's easy to change this behaviour.

Share this post


Link to post

I am gonna give a try with GLboom but I need to tweak the display so lighting isnt screwed up too much and textures/sprites not too blur.

I looked around but I find no documentation about the GL options in GLBOOM.CFG :(

anybody knows a bit about it ?

Share this post


Link to post

If you want stuff pixelated, then use this:

gl_tex_filter_string      "GL_NEAREST"
If you have "detail texture" turned on, then you'll want to turn it off - it looks very weird together with GL_NEAREST.

Some documentation (for the regular glboom) here (scroll down to "OpenGL Settings").

Share this post


Link to post

thanks a lot, I will try both filtered and non filtered, as I think that sharp pixels are harder to compress for AVIs...

edit : I had to use "gl_sprite_offset 3" or the bottom of sprites is clipped into the ground :) but I feel they are taller than usual now :)

Share this post


Link to post

I have not understood, that you mean. Brightness can be increased by means of F11 and you should know it. The filtration of textures and sprites depends on value of the gl_tex_filter_string, but I don't see any sense not to use the trilinear filtering (GL_LINEAR_MIPMAP_LINEAR)

gl_tex_filter_string "GL_LINEAR_MIPMAP_LINEAR"
gl_tex_filter_string "GL_LINEAR_MIPMAP_NEAREST"
gl_tex_filter_string "GL_NEAREST_MIPMAP_NEAREST"
gl_tex_filter_string "GL_LINEAR"
gl_tex_filter_string "GL_NEAREST"

Share this post


Link to post
VinceDSS said:

as I think that sharp pixels are harder to compress for AVIs...

You don't need to think about it

Share this post


Link to post
VinceDSS said:

edit : I had to use "gl_sprite_offset 3" or the bottom of sprites is clipped into the ground :) but I feel they are taller than usual now :)

Try turning on Smart Items Clipping.

Share this post


Link to post

thanks!

I just did the 30cs2227.lmp in high quality H.264, it takes 300 megs.
It has Radeg's view as main and mine as a thumbnail in a corner.

I don't know where I could get that hosted as my bandwidth is limited, just like any DSL users I guess. Could it be available as a torrent?
I have no idea how to do that...

PS : I am making now a 50 megs xvid low quality one...

Share this post


Link to post

http://www.geocities.com/e6y/doom.html
http://sourceforge.net/projects/prboom-plus/

2.2.6.27

[+] PrBoom compatibility: two new options for intercepts overflow detection. It detects and tries to emulate overflows on some odd demos like blackbug.lmp, manorbug.lmp, hr27odd.lmp, av08-odd.lmp, etc.
[+] PrBoom compatibility: two new options for playeringame overflow detection. It detects and emulates overflows on vex6d.wad\bug_wald(toke).lmp, etc. It works without crashing in Eternity and chocolate-doom only by good fortune.
[+] Cheating: new command line switches: -trace_thingshealth, -trace_thingspickup, -trace_linescross. Usage:

-trace_thingshealth ThingID [ThingID] [ThingID]
-trace_thingspickup ThingID [ThingID] [ThingID]
-trace_linescross   LineID  [LineID]  [LineID]
[+] Autorun: the "RUN" key inverts the autorun state
[!] PrBoom compatibility: minor changes in processing overflow of spechit array. It became possible after decompiling of DOS EXE.
[!] Names of variables responsible for overflows and their default value have been changed. It's switched on for emulation and switched off for warnings now.
[-] Smooth turns in demos: movements of first player in a net-demo were not smooth if the second player is dead.
[-] GLBoom: from certain angles and distances, things behind a translucent texture become invisible (test).
[-] Boom bug: desyncs after using the key for switching to SSG directly with demo compatibility. This bug is present in current Eternity too. Thanks myk for the detailed information about it.
[-] Launcher: the selected IWAD was loaded after preloaded wads.
[-] Detail texture: detail texture moves slower than scrolling floors.
[-] Detail texture: fixes for old videoadapters which do not support gl_arb_multitexture extention (still buggy).
[-] Impossible to change game speed when viewing a net-demo (2.2.6.25).

Share this post


Link to post

I searched around for a few more demos with Intercepts overflows, and found these:

bug_hr.zip (Opulent) contains (all on HR.wad):
bug_hr10.lmp
bug_hr24.lmp (I suggest -skipsec 330)
bug_hr01-09.lmp (I suggest -skipsec 2650)

yab_wow!.lmp by Albert Valls (on yab.wad)

nutsnp52.lmp by me (on Nuts.wad). The effect of the overflow here is to desync the demo (recorded without emulation) and to cause (for me at least) a massive drop in performance. So it might be best not to watch this one.

The emulation appears to work OK for all of these (though it's hard to say for the Nuts one, as it would tie my machine up for a few hours to test it to the end).

Any others? (Edit: yes - meph-bug.lmp and n1m3bug.lmp. Any others besides those?)

Share this post


Link to post
entryway said:

[-] Boom bug: desyncs after using the key for switching to SSG directly with demo compatibility. This bug is present in current Eternity too. Thanks myk for the detailed information about it.

I hope that myk has not taken offence that his some demos have ceased to work (they should not work) in PrBoom :)

Share this post


Link to post

entryway said:
I hope that myk has not taken offence that his some demos have ceased to work (they should not work) in PrBoom :)

Heh, no problem, they were mainly for /newstuff reviewing purposes during the month those wads were uploaded.

Share this post


Link to post

@entryway:

Something new! Many thanks!
:)



Edit:
The launcher takes only IWADs, that are in the same directory. Would it be possible, to browse frm that interface to an iwad, that is not in the same directory, and to store then automatically it's location in a configuration file?

Greetings
Funduke

Share this post


Link to post
funduke said:

The launcher takes only IWADs, that are in the same directory.

PrBoom+'s launcher searches for iwads (and pwads) in the current dir, PrBoom EXE dir and %DOOMWADDIR%

Share this post


Link to post
entryway said:

PrBoom+'s launcher searches for iwads (and pwads) in the current dir, PrBoom EXE dir and %DOOMWADDIR%

Ah, now I understand why the cache can contain up to three copies of each wad name.

BTW, if anyone doesn't know how to set the %DOOMWADDIR% in XP or Win2k:
Control Panel - System - Advanced - Environment Variables - System Variables - New
Then enter DOOMWADDIR as the variable name and whatever the folder is (e.g. C:\DOOM2) as the variable value.

Share this post


Link to post
entryway said:

I hope that myk has not taken offence that his some demos have ceased to work (they should not work) in PrBoom :)

This seems to affect more demos than that. For instance, 1427uv01.lmp now desyncs (see this post).

Indeed, one would expect desyncs with any vanilla demos recorded with Prboom or Prboom-plus where the player has used a key to switch directly to the SSG. I don't know if any regular recorders have that as part of their set-up, and don't have time to test many demos right now.

Edit: I doubt there are very many though - I presume most recorders test their own demos, and at the very least any in demopacks will have been tested, so we'd probably have spotted if anyone regularly recorded demos with this problem.

Two ways to solve this occur to me:
* Make it so this fix is for recording only (so you can't now record a demo with Prboom-plus that desyncs with Doom2.exe for this reason), but not for playback (so any such demos recorded with older versions will still play back OK).
* Add in a command-line switch to enable the direct switch to SSG, so that demos specifically affected can be made to play back. This would be consistent with the solution for the old desyncs resulting from the monsters_avoid_hazards bug.

Share this post


Link to post

I wrote a script that converts "1.9" demos relying on the Boom behavior to genuine Vanilla demos that play back properly in Vanilla Doom. It isn't perfect though. You can see my fixed version of 1427uv01.lmp here.

We're stuck in the weird position of (presumably) having a bunch of demos that are "Boom Vanilla" demos - demos that rely on this incompatible boom behavior but are otherwise Vanilla demos. I'm of the opinion that it would be more sensible to fix the demos than to add yet more compatibility hacks into the source ports.

EDIT: Here is my script.

Share this post


Link to post
Grazza said:

This seems to affect more demos than that. For instance, 1427uv01.lmp now desyncs (see this post)

Surprisingly. Desync at viewing this demo with DOS EXE has been found only after fixing of Boom's bug. In a two years. I prefer the second variant, but PrBoom team has preferred the first (2.4.1)

Share this post


Link to post

Grazza said:
I don't know if any regular recorders have that as part of their set-up, and don't have time to test many demos right now.

I never touched the key_weapon settings. Perhaps I hit the 9 or something? (I was playing like shit due to relatively recent cfg changes when I recorded the demos where I first spotted the desynch, so that's not impossible.)

Anyway, I watch v1.9 demos recorded with PrBoom on Doom/2 all the time, and I don't remember any such desynchs on other people's demos... at least not enough for it to matter? I tend to ignore TAS demos though, so I'm pretty sure I never watched Andrey's enhanced or cheated max.

Share this post


Link to post
entryway said:

What do you think about my posts and two screenshots on:
http://forum.drdteam.org/viewtopic.php?p=12187#12187


I agree that it looks bad at stupid angles: however that isn't a GL only issue, many software ports have mouselook and therefore allow stupid angles, too.

I think keeping the sprite's orientation the same at all times, as per vanilla doom, looks best in most cases (giving that most doom levels are not designed with stupid angles via mouselook in mind)

Share this post


Link to post

mlook will inevitably lead to some odd-looking stuff, but I think this is a change for the better.

On another topic, I noticed something odd in your default cfgs. render_fov has the value 100, whereas in history.txt we have:

[!] FOV units have been adjusted to conform with commonly used scale. (64=>90)
I presume 90 should be the default (i.e. it matches the FOV in the original game).

Share this post


Link to post

Does mouselook even matter for PrBoom+? I can see why Graf Zahl might not like those changes for GZDoom, but PrBoom+ is for Doom and Boom maps... why use mouselook in PrBoom+ except for spectating demos and such? (And while spectating you can't expect things to look perfect always anyway.)

Share this post


Link to post
Grazza said:

On another topic, I noticed something odd in your default cfgs. render_fov has the value 100. I presume 90 should be the default (i.e. it matches the FOV in the original game).

The default value is really equal to 90. The cfgs inside zip is only my settings. Probably it will be better if I'll move them to .\cfgs subdirectory.

Share this post


Link to post

I think it makes sense to have the cfgs in there (and not in a subdirectory), so that people using it "straight out of the box" will have a good "typical" set-up in terms of compatibility options, display and controls. Or else adjust the engine defaults.

Although it is a non-issue to "expert users" who will tend to tweak the settings to their liking immediately, a lot of people clearly rarely edit their cfg or explore the in-game menus too much, so it is quite important that the default behaviour doesn't put newcomers off (low resolution, weird MBF monster AI, etc.).

Share this post


Link to post

Grazza said:
Or else adjust the engine defaults.

This should be done, in my opinion; the dependence on the extra file can cause confusion. Not so much for regular users, like you say, since they generally just use an older CFG, but for people trying out the engine. And the defaults should have pretty clean settings (unlike Boom's; it stuffs most of the new features in your face... and so does PrBoom to a degree, using those ugly status bar number colors by default, for example.)

And even then, important "default cfg" changes should be noted in the "new/update" document so that people with existing CFGs may be aware of any changes or optimizations.

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
×