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


  • Content count

  • Joined

  • Last visited

About drfrag

  • Rank

Recent Profile Visitors

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

  1. drfrag

    uh.... is this a false positive?

    And that defender garbage makes windows 10 extremely slow.
  2. drfrag

    Crispy Doom 5.9.2 (Update: Sep 22, 2020)

    Or download an older Crispy version.
  3. drfrag

    uh.... is this a false positive?

    It's a false positive, i thought this was solved. Add an exception to defender, seems RUDE is not affected as i use an older compiler.
  4. drfrag

    Crispy Doom 5.9.2 (Update: Sep 22, 2020)

    It's a known problem with SDL 2.0.9 and later and i reported the issue, i compile RUDE with 2.0.8 so controllers work. Also recent SDL versions have the white screen issue with old graphics drivers.
  5. drfrag

    PrBoom+/UMAPINFO v

    Seems this is the classic vanilla demo desync when accesing the menu, Boom? fixed it with a sophisticated silent pause and in Crispy you get a pause when playing back the demo. I fixed it in RUDE just preventing menu access when recording and showing a message about it, those don't cause demo desync.
  6. Has anyone else noticed that the status bar has wrong aspect ratio in GZDoom unless you use the scale to fullscreen option? In ZDoom it was the same unless you set the stretch option which was the default. But now it looks bad at mid-low resolutions when scaled to fullscreen.
  7. drfrag

    GZdoom won't start up

    Just extract the file to a new folder and put your wads there and don't use a system folder just something like c:\games\gzdoom
  8. drfrag

    GZdoom won't start up

    You don't, you need both.
  9. An alternative is to use SP respawn in RUDE with backpacks and keeping keys. Right now i'm playing 1000 lines 2 in classic mode (only D1 monsters so it's easier but there are a lot of barons). Or you can use the resurrect cheat with iqqdq (from Crispy but a bit different). This is my command line: rude-doom -file 1klinecp2.wad -nod2monsters -sprespawn -backpack -keepkeys
  10. Chocolate Doom has the -merge parameter and for RUDE and Crispy -file already uses -merge.
  11. drfrag

    How can I work on my own Source Port? (not a joke)

    Chocolate Doom should compile with Code::Blocks and TDM-GCC 5.1 (i made a PR to fix it). You create the projects with CMake (GUI).
  12. drfrag

    Best performance settings in gzdoom and lzdoom?

    LZDoom is already set for performance and most settings there will have very little impact (not dynamic lights). Resolution/scaling is important for software on OpenGL it would be only a bit faster. That said the default resolution is very low in LZDoom (same as in ZDoom) and scaling only works on OpenGL.
  13. sponge wrote this at zdoom.org: " Hi all! The changes to the widescreen versions of the lumps were basically the simplest possible way to retain compatibility with all the WADs that don't have widescreen graphics, and the new IWAD/add-ons that have been updated with widescreen graphics. There's not really a way to do this without breaking assumptions in the original engine, and we wouldn't have gained much by having different lump names since the 4:3 ones would never be read anymore anyway. The original DOS WADs are still available in the same path if that is the desire. However, the approach is extremely simple, in the hopes that if other source ports wanted to draw these graphics from our IWAD it would be minimally invasive. Most patch drawing is the same, and will adjust position based on an invisible centered 4:3 box, something like x += (426 - 320) / 2 where 426 is the width of the new widescreen framebuffer. The total diff for WS lumps is a couple of dozen lines of mostly moving stuff from V_DrawPatch (centered 4:3 box) to V_DrawPatchLeft (left of screen) based on whether they should be drawn from the left (minimap counters) or drawn in a centered 4:3 box. This was the cleanest way to get this working within our constraints, which is being able to handle WAD files that contain either 320, or 426 width graphics (or theoretically somewhere in between, but that is not really a concern for us). I did something similar in Quake Live which also assumed 4:3 screenspace to gradually support widescreen UIs and HUDs back in the day and it was straightforward to convert stuff into widescreen aware. Fullscreen graphics like TITLEPIC and CREDIT and stuff like STBAR are drawn by adding an offset like (426 - lump_width) / 2 to just distribute the empty space evenly. We don't support drawing patches larger than 426, nor is the framebuffer aspect ratio adjustable at runtime, but this would still work just fine if it did. PFUB0/1 was the only slightly weird one, I think it was the beginning graphic, that was left at 320 width, and then PFUB1 was 426 width. In widescreen, the initial screen starts with both PFUB lumps visible, and it still scrolls 320 pixels with the same timing as the original, ending on showing the full 426 wide PFUB lump. The only change there was to just fill the left of the screen with the second PFUB lump at the start. Hope this is helpful for anyone! -sponge "
  14. Great episode, i'm on MAP24 now and i'm enjoying it very much. On MAP21 i had to IDCLIP to get the red key and then again later (even looking at the map in the editor i'm not sure how it's supposed to work). There were some demons sunk into the floor and i fell down since i didn't get the rocket launcher next to them before to make the floor rise.
  15. drfrag

    Good Doom SourcePorts i could try?

    But at the end of the day that doesn't make much of a difference. Now i've extended it for other non game-breaking generators such as monster actions and then there should be a better randomization as it comes from the index being increased and this way the feature is less intrusive regarding code changes. I had to reverse Edward850's logic as many named generators are created on the fly in ZScript. Actually only a few generators are game-breaking AFAIK (i've been reviewing the code again). Those changes are in the latest devbuild.