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

PrBoom-Plus, ver. 2.5.1.4

Recommended Posts

I disagree with you. Without strafe50 we have proportions for walking: forwardmove / sidemove = 0x19 / 0x18 ~ 1 Why with strafe50 we should have these strange proportions: forwardmove / sidemove = 0x19 / 0x30 ~ 0.5 ? I think the walking side speed for strafe50 should be equal to the walking forward speed (0x18) because they are equal at run

Share this post


Link to post

Strafe50 is normally activated by pressing either strafeleft/straferight in addition to pressing StrafeOn & left/right. Because of the button combination it's true for both if() statements, meaning side is increased twice. In the case of running that's 40+40=80. Because that's higher than MAXPLMOVE, it's reset to MAXPLMOVE(or 50). When walking, the combination produces 24+24=48.

If Strafe50 were an intended effect(like I thought when I made my original post), then 0x19/0x32 would be the logical choice. However, AFAIK, the old mousedriver simply took advantage of the bug, which would make 0x30/0x32 the correct pair.

Can someone who actually has the mousedriver confirm this? What was the strafe speed when walking?

Share this post


Link to post
Andy Olivera said:

Strafe50 is normally activated by pressing either strafeleft/straferight in addition to pressing StrafeOn & left/right.

Well, there's no need for the combination; I can achieve Strafe50 only with strafe-on. I strafe-on with the right mouse button and rarely use strafe left or right, yet I often find S50 tics in my demos.

Share this post


Link to post

Yes, it is known that you can get S50 just from side-to-side mouse movement plus strafe-on. I think most people just find the way Andy described as more convenient and controllable.

As I see it, the most important thing here is to make sure Prboom-plus's standard input behaviour (without permanent S50) matches that of Doom2.exe (without S50 mousedriver), and fortunately that is relatively straightforward to check, as long as you remember to test all the methods that can be employed to achieve it.

Share this post


Link to post
Grazza said:

I think most people just find the way Andy described as more convenient and controllable.

0x30/0x32 for walking? It is wrong. For walking more correct pair is 0x32/0x32 because:

  forward += mousey;
  if (strafe)
    side += mousex / 4;
Hence, if you move the mouse (for strafe50 with mouse2=StrafeOn) - you will get 0x32/0x32 ticks very often. But this pair is not sense for walking (you cannot walk with permanent strafe50 in prboom+), therefore I prefer 0x19/0x19 or something.

Share this post


Link to post

When I said "pair" I meant walking vs. running, and I'm not taking the mouse movement into consideration. Let me try to explain again...

Given that automatic Strafe50 is simply binding the three key combination to a single key we want it to behave exactly as the combination would.

When using the three key combo while walking, the resulting strafe speed is 0x30. While running, it's 0x32. Therefore, the proper code would be:

fixed_t sidemove_strafe50[2]    = {0x30, 0x32};
Of course, I'm assuming your goal is to emulate the mousedriver. If not, then 0x19/0x32 should would be ideal. Sorry for the confusion. :-)

Share this post


Link to post

I never saw the "mousedriver", but in any case I think that forward/side speed for walking with permanent strafe50 should have a sense at least and should be in habitual proportions (~1). Maybe it is necessary to limit forward/side walking speed to 0x19/0x19 in permanent strafe50 mode. Do you agree with me? Or I should rename my permanent strafe50 option as emulation of the XXX mouse driver and make as you wish.

Share this post


Link to post

I'd say go ahead with 0x19/0x19. 0x30 is pretty fast and could be difficult for navigation in crucial situations. Besides, I've a feeling anyone who uses Strafe50 isn't going to be doing much walking, anyway. :-)

Share this post


Link to post
myk said:

Version 2.2.6.29 doesn't let me set non-standard Windows resolutions. 320x200, 320x240 and 640x400 all failed, while 640x480 and 1024x768 worked.

Can you check up your issues with the newest sdl library?

Share this post


Link to post

entryway said:
Can you check up your issues with the newest sdl library?

Again...? I replied to a PM where you sent me a test version answering that it worked correctly.

Share this post


Link to post
myk said:

