I have removed the 35 FPS limit in prboom without loss of any compatibility

[entryway]

I've applied my changes of a prboom for the new version (2.2.6), have corrected some mistakes, made few improvement and removed the 35 FPS limit without loss of any compatibility. It looks excellently in game on my p4 3.4GHz and p3 1GHz and also at viewing and recording of demos. But I need in testing of this version. Especially on slow p3 computers.

[Grazza]

Sounds very interesting indeed - is this 2.2.5, with all the improvements from your 224_5, and some new features/fixes too?

I'm willing to put it through its paces, though I don't have much free time right now - I'll probably just have time to test playback of stuff. My new notebook is a Dothan 745, which isn't exactly slow [ :) ] but is at least a different processor to test it with.

[Off-topic: I don't know if you noticed, but your wad suffered a bad upload to the archive - that's why it wasn't in /newstuff this week. If you continue to have problems FTPing it, I'll upload it for you if you like.]

[Szymanski]

Sounds cool. I can test it with a 2800XP and see how fast it goes.

[entryway]

Grazza said:

Sounds very interesting indeed - is this 2.2.5, with all the improvements from your 224_5, and some new features/fixes too?

Yes, but 2.2.6 version, instead of 2.2.5

http://www.gamers.org/pub/idgames/REJECTS

I saw it, I shall try once again

http://geocities.com/e6y/beta.html
glboom\Main Menu\Options\Setup\StatusBar/HUD\Smooth movement

[Quasar]

Wow, I didn't realize this could be done O_O I am very curious!

[entryway]

Quasar said:

Wow, I didn't realize this could be done O_O I am very curious!

Only 20-30 lines of a code for the smooth camera movement and about fifty for realization of smooth movement of platforms. I am not sure, that it always works correctly. For example for smooth movement it was necessary to switch off vsync on slow computers (I do it)

[Szymanski]

looks better when moving fast. Does the 'Speed' status bar item mean much? it doesn't budge from 100 when playing.

[entryway]

Szymanski said:

looks better when moving fast.

If you will play not less than one hour with smooth movement, you never will want to switch off it. Because after switching-off at you puke will begin
(as at Vince from my movements in 30uv1441)

Does the 'Speed' status bar item mean much? it doesn't budge from 100 when playing.

But it incorrectly works with "smooth movement"
Try PAD+ and PAD- with "smooth movement off"

[Szymanski]

LOL, I need to read the manual (I guessed it was framerate)

As Grazza points out it only works with speed set to 100. Otherwise it breaks and for me doesn't work again until I exit and restart.

With speed = 100 though it ********ly works better than a capped framerate.

[Grazza]

It seems that:
1) If you turn on smooth movement, you should never reduce the game speed (can increase it, up to 100%, though).
2) You should never use smooth movement together with a gamespeed greater than 100%.

For me at least, it goes haywire in those two cases.

Edit (in response to Syzmanski): What I meant was that if you want to use slomo and smooth movement, you need to reduce the gamespeed and only then switch to smooth movement. [Or, as Ling points out, be willing to wait until it settles down.]

Edit2: I've observed that the screen flashes when teleporting if smooth movement is on. Normally this isn't very noticeable, but in my aotw-154 demo (on aotw.wad - it's in the new DSDA update), there are two silent teleporters in dark areas, and it is very noticeable then. The flash does not occur when smooth movement is off.

[Linguica]

Grazza said:

It seems that:
1) If you turn on smooth movement, you should never reduce the game speed (can increase it, up to 100%, though).
2) You should never use smooth movement together with a gamespeed greater than 100%.

For me at least, it goes haywire in those two cases.

Yeah it goes haywire, but then settles back down after 20 seconds or so. Very weird.

[Grazza]

You're right, it's only temporarily haywire when you reduce the speed (seems to take longer to settle down the more you reduce the speed).

However, it never works right if the gamespeed is >100% (the marine sprite becomes visible when you run forwards).

[Szymanski]

Switching after reducing the speed works, although it doesn't settle down if I enable it before.

Oh and in map05 the red key doors don't open properly, the texture stays put as the door opens.

[Grazza]

I noticed two more oddities when playing with smooth movement on. In both cases this was with normal gamespeed (100):

1) Very occasionally you briefly see the marine sprite (i.e. yourself). An example can be found at the start of map09 of 30nm3112. I managed to recreate this myself, but don't really know what triggers it. Rapid turning/movement and a height change seem to be involved though.

2) When the engine is struggling to get a decent framerate, the invulnerability effect flickers on and off. I observed this in nuts.wad.

[entryway]

Linguica said:

Yeah it goes haywire, but then settles back down after 20 seconds or so. Very weird.

Fixed.
Also the stupid desync was fixed.

[entryway]

Szymanski said:

Oh and in map05 the red key doors don't open properly, the texture stays put as the door opens.

It is a defect of the level design (line without upper unpegged flag).

[entryway]

Grazza said:

Very occasionally you briefly see the marine sprite

Fixed too

[Szymanski]

entryway said:

It is a defect of the level design (line without upper unpegged flag).

The door sectors (166 and 168) have LOWER UNPEGGED, not upper. It works correctly in prboom.exe

[entryway]

Szymanski said:

The door sectors (166 and 168) have LOWER UNPEGGED, not upper. It works correctly in prboom.exe

It works incorrectly in prboom.exe and vanilla doom2.exe, but correctly with any version of glboom.exe

[entryway]

Try last version prboom226_2.zip with few bugs fixed and increased performance.