I guess u r pushing movementbuttons after bfg shot?

Oh, and to get a more clear result, pls write that u compared plus with plusN and 1.03 probably with RC2a. 1.04 was yesterday.

wrote:

It seems the drop is dependent of how you execute the jump (i guess the airmovement has its part in this) - but the overall speed of the jump is still faster in 1.04 than in 1.03.

When ive seen your post i thought maybe the next link:
http://ucguides.savagehelp.com/Quake3/FAQFPSJumps.html
will be useful as a bit of a background for how the q3 is doing the jump.

__________
epsislow

Hmm what's that noise?

ZING!

wrote:

Actually, nop. That would be true if the pmove code would use float-integer casts, since it is the code that handles physics and is shared by both modules, but if you take a closer look you will find out that all the pmove code is floating point, except for the snap of the velocity vector at the end of PmoveSingle, and in that case that doesnt apply because the vector is snapped using an engine call, outside the rules of the qvm, so no rounding differences occurs (im guessing that change was introduced after the creation of the article, since several versions were released after it).

That said, it does seem that the precision of multiple floating point operations seems to have little differences between qvm/dll/so binaries. However, the precision errors are quite small, and even when cg_showmiss 1 shows several (in the dll case, a lot) of "prediction error" messages, the majority of them are really really tiny, in 99 % less than 0.001, so by no means that is the cause of all this whine.

Searching in all the code i can only see one factor that could possibly affect physics in e+ 2.0 and make them different from 1.03: the re-enabling of the overbounce "bug", since the actual modification is done in the code that handles ground movement, but that would mean that now the feeling is more vq3-alike, and that the v1.03 was the one that introduced those differences.