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

fabian

Members
  • Content count

    1005
  • Joined

  • Last visited

7 Followers

About fabian

  • Rank
    Senior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. fabian

    EDGE 2.1.0 Impending Release

    I am confused. Wasn't this called 3DGE at some time?
  2. fabian

    Crispy Doom 5.3 (Update: August 12, 2018)

    It's not a bug, it's a feature. ;) Others before you have complained that "god" shows emotions during firing and thereby loses the golden gloss in his eyes.
  3. If this is medusa issue, then Crispy Doom should *not* be affected by this!
  4. fabian

    Crispy Doom 5.3 (Update: August 12, 2018)

    I think I'll modify P_CalcHeight() a bit to provide a "harmless" call.
  5. fabian

    Crispy Doom 5.3 (Update: August 12, 2018)

    If you are moving up on an elevator, and then the elevator stops, your view height is updated only one tic later than when the elevator stopped moving. It's barely noticable, but once you've seen it, it cannot be unseen. The narrow elevator in MAP01 is a nice example: Stand on it so you can see the elevator's edge. And after it stops moving up, your view will move another step up just one tic later.
  6. fabian

    Crispy Doom 5.3 (Update: August 12, 2018)

    @Dwaze Thank you very much for this nearly perfect bug report! You are right that the player's viewz is recalculated if he is standing within a sector that has a moving ceiling of floor, but the view bob is omitted in this calculation. The code is here: https://github.com/fabiangreffrath/crispy-doom/blob/master/src/doom/p_map.c#L642 Originally, in order to achieve what I want (i.e. smooth update of the player's view height while standing on a moving floor that just stopped moving) I should rather call P_CalcHeight(). This function, however, is supposed to get called only once per tic (because of the way it changes some variables). I am not entirely sure what to do now, but since the code has caused another similar bug only recently and the glitch that it is supposed to fix isn't that glaring, I am inclined to remove it entirely instead of band-aiding around it another time. :S
  7. fabian

    Crispy Doom 5.3 (Update: August 12, 2018)

    It's already there, but only if you record or play a demo. You'll have to explicitly enable it in the Crispness menu, though.
  8. fabian

    Crispy Doom 5.3 (Update: August 12, 2018)

    You'll have to disable "Aspect Ratio Correction". The clients joining the game will have to add the same WADs as you did when starting the server.
  9. fabian

    Crispy Doom 5.3 (Update: August 12, 2018)

    The fact that sounds play back properly on some systems with the WASAPI backend but not on others leads me to think that this is a driver issue on these specific systems - or a mismatch between SDL2's WASAPI backend code and some other layers of Windows' audio stack. Anyway, this is not a Crispy-specific issue, so I don't see any sense in trying to "fix" it in Crispy. In the end, what you suggest is just another workaround for broken backend code - just as switching the actual backend is a workaround for that. After all, this is an SDL2 issue, but until I found a reproducible use case, I don't see how I could issue a meaningful bug report upstream. :(
  10. fabian

    Chocolate Doom

    Well, because it works like that in the code. If you run out of ammo, the CheckAmmo() function checks (among others) if you have the chaingun and at least one clip available. If yes, it selects the chaingun for you. It does not check, though, if you have the chaingun available and the ammo that you have assigned to the chaingun by means of a DEH patch.
  11. fabian

    Chocolate Doom

    I guess it's because you still have ammo of type `am_clip` available: https://github.com/chocolate-doom/chocolate-doom/blob/master/src/doom/p_pspr.c#L188 If you first empty your clips by shooting with the pistol, it will change to a different weapon if you run out of ammo with the chaingun.
  12. fabian

    Crispy Doom 5.3 (Update: August 12, 2018)

    Thanks for checking, the directsound backend seems to be reliable across many SDL library versions. It has always been like this. Choco and Crispy daily builds as well as Choco releases all use SDL2.0.5 libraries, whereas Crispy releases use SDL2.0.8.
  13. fabian

    Crispy Doom 5.3 (Update: August 12, 2018)

    Well, "force" here means that it is set as the new default. You are still free to choose your own audio backend by setting the SDL_AUDIODRIVER environment variable. In general, yes. But Choco is still unaffected, because it is (deliberately?) built and released with an outdated SDL library, which doesn't yet have the faulty WASAPI backend.
  14. fabian

    Crispy Doom 5.3 (Update: August 12, 2018)

    I don't even know what the XAUDIO2 backend is. The next devel snapshot will force the directsound backend. Could you please confirm that everything still works as expected with the dev DLLs? Else I will have to introduce a runtime library version check.
×