fabian

Members
  • Content count

    913
  • Joined

  • Last visited

5 Followers

About fabian

  • Rank
    Forum Regular
  1. Ah, this. Yeah, coincidentally I fixed this some weeks ago : https://github.com/fabiangreffrath/crispy-doom/commit/64ade24910437b2ec9e4a64a7a6444c0be0f5300 Edit: Though, currently only for bullets emitted by the player. Edit2: Now fixed for all sloped trajectories.
  2. @Dobermann Please try to locate this dialog box for your sound device and set the bitrate to something reasonable, e.g. "cd quality": https://superuser.com/questions/698522/how-should-i-decide-on-a-default-audio-format @Linguica Is this possible the "hitscan attack hits invisible barrier" bug? https://doomwiki.org/wiki/Hitscan_attacks_hit_invisible_barriers_in_large_open_areas
  3. Phew, thanks for checking! 😉
  4. Could you probably check if the same happens if you play back the demo in Choco (and in PrBoom+ with -complevel 2, while at it), please? If not, you have found a severe bug in Crispy.
  5. That would be an interesting, but fairly non-trivial change. I am currently not considering it, but maybe in the future...
  6. All these features are strictly optional and if you leave them disabled in the menu, you pretty much get the authentic Vanilla experience. So, IMHO @42PercentHealth still stands true with what he posted. No, this would be a demo breaking change without any chance for a demo-safe implementation.
  7. I aim for demo compatibility with Vanilla (and Choco, that is). In this case that means "how would Vanilla behave if it wouldn't crash due to VISPLANE overflow?" However, I cannot aim for demo compatibility with any EXE hack that people come up with... IIRC, PrBoom+ handles NERVE.WAD just as any other PWAD when it comes to demo recording and playback. So, yes, both Crispy and PrBoom+ would be demo compatible in this regard. This isn't too far fetched. In fact, there is already a discussion over at the Choco bug tracker and there is even an (unfinished!) branch that can convert video but no audio, currently. It might be a good idea to bring back some life to this topic... https://github.com/chocolate-doom/chocolate-doom/issues/715
  8. Thank you very much! https://github.com/fabiangreffrath/crispy-doom/commit/ce81b4be1d1a10db466470b3dd23991ebd7883c2
  9. Thanks for the report. If it crashes it is pretty sure a bug, Crispy is not supposed to crash at all! I will try to reproduce this, could you possibly provide some more detailed instructions?
  10. Honestly, I don't think that a Doom source port that was released in 1999 (or was it 1998?) uses an instruction set that Intel introduced in 1997.
  11. It canbe found on the PrBoom+ homepage: http://prboom-plus.sourceforge.net
  12. Initially, Crispy was meant to be right that: Chocolate Doom with the most often requested non-Vanilla features on top. But once this was achieved (around the time of the 1.5 release in late 2014), people requested more and more features and improvements. And where I found that I could help, I delivered. But even nowadays, if you leave all the extra features disabled and switch to low-resolution mode, I guess you won't be able to distinguish Crispy Doom from Choco - unless you do a frame-by-frame comparison or find the Crispness menu, that is.
  13. I regularly used this approach in the past, but then decided I didn't want two different "feature sets" - or more generally "experiences" - when playing a regular game or recording/playing back a demo. Thus I always try to find ways to fix such little glitches that can be applied in all circumstances without risking demo or netgame sync.
  14. Yes, of course it is like that: https://github.com/fabiangreffrath/crispy-doom/blob/master/src/doom/st_stuff.c#L512
  15. @scifista42 Yep, this is how I usually handle cases like this, but here it would be the whole work of duplicating the mobj->angle field just to mitigate this one rare issue. :/ @Linguica Thank you very much for confirming my doubts. This was pretty much the kind of thoughtful reply that I was hoping for!