Again...? I replied to a PM where you sent me a test version answering that it worked correctly.

No.
That version contained old library. I ask to take 2.2.6.29 and to replace SDL.DLL in it on last version from site

Share this post


Link to post

entryway said:
I ask to take 2.2.6.29 and to replace SDL.DLL in it on last version from site

"Couldn't set 320x200 video mode []". So it's... apparently worse. The previous SDL version launched with a screen that wasn't stretched out correctly, but at least it worked.

Share this post


Link to post

http://sourceforge.net/projects/prboom-plus/

2.4.3.1

[!] Updated to the latest prboom 2.4.3.
[!] PRBoom-Plus is now available on UNIX, Linux, and other POSIX systems and also on Mac.
[+] Several predefined cfgs and batch launcher for them are included.
[+] Simple aspect ratio adjustment made posible in OpenGL. It may be useful for people with unusually shaped monitors. Some usage examples:

    glboom-plus.exe -aspect 320x240 
    glboom-plus.exe -aspect 2x1
  • Changes in processing of spechit overflow for correct playback of some Xit's demos on scythe2.wad\map02.
  • Roll back to old SDL library. Some people had some problems with new.
  • The maximal supported resolution is increased from 1600x1200 up to 2048x1536.
  • GLBoom will try to set the closest supported resolution if the requested mode can't be set correctly. For example glboom.exe -geom 1025x768 -nowindow will set 1024x768. It affects only fullscreen modes.
  • The maximum walking side speed for strafe50 is 0x19.
  • The prboom's savegamename mask "prbmsav" was renamed to "prboom-plus-savegame". Also:
        prboom_server.exe -> prboom-plus_server.exe
        prboom.exe -> prboom-plus.exe
        glboom.exe -> glboom-plus.exe
        prboom.cfg -> prboom-plus.cfg
        glboom.cfg -> glboom-plus.cfg
        prboom.wad -> prboom-plus.wad.
    [-] Fix from Eternity (adapted by RjY) for ancient doom software render overflow that happens when the player goes over a linedef between two sectors of extreme height. There are no more crashes on thespir2.wad.
    [-] At use of the keyboard or joystick for strafing, prboom+ always generated strafe50 tics on turns independently of value of a corresponding option.
    [-] The launcher did not select last entry from history after start.
    [-] Problems with sky on thespir2.wad in opengl.

  • Share this post


    Link to post

    You may have the pick of my daughters
    entryway! At least when I get around to having daughters....I'm testing it out on my mac right now!

    EDIT: Okay you may only have my ugliest daughter now. It wouldn't work until I transfered the prboom-plus.wad over from my Windows computer and added that wad in via the launcher. Just thought I'ld give you the heads up.

    Share this post


    Link to post

    Thanks. Can somebody test the Linux version? I wish to try to announce it in news thread

    P.S. Fixed version of the Mac build was re-uploaded.

    Share this post


    Link to post

    Donce, myk and all the others who could force to play this demo without desync in doom2-plus

    Apply this patch to your doom2p.exe or doom2.exe and start the demo with modified exe. It should create e6y file in exe's directory. Look into it and use its contents with this test version of prboom-plus.

    glboom-plus.exe -spechit magic_from_e6y -file SCI2.wad -deh SCI2.DEH -playdemo S205n546.lmp

    or without deh if you did not apply the deh to doom+ before recording

    As I am not assured that desync occurs because of overflow, you should check up it with this Xit's demo also. I have returned old behaviour in PrBoom and that demo does not play correctly for me (as well as in doom+ on my WinXP) with new test version of prboom-plus and with default spechit magic.

    Share this post


    Link to post
    entryway said:

    or without deh if you did not apply the deh to doom+ before recording

    Deh was not applied when recording, because I forgot to use the patched exe. That's why the deh patch should be deleted from the wad itself when playing back with PrBoom.

    Not at home currently, will check it later.

    Share this post


    Link to post

    Might be nice to add a command-line option (e.g. -nodeh) to tell the program not to load an internal dehacked lump. That would make for a little extra convenience in cases like this, and also make it easier to disable a dehacked lump if you wish to for some other reason.

    I don't think there is such an option already (I had a feeling there was, but couldn't find anything about it).

    Share this post


    Link to post

    Unfortunately, it didn't work.

    After playing back S205n546.lmp with patched doom2+.exe I got number 2074523268. Then:

    prboom -spechit 2074523268 -file sci2.wad -playdemo S205n546

    (with removed internal dehacked patch) desynced exactly the same way as did an earlier PrBoom+ version (2.2.6.something): in both cases the player dies at time 4:45.

    Tried Xit's demo with this new test version, and it also desynced for me.

    Share this post


    Link to post

    All the demos work fine using the spechit number:

    e6y of s205n546: -spechit -2041329432
    command line: prboom-plus -file sci2.wad -playdemo s205n546 -spechit -2041329432
    
    e6y of s207n516: -spechit -2044177336
    command line: prboom-plus -file sci2.wad -playdemo s207n516 -spechit -2044177336
    
    e6y of s202-207: -spechit -2043677312
    command line: prboom-plus -file scythe2.wad -playdemo s202-207 -spechit -2043677312 
    Without it they all desynch; s205n546 in the dim room with the catwalk defended by Hell knights, s207n516 in the open right after leaving the dark red hall area, and s202-207 before a switch that just failed to activate.

    Donce, might you not have forgotten the dash before the spechit number?

    Share this post


    Link to post
    myk said:

    Donce, might you not have forgotten the dash before the spechit number?

    Ah, I must embarassingly admit that yes, I didn't use the dash thinking it should not be there... you know, that it sort of should be a value of -spechit parameter... well, then everything's fine :p

    Share this post


    Link to post

    Grazza said:
    Might be nice to add a command-line option (e.g. -nodeh) to tell the program not to load an internal dehacked lump.

    That's a good idea, if you ask me.

    Share this post


    Link to post

    As far as I understand it, we have completely an universal way of emulation now.

    If you have this overflow in your doom demo, and that does not play correctly with prboom-plus with common method (compromise magic number), you can always explain magic number for your system in a text file.

    I should say. It's done.

    Share this post


    Link to post

    Yes, this is great!

    entryway said:
    Negative numbers. We should get rid of them Does it still work?

    It does:

    e6y of s205n546: -spechit 2230937832
    command line: prboom-plus -file sci2.wad -playdemo s205n546 -spechit 2230937832
    
    e6y of s207n516: -spechit 2231485512
    command line: prboom-plus -file sci2.wad -playdemo s207n516 -spechit 2231485512
    
    e6y of s202-207: -spechit 2230220160
    command line: prboom-plus -file scythe2.wad -playdemo s202-207 -spechit 2230220160
    I noted a couple of things that might not be obvious to users; one needs to merely start a demo in the Doom hack to get the number (no need to play the whole demo), and the e6y file takes any new results under previous entries, so there's no need to delete the file after each use.

    Share this post


    Link to post

    But emulation still may not work with multi-level demos. Because for each level the magic number will differ (and patched doom will put all of them in e6y file), but you cannot set the list of these numbers for current PrBoom-Plus

    Share this post


    Link to post

    entryway said:
    but you cannot set the list of these numbers for current PrBoom-Plus

    Could PrBoom-plus be made to read an e6y file applying a spechit number for each map sequentially?

    So if one were to use the spechit parameter without adding a spechit number, the program would look for the e6y file with the values. That way people could include usable spechit number files along with demos in their zip files, when necessary; especially for multilevel recordings that might have more than one level with a spechit overflow.

    Could the e6y file somehow be made to take the levels, some form of numbering, or other formating, for the sake of clarity?

    Share this post


    Link to post

    One little comment: when using the patched exe that generates the e6y file with the magic number, you need to make sure you don't have an existing subdirectory with the name e6y. If you do, it doesn't work.

    Share this post


    Link to post
    myk said:

    Could the e6y file somehow be made to take the levels, some form of numbering, or other formating, for the sake of clarity?

    Yes. Later.

    Grazza, you're right, but DOOM2.EXE - not the best place for such checks of course :)

    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
    ×