Activity for Michael Bäuerle
-
Michael Bäuerle created ticket #693
Bossaction problem
-
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.
-
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).
-
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
-
Does this discussion explicitly cover the content of the library, or just the interface between the library and DoomLegacy All code proposed in this FR was written by me (the library itself, the glue code for the engine in "umapinfo.c" and the patches for the engine to use the UMAPINFO data). Nobody else has a copyright on (parts of) this code. You have explicit permission to cherry pick and integrate the code (including the library code) under the Doom Legacy license (GPLv2), as this seems what...
-
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. No, my comment was about the law in some countries. The final 1.0.0 release of the library (with BSD license) is now available here: https://micha.freeshell.org/libdoom-umapinfo/ Attached is a version containing the same code, but without the copyright line and a literal copy of the GPLv2 license from Doom Legacy. This version should allow you to rip...
-
In Version 1.0.0rc4 of the library, the API function doom_umi1_register_mmanager() was exported with wrong prefix. This is fixed in the attached version 1.0.0rc5. The attached version of "umapinfo.c" let the library use zone memory of the engine.
-
In Version 1.0.0rc4 of the library, the API function doom_umi1_register_mmanager() was exported with wrong prefix. This is fixed in the attached version 1.0.0rc5.
-
This problem is similar to my voodoo doll problem from #688. The switch was already present, but I overlooked it. Today it seems that nobody uses Doom Legacy for testing new WADs anymore. People use Crispy for Limit removing, PrBoom+/DSDA for Boom, Woof for MBF and GZDoom otherwise to test if their new WAD "works". Very few new WADs are created for Doom Legacy and its specific features. Speaking as a player, not as a developer: Facing reality I would propose to change the default behaviour to follow...
-
Some words about the library: I have first taken a look at the reference implementation in PrBoom+. It is written in C++ and I expected that you don't like this for Legacy 1 (I assume you would work with Legacy 2 code otherwise). There is another implementation in Woof, that is written in C. Maybe you should consider using this code, if you don't like my implementation. Modifiying it for this project means that code for parsing UMAPINFO data already was implemented at least three times. The idea...
-
Vanilla compatible bossactions
-
For some keys, e.g. "intertext", the UMAPINFO specification 2.2 allows for multiple lines. No formal syntax is given, only an example that uses multiple, comma separated, string values. Some real world WADs use a single string value with a "\n" semantic for line breaks instead. Example: https://www.doomworld.com/idgames/levels/doom2/Ports/megawads/poogers The attached file "umapinfo.c" was modified to accept this semantic.
-
Facing of voodoo dolls should not be relevent for progression. But if visible from regular map areas, maybe things does not look like the map designer has intended. Would it be a problem to simply spawn all voodoo dolls with the orientation defined by the map?
-
Sorry for overlooking this option. I can confirm that it works with the "Vanilla" setting.
-
Incorrect voodoo doll behaviour
-
Test WADs: - For Ultimate Doom "umapinfo1.wad" attached. Uses episode crossing progression. - For Doom II "umapinfo2.wad" attached. Real world WADs that use UMAPINFO: - 2022 A Doom Odyssey (for Ultimate Doom) https://www.doomworld.com/idgames/levels/doom/Ports/megawads/2022ado The 5th episode should work, but levels ExM10 do not work because of engine limitations unrelated to UMAPINFO. - Solar Struggle (for Ultimate Doom) https://www.doomworld.com/idgames/levels/doom/Ports/megawads/sstruggle
-
Test WADs: - For Ultimate Doom "umapinfo1.wad" attached. Uses episode crossing progression. - For Doom II "umapinfo2.wad" attached. Real world WADs that use UMAPINFO: - 2022 A Doom Odyssey (for Ultimate Doom) https://www.doomworld.com/idgames/levels/doom/Ports/megawads/2022ado The 5th episode should work, but levels ExM10 do not work because of engine limitations unrelated to UMAPINFO. - Solar Struggle (for Ultimate Doom) https://www.doomworld.com/idgames/levels/doom/Ports/megawads/sstruggle
-
Files.
-
Files.
-
Files.
-
Support for UMAPINFO Rev 2.2
-
Remove limits for map numbers
-
Tested again with SVN 1647: Looks good now. Ticket can be closed.
-
Texture not rendered correctly
-
The pkgsrc package for xnedit has been updated: https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/editors/xnedit/index.html Version 1.4.1 will be in the 2022Q3 release.
-
| Please check that you have monster dropoff set ON, as that is necessary (MBF logic, not mine). Yes, both are set to ON. If I wait directly beyond the ledge they jump down. If I wait a bit more far away (but still between the starting ledge and the first enemies on Doom 2 / Map 1), they don't jump down. What was missing in my test was Monkeys set to ON. In the "FAQ/Compatibility" section of the documentation there is now a good description. I think it is sufficient and the extra setup options are...
-
Use POSIX struct dirent by default
-
| - How many other users will find this useful ? +1 (most interested in secret count/secrets found)
-
Tested again with SVN revision 1620 and clang 13.0.0: In file included from r_draw.c:751: ./r_draw8.c:312:22: warning: variable 'frac' set but not used [-Wunused-but-set-variable] register fixed_t frac; ^ In file included from r_draw.c:759: ./r_draw16.c:146:25: warning: variable 'frac' set but not used [-Wunused-but-set-variable] fixed_t frac; ^ 2 warnings generated. r_segs.c:1747:14: warning: variable 'topheight' set but not used [-Wunused-but-set-variable] fixed_t topheight, heightstep, bot_patch;...
-
Tested with SVN 1620 (two helper dogs and dogs.wad): Seems to work now in general. It is still possible to complete Map 1 of Doom 2 while both dogs are located on the starting ledge.
-
Xft header not found
-
LDFLAGS are not used
-
Primary selection not working
-
Tested SVN 1608 (with my modified legacy.wad for the dog sprites): With my test map: I have configured two helper dogs and my map contains one enemy dog. Only the enemy dog attacks me. Looks good. With Antaresian Spacepond: The dog behind the first door does not attack. It is marked as "friendly" in the map. Looks good too. "Dog Jumping" configured to "On" does not work: If I start Map 1 of Doom2 with helper dogs, they don't jump down from the starting ledge (and therefore can't follow me). Compared...
-
SVN 1603 works better, e.g. in Eviternity the Nightmare demon uses the correct sprite. SVN 1604 is a regression, e.g. the rocket launcher in Valiant is broken again (and the "Lunch" from Antaresian Spacepond attacks me). If this cannot be fixed cleanly with autodetection. What about a manual configuration option? In MBF mode at least the dogs (and replacements like in Eviternity) should be compatible with MBF (Woof) or PrBoom+ complevel 11 (looks like most MBF-WADs are designed for, or at least tested...
-
The Dehacked lump defines this type as "Lunch" and with PrBoom+ and Woof it has a sprite -- looks like a sandwich (and does not attack as expected). Seems that Legacy does not correctly handle the Dehacked modification.
-
Internal blockmap generation works. Can be closed.
-
Played again all maps of Avactor with the software renderer and noticed no more rendering errors. I think this bug can be closed now.
-
I can confirm that the helper dogs now spawn as expected. Tested with svn 1601.
-
prboom+ has sprites and sounds for the dogs in its engine WAD (prboom-plus.wad). I have used SLADE to copy them from there. If there are no license issues: Would it be possible to add them to legacy.wad too?
-
The friendly dogs need start points for additional players. The attached WAD file contains 4 player start points.
-
MBF dogs are broken
-
I have now played all maps of Avactor again (SVN 1598 with the software renderer on my big endian machine). I noticed no blockmap problems.
-
At least the problem with Lost Civilization Map 4 (that I described at 2021-09-27 in the FR #95 thread) is still present with SVN 1598, if I configure the blockmap generation to "Vanilla". While loading the blockmap there are many warnings like: Blockmap offset[4046]: Overflow 0x30000, exceeds lastlist=0x2327A
-
No time for more testing yet. Maybe I can play again some Avactor levels with SVN 1598 at the weekend.
-
Tested Map 9 again with SVN 1598 and hardware renderer: Yes, I can see the holes too. Tested with an old (SDL1 based) PrBoom+: Similar behaviour. No holes with software renderer. Holes present with hardware renderer (see attached screenshot). No crashes on my test machine (NetBSD/amd64).
-
Tested Avactor Map 9 with the software renderer: Looks good. I have not noticed holes in the ceiling. But the map is large, at which locations you see them?
-
Thank you for merging FR #96! Quick test with Eviternity: It seems to work in general. When I save a game, change the option and than reload it, the former option is used. I think this is intended and correct. But something looks wrong with the selection logic: After loading a game that restored a different setting, all maps now use this setting (new game or idclev cheat). I think the start of every map should use the configured setup again. While testing new game with "Vanilla" configuration and...
-
Thank you for merging FR #96! Quick test with Eviternity: It seems to work in general. When I save a game, change the option and than reload it, the former option is used. I think this is intended and correct. But something looks wrong with the selection logic: After loading a game that restored a different setting, all maps now use this setting (new game or idclev cheat). I think the start of every map should use the configured setup again. While testing new game with "Vanilla" configuration and...
-
Unlikely, because the map was not playable without the code for extended nodes. But if I remeber correctly, you have modified/improved the blockmap import code (for Lost Civilization) since the time I created this FR.
-
Label at end of compound statement
-
Thank you for merging FR95! Test with Lost Civilization Map 4 and software renderer looks good. It still doesn't work with the hardware renderer (but has never worked for me). And there are blockmap problems. If you are entering the building in the attached screenshot on the left side, you can walk through the left wall on the second screenshot (and the wall straight forward beyond the opening to the right). The building shown is located to the north of the map. Eureka displays the coordinates -8256/11584...
-
Thank you for merging FR95! Test with Lost Civilization Map 4 and software renderer looks good. It still doesn't work with the hardware renderer (but has never worked for me). And there are blockmap problems. If you are entering the building in the attached screenshot on the left side, you can walk through the left wall on the second screenshot (and the wall straight forward beyond the opening to the right). FR96 solves this problem. Either the blockmap in the WAD is broken or there is a bug in the...
-
Tested again with SVN revision 1574 => One regression: d_netfil.c: In function 'CL_waiting_on_fileneed': d_netfil.c:306:37: warning: '%-40s' directive output may be truncated writing between 40 and 9471 bytes into a region of size 127 [-Wformat-truncation=] 306 | snprintf( b, BUFFSIZE-1, "%-40s %4i %4i", | ^~~~~ d_netfil.c:306:36: note: directive argument in the range [0, 4194303] 306 | snprintf( b, BUFFSIZE-1, "%-40s %4i %4i", | ^~~~~~~~~~~~~~~~~ d_netfil.c:306:36: note: directive argument in the...
-
Tested again with SVN revision 1574 => No warnings.
-
Looks good now. No more warnings.
-
There is still one warning with clang 10: r_things.c:489:29: warning: result of comparison of constant -1 with expression of type 'uint16_t' (aka 'unsigned short') is always true [-Wtautological-constant-out-of-range-compare] if( (rtp->spritelump_id != -1) && devparm ) ~~~~~~~~~~~~~~~~~~ ^ ~~ 1 warning generated. PS: This patch format is inconvenient. Neither BSD nor GNU patch detects the filenames and I have to enter them manually. Please create unified diffs.
-
"d032_gcc10c.diff" applied to SVN 1568 with some offsets (SVN 1569 not on the server yet). => Looks good, no warnings with GCC 10.
-
Compiler warnings with clang 10
-
No more warnings with the "src_gcc10c.diff" patch and GCC 10. I will open a new ticket for clang.
-
Wesley Johnson wrote: They are also making patches to the code, so probably GCC8, and GCC9 are even worse. I have checked your patch with GCC 7.4.0: No warnings. If GCC 10 will be OK again, maybe GCC 8 or 9 are not worth to care for.
-
I have tested your patch against SVN revision 1567: One warning left with GCC 10, it's the one at "m_menu.c" line 4255: m_menu.c: In function 'M_ReadSaveStrings': m_menu.c:4255:9: warning: 'strncpy' output may be truncated copying 23 bytes from a string of length 59 [-Wstringop-truncation] My suggestion tried to not change the behaviour of the existing code. Using strcpy() will silence the warning too: strcpy( &sgdp->desc[0], slot_str); sgdp->desc[SAVESTRINGSIZE-1] = '\0'; But this may end with a...
-
Tested again directly with SVN revision 1568: 3 warnings left. See attached file for the warnings and tested workarounds.
-
Maps with DeePBSP V4 extended nodes: - Avactor Map 9 - Avactor Map 10 Maps with uncompressed ZDoom extended nodes (they are used more often): - Lost Civilization Map 4 - Lost Civilization Map 19 - Lost Civilization Map 20 - Remnant Map 1 - Man on the Moon Map 1 - NOVA II Map 32 - NOVA III all maps The maps themselves are not ZDoom-specific, only the nodes use the ZDoom format. Some maps need #96 too, because the blockmaps are not imported correctly or missing (NOVA III). Are the maps listed above...
-
Wesley Johnson wrote: I could save the result of snprintf, but it would go unused. Won't that be another warning ? Or the optimizer will eliminate all code for unused values and the warnings will not change. The way you fixed it in the patch looks good, no more snprintf() warnings. Tested again with r1567 and your patch. Two snprintf() warnings left, see attachment. My original log was created with FR #95 patches (32-bit extended nodes with type "int" for "children", see "patch-src_r__defs.h"). The...
-
Warnings for SVN1567 build with GCC 10 attached. sdl/i_system.c: 1507 strncpy(username, p, MAXPLAYERNAME); strncpy() does not ensure that the result string is NUL-terminated. Proposed patch: strncpy(username, p, MAXPLAYERNAME - 1); username[MAXPLAYERNAME - 1] = 0; hardware/hw_bsp.c:1959 The pointer mismatch comes from my extended node patchset #95, that redefines the array children[] to 32-bit. I will look at this, the patch must be reworked for r1567 anyway. For the snprintf() warnings: GCC 10 considers...
-
Looks good now (for both cases). There are still some other warnings. I have attached them, if you are interested to check them too. Note: The list is from a pkgsrc-build of SVN1563 with our patches applied (if some line numbers should differ compared to the SVN source tree).
-
I have tested Antaresian Reliquary and Doom 2 again. Heretic looks good too. Ticket can be closed.
-
Undefined behaviour (Warnings from GCC 10)
-
"Sky Draw option set to Vanilla" maybe was active. I have played with the options for "ANTA_REQ.wad" before and "Vanilla" sounds like "Default". I have tested it again with "Auto" and it looks similar, see attached screenshot. This time I walked to the border of the map with noclip (tiling only happens on the top end).
-
Antaresian Reliquary Map 3 looks good now (no pink lines) and no tiling (at least on the bottom end). But Map 1 from the Doom 2 IWAD looks like on the attached screenshot. Sky is tiled and has lines with garbage (now in vertical direction).
-
Updated version attached. It contains a patch from Altazimuth for Eternity Engine: Fixes MBF's code, which has a bug where maxx/maxy are wrong if the 0th node has the largest x or y.
-
pkgsrc bulkbuilds on SmartOS are working now with 1.48.6. Ticket can be closed.
-
If the player is looking up or down, a pink stripe is rendered. It looks similar to that from bug #663. Can this be a "tall patch" problem too?
-
If the player is looking up or down, a pink stripe is rendered. It looks similar to that from bug #663. Can this be a "tall patch" problem too?
-
Height extension of sky
-
Savegame buffer overrun
-
Tested SVN 1549 with software renderer: The tree from Map 1 looks good now. The rotating saw blade in the building at the start of Map 4 (needs Feature #95 and #96) is fixed too.
-
Thank you for adding DeePsea tall patch support! I have first tried to patch all places in the code, but removed that part of the patchset again because it has not worked as intended for the software renderer. Tested SVN 1547 with software and hardware renderer and the textures on walls seems to be OK now. Also looked at the tree sprite in question: Here it looks good with the hardware renderer. With the software renderer there seems to be a horizontal wraparound. The right part of the tree is missing...
-
Thank you for adding DeePsea tall patch support! I have first tried to patch all places in the code, but removed that part of the patchset again because it has not worked as intended for the software renderer. Tested SVN 1547 with software and hardware renderer and the textures on walls seems to be OK now. Also looked at the tree sprite in question: Here it looks good with the hardware renderer. With the software renderer there seems to be a horizontal wraparound. The right part of the tree is missing...
-
Patches are for SVN revision 1541 Solaris has a native net_aton() in libresolv at least since version 2.6 from 1997. The FIONBIO ioctl() does not work anymore. The patches replace it with the portable POSIX fcntl() variant (that should work for all modern Unix systems). The type label_t does not exist (see Discussion). Tested with network games between a NetBSD and a GNU/Linux machine (with and without master server).
-
Solaris has a native net_aton() in libresolv at least since version 2.6 from 1997. The FIONBIO ioctl() does not work anymore. The patches replace it with the portable POSIX fcntl() variant (that should work for all modern Unix systems). The type label_t does not exist (see Discussion).
-
Solaris has a native net_aton() in libresolv at least since version 2.6 from 1997. The FIONBIO ioctl() does not work anymore. The patches replace it with the portable POSIX fcntl() variant (that should work for all modern Unix systems). The type label_t does not exist (see Discussion).
-
Solaris has a native net_aton() in libresolv at least since version 2.6 from 1997. The FIONBIO ioctl() does not work anymore. The patches replace it with the portable POSIX fcntl() variant (that should work for all modern Unix systems). The type label_t does not exist (see Discussion).
-
Support for SunOS based operating systems
-
Looks like the textures are not missing, but they use DeePsea tall patches as explained here in the Doom Wiki: https://doomwiki.org/wiki/Picture_format#Tall_patches (Some tree sprites in Lost Civilization looks crippled in the same way as on the picture in the Wiki too) I have looked at Crispy Doom and imported the attached patch for R_DrawMaskedColumn(). The other patch is for the hardware renderer. I have used this demo WAD from Julia Nechaevskaya: http://jnechaevsky.users.sourceforge.net/files/512x512.wad...
-
Looks like the textures are not missing, but they use DeePsea tall patches as explained here in the Doom Wiki: https://doomwiki.org/wiki/Picture_format#Tall_patches (Some tree sprites in Lost Civilization looks crippled in the same way as on the picture in the Wiki too) I have looked at Crispy Doom and imported the attached patch for R_DrawMaskedColumn(). The other patch is for the hardware renderer. I have used this demo WAD from Julia Nechaevskaya: http://jnechaevsky.users.sourceforge.net/files/512x512.wad...
-
Looks like the textures are not missing, but they use DeePsea tall patches as explained here in the Doom Wiki: https://doomwiki.org/wiki/Picture_format#Tall_patches (Some tree sprites in Lost Civilization looks crippled in the same way as on the picture in the Wiki too) I have looked at Crispy Doom and imported the attached patch for R_DrawMaskedColumn(). The other patch is for the hardware renderer. I have used this demo WAD from Julia Nechaevskaya: http://jnechaevsky.users.sourceforge.net/files/512x512.wad...
-
Looks like the textures are not missing, but they use DeePsea tall patches as explained here in the Doom Wiki: https://doomwiki.org/wiki/Picture_format#Tall_patches (Some tree sprites in Lost Civilization looks crippled in the same way as on the picture in the Wiki too) I have looked at Crispy Doom and imported the attached patch for R_DrawMaskedColumn(). The other patch is for the hardware renderer. I have used this demo WAD from Julia Nechaevskaya: http://jnechaevsky.users.sourceforge.net/files/512x512.wad...
-
Looks like the textures are not missing, but they use DeePsea tall patches as explained here in the Doom Wiki: https://doomwiki.org/wiki/Picture_format#Tall_patches (Some tree sprites in Lost Civilization looks crippled in the same way as on the picture in the Wiki too) I have looked at Crispy Doom and imported the attached patch for R_DrawMaskedColumn(). The other patch is for the hardware renderer. I have used this demo WAD from Julia Nechaevskaya: http://jnechaevsky.users.sourceforge.net/files/512x512.wad...
-
Wesley Johnson wrote: Otherwise, I must ask, how did you manage to get it to fail compiling. I have tested on NetBSD and GNU/Linux (as usual) with minor problems. In few cases the game crashed in libxcb, but this may not be Legacy related (GNU/Linux on a big endian Mac is an exotic use case and I expected problems). With NetBSD on maintream hardware I never saw something like that. The build on SmartOS formerly have failed because of statfs(). SmartOS is SunOS based, but does not define SOLARIS....
-
My pkgsrc package of version 1.48.4 fails to build on SmartOS because label_t is missing. Build log: https://us-east.manta.joyent.com/pkgsrc/public/reports/upstream-trunk/20200524.2251//doomlegacy-1.48.4/build.log Searching the source tree for "label_t" finds only the file t_prepro.h where it is used for the return value for the function "labelforname()". Searching the source tree for this function finds nothing (only the declaration itself in t_prepro.h). Is this something old that is no longer...
-
Same problem can be seen above the bridge in the start area. PrBoom+ does not display such colored stripes. See attached screenshots for comparison. Tested with version 1.48.4, but older versions show similar behaviour.
-
Same problem can be seen above the bridge in the start area. PrBoom+ does not display such colored stripes. See attached screenshots for comparison.
-
Same problem can be seen above the bridge in the start area. PrBoom+ does not display such colored stripes. See attached screenshots for comparison.
-
Textures with pink/black/pink stripes
-
Nova II Map 32 triggers two issues: 1) It uses extended nodes (see Feature request #95) 2) The blockmap import problem described above I have created Feature Request #96 as workaround for issue 2. If the blockmap is created internally (with "-blockmap"), the map can be played. It is still unclear if the blockmap of Map 32 is not imported correctly, or broken, or has hit the limit of the WAD format and was truncated (broken too, lump should be empty in this case).
-
I have now tested the code for compressed ZDoom extended nodes guarded with HAVE_ZLIB. Z_Realloc() was missing and I replaced it with an ugly hack in the attched file. The memory management should be rewritten to use either Z_Malloc() or malloc(), not both. It now works with: CFLAGS+=-DHAVE_ZLIB LDFLAGS+=-lz
1 >