Activity for Doom Legacy
-
Wesley Johnson modified ticket #695
BSP rendering through the sky
-
Texture filter won't apply
-
Sorry, the system did not notify me of this bug report, so I have just discovered it. Confirmed, that the OpenGL setup does not update from saved opengl config settings. This whole area of the code needs review.
-
Player character slows down to a crawl
-
There is a new announce window that reduces the need to make new legacy features default on. I am also considering other ways to reduce the conflict between expecting vanilla behavior, and features of DoomLegacy. Just defaulting everything to vanilla would of course nerf DoomLegacy to always be vanilla for most users.
-
w111_025 numxxx
-
w111_024 teamstat
-
w111_023 viewpoint angle
-
w111_022 missile NUMXXX
-
w111_021 mapcolor
-
w111_020 playersprite
-
w111_019 MFE
-
w111_018 for var
-
w111_017 CheckMeleeRange
-
w111_016 vile raise
-
w111_015 reference count
-
w111_014 water sink BUG
-
w111_013 recursive sound
-
w111_012 notify new cvar
-
w111_011 thinker_func
-
w111_010 FIXFL
-
w111_009 sec special
-
w111_008 misc08
-
w111_007 linespecial
-
w111_006 GM gamemode
-
w111_005 unsigned flatnum
-
w111_004 spawnpoint, Makefile
-
w111_003 FRACBITS
-
w111_002 mobj funcs
-
w111_001 FLAGS3
-
Nikku4211 posted a comment on ticket #700
Okay, now it's a different kind of weird. Is this tired run feature on by default? All I did was drag the config file from the one I set up for the older version of Doom Legacy I had years ago, so that of course didn't specifically turn it off. This default is going to be especially egregious because every time I boot Doom Legacy, it always resets my config path to my user directory on my internal SSD (C:) too.
-
Michael Bäuerle posted a comment on ticket #700
Since version 1.48.16 there should be an option for this new feature in the menu: "Options->Game options->Tired Run" In the config file you likely want: tiredrun "Off" I have overlooked this too, but it is listed in the changelog: https://doomlegacy.sourceforge.net/docs/whatsnew.html
-
Player character slows down to a crawl
-
What is the emulated CPU speed? Which emulator core are you using within Retroarch for MS-DOS? What platform are you running Retroarch itself on?
-
Sam Al-Awami created ticket #699
Texture filter won't apply
-
Ville Bergholm committed [r1751] on SVN
Fix the release script and the README.rst template.
-
Bossaction problem
-
BFG Blast always throws enemies in same direction
-
Extend LIBZIP support to FreeBSD (and maybe others)
-
Been over a year, no response on the testing. I assume it worked. Closing the ticket.
-
Problems with MBF21 maps
-
Please open a separate bug report for any other wads that give MBF21 problems. That allows me to track what needs work, and close some as done. I expect there will be many more MBF21 problems, and even more DSDA compatibility issues. Thank you for your testing.
-
Tested some WADs on NetBSD/amd64: Sleepwalking and AdMortem work much better now, Most important the weapons work and the monsters can be killed. I can confirm that sky imps, snow and bobbing trees are fixed for Sleepwaling. Problems with the sky and secret areas have low priority for me. No problem that Evilternity II is not suitable for Doom Legacy. Looks like that the MBF21 support is at least usable now. Many thanks for your work on MBF21 support! This ticket can be closed.
-
I am burned out due to all those MBF21 fixes. Got other projects to work on too. This MBF21 emergency patching burned up 4 months for me. What I need now is to know what reported bugs got fixed and what remains. What I remember: Sleepwalking: sky imps, snow, bobbing trees, weapons, cyberdemon, monsters are fixed. Secret area is inaccessible, cause unknown. Evilternity II: Massive, too large for any port except one with dynamic state allocation. Only for DSDA and its clones. AdMoretum : fixed state...
-
w110_114 gren
-
Yes, it's OK now.
-
https://sourceforge.net/projects/doomlegacy/files/1.48.18/doomlegacy_1.48.18_common.zip looks fine to me now, I guess Wesley fixed it?
-
I haven't been reading my emails for a while due to all kinds of time pressures, sorry for the lack of communication. The release files are indeed created by the bash script trunk/scripts/release.sh I can try to recreate and replace the broken file tomorrow. On Thu, 15 May 2025 at 12:17, Wesley Johnson wesleyjohnson@users.sourceforge.net wrote: Replaced the common file with a new one that I made by hand this time. Ville did not reply, so after waiting 2 weeks, I decided to put up the files myself....
-
Doom Legacy updated /1.48.18/doomlegacy_1.48.18_common.zip
-
-
-
If you downloaded the common zip file, then there is a docs directory in that. There are two html files, legacy.html that covers the command line, and console.html that covers console commands within the game. Otherwise, these doc files can be read on the docs page of the DoomLegacy home site.
-
Replaced the common file with a new one that I made by hand this time. Ville did not reply, so after waiting 2 weeks, I decided to put up the files myself. I did not expect it to go without problems. Usually Ville (smitemeister) creates the common file, which is created using a script tool. These files are made by a combination of automated scripts, which I use sometimes, and do not have any idea of what happened, or was it right, and hand operations to fix things that I do notice were not right.....
-
-
Looks like the file "doomlegacy_1.48.18_common.zip" is wrong/incomplete. It contains a subdirectory with the version number "doomlegacy_1.48.16_common" and the file "legacy.wad" is missing. In the archive "doomlegacy_1.48.18_source.tar.bz", the path to the sources has changed from "src" to "svn1749/src". Is this intended?
-
-
-
-
-
-
-
-
-
-
-
DoomLegacy 1.48.18 SVN 1749
-
DoomLegacy 1.48.18 SVN 1749
-
w110_113 version 1.48.18 1749
-
I tried the -pedantic and it produced 100's of warnings, went on for pages and pages. I only found two of those warnings could be fixed, and many that I could not do anything about. As we have achieved compiling without warnings, this -pedantic does not represent what the standard the code it written to. The code was originally C89, but uses "//" comments heavily (I do not use the old commenting) . It is also not C99, because it uses alloca, which that does not recognize. I have been through this...
-
w110_113 Version 1.48.18
-
w110_112 fix9
-
For C99 I have checked draft N1256: Section 6.8 (Statements and blocks) defines a "labeled-statement" as: labeled-statement: identifier : statement case constant-expression : statement default : statement Declarations are defined in Section 6.7 (Declarations). The block with braces forms a "compound-statement": compound-statement: { block-item-list opt } block-item-list: block-item block-item-list block-item block-item: declaration statement I cannot think of a way to stop that from happening. Specify...
-
Got it. I cannot think of a way to stop that from happening. Was generally happy that finally found what was causing the bushes to be missing. Caused by introducing the fnd_count, which as it ended up was not used exactly as I expected.
-
Since SVN r1746 my GCC 10 again has problems with a label that is not part of a statement: r_things.c: In function 'R_AddSpriteDefs': r_things.c:909:9: error: a label can only be part of a statement and a declaration is not a statement 909 | int fnd_count = R_AddSingleSpriteDef ( sprname, &sprites[sprindx], wadnum, ln1, ln2); | ^~~ --- r_things.c.orig 2025-04-11 10:35:37.018924659 +0200 +++ r_things.c 2025-04-11 12:00:45.073314356 +0200 @@ -905,23 +905,25 @@ continue; add_this_sprname: - // Load...
-
w110_111 mbf21 clear state, flag bits
-
w110_110 mbf21 parm nomap
-
Maybe a problem with MBF #271 sky transfer? I found this test WAD from ukiro (works e.g. with Woof): https://www.doomworld.com/forum/topic/102222-sky-rendering-inconsistencies-gzdoom-get-your-shit-together/ Again for potential Dropbox problems: $ wget "https://www.dropbox.com/s/y9wsjoti6scukbr/skyalign.wad" But it crashes Doom Legacy r1744.
-
Got fix for AdMoretum, and as usual it is dehacked defaulting. They just could have filled in the args. The MBF21 defaulting had the wrong index used, my fault. The shotgun has a trooper for the smoke, and no missile comes out. This is fixed by using -dsda again, so it is likely another incomplete Frame in the dehacked. Will think about how to deal with this, but will not be turning DoomLegacy into a DSDA look-alike. I only spend this many hours on DoomLegacy because it plays the way I want it too....
-
The problem with the sky is because sleepwalking.wad does not follow the convention for SKY patch names. It has a texture.txt lump that lists "SKY RSKY1", which clearly has only one patch, named RSKY1. This is the same as every other wad because RSKY1 is the standard name for the sky patch. But sleepwalking.wad does not have an RSKY1 patch, so when the search looks for it, it only finds the RSKY1 in legacy.wad (the one used to replace short doom2 skies). The sky patch in the wad is named skynd03a,...
-
If you run sleepwalking.wad with the switch -dsda, the fists work, and the there are no imps in the sky. I can confirm that with "-dsda": - Fists work - No more Imps in the sky - Snowflakes now fall down to the ground Leaving the default at 0 has its own downside, which is how going to state 0 can freeze behavior. But that also made it obvious to the developer that they forgot to fill in the next field. If the engine knows that something is wrong, I think it should be fixed and there should be an...
-
AdMortem is locked behind a "give me your email" Dropbox, ... Maybe a JavaScript problem. I have used wget: $ wget -O AdMortem_1.5.6.zip "https://www.dropbox.com/scl/fi/3exnqm8nxg4gukhj10hcp/AdMortem_1.5.6.zip?rlkey=r5nwzu32pfh2dtefpbjy2p49b&dl=0"
-
I have played pirate doom (using the latest SVN 1744, "w110_109 deh pirate", through at least 10 levels. I have not had a memory crash. The problems were due to sloppy dehacked lump. I could fix some of that, but some of it violates the unofficial dehacked expectations, like having a blank line after a Thing or Frame because everyone uses that to terminate the block. It seems that the dehacked bugs do not affect it that much. The sword works now. The Evilternity wad has a huge dehacked that exceeds...
-
Found that the sleepwalking.wad sets incomplete new states and thus relies upon the DSDA behavior for such, which is different than our traditional. If you run sleepwalking.wad with the switch -dsda, the fists work, and the there are no imps in the sky. The fists do not require picking up the berserk pack, just select fists. It fails because the sleepwalking dehacked leaves the PUNCH state with a next field of 0, which is the default. My problem is that we have many wads that already are dependent...
-
AdMortem is locked behind a "give me your email" Dropbox, and I do not have a throwaway email address to give it. I do not want to risk my primary email address.
-
Found that the sleepwalking.wad sets incomplete new states and thus relies upon the DSDA behavior for such, which is different than our traditional. If you run sleepwalking.wad with the switch -dsda, the fists work, and the there are no imps in the sky. The fists do not require picking up the berserk pack, just select fists. It fails because the sleepwalking dehacked leaves the PUNCH state with a next field of 0, which is the default. My problem is that we have many wads that already are dependent...
-
w110_109 deh pirate
-
w110_108 mbf21 fix8
-
w110_107 deh flags
-
Tested Sleepwalking.wad again with r1741: - Trees are looking OK - All weapons seem to work, except the fist (modified with black gloves), see below. - The plasma zombies take damage and can be killed. Still not working: - The green Cyberdemon cannot be killed. Rockets and plasma balls fly through. - The IMPs in the sky (and the sky picture itself) are wrong. Woof shows a black sky with white stars (likely this is what the author intends). - Picking up the berserk pack in the first level makes all...
-
With Pirate Doom II (on Doom Legacy SVN r1741): https://www.doomworld.com/idgames/levels/doom2/Ports/megawads/pd2 the crash does not happen if memory management is configured to PLAIN_MALLOC like this: --- src/z_zone.c.orig<->2023-02-10 15:51:01.000000000 +0000 +++ src/z_zone.c @@ -100,7 +100,7 @@ // When the user writes out-of-bounds of malloced region it will do a sigsegv. // It does not use the tags, cannot recover PU_CACHE, PU_LEVEL, etc. memory. // Uses the most memory of all choices. -//#define...
-
With Pirate Doom II (on Doom Legacy SVN r1741): https://www.doomworld.com/idgames/levels/doom2/Ports/megawads/pd2 the crash does not happen if memory management is configured to PLAIN_MALLOC like this: --- src/z_zone.c.orig<->2023-02-10 15:51:01.000000000 +0000 +++ src/z_zone.c @@ -100,7 +100,7 @@ // When the user writes out-of-bounds of malloced region it will do a sigsegv. // It does not use the tags, cannot recover PU_CACHE, PU_LEVEL, etc. memory. // Uses the most memory of all choices. -//#define...
-
This one: https://www.doomworld.com/vb/thread/125461
-
I cannot find Ad Mortem wad, can you give me a link to it. I found some Ad Mortem deathmatch from 1997.
-
I cannot find Ad Mortem wad, can you give me a link to it.
-
Patch to svn 1741 seems to fix most of these. Trees bobbing (I thought it was SUPPOSED to be doing that) was caused by Heretic FLOATBOB flag being in those states (which had not been cleared). The weapons were being drawn off screen due to parm1 and parm2 conflict with args, had to separate them back the way they were. Never had all weapons stop working, and test shows they don't now. Those immune guys are no longer immune, don't know exactly why. I don't have Ad Mortem wad yet. The above fixes might...
-
w110_106 mbf21 fix7
-
w110_105 phobiata
-
With SVN r1739 on NetBSD/amd64 there are still problems, e.g. with the weapons in Sleepwalking and Ad Mortem. Sleepwalking: Trees are bobbing up and down. Weapon sprites of the fire sequence are not displayed (weapon invisble until back in idle state), All weapons stop working if one runs out of ammo. Some of the custom enemies take no damage from the players weapon. Ad Mortem crashes when the Shotgun is fired: - At the start of Map1 - Console => "GIMME WEAPONS" - Switch to Shotgun (not SSG) - Fire...
-
Any comments on the giving the for loops their own loop variable Limiting the scope of the variable looks right in general.
-
w110_104 compilers
1 >
