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

fabian

Members
  • Content count

    1610
  • Joined

  • Last visited

Everything posted by fabian

  1. Update Sep 04, 2020: Crispy Doom 5.9.1 is released! Crispy Doom is a friendly fork of Chocolate Doom that provides a higher display resolution, removes the static limits of the Doom engine and offers further optional visual, tactical and physical enhancements while remaining entirely config file, savegame, netplay and demo compatible with the original. Crispy Doom 5.9.1 is released on September 04, 2020 to fix some minor bugs. Please visit the Crispy Doom homepage for more information: https://github.com/fabiangreffrath/crispy-doom/releases Binaries for Windows (x86) are available here: https://github.com/fabiangreffrath/crispy-doom/releases/download/crispy-doom-5.9.1/crispy-doom-5.9.1-win32.zip https://github.com/fabiangreffrath/crispy-doom/releases/download/crispy-doom-5.9.1/crispy-heretic-5.9.1-win32.zip Have a lot of fun! - Fabian
  2. fabian

    Crispy Doom 5.9.1 (Update: Sep 04, 2020)

    That's what I implemented today. Now you could name your demo files as you wish!
  3. fabian

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

    Yeah, because that's how coding works, right? *sigh* I have spent a couple of weeks this year to cleanly port WinMBF to 64-bit, the result is called Woof!. Maybe you should use that as your starting point and then add back the Fusion features that you are looking for.
  4. Woof! is a continuation of Lee Killough's Doom source port MBF targeted at modern systems. MBF stands for "Marine's Best Friend" and is regarded by many as the successor of the Boom source port by TeamTNT. It serves as the code base for many of today's successful Doom source ports such as PrBoom+ or The Eternity Engine. As the original engine was limited to run only under MS-DOS, it has been ported to Windows by Team Eternity under the name WinMBF in 2004. Woof! is developed based on the WinMBF code with the aim to make MBF more widely available and convenient to use on modern systems. To achieve this goal, this source port is less strict regarding its faithfulness to the original MBF. It is focused on quality-of-life enhancements, bug fixes and compatibility improvements. However, all changes have been introduced in good faith that they are in line with the original author's intentions and even for the trained eye, this source port should be hard to distinguish from the original MBF. In summary, this project's goal is to forward-port MBF.EXE from DOS to year 2020 and remove all the stumblings blocks on the way. Please visit the Woof! homepage for more information: https://github.com/fabiangreffrath/woof Binaries´╗┐ for Windows (x86) are available here:´╗┐ https://github.com/fabiangreffrath/woof/releases/download/woof_2.2.0/Woof-2.2.0-win32.zip Have a lot of fun! ´╗┐ - Fabian
  5. In general, I agree. However, for some unknown reason, Lee explicitly decided to load them last: https://github.com/fabiangreffrath/woof/blob/583e6d2196438bc8099abd41eeb2f844b519ba51/Source/d_main.c#L1742 Edit: I guess I figured it out. DEHACKED lumps are processed from last to first, so it actually makes sense to load "preloaded" DEH files last - their changes will be overridden by DEHACKED lumps included in WADs and DEH files loaded from the command line. WAD files, however, are loaded in order and thus override each other. Now, what happens with DEHACKED lumps in WAD files? If preloaded WAD files contain DEHECKED lumps, these will get processed last if the WAD files are loaded first. I guess that's what Lee wanted to avoid by loading "preloaded" WAD files last - this way makes sure that their embedded DEHACKED lumps will be processed first.
  6. Here is a rather vague explanation by Lee himself: https://github.com/fabiangreffrath/woof/blob/583e6d2196438bc8099abd41eeb2f844b519ba51/docs/options.txt#L361
  7. fabian

    Crispy Doom 5.9.1 (Update: Sep 04, 2020)

    That would crash the demo loop then. No, DEMO1 is almost certainly already a demo lump.
  8. fabian

    My favourite source port is a fridge...

    Seriously, what is this?
  9. fabian

    Crispy Doom 5.9.1 (Update: Sep 04, 2020)

    I could just rename the lump to DEMO1 internally for the very reasons you outlined above.
  10. fabian

    PrBoom+/UMAPINFO v 2.5.1.7

    Looks reasonable, could you please try this approach and report back?
  11. fabian

    Crispy Doom 5.9.1 (Update: Sep 04, 2020)

    Oh, this bug again! I should find a solution for this, it is getting annoying... Edii: It didn't crash for me because I loaded the demo as "~/armadosia_01.lmp", which M_ExtractFileBase() couldn't properly truncate to "armadosi". Thanks a lot @plums for the analysis! Edit 2: This could be a solution: --- a/src/doom/d_main.c +++ b/src/doom/d_main.c @@ -1842,6 +1842,18 @@ void D_DoomMain (void) if (D_AddFile(file)) { + char *name = lumpinfo[numlumps - 1]->name; + int i; + + // [crispy] check if the demo file name gets truncated to a lump name that is already present. + if (strncasecmp(name, "demo", 4) && + (i = W_CheckNumForNameFromTo(name, numlumps - 2, 0)) > -1) + { + I_Error("Demo lump name collision detected with lump \'%.8s\' from %s!\n" + "Please rename your demo file.", + lumpinfo[i]->name, W_WadNameForLump(lumpinfo[i])); + } + M_StringCopy(demolumpname, lumpinfo[numlumps - 1]->name, sizeof(demolumpname)); } That is, quit with an error message if the case is detected that a demo file name gets truncated to a lump name that is already present.
  12. Single-patched masked textures with a different height between the texture and the patch, yes.
  13. fabian

    Crispy Doom 5.9.1 (Update: Sep 04, 2020)

    Thanks, but they don't crash for me. I have just timedemo'd through 01 and 15s and they both finished just fine. Did you know that you could simply attach a ZIP archive to your reply?
  14. I have just added an "integer_scaling" option, but I found this feature obscure enough to hide it from the menu. You'll have to edit the config file to enable it. Also, it is now possible to bind the "use" action to a dedicated mouse button. Using by double-click is still available, but needs to get explicitly enabled in the "Input Methods" section of the "General" Options menu. (NB: You might have to rebind your mouse keys.)
  15. fabian

    Crispy Doom 5.9.1 (Update: Sep 04, 2020)

    Sure, I'll review any code submission. Oops, looks like an oversight. Should be pretty straightforward to add. I don't own any Apple hardware, but there is a wiki article describing in detail how to build Crispy on Mac Os: https://github.com/fabiangreffrath/crispy-doom/wiki/OS-X-Compilation-and-Installation-Guide
  16. fabian

    Questioning the stigma towards DOSBox

    Crispy Heretic is back for quite some time.
  17. I know and I am not even sure if it should get fixed...
  18. Hm, is there a specific reason why you would want this? I don't even interpolate the scaled picture, so sticking to mere integer factors shouldn't make a huge difference anyway.
  19. I have just released Woof! 2.2.0: Level stats and level time widgets have been added to the automap. The weapon sprites can now be centered during attacks. A crash when a Dehacked patch attempts to assign a non-existent code pointer has been fixed. https://github.com/fabiangreffrath/woof/releases/download/woof_2.2.0/Woof-2.2.0-win32.zip
  20. Granted, it's ambiguous, but it's not my wording. ;)
  21. Automap coordinates are always enabled in MBF. This switch merely affects follow mode. If the latter is disabled, it decides whether the coordinates of the player arrow or of the screen center are displayed.
  22. Good catch, thank you! Fixed in GIT.
  23. Sounds fair! I didn't even know this feature was that popular, but here you go: https://github.com/fabiangreffrath/woof/commit/b00e9460b40e796deab82469d74e36b882eead7e
  24. Binding the Use key to a mouse button is somehow special-cased in MBF: https://github.com/fabiangreffrath/woof/blob/18c2167893a1be1db15ff2e397767e0a4fcade77/Source/m_menu.c#L1933
  25. fabian

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

    Boom has already changed pretty much every line of code.
×