Tracker: Issueshttps://tracker.dengine.net/https://tracker.dengine.net/favicon.ico?13985035312022-09-28T19:55:55ZTracker
Redmine Doomsday Engine - Bug #2470 (New): File WAD cannot be played back.https://tracker.dengine.net/issues/24702022-09-28T19:55:55ZSarawut
<p>When opening file WAD, it exits the program and displays this message.</p> Doomsday Engine - Bug #2448 (New): crashes when configuring mods an wads folder an video an audio...https://tracker.dengine.net/issues/24482021-02-01T20:55:12ZDOOMMarine117
<p>Hi, i just recently came back to doomsday for 2.3 update. it crashes after you configure the wads an mods folders an happens right after you configure the videos an audio settings.</p>
<p>it didn't happen before in 2.2.</p>
<p>please fix it. thanks.</p>
<p>are tons of mod support doomsday now like zblood, terminator future war, aliens eradication tc, halo in doom.pk3, wolfenstein 3d, duke 3d an many otehrs?</p>
<p>thanks.</p> Doomsday Engine - Bug #2152 (New): [Hexen] Afrits become stuck/invincible in multiplayerhttps://tracker.dengine.net/issues/21522016-03-27T07:49:37Zskyjake
<p>Version:<br />1.15.8 (Windows 64bit)</p>
<p>Reproducible:<br />Always</p>
<p>Steps to reproduce:<br />In a Hexen multiplayer session (tested in coop only), meet any afrit (black gargoyle that spits fireballs at you) creature.<br />(Best is to choose mage class and set difficulcy level to highest or second highest, the afrit spawns in first map at the beginning just in front of you).</p>
<p>Expected result:<br />Afrit flies around and attacks player.</p>
<p>Actual result:<br />Afrit gets stuck at the location where encountered and is invulnerable and non-clipable (you can't walk through it). A second copy flies around and attacks player. The copy can be killed normally. This behavior works only in multiplayer (even with just 1 player), in singleplayer everything is fine. This breaks several maps where the afrit spawns in the middle of corridors.</p>
<p>(See also: <a class="external" href="http://dengine.net/forums/viewtopic.php?f=7&t=2221#topic">http://dengine.net/forums/viewtopic.php?f=7&t=2221#topic</a>)</p> Doomsday Engine - Bug #2068 (New): [HeXen] Badguys not retaining alerted status upon return to a maphttps://tracker.dengine.net/issues/20682015-05-21T10:46:48Zvermil
<p>Bad guys are incorrectly loosing their alerted status when the player returns to a map they have previously been to (i.e they aren't staying woken up and targeting the player as they do in Vanilla).</p> Doomsday Engine - Bug #2064 (New): Bugs in HeXen Multiplayerhttps://tracker.dengine.net/issues/20642015-05-20T12:07:45Zvermil
<p><strong>This is parent issue for Hexen MP related bugs.</strong></p>
<p>I wasn't sure I should make separate issues for each of these and I debate that some of them might actually be caused by similar issues. Hence the simple subject title.</p>
<p>This is sort of a log of known issues in HeXen MP, as I know HeXen MP has deliberately been left untouched since the new MP code (i.e that Doom and Heretic have received all the focus so far).</p>
Non-missile based mobj spawning is broken; there are lot's of examples of this one that include:
<ul>
<li>Afrit's visually disappear when they spawn, leaving behind a solid un-interactive version of themselves where they spawned (appears to correct itself if one disconnects and re-connects). They only re-appear when they make an attack.</li>
<li>Pot's spawn duplicates of themselves upon destruction that can be pushed around, but not re-destroyed (appears to correct itself if one disconnects and re-connects). Both the item potentially inside the pot and the pot fragments appears to spawn correctly though.</li>
</ul>
<p>Flying bad guys (Afrits, Dark Bishops, Reivers) become visually stuck in their last attack sprite after making an attack, though they seem to behave as normal.</p>
<p>Console cheats aren't disabled; I used this to test the below.</p>
Artefacts:
<ul>
<li>All timed artefacts run out in a few seconds</li>
<li>Wings of Wrath run out after a few seconds</li>
<li>Panic mode causes a client to seg fault</li>
<li>Inventory always resets to first item after any inventory item is used</li>
<li>Attempting to use a puzzle item in the wrong place leads to a used successfully sound effect and hud effect, though the item doesn't appear to be wrongly used</li>
<li>Choas Device, Boots of speed and Bracers do nothing when used</li>
<li>Dark Servant doesn't always disappear/appear correctly</li>
</ul> Doomsday Engine - Bug #1989 (New): Client assert fail (possible crash) if joining game during int...https://tracker.dengine.net/issues/19892015-03-08T17:04:10Zskyjake
<p>If the server is in the intermission screen, a client connects, and then triggers the Fire control (to advance to the next map), the client has an assertion failure: <pre>ASSERT failure in QList<T>::operator[]: "index out of range"</pre></p>
<p>Relevant stack trace:<br /><pre>5 doom 0x0000000118f28450 QList<internal::wianimstate_t>::operator[](int) + 96 (qlist.h:486)
6 doom 0x0000000118f2247d beginAnimations() + 173 (intermission.cpp:540)
7 doom 0x0000000118f227e4 initShowNextMap() + 36 (intermission.cpp:637)
8 doom 0x0000000118f22784 IN_SetState(interludestate_t) + 84 (intermission.cpp:1544)
9 doom 0x0000000118f5b13c NetCl_Intermission + 540 (d_netcl.cpp:710)
10 doom 0x0000000118f58ec6 D_HandlePacket + 838 (d_net.cpp:578)
11 0x000000010c7cd8ff Cl_GetPackets() + 1375
</pre></p> Doomsday Engine - Feature #1945 (Resolved): Efficient reuse of world geometry across multiple fra...https://tracker.dengine.net/issues/19452015-01-13T13:44:08Zskyjake
<p>One of the most fundamental performance problems of the old 1.x renderer is that every time the player view is drawn, world surfaces are recomputed into GL geometry. (One can see how costly this is by freezing the rendering lists.) However, many rendering techniques require rendering all or some parts of the world multiple times: VR modes draw dual views, shadow mapping requires passes from lights' point of view, reflections need several passes for dynamic cube maps, and overall most of the world remains static across frames so recomputing geometry is wasted effort.</p>
<p>In practice, geometry should be stored as a reasonably small number of static vertex buffers. We should explore if moving planes could be partially or even completely implemented similarly to skeletal animation, where certain vertices would be affected by selected transformations. The trick would be to do this efficiently only for the needed planes, and only when the planes are expected to move. (After all, it is not necessary to efficiently support for <strong>all</strong> planes to move in the map with no foreknowledge.)</p>
Benchmarking:
<ul>
<li><a class="external" href="http://www.moddb.com/games/doom-compile-project">http://www.moddb.com/games/doom-compile-project</a></li>
</ul> Doomsday Engine - Feature #1886 (In Progress): Use SDL 2 for window management, display modes, co...https://tracker.dengine.net/issues/18862014-10-20T15:17:31Zskyjake
<p>SDL 2 has quite good support for low-level functionality that is essential to games. Particularly, it supports native input APIs like XInput on Windows, for raw device events. Using SDL 2 instead of custom code and Qt for all these things (wm, video, input) should improve robustness and reduce the maintenance burden.</p>
In practice:
<ul>
<li>SDL 2 should be linked to libgui and there should be a variant of GLWindow that creates an underlying SDL_Window.</li>
<li>DisplayMode should be removed and replaced with SDL video functions.</li>
<li>Qt's OpenGL API wrappers should still be usable with an SDL-created OpenGL context (after creating a QOpenGLContext representing the previously created context).</li>
</ul> Doomsday Engine - Feature #1648 (Progressed): Complete vanilla DOOM emulationhttps://tracker.dengine.net/issues/16482013-11-02T14:26:05Zskyjake
<p>This is an umbrella issue for tasks related to features/bugs that allow Doomsday to look and behave exactly like vanilla Doom (except with higher resolution, etc. — we aren't going to implement, say, a column-based software renderer).</p> Doomsday Engine - Feature #1630 (New): Implement game menus with InFine (InfineWidget)https://tracker.dengine.net/issues/16302013-10-22T10:20:08Zskyjake
<p>It is not ideal that game menus are completely hard-coded into the game plugins. Also, implementing the game menus directly on Doomsday UI widgets makes quite a large leap from generic components into game-specific ones.</p>
<p>One solution would be to replace the game plugins'/libcommon menu system with an InFine-based one. This would consolidate existing subsystems in a nice way, and act as a good use case for interactive, script-based InFine. It is also a good match for InFine because it is responsible for game-side UI animations; only the interactivity and scripted logic needs enhancing.</p>
<p>InFine-based menus would be easily extensible/modifiable by addons, especially if the functions activated by menu items would be implemented as script functions.</p>
<p>In practice, InFine would likely have to be refactored to use a separate Doomsday widget (<code>InfineWidget</code>) per each InFine layer (the menu, including all its subpages, would be a single layer).</p> Doomsday Engine - Feature #1625 (Progressed): Per-pixel surface shading (bump/specular/reflection...https://tracker.dengine.net/issues/16252013-10-22T07:59:02Zskyjake
<p>Bump/Specular/Enviroment/Reflection/Procedural mapping for models/walls/flats.</p>
<p>Would greatly enhance the look of Doomsday.</p> Doomsday Engine - Feature #1623 (Progressed): Shadershttps://tracker.dengine.net/issues/16232013-10-22T07:53:57Zskyjake
<p>Support for vertex and fragment shaders for surfaces, objects, and UI.</p>
<p><code>libgui</code> already implements the basic support for shaders, and the new UI framework uses them for drawing the taskbar and other UI elements. The next step is to use them in game and map rendering.</p> Doomsday Engine - Feature #1622 (New): Vanilla depth shadinghttps://tracker.dengine.net/issues/16222013-10-22T07:46:22Zskyjake
<p>We should replicate the original games' depth shading as closely as possible.</p>
<p>In practice, the depth shading gradient could be stored in a texture that is multiplied into the other lighting. (A per-pixel shader to calculate it programmatically might be a waste of GPU time; however it shouldn't require a very complex function.)</p> Doomsday Engine - Feature #1603 (Progressed): Support for id Tech 1 map hackshttps://tracker.dengine.net/issues/16032013-10-18T14:05:46Zskyjake
<p>With carefully manipulated map data, the original DOOM engine could be tricked into rendering special effects like deep water. Doomsday should replicate the appearance of these hacks using 3D geometry. Similarly, limitations of the usual 2.5D physics can be worked around with tricks that involve dynamic behavior of sectors (e.g., bridges).</p> Doomsday Engine - Feature #1601 (In Progress): Package managementhttps://tracker.dengine.net/issues/16012013-10-18T13:41:21Zskyjake
<p>Doomsday should have an internal package manager for managing the installed addons and for accessing online repositories of addons.</p>
<p>One of the key features of the system should be modular packaging, which essentially means resource files packaged into folders by logical entity (game, mobj, etc.). This allows easily selecting which packages to use.</p>
<p>See also: <a href="http://dengine.net/dew/index.php?title=Resource_package" class="external">Resource Package proposal</a></p>