Activity for Wesley Johnson
-
Wesley Johnson posted a comment on discussion Open Discussion
Was that failed to build SDL 1.2 (compiling SDL1 itself), or failed to build DoomLegacy using SDL 1 ? Some things like MP3 need the SDL library itself to be recompiled, as by default they had disabled it.
-
I was thinking COOP too, but it would be even worse for a match player waiting to get back into the battle. Switching from single player to 2 player game is not something that was ever supported. Do not know how you managed to do that, as I do not think the menu system would have let you. I build the windows version using a separate computer that runs XP. It has MSYS and MINGW compiler installed for this purpose. It was setup so many years ago that I no longer remember any of the special settings....
-
That would possible. I think the reason it has not been done, is that it would leave the dead players doing nothing until the other players died. That could be a long time. I had considered adding a delay until respawn, so that they must wait x-seconds until the get respawned. If that was set high, like 120 seconds, it would have a similar effect. Perhaps there could also be a limit on the number of respawns, or possibly that the respawn time would have a penalty added for every respawn. That could...
-
That would possible. I think the reason it has not been done, is that it would leave the dead players doing nothing until the other players died. That could be a long time. I had considered adding a delay until respawn, so that they must wait x-seconds until the get respawned. If that was set high, like 120 seconds, it would have a similar effect.
-
w110_058 sdl MP3
-
w110_058 gcc12 2
-
w110_058 tired run
-
w110_057 slopediv_64
-
w110_054 register control list
-
w110_054 gcc12 fixes
-
w110_054 MBF21 savegame
-
It is not always. A direct hit will throw the enemy back. Some hits will just gib them in their tracks. But if it is only BFG rays, then it does prefers the one direction. This is present in older versions of DoomLegacy too. It may be the same in PrBoom. If it is a Doom standard, then I will not be able to change it, as it could affect demos. The throwing of an enemy due to being shot does not always make sense. If you shoot an enemy on a wall, it will sometimes fling itself towards you. There are...
-
It is not always. A direct hit will throw the enemy back. Some hits will just gib them in their tracks. But if it is only BFG rays, then it does prefers the one direction. This is present in older versions of DoomLegacy too. It may be the same in PrBoom. If it is a Doom standard, then I will not be able to change it, as it could affect demos.
-
This looks like the usual sector height problem. It may be that, one or more sectors do not have the ceiling set to sky. I would have to see the wad to diagnose this. The sky is just the area over walls. It is rendered to the screen wide sky texture, as if it was a wall. A linedef that has upper areas set differently will render something other than sky. see DoomLegacy editing docs see: https://doomlegacy.sourceforge.net/hosted/level_design_r3.txt see: https://doomlegacy.sourceforge.net/hosted/level_concept_r2.zip...
-
We only have analog (joystick) and buttons. The hats are mapped as 4 buttons. The person who submitted the code for the XBox controller would be the best person to investigate Xbox controller problems. [feature-requests:#93] Addition of console-like features If this is a Dreamcast controller problem, then must refer to: Feature request #83 Sega Dreamcast port The deadzone sets how much movement is required to be sensed as activation of the joystick. This provides a deadzone around the joystick zero...
-
Support for XBox joysticks was added some time ago. This was done by a user submitting the patch needed to support such. As I do not have XBox controllers, I have never been able to test this myself. However the code added to support XBox should support using the XBox controllers just like any other joystick. You would have to use the joystick for movement. I do not know the SNES control scheme as I only use Linux, am not a game system user.
-
w110_053 hexen defs
-
w110_052 bot friend
-
w110_051 heretic
-
w110_053 mbf21 fix2
-
Patched in SVN 1679. Removed extra int i: The copy of mobjinfo->flags3 to the spawned mobj was missing. The DSDA-Doom reference did not have a flags3, as they had just expanded flags2 to 64 bits instead. There may be more bugs like this due to implementing it in a significantly different environment. I have not done much for test playing it yet. The fix for the sep in fix_action_parm is in next commit. That line gets moved up into the if brackets.
-
w110_049 mbf21 fix1
-
w110_047 MBF21 game
-
w110_047 MBF21 player
-
w110_046 MBF21 enemy
-
w110_045 MBF21 fast monsters
-
w110_044 MBF21 dehacked
-
w110_043 MBF21 defs
-
w110_042 ammo
-
w110_040 dehack
-
w110_040 sector flags
-
w110_039 set reference
-
w110_038 misc5
-
Support for UMAPINFO Rev 2.2
-
I know, many sources tout thread safe as being some achievement. But, most programs, like DoomLegacy, and every other Doom port, are monolithic with highly global data structures. They have no good place to even run more than one thread. The dehacked parsers are not going to get called as a separate thread, mostly because nothing else can run in parallel with them. All the dehacked parsing must be done in the correct sequence, and it is dependent upon the previous wad and the previous dechacked results....
-
Flats not rendered correctly with viewfit set to auto
-
Flats not rendered correctly with viewfit set to auto
-
Fixed SVN1667. Two ratio scaling variables were getting different values. There were two changes that were trying to do the same thing. Replaced aspectf_x uses with projection_y. Removed the var aspectf_x. It will now be consistent. I had tested using the 1280x800 screen size, because it looked extreme in width, compared to the other available choices. It happens the screen size 1280x800 has the same ratio as the original 320x200, and this hides defects in the ratio and scaling. It is one of the...
-
w110_037 viewfit2
-
What I see is that some of the brown edge is cutoff when seeing the teleporter viewed from any distance. When you get up close, it looks normal. That could be something like round-off from the scaling conversions. It will take a while to track that down. My "Auto" looks normal, even when using a wide screen (1280x800). Stretch looks normal. Fit_Width looks normal. Only Fit_Height does this.
-
w110_036 version and opts report
-
Note: If you select Fit Height where the window size does not match normal Doom ratios, it will scale the width to whatever the correct ratio requires. The width may be cropped, or it may be drawing past normal boundaries. Same for Fit Width, it is the height scaling that is dependent upon the ratio. Each of these combinations will have its own separate debugging issues. Drawing beyond normal boundaries has special problems of its own. I thought it looked OK, but you need to know that is a unique...
-
There is good reason I put off this kind of thing for so long. It modifies the draw scaling, one of the most touchy areas of the Doom Legacy code. Auto responds to your window size, and I cannot guess at that at all. "Fit Height" is probably what it is selecting. "Fit Height" also is highly dependent upon the window size. It should still draw normally, if you are using a normal Doom window like 800x600. It is the wide windows that are going to cause problems. I tested with Doom2 for days, trying...
-
Extend LIBZIP support to FreeBSD (and maybe others)
-
Makefile patched SVN 1664.
-
w110_034 gren blockmap unlink
-
w110_034 makefile compile zip
-
Thank you, that fixed the problem. I was able to delete files and add new files. The system, of course, does all the wrong things, forcing me to reload files into it just to get the latest downloads to present properly. The latest download is still wrong as it points to a 1.48.12 file now (that I had to fix), but it is not worth the trouble to reload files just to get it to point to any of the 1.48.14 files. That would make those files look new to all the users.
-
Admin cannot change files
-
It was always the intention that all the -nix would be able to use a zip libaray. I did need someone from the various -nix to tell me it does work and if any changes are needed to find the library linked, and dynamically using dlopen(). I was expecting that most FreeBSD users were just compiling as Linux, but I see now that at some time I had added a FreeBSD target compile. I will make such changes that you need to use all the capabilities. Does this mean that no other changes are needed, that dlopen...
-
Mostly people who update their binary only, and not the docs or the wad. That actually works. This distribution model is not based upon the Windows world, but other distributions in Linux. For example, FlightGear.
-
DoomLegacy 1.48.14
-
DoomLegacy 1.48.14
-
w110_033 x11 misc warnings
-
w110_032 docs faq
-
w110_031 docs update
-
w110_032 ver 1.48.14
-
w110_031 viewfit
-
w110_030 UMAPINFO2
-
w110_030 UMAPINFO
-
w110_029 misc4
-
w110_028 bob4
-
w110_027 gcc
-
I am sorry your code got shredded so bad. I removed the intermediate database, and finished cleaning up the connection to DoomLegacy. The code has shrunk. The umi malloc is no longer needed, as nothing uses it anymore. Most of the error conditions have disappeared, as most of them were caused by bad results from searching that intermediate database. The parser now directly calls a routine in umapinfo.c that stores the umapinfo line direct to the final DoomLegacy umapinfo structure. I pass a single...
-
I have been working on this, for a few months. I am reminded how much I dislike FLEX and YACC. I did try to just modify, but had to replace the lexer, and then could not do anything with the YACC, so in a couple days I wrote a new parser from your yacc sources. I give you my permission to use any of my code in the doomlegacy umapinfo code in your library. I strongly urge you to abandon using YACC and FLEX as they produce horrible unmanageable code.
-
Is there any reason that the parser makes an intermediary database. It looks to me like there is no interaction at all between umapinfo keyword assigns. The parser, at the end of each keyword statement, could just put the values into the final assignments and not allocate any value stacks, no keyword stacks, nor map stacks. The existing value of any map keyword cannot be accessed by umapinfo, so there is no need for keeping that pristine. All interactions in the umapinfo data is by a string, like...
-
w110_026 dos1 update
-
w110_026 joystick option
-
Here is an overall tar file. It is based on SVN 1647.
-
I have been working on this, for a few months. I am reminded how much I dislike FLEX and YACC. I did try to just modify, but had to replace the lexer, and then could not do anything with the YACC, so in a couple days I wrote a new parser from your yacc sources. I have my permission to use the doomlegacy umapinfo code in your library. I strongly urge you to abandon using YACC and FLEX as they produce horrible unmanageable code.
-
Thank you for that. I downloaded it. Probably explore that tomorrow. Because of the way that library header does not give names about who is giving the copyright, I have to ask explicitly. Does this discussion explicitly cover the content of the library, or just the interface between the library and DoomLegacy, that extra code with your name on it ?? I still do not know if YOU wrote the library, or some other group, with some unknown relationship between you and library group. Everytime I think I...
-
Thank you for that. I downloaded it. Probably explore that tomorrow. Because of the way that library header does not give names about who is giving the copyright, I have to ask explicitly. Does this discussion explicitly cover the content of the library, or just the interface between the library and DoomLegacy, that extra code with your name on it ?? I still do not know if YOU wrote the library, or some other group, with some unknown relationship between you and library group. Everytime I think I...
-
Attached are my planned patches to the code base. They will be applied to SVN soon, unless you or I find an error in them. You should use these as soon as possible.
-
Attached are my planned patches to the code base. They will be applied to SVN soon, unless you or I find an error in them. You should use these as soon as possible.
-
Thank you for the work. I see many things that I changed in the base code, and see that I missed updating the DJGPP port a number of times. Changes to the makefile are not going to go smoothly. Is that HOSTCC variable supported on DJGPP, gcc, vc, and all the other compilers, for the last 10 years. I have not seen it before. That you need to introduce "-I ." is suspicious, as I thought that it was already covered in one of the other compile flags. It certainly compiles under gcc and DJGPP on my systems....
-
Thank you for the work. I see many things that I changed in the base code, and see that I missed updating the DJGPP port a number of times. Changes to the makefile are not going to go smoothly. Is that HOSTCC variable supported on DJGPP, gcc, vc, and all the other compilers, for the last 10 years. I have not seen it before. That you need to introduce "-I ." is suspicious, as I thought that it was already covered in one of the other compile flags. It certainly compiles under gcc and DJGPP on my systems....
-
Thank you for the work. I see many things that I changed in the base code, and see that I missed updating the DJGPP port a number of times. Changes to the makefile are not going to go smoothly. Is that HOSTCC variable supported on DJGPP, gcc, vc, and all the other compilers, for the last 10 years. I have not seen it before. That you need to introduce "-I ." is suspicious, as I thought that it was already covered in one of the other compile flags. It certainly compiles under gcc and DJGPP on my systems....
-
I am programmer on the project, not owner of DoomLegacy. Messing with copyright issues would by necessity bring other people into this. That is good way to waste several months having endless discussions. The issue would lead me to use one of the alternatives. From my understanding, you cannot make that version with that copyright cease to exist, as someone else may have relied upon what that copyright says. However, by editing even a few lines, you can create a new work, and put any copyright you...
-
I am programmer on the project, not owner of DoomLegacy. Messing with copyright issues would by necessity bring other people into this. That is good way to waste several months having endless discussions. The issue would lead me to use one of the alternatives. From my understanding, you cannot make that version with that copyright cease to exist, as someone else may have relied upon what that copyright says. However, by editing even a few lines, you can create a new work, and put any copyright you...
-
Vanilla compatible bossactions
-
Thank you for the information. Going to have to think on this a while. First to remember what happened that required the fix. I expect that some compatibility switch will have to be invented. However, I doubt that any player that walks to that door will ever realize which switch they need to find to make that door work. Got any idea what the door logic is that breaks. There are always going to be wads that make use of broken behavior and thus break when it gets fixed.
-
I have been working on this and having some difficulty. I did notice your name in several place, and I expect you may have spent some time developing this. I am not sure the copyright is compatible with ours. I would prefer to be able to modify a copy of the code, adapt it to our ZMalloc, and the DoomLegacy coding. I also have kept DoomLegacy compatible with many systems, some of which I really doubt have the meson compiling environment. I see no need to keep that part, and would just integrate the...
-
The 64 bit executables are produced by another member. I run a 32 bit system, so I leave it to him to produce them. I think he got distracted, so I have forwarded a message to him. This may take a while, as he has mostly retired and has family. I have my limitations too as I have way too many projects to service, and have distractions of my own, and I might not be able to get much done on non-critical items until September.
-
Incorrect voodoo doll behaviour
-
I already have a patch that would fix it, but was wondering exactly what bug I would be fixing. It seems to really be of low priority, so might put it in with some other patch.
-
Is there anything in any wad that has the voodoo facing be relevant ? It is set to 0 in P_Set_Voodoo in p_mobj.c
-
The thrust seems to work if you change the voodoo mode menu item to "Vanilla". This switch is in the game options, adv options, 2nd page. At least the platform went down in your test wad. In the other voodoo modes, it will redirect the damage, and probably the thrust, to a selected player. Did not feel much of a thrust, but that voodoo doll does not move much either. There are some wads that did not work without this fix. It was being used to damage the player when the touched an electric arc, and...
-
Support for UMAPINFO Rev 2.2
-
I downloaded your files. I had already started with getting mapinfo from doomlegacy 2, but was interrupted. I will have to reconcile the two sources.
-
SVN 1648 A patch has been made, which removes the track pad, and makes the "Program_Change" and control variable option (default Off). The Midi compression is also enabled by a control variable which is default On. This should improve the MIDI for Win10 and Win11. Thank you for your tests and reports. Please create a new Bug report for things like these, that are not identical to the original bug report. I cannot close this bug report because this does not fix the issue stated in the original bug...
-
A patch has been made, which removes the track pad, and makes the "Program_Change" and control variable option (default Off). The Midi compression is also enabled by a control variable which is default On. Please create a new Bug report for things like these, that are not identical to the original bug report. I cannot close this bug report because this does not fix the issue stated in the original bug report.
-
w110_024 midi control
-
I have created a doomlegacy with some debug controls. Please test with, varying the controls, to discover what affects the playback in Win 11. doomlegacy dl_qmus_02 debug binary updated 2/7/2023 This is a debug version of doomlegacy 1.48.12. It has added 3 control vars, that are accessed by the drop down console. They are not in the menus. They can only be accessed in the drop down console. They are saved in the config with the other control variables. These enable things that I found in the DoomLegacy...
-
Texture not rendered correctly
-
Texture not rendered correctly
-
It is amazing that Doomlegacy went so long without this bug being obvious. I think it was correct about 2 years ago, but later bug fixes took out the correct code because it was not obvious what it was protecting against. patchfile = w110_022_post_term - commit revision 1644 Fix to Bug 687. In Pagodia.wad, Map06, the hanging vine texture had visual artifacts. (AUR008, texture #624, lump 132961). Due to some of the columns being totally empty, some of the columns of the generated texture had the 0xFF...
-
w110_023 texture 1s 2s
-
w110_022 texture post term
-
I have created a doomlegacy with some debug controls. Please test with, varying the controls, to discover what affects the playback in Win 11. doomlegacy dl_qmus_02 debug binary This is a debug version of doomlegacy 1.48.12. It has added 3 control vars, that are accessed by the drop down console. They are not in the menus. They can only be accessed in the drop down console. They are saved in the config with the other control variables. These enable things that I found in the DoomLegacy midi stream...
-
The MIDI dump reader seems to be working now. The midi_dump makes sense and there does not seem to be anything that could cause a problem. The MIDI analyzed shows that Linux MIDI output and Windows MIDI output are identical, except that compression (running status) is disabled for Windows platforms. You midi_dump and my WinXP midi_dump match exactly. Do you have any easy way on Windows to capture the MIDI output of one of those other Doom ports ? It may take a while to get the sound tools I have,...
1 >