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

PrBoom-Plus, ver. 2.5.1.4

Recommended Posts

Grazza said:

Maybe it looks a bit too grainy sometimes though. Are they any settings that affect the way it works, or is it all or nothing?

It is possible to try to replace my detail texture with any another in the same format. By means of any editor of resources.

And of course on some textures it just looks odd - you don't expect, e.g., brushed metal to look bumpy close-up. Presumably that couldn't be changed without some very clever programming though.

It is necessary to use a few detail textures instead of one.

Share this post


Link to post

Oh, I see (looks at detail256.bmp in the source zip). Given that it wasn't using any external resources, I presumed it was somehow done using an algorithm.

Share this post


Link to post

>looks at detail256.bmp in the source zip
From Serious Sam: The First Encounter. I have installed it for viewing Vile's speedruns.

Share this post


Link to post
entryway said:

From Serious Sam: The First Encounter. I have installed it for viewing Vile's speedruns.

Oh, I'd missed that. I'd better see if I can pick up a copy of the game.

Share this post


Link to post

prboom226_11.zip could be found on:
http://www.geocities.com/e6y/doom.html

Changes:
(+) demos: option for smooth turns during viewing of demos. It makes sense for TAS demos recorded with slowmotion.
(-) smooth movement: some flickers after menu closing.
(-) original prboom: prboom uses monster_avoid_hazards setting from the cfg file when you are using -complevel 0 or -complevel 1. If you have this option set to 1 in your cfg, then you are at risk of getting desyncs in demos that feature crushers. (Dashiva)

Share this post


Link to post
entryway said:

(+) demos: option for smooth turns during viewing of demos. It makes sense for TAS demos recorded with slowmotion.

I like this feature very much. With all my demos %))

Share this post


Link to post
entryway said:

(+) demos: option for smooth turns during viewing of demos. It makes sense for TAS demos recorded with slowmotion.

I have noticed a problem with this when the demo includes very sharp turns. My ic25n102 (TAS NM on Icarus map25) features a TR99 tic(!). If you watch it with smooth movement and smooth turns (factor 6), then the player ends up pointing the wrong direction for the rest of the demo. I noticed that it is OK with factor 1 (but not factor 16), so presumably it depends on both the sharpness of the turn and the degree of smoothing. (Perhaps it depends on other things too, so you may have to adjust your settings.)

Share this post


Link to post
Grazza said:

I have noticed a problem with this when the demo includes very sharp turns. My ic25n102 (TAS NM on Icarus map25) features a TR99 tic(!). If you watch it with smooth movement and smooth turns (factor 6), then the player ends up pointing the wrong direction for the rest of the demo.

Thanks. I should use __int64 instead of int for demo_lastturnssum and you should reload the corrected version.

Share this post


Link to post

prboom226_12.zip
(*) demos: changes in algorithm of smooth turns. Now smoothing occurs in a range [currtick-smoothfactor..currtick+smoothfactor] instead of [currtick-smoothfactor..currtick]
(-) demos: turns did not smooth out if the option of smooth movements has been switched off
(-) demos: problem with smooth turns when the demo includes very sharp turns (Grazza)

Share this post


Link to post

I found another demo where the smoothing causes a similar problem: mw16-531 (Marswar map16 UV Max, non-TAS). The problem occurs right at the beginning. I don't make any particularly sharp turns, but do get buffeted about by the demons that I'm chainsawing.

The problem occurs with the original 226_11, the amended 226_11 and 226_12.

Share this post


Link to post
Grazza said:

I found another demo where the smoothing causes a similar problem: mw16-531

prboom226_13.zip
(-) smooth turns in demos: bug arising after forcibly changing of the player's viewangle by the engine at use of a saw or a fist (Grazza)

P.S.
Still does not work and switched off by default.

Share this post


Link to post

prboom226_14.zip
(*) smooth turns in demos: changes in algorithm. Now smoothing occurs in a range [currtick-smoothfactor..currtick] instead of [currtick-smoothfactor..currtick+smoothfactor]
(-) smooth turns in demos: wrong direction of a player sight after respawn.

P.S.
I hope, that now all works as intended.

Share this post


Link to post

prboom226_15.zip
(*) full mouselook: a big increase in FPS if the viewpitch of the player is in the range from -45 to +45 degrees (with default FOV). From 87 up to 175 on my system in the first room after the lift on MAP14@scythe2, but still remains absolutely not optimized
(*) smooth movement: minor changes.

Share this post


Link to post

Just wondering if in a future version could autoaim be disabled as an option ? - would work nicely with freelook. :)

Will there be detail textures for flats ?

Share this post


Link to post
hawkwind said:

Will there be detail textures for flats ?

