|
Notes |
|
|
(0005901)
|
|
Ru5tK1ng
|
2013-02-01 00:40
(edited on: 2013-02-02 04:32) |
|
Comparisons
Identical to 1.23b33:
Similar to 1.23b33:
V2.0.21: Jumping physics differ; slightly less gravity feel. RJumping is slightly different as well.
V2.0.98: Jump physics identical to V2.0.21; last version without 26 reverse window jump. Rocket Jumping is vastly different from b33; more akin to what is currently implemented in Zandronum.
Quite Different from 1.23b33:
V2.1: First version where map26 reverse window jump occurs.
|
|
|
|
|
|
One thing to keep in mind: According to Sourceforge, surprisingly 1.23b33 is newer than 2.0.47l (and older 2.0.x versions) as if the development of 1.23 continued after development of 2.0.x already started. 1.23b32 on the other hand is older than 2.0.x, so I assume that 2.0.x was originally based on 1.23b32. To get started I suggest to check whether 1.23b32 is identical to 1.23b33. |
|
|
|
(0005904)
|
|
Dusk
|
|
2013-02-01 12:32
|
|
|
I'd imagine having one ticket per issue would be easier to manage. though this ticket could still be kept as a "hub" through ticket relationships. |
|
|
|
|
|
Some updates have been added in my first post. Still need to test versions 1.23b32 and 2.0-13. Having difficulty compiling or obtaining a compiled version. |
|
|
|
|
Some of the air control physics change from 2.0.98 to 2.1.0.
I've been looking through the diff's for hours and I'm quite stuck on what exactly Randy changed to make the jumps go farther/maintain a higher velocity (and thus on Zandronum break some maps where you should be able to jump to places that you weren't intended to originally) |
|
|
|
|
Quote from Dusk
I'd imagine having one ticket per issue would be easier to manage. though this ticket could still be kept as a "hub" through ticket relationships.
The main problem is that it's very difficult to pinpoint the separate issues. We can create separate ticket for each issue we manage to isolate.
Quote from Watermelon
Some of the air control physics change from 2.0.98 to 2.1.0.
Yeah, the code differences between 2.0.98 and 2.1.0 are quite big. With which dmflags/compatflags were the test made? |
|
|
|
|
|
|
|
|
Nice! Does anybody know if this are all versions that still exist? Or does Randy have some more saved somewhere?
Some clarification on an older observation:
Quote from Torr Samaho
According to Sourceforge, surprisingly 1.23b33 is newer than 2.0.47l (and older 2.0.x versions) as if the development of 1.23 continued after development of 2.0.x already started. 1.23b32 on the other hand is older than 2.0.x, so I assume that 2.0.x was originally based on 1.23b32. To get started I suggest to check whether 1.23b32 is identical to 1.23b33.
The Sourceforge ordering was misleading. 1.23b33 is older than all 2.0.x versions. Apparently 1.23b33 Linux binaries were added after 2.0.47l was released, bumping 1.23b33 in the Sourceforge list. So there is no need to test 1.23b32. |
|
|
|
(0005918)
|
|
Dusk
|
|
2013-02-02 17:40
|
|
|
|
|
(0005919)
|
|
Watermelon
|
2013-02-02 18:11
(edited on: 2013-02-02 20:08) |
|
I don't know if it'd be useful, but I could always get the .diff files between 2.0.98 and 2.1.0 (despite it probably being large) and try and figure out what was changed.
I'm pretty sure it has to do with capping the horizontal movement. The Z gravity between both based on ACS seems to be completely unchanged (the Z momentum between 2.0.98 is the same as 2.1.0), which means that it has to just be a cap on the horizontal speed.
I just did some number crunching by debugging the x/y/z for both ports (with ACS since I can't get them compiled) for each tic to get the velocity, and it appears that there is a velocity change in ZDoom 2.1.0:
Data compilation here:
'http://pastebin.com/raw.php?i=Tr9NTUc0 [^]'
Raw data:
'http://pastebin.com/raw.php?i=SBFWJ77q [^]'
I did these in the same map from the same position hitting the same key with the same commands and same dmflags/compatflags as each other. Everything is identical that I did to rule out anything human error based as far as I could tell. I will attach the map. Both runs are done with SR50 (if you need my config I'll upload), I only click the SR50 button which performs SR50 left (forward + left strafe + turn which makes you gain slightly extra speed).
I got this data by running MAP26, then doing:
skill 4
map map26
logfile "data.log"
then I just hit Q to perform SR50 left only and got the data when jumping at the very edge of the platform.
EDIT: IT appears there is some capping done. The y movement based on SR50 for the following data was changing 0.09 map units in ZD 2.1.0, and the same while on the ground in ZD 2.0.98, but upon going airborne the velocity is capped by a ration which reduces 0.09 units of Y movement to 0.08.
Before jump change in x map units (delta between position tic x and tic x - 1)
Tic x: 22.690 vs 23.080
When the player jumped:
Tic x + 1: 20.580 vs 23.080
The left is ZD 2.0.98, right is ZD 2.1.0
THEREFORE it appears that your velocity is reduced 10% when you press jump based on the math that was done. So far a hacky workaround would be to just multiply the velocities of X and Y by 0.9 on the tic that jump is pressed and the player is on the ground while it creates vertical thrust when the player has none.
|
|
|
|
(0005920)
|
|
AlexMax
|
2013-02-02 20:11
(edited on: 2013-02-02 20:18) |
|
@Torr, that repository is basically identical to the sourceforge source zips. The only difference is that when both the windows and linux versions were available for the same version, only the linux version was put in the repository.
Those are all the source zips that remain. All the others were lost to a hard drive crash years ago. I am also under the impression that ZDoom 2.0.98, or some close descendant, was put into the modern zdoom SVN repository as the starting point.
EDIT: Perhaps it also might be worthwhile to try and bring forward Vanilla physics, while we're at it?
|
|
|
|
|
@Torr
Keeping the absolute velocity capped stops some of the 'impossible' jumps, but not others, so I can't solve it by capping the velocity
@Alex
For vanilla physics do you mean
- X and Y movement from doom95.exe stuff
- Z movement from ZDoom < 2.1.0? |
|
|
|
|
@Water
I'm guessing for Z movement, the 'vanilla' physics would be from 1.23b33. There exists a difference in Z movement between v1.23 and v2.0.21.
I would still like to get my hands on 2.0-13 out of interest. |
|
|
|
|
Quote from AlexMax
I am also under the impression that ZDoom 2.0.98, or some close descendant, was put into the modern zdoom SVN repository as the starting point. You're right! The first ZDoom SVN revision is more than 200 hundred revisions older than ZDoom 2.1.0 and newer than 2.0.98. Can somebody compile the first SVN revision?
Water, I'll have to look at your analysis in more detail later. |
|
|
|
(0005924)
|
|
Watermelon
|
2013-02-03 16:45
(edited on: 2013-02-03 16:50) |
|
Too much stuff is missing from the early ZDoom revisions.
- Required an unknown old FMod version that the FMod site has completely dropped support for and can no longer be found on the net
- Trouble solving what NMAKE is/does
NOTE: One may be able to find Fmod < v4, located here:
'http://www.basic4ppc.com/forum/official-updates/2661-fmod-library-v1-5-a.html [^]'
The problem is it requires an account, and even then it wont let me download, so I fired off an email to the tech support on that site to help me get it. This may not even be the FMod API... I think we're out of luck here unless someone has a backup somewhere.
We may be in for some problems here because all these old ZDoom revisions are completely broken since FMod doesn't look like it can be found, let alone compiled.
What I COULD do is get all the .diff's between the files and attempt to see what was changed in game.
Can we guess safely that between revision 4 and revision 200 there was this 'physics' change?
@Torr
Is there an area of code that would handle this? I have all the .diff's between 2.0.98 and 2.1.0, but I could not seem to find it in p_mobj or p_user... I'm not sure exactly where to look.
|
|
|
|
|
These old ZDoom versions require FMOD 3.75, which I still have. With a few changes I managed to compile ZDoom revision 18. Please test this binary to see if it behaves like 2.0.98 or ZD 2.1.0.
Quote from Watermelon
I just did some number crunching by debugging the x/y/z for both ports (with ACS since I can't get them compiled) for each tic to get the velocity, and it appears that there is a velocity change in ZDoom 2.1.0: Can you post your ACS analysis wad here?
|
|
|
|
|
|
|
|
|
So the difference was introduced between revision 18 (binary I posted) and 2.1.0 (revision 204). I'll compile another binary to narrow it down further.
BTW: Your note says "ACS here:" but there is not ACS. |
|
|
|
(0005928)
|
|
Watermelon
|
2013-02-03 20:06
(edited on: 2013-02-03 20:09) |
|
Sorry my bad, by ACS I meant what was calculated from GetActorX and GetActorY (in the raw data thing, that's straight from ACS GetActorX, Y, X, and Y)
I wish I could compile this stuff, if you have a link to the FMod/whatever else I need I will gladly do half cuts in the SVN until I get to the proper version.
|
|
|
|
|
|
|
|
|
|
Yes that's perfect for me, I use Windows for most of my compiling |
|
|
|
(0005931)
|
|
Watermelon
|
2013-02-03 20:27
(edited on: 2013-02-03 20:36) |
|
Also I do successfully make that jump in that version, so the physics have changed in the new one you put up
EDIT: Was your first binary revision 4?
EDIT2: Is there any other utility you use for them? Like nasm-2.00
EDIT3: I assume this is from this SVN right? 'http://zdoom.org/Changelog/1 [^]'
|
|
|
|
(0005932)
|
|
Torr Samaho
|
2013-02-03 21:43
(edited on: 2013-02-03 21:44) |
|
Quote from Watermelon
Was your first binary revision 4?
No, it's 18 (see 0001271:0005925 and the file name of the archive).
Quote from Watermelon
EDIT2: Is there any other utility you use for them? Like nasm-2.00
Yes, I use nasm. For this I just replaced "nasmw" by "nasm" in the VC++ project files.
Quote from Watermelon
EDIT3: I assume this is from this SVN right?
Yes, it is.
|
|
|
|
(0005933)
|
|
Watermelon
|
2013-02-03 21:59
(edited on: 2013-02-03 22:17) |
|
What FMOD version are you using? The current one 4.26.[something] that works with the current Zandro doesnt work with ZDoom
EDIT: I may need an older one
Or maybe I can somehow have it not compile sound?
It said on the ZDoomWiki you need 3.x series of FMOD to compile and that's been removed from the net.
EDIT2: My bad didn't see the PM
|
|
|
|
|
FOUND IT
Is there a way I can do a quickie commit for review for the Zandro code? |
|
|
|
|
Quote from Watermelon
FOUND IT
So you found what's causing the map26 jump? Great! Which ZDoom revision caused the change?
Quote from Watermelon
Is there a way I can do a quickie commit for review for the Zandro code?
Sure, there are multiple ways. For instance you could commit it to a local clone of the Zandronum repository, export the commit as patch and attach it here. Or Create a fork on bitbucket and commit it over there. |
|
|
|
(0005936)
|
|
Watermelon
|
2013-02-04 20:50
(edited on: 2013-02-04 20:53) |
|
|
|
|
|
|
I assume you also made changes in d_main.cpp. Can you attach this file? Or just tell me how you named the new CVAR and I can add the line myself. |
|
|
|
|
Sorry I haven't, I didn't even know what to add to d_main.cpp.
I named it COMPATF2_OLD_JUMP_PHYSICS but feel free to name it whatever you wish. |
|
|
|
|
|
|
|
|
|
Ok, this binary add the CVAR compat_oldjumpphysics that activates an altered version of your patch. As far as I can tell, your patch didn't work properly for actors with FLOATBOB. Those got momz added twice. |
|
|
|
(0005941)
|
|
Dusk
|
2013-02-05 11:50
(edited on: 2013-02-05 11:52) |
|
I'd still suggest leaving "old" out of compatibility flag names because compat flags kind of imply in itself that they reactivate old stuff and bugs. The name could just be compat_jumpphysics.
|
|
|
|
|
|
Confirmed working on my end for the latest binary. My mistake if FLOATBOB got added twice, I made the mistake of not actually testing that :( |
|
|
|
|
I have attempted to compile ZDoom 2.0.13 myself, and I actually made progress towards it. There are six main classes of errors:
- zlib project was broken. Actually, the zlib project was correct, it's just that the zdoom project file was using the wrong version number. Editing the project to point at the correct directory fixes this.
- Can't find nasm to compile the assembly files. I simply deleted them from the project, and I assume there is a define to disable usage of assembly functions in place of C equivalents.
- Some template ugliness in v_font.cpp/h that modern Visual C++ doesn't like. Thankfully, there was a ready replacement in the form of a GNUC++ equivalent that was #ifdefed, so I just deleted the MSVC-specific version.
- Lots of cases where the codebase tries to take the square root of a non-float or an absolute value of an unsigned int. Simple casts seemed to smooth things over.
- I didn't have the proper version of FMod. I was prepared to stub out the sound system if it would get the thing to compile.
- Invalid casts of const char* to BYTE. This is where I got stuck.
This release is from the dark era of Randy using multi-layered macros to define actors. The trouble comes in when attempting to initialize FActorInfo::DefaultList, which is of type BYTE[], using said multi-layered macros. Some of those macros take hardcoded strings (const char*) as parameters, and Visual C++ doesn't like this conversion. This is where I'm stuck. Thanks to DavidPH for helping me get this far. :)
As for what to call the cvar, why not have the cvar describe which version it came from? compat_123b33jumpphysics is a lot more descriptive than 'old', since zdoom's physics appear to have changed several times in subtle ways over the years. |
|
|
|
|
|
I also had a shot at compiling ZDoom 2.0.13. I'm down to two linker errors that may be caused by the v_font.cpp/h you mentioned. I'll look into this again later. |
|
|
|
|
|
I tried adding this to the server end, though it tends to cause some slight vertical de-syncs, I figure this won't happen when the client has the code since it will interpolate correctly? |
|
|
|
|
Here is ZDoom 2.0.13. I had to remove parts of the FMOD code, apparently this ZDoom version was intended for an FMOD version even older than 3.75. The source was also missing zdoom.wad, so I used the on from 1.23b33.
Quote from Watermelon
I tried adding this to the server end, though it tends to cause some slight vertical de-syncs, I figure this won't happen when the client has the code since it will interpolate correctly? Making this kind of changes server side only will mess up the client side movement prediction. It should work just fine if the code is on client and server. |
|
|
|
|
|
When I try to run 2.0.13, I get an error: side-by-side configuration is incorrect. I'm on Win7. |
|
|
|
(0005980)
|
|
Torr Samaho
|
2013-02-10 12:05
(edited on: 2013-02-10 12:24) |
|
Other than all messed up colors, I can run 2.0.13 on Win7 x64. Did you try deleting your ini? Can somebody test it on an older Windows version or with Wine under Linux?
EDIT: Does 2.0.21 feel closer to 1.23b33 if you set compat_wallrun to 1?
|
|
|
|
|
The executable works fine on my PC; Windows 7 64-bit. I'm not skilled enough to be able to tell the difference in terms of physics, but it does work.
Out of curiosity, Torr, how did you fix the const char* to BYTE casts? |
|
|
|
|
|
Actually I didn't touch theses casts. VC++ 2005 didn't complain about them. |
|
|
|
|
|
I'm still unable to run zdoom.exe even with no ini in the folder. |
|
|
|
|
|
I have no idea what's causing this error for you. Can you post a screen shot of the error? |
|
|
|
|
|
|
|
|
|
Can you check the error message in the application event log? |
|
|
|
|
Quote
Activation context generation failed for "D:\ZDoom-2.0.13\zdoom.exe". Dependent Assembly Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.6195" could not be found. Please use sxstrace.exe for detailed diagnosis. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
That did the trick. I've concluded that .13 has a similar feel as .21 |
|
|
|
(0006038)
|
|
Torr Samaho
|
2013-02-17 08:22
(edited on: 2013-02-17 10:03) |
|
So 2.0.21 and 2.0.13 are the same and thus both have different jumping physics compared to 1.23b33? Are the differences big enough so that it would make sense to search for the code differences and add a new flag (or extend compat_123b33jumpphysics) to compensate for this?
BTW: Nobody answered my question regarding the wallrun flag yet:
Quote from Torr Samaho
EDIT: Does 2.0.21 feel closer to 1.23b33 if you set compat_wallrun to 1?
|
|
|
|
|
|
It appears that setting compat_wallrun to 1 doesn't affect the physics or feel. The difference between the jumping of b33 and 2.0 is really miniscule and the search for code differences really wouldn't be wroth the effort. I've recently switched to a new computer and the 'slightly less' gravity feel is even more slight. |
|
|
|
|
|
Is it possible that any further differences in feel could be accounted for by the fact that 2.0 had uncapped framerate compared to the 35FPS cap of 1.23b33? |
|
|
|
|
|
Shouldn't this be flagged as resolved since compat_123b33jumpphysics was added already? |
|
|
|
(0007347)
|
|
Arco
|
|
2013-10-08 01:28
|
|
Quote from Jroc
Shouldn't this be flagged as resolved since compat_123b33jumpphysics was added already?
Noted. I'll close this then. |
|
MAP26.wad (233,145) 2013-02-02 18:16
p_mobj.cpp (186,263) 2013-02-04 20:53