Activity for Doom Legacy
-
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....
-
Roman Wieczorek posted a comment on discussion Open Discussion
With few modifications all builds with SDL2 on windows command prompt with force disabling msys: make HAVE_DOSCOMMAND=1 Program runs but crashes a while after game start
-
Failures for now: failed to build SDL1.2 - current mingw says packages from https://sourceforge.net/projects/libsdl/files/SDL/1.2.15/ - is incomatible failed to build using SDL2 failed building on MSYS2 - it is cygwin which uses linux like system which requires some changes in i_system.c - still probably easiest way How do you build for windows? Cross compiling?
-
I have coop mode in mind. Previously there was a bug: when you started game as single player and switched to two players, map restarted when one player tried to respawn. I think i get it: add d_netcmd.h extern consvar_t cv_playerrespawn; menuitem_t GameOptionsMenu[]= { {IT_STRING | IT_CVAR,0,"Player Respawn" ,&cv_playerrespawn ,0}, at void P_DeathThink (player_t* player) if (player->cmd.buttons & BT_USE) add check cv_playerrespawn and if this is last player living at G_DoReborn check cv_playerrespawn...
-
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.
-
Add option player_respawn to disable players respawning. When player dies, check if this is the last player and restart map.
-
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...
-
Juliano Reis created ticket #695
BSP rendering through the sky
-
BFG Blast always throws enemies in same direction
-
So, like I've said, the Xbox joystick works, but the analog sticks on the controller don't appear to do anything. This forces the player to use the D-pad to move, which is far from ideal. I've looked around, but there's just one generic option for "deadzone", which doesn't make any sense (it's set at 800 by default, but controllers usually go from 0 to 1, with 0.2 or 0.3 being ideal defaults), and it doesn't even specify what this deadzone refers to. Documentation also cites there being support for...
-
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.
-
Hey all. Is it possible at all to map the movement to the analog sticks on an Xbox controller? Aiming with the controller requires fine movement from both analogs, and currently it seems that none are supported, sending joystick users back to the SNES control scheme. If not, would it be possible to add this feature on an upcoming revision or release?
-
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
-
Michael Bäuerle created ticket #693
Bossaction problem
-
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....
-
The reason for the intermediate data is to provide a thread-safe API. The parser itself is not thread-safe. The library selects the last (not the first) entry, if there are multiple entries. The UMAPINFO specification is not very precise what should happen in such cases.
-
Looks good now. Ticket can be closed.
-
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
-
On my system "Auto" does the same as "Fit_Height" (looks wrong with both). I have used 1280x1024 pixels fullscreen, but a test with a 320x200 window shows the same problem. The settings "Fit_Width" and "Stretch" do not show this problem. The attached archive contains the WAD file and some screenshots (there is also a screenshot from PrBoom+ for comparison).
-
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...
-
Sorry for the late answer. Thank you for merging UMAPINFO support! I have done a quick test with 1.48.14 and it seems to work as expected. I have not looked at the details yet.
-
Flats not rendered correctly with viewfit set to auto
-
Extend LIBZIP support to FreeBSD (and maybe others)
-
Makefile patched SVN 1664.
-
w110_034 gren blockmap unlink
-
w110_034 makefile compile zip
-
Alexey Dokuchaev posted a comment on ticket #691
Does this mean that no other changes are needed, that dlopen and the libraries can be found in the same locations as on a standard Linux? Admittedly, I've only tested normal linking (that check guards the entire LIBZIP block), but will test dlopen(3) mode and reply later.
-
Doom Legacy updated /1.48.14/README.rst
-
-
-
-
-
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...
-
Extend LIBZIP support to FreeBSD (and maybe others)
-
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.
-
lantern424 posted a comment on discussion Open Discussion
Hi, I'd ask you to consider about combining the contents of the Doom Legay executable package and the wads from the common zip together, please. At the moment the latest version 1.48.14 Windows binarien have been downloaded 57 times from Sourceforge. But doomlegacy_1.48.14_common.zip has been dowloaded only 32 times. Does that mean that over 40 % of people who downloaded Doom Legacy won't be able to run it because of the missing legacy.wad resource file? It's perfectly understandable why the division...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Ville Bergholm committed [r1663] on SVN
Small README fix.
-
Convert docs to HTML 5.
-
README updated.
-
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
1 >