Detailed texture for flats is already available. Look in options. But I think it'd be better to eliminate it or implement full support of detail lump, where for every texture would be possible to set detailed

Share this post


Link to post

It might me worth considering putting demos, movements, pallete and bumpmapping under GENERAL options. It really doesn't make much sense having these under Status bar \ HUD.

Share this post


Link to post

prboom226_16.zip
(-) bugs of the previous version.
(-) smooth movement: bugs in algorithm appearing at low framerate (40<fps<100).

Share this post


Link to post

prboom226_18.zip
(+) full mouselook: "mouse look" sprite for adjustment of mlook sensitivity in the "OPTIONS\Mouse Sensitivity" menu
(+) demos: "overwrite existing" setting for overwrite of existing demo. (if it does not contain savegames)
(-) GLBoom: bug in my algorithm of a middle textures drawing if the value of the gl_tex_filter_string setting in your config is GL_NEAREST or GL_LINEAR (without mipmaping) Tell me if it does not work.
(-) smooth turns in demos: wrong direction of a player sight after loadgame request caused from the demo.
(*) factor of vertical sensitivity was reduced in four times
(*) smooth movement: more smooth movements at low FPS.

Share this post


Link to post
Janizdreg said:

Could you possibly borrow code from other OpenGL ports to make the sprites not clipped at the bottom?

prboom226_19.zip
(+) support up to 65536 sidedefs instead of 32768.

prboom226_20.zip (includes the newest version of the sdl.dll)
(+) glboom: multisamling (anti-aliasing) support.
(+) glboom: "smart items clipping" setting.
(-) detail texture: dividing by zero.

P.S.
Now this project has a mirror on sourceforge.net: http://prboom-plus.sourceforge.net
Please post any feedback there: http://sourceforge.net/projects/prboom-plus

Share this post


Link to post

Best version of PrBoom yet, but...why isn't music playing? I have a Sound Blaster Live and my onboard sound is disabled completely. I've already tried all the different MIDI devices. I'm guessing I need Timidity or MP3 files, though I can't imagine why. Check that, neither of those work, either.

Share this post


Link to post

2.2.6.21
(+) Added switch to force monster_avoid_hazards: -force_monster_avoid_hazards. It is meaningful for viewing doom-compatible demos recorded with "monster_avoid_hazards 1" in config (in cases of desyncs).
(+) Renders bsp tree in automap mode.
(!) Allows mouselook during playdemo in camera mode.
(!) FOV units have been adjusted to conform with commonly used scale. (64=>90)
(!) The step of gamespeed change varies automatically depending on current speed. Option "step of speed change" is removed.
(-) Wrong keys size in automap mode. (the bug was introduced in 2.2.6.19)

Share this post


Link to post
entryway said:

(!) The step of gamespeed change varies automatically depending on current speed. Option "step of speed change" is removed.

I have to say I don't like this change. I liked the complete control that you had the way it had been set up - you could change it to any percentage you wanted. The only possible improvement I could have suggested was introducing a large step and a small step, so you could quickly change it by a large amount while still retaining fine control. I feel the new set-up is clumsy and restrictive.

(-) Wrong keys size in automap mode. (the bug was introduced in 2.2.6.19)

I was wondering about that... I thought maybe it was to make them easier to find. :p

If you're looking for further things to change, then I can suggest looking at my bug reports in the standard prboom forums. Perhaps the most useful would be: fixing the remaining bugs in dehacked support (so, e.g., Hacx works), fixing the error when recording with MBF compat (the header is wrong) and trying to improve the behaviour at start-up (turn-snap in software mode; hard to get any sort of quick start with either), and maybe giving the user more options with respect to mouse acceleration (like Chocolate-Doom does).

Share this post


Link to post
Grazza said:

I have to say I don't like this change at all. I liked the complete control

In what real cases it is inconvenient? Examples, please.

Share this post


Link to post

Extra control is generally useful. Maybe I want to watch something at 1% or 125%. Or to set the step to 900 so I can flip between normal speed and 1000% in a single key press (to watch certain sections at normal speed and fast forward between them).

A suggestion: why not have the automatically varying step (as it now is in 2.2.6.21) as the default, but add the "step of speed change" option back in so the user can choose something else instead. For instance, 0 could mean "varies automatically depending on current speed", and higher values mean a fixed step of the user's choosing. Those who like the new method need never worry about it; those who prefer the old way can still have complete control.

BTW, I should add that I can see the new method being rather useful - just as long as it isn't the only way to control it. :)

Share this post


Link to post
Grazza said:

A suggestion: why not have the automatically varying step (as it now is in 2.2.6.21) as the default, but add the "step of speed change" option back in so the user can choose something else instead.

ok

Share this post


Link to post

You did not try to use it indeed :))) The universal method is more convenient in overwhelming majority of cases.

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
×