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
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.
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
Annoying comment. Our project has 5 different binary downloads, so it has a common file for the data. This saves us from having to include that in every one of the binary files. This is the situation with many projects. The default download button ought to download both a binary and the data file (or files). We have a continual problem with Windows users who expect everything to happen for them auto-magically and who do not download the data file and then complain. Reading the README is also not...
Here is a suggestion. There ought to be a BLUE BOX, like the others, to control this. Create a "Default" blue box button after Git Hub integration. Within that page, have a button "Remove all default download assignments", which is the button that you need when you make a new release. After that put the statement, "To assign default downloads, go to the individual file and press the 'i' button." That will solve the problem, and at least gives people a chance to figure it out in less than a hour of...
Thank you for your prompt reply. Now that I have found the button, I have managed to fix that. I do NOT expect to be able to remember that is a file control button, 12 months from now, when the next release will happen. That "i" does not look like a button that controls anything. It looks like part of the file download statistics information. I had spent an hour poking every odd button that I could find, and never realized that the "i" was even a possibility. Even the Badges, for a while, looked...
Download latest is WRONG version
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.....
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
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.
w110_111 mbf21 clear state, flag bits
w110_110 mbf21 parm nomap
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,...
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
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
w110_104 compilers
Got it, fixing it. Thank you, Again, GCC 12 did not say a thing. Have not dared try that yet, too many compilers out there, especially the Mingw. I got to test this with clang too. The GCC12 did accept it either way. I never understood why labels were restricted this way in the first place. Any comments on the giving the for loops their own loop variable, instead of trying to share one with every loop in the function. The possible conflict with signed and unsigned int in the program was making it...
w110_103 chex
w110_102 dehname
w110_101 cleanup
w110_100 reject
w110_099 slow react tune
That comes from editing the code 50 times, moving stuff around. Do not know why GCC 12 did not complain about that, it usually does, it has done so before for very similar code. Will put that fix into the next patch, which will be tuning the slow_react. I was just working on it. Thank you for testing and noticing this, before we got to release.
w110_098 MPEGIII
w110_097 remap3
w110_096 sfx extra
w110_095 sprite3
w110_094 remap2
I do not know the JVM window manager (I don't even recognize the name), so I can not tell you anything about how to get to its settings. Somewhere in its user interface there will be a settings, and within that there will be a display settings. On this window manager, there is a menu button at the lower left, within that menu is settings, within that menu is display. Search around and find something similar on your JVM. For some window managers, it is possible to get to settings by right clicking...
I do not know the JVM window manager (I don't even recognize the name), so I can not tell you anything about how to get to its settings. Somewhere in its user interface there will be a settings, and within that there will be a display settings. On this window manager, there is a menu button at the lower left, within that menu is settings, within that menu is display. Search around and find something similar on your JVM. For some window managers, it is possible to get to settings by right clicking...
When DoomLegacy is told 320x240, that is exactly what size window it makes. I just tested it to make sure. You need to fix your system resolution. Or you might have engaged some zoom function for vision impared people. On your system, open the Applications/settings/display and look at the resolution. It should be something like 1920x1080 for a modern display. The resolution usually should be the max size that your display can handle. If a game must change it for fullscreen, it will do so itself....
Config is very individualistic, but the defaults are usually safe, and should be used until you decide otherwise. I keep my wads in a separate directory. The docs will tell you which directories you can use. See the README file, as it already has all this information. Another copy is on this site, on the files/1.48.16 page. You got a copy in the docs when you got the legacy.wad. The zip file reading was broken. That has been fixed in the current patches. The savegame is also broken, and also has...
Config is very individualistic, but the defaults are usually safe, and should be used until you decide otherwise. I keep my wads in a separate directory. The docs will tell you which directories you can use. See the README file, as it already has all this information. Another copy is on this site, on the files/1.48.16 page. You got a copy in the docs when you got the legacy.wad. The zip file reading was broken. That has been fixed in the current patches. The savegame is also broken, and also has...
This is not one of the video settings that I have tried out personally. There are several ways to config for 320x200, as that is one of the preset video sizes. To get it to be 320x240 may depend upon what port you are running, like SDL, or X11. I have to wonder, what kind of physical screen do you have on Linux, that default settings would be too large for the screen. Unless you are running Linux on an Arduino with only a tiny screen, I would first try for 800x640, as that is the default. From the...
This is not one of the video settings that I have tried out personally. There are several ways to config for 320x200, as that is one of the preset video sizes. To get it to be 320x240 may depend upon what port you are running, like SDL, or X11. I have to wonder, what kind of physical screen do you have on Linux, that default settings would be too large for the screen. Unless you are running Linux on an Arduino with only a tiny screen, I would first try for 800x640, as that is the default. From the...
w110_093 sprite extra
w110_092 slow react
w110_091 sprite remap
w110_089 music umapinfo again
w110_090 mbf21 fix6
w110_089 odd music
w110_088 zipseek
w110_087 mbf21_init
w110_086 mbf21_fix5
I have been using whatlies.wad for testing and it does seem to work, however cannot identify what ever it is using MBF21 upon, and I suppose that is a good thing. Thank you for the testing. Have found more problems, and gotten hints from doomworld. The decohack lump is a leftover from an editor, it is not used by any port. DSDA sets its zeroed states and things to a default value, that is not zero. And almost every wad developed upon DSDA is likely to depend upon that. The fields added to states...
w110_085 acp func
w110_084 dehextra 1
w110_083 mbf21 state