EDuke32 issueshttps://voidpoint.io/terminx/eduke32/-/issues2022-03-09T22:36:14-08:00https://voidpoint.io/terminx/eduke32/-/issues/228Polymost: Interlacing effect on overlapping sprites with TSPR_FLAGS_DRAW_LAST...2022-03-09T22:36:14-08:00Dino Bollingerdino.bollinger@gmail.comPolymost: Interlacing effect on overlapping sprites with TSPR_FLAGS_DRAW_LAST setcstat 1024 is supposed to enable `TSPR_FLAGS_DRAW_LAST`, meaning that with two overlapping sprites, the one with the flag set should be drawn over the one that doesn't have the flag. (correct me if this is wrong.)
As of commit 9a2a8c3e ...cstat 1024 is supposed to enable `TSPR_FLAGS_DRAW_LAST`, meaning that with two overlapping sprites, the one with the flag set should be drawn over the one that doesn't have the flag. (correct me if this is wrong.)
As of commit 9a2a8c3e , sprites that overlap now produce an interlacing effect, where both sprites are partially drawn over each other. Note that this effect is much more noticeable ingame as the interlacing rapidly flickers over the sprite:
![duke0003](/uploads/72e11e9eb99b6ade72e241bb6fa4eadf/duke0003.png)
In older versions this worked correctly, with no visual artifacts:
![duke0000](/uploads/bff58bfefb24df4e4a14af89d3c84e9e/duke0000.png)
Here's a test map and CON file to test the effect:
[cstat1024_test.zip](/uploads/4b0d6d88f5023a78bef2372b195fdca9/cstat1024_test.zip)https://voidpoint.io/terminx/eduke32/-/issues/227Duke3D: Parsing for negated CON labels does not work properly2022-03-09T22:34:32-08:00Dino Bollingerdino.bollinger@gmail.comDuke3D: Parsing for negated CON labels does not work properlyWhile it is currently possible to negate gamevars (and constant integers) inside CON statements as such:
```
mul temp1 -temp2
```
The same is not possible for labels. The following code will throw a warning in the console, indicating th...While it is currently possible to negate gamevars (and constant integers) inside CON statements as such:
```
mul temp1 -temp2
```
The same is not possible for labels. The following code will throw a warning in the console, indicating that the label is being interpreted as a constant due to the negation that's placed in front:
```
define TEST 10
var temp 20 0
onevent EVENT_ALTFIRE
set temp -TEST
al temp
endevent
```
Console output after pressing Altfire:
```
CONLOGVAR: L=6 temp (Global) =0
```
Not only does the parsing fail, it also produces a completely unexpected value.https://voidpoint.io/terminx/eduke32/-/issues/226Automap frame pacing problem2022-02-15T10:59:09-08:00NY00123Automap frame pacing problemI recall beginning to notice it around the time the Polymer-related changes from the last few months were introduced (originally in the dev branch).
It isn't consistently reproduced, but it doesn't seem to depend on the renderer. When o...I recall beginning to notice it around the time the Polymer-related changes from the last few months were introduced (originally in the dev branch).
It isn't consistently reproduced, but it doesn't seem to depend on the renderer. When observed, this is the case while changing APLAYER's angle or zooming the map, but probably not while moving APLAYER without turning.https://voidpoint.io/terminx/eduke32/-/issues/222Engine: Compiling with the included Visual Studio project uses signed char, b...2022-03-09T22:36:14-08:00Dino Bollingerdino.bollinger@gmail.comEngine: Compiling with the included Visual Studio project uses signed char, but unsigned char is requiredIf the binary is compiled using the included Visual Studio project, it compiles `char` as a signed 8 bit integer. However, the assumption made in the code is that `char` is unsigned. This probably affects the entire codebase, but in part...If the binary is compiled using the included Visual Studio project, it compiles `char` as a signed 8 bit integer. However, the assumption made in the code is that `char` is unsigned. This probably affects the entire codebase, but in particular, the caching system is broken by this issue:
```cpp
enum cachelock_t : char
{
CACHE1D_FREE = 1,
CACHE1D_UNLOCKED = 199,
CACHE1D_LOCKED = 200,
CACHE1D_PERMANENT = 255,
};
```
Because the enum values are all greater than 127, all values except `CACHE1D_FREE` will be negative if compiled with VS.
One observable effect is that per-map art will never load:
```cpp
// Tiles having dummytile replacements or those that are
// cache1d-locked can't be replaced.
if (faketile[i>>3] & pow2char[i&7] || walock[i] >= CACHE1D_LOCKED)
{
initprintf("loadpics: per-map ART file \"%s\": "
"tile %d has dummytile or is locked\n", fn, i);
kclose(fil);
return -3;
}
```
Since walock[i] is initialized to 0, this conditional will likely return true, preventing the mapart from replacing the tile.https://voidpoint.io/terminx/eduke32/-/issues/218Missing Feature: Voxel support for Polymer2022-03-09T22:36:14-08:00Dino Bollingerdino.bollinger@gmail.comMissing Feature: Voxel support for PolymerCurrently with r9805 (76b84216), voxels are supported in Classic and Polymost, but are not supported in Polymer. (was never supported in the past)
I'm recording this as Polymer has seen some progress again recently, and so it's not forg...Currently with r9805 (76b84216), voxels are supported in Classic and Polymost, but are not supported in Polymer. (was never supported in the past)
I'm recording this as Polymer has seen some progress again recently, and so it's not forgotten.https://voidpoint.io/terminx/eduke32/-/issues/216Polymost : severe HRP drawing issue2022-03-09T22:36:14-08:00LeoDPolymost : severe HRP drawing issueIntroduced by b6740a7b3 (doesn't compile) or e67e5391e. When using the HRP + Polymost renderer, many sprites are not drawn, partly based on the viewing angle. (Polymer is OK.) Setting "r_models 0" 'repairs' that, but messes up the former...Introduced by b6740a7b3 (doesn't compile) or e67e5391e. When using the HRP + Polymost renderer, many sprites are not drawn, partly based on the viewing angle. (Polymer is OK.) Setting "r_models 0" 'repairs' that, but messes up the former models. (I had rather expected r_hightile to make a difference.) Blatant example map (convenient start point): [RUSHtest.map](/uploads/03a690cfb42ae3dd536a58aa2244cf50/RUSHtest.map). Logfile: [RUSHtest.log](/uploads/7cddea837f98a6174abe9cda6070f558/RUSHtest.log).
Screenshots (Polymer, Polymost, Polymost with r_models 0): ![RUSHtest-Polymer](/uploads/07117f7a3a58c16760359809f119c1e4/RUSHtest-Polymer.jpg) ![RUSHtest-Polymost](/uploads/3a6d0d0941ad02a4d3aeb353a7fa673a/RUSHtest-Polymost.jpg) ![RUSHtest-Polymost-r_models_0](/uploads/7b884144caecef8556ca2d7d32f8be2b/RUSHtest-Polymost-r_models_0.jpg)https://voidpoint.io/terminx/eduke32/-/issues/208SW mouse aiming regressions2022-01-28T04:34:45-08:00NY00123SW mouse aiming regressionsBoth regressions were originally reported in the Duke4.net Discord.
The most significant one, making mouse aiming quite slow, was a side-effect of b51b553460b711b6965dda2e18e37b696312e191.
An earlier commit which also made aiming slowe...Both regressions were originally reported in the Duke4.net Discord.
The most significant one, making mouse aiming quite slow, was a side-effect of b51b553460b711b6965dda2e18e37b696312e191.
An earlier commit which also made aiming slower, albeit less significantly, was 08d6271dfe4efbe84f4baf46bd324cd624aca6a5.https://voidpoint.io/terminx/eduke32/-/issues/205Exotic crash/freeze with shareware GRP2023-05-21T13:55:00-07:00LeoDExotic crash/freeze with shareware GRPEDuke32 crashes instead of bailing out gracefully, when using the shareware GRP, and a CON file isn't found. The current behaviour has been introduced by svn8178-git4dc2d5bab. The previous behaviour is erroneous as well: a freeze which n...EDuke32 crashes instead of bailing out gracefully, when using the shareware GRP, and a CON file isn't found. The current behaviour has been introduced by svn8178-git4dc2d5bab. The previous behaviour is erroneous as well: a freeze which needs the taskmanager to get rid of. Bisect-compiled to svn5883-gitcc2dfd926. Btw., any idea why the crash.log of my locally compiled exe does not list the according source files?
Attachment: simple 'testsuite' + executables + logs. [shr-grp-crash.7z](/uploads/cca08d6f4fbcd7dcdbb1fafacaadaceb/shr-grp-crash.7z)https://voidpoint.io/terminx/eduke32/-/issues/202Model animations played via action do not obey y-flipping cstat bit2023-05-21T13:54:52-07:00Michelle SleeperModel animations played via action do not obey y-flipping cstat bitAny model that is currently playing an animation via the `action` CON command do not obey the y-flipping cstat bit (4).
The first screenshot is when the model is not playing any action with cstat 4 set, the second is the same model afte...Any model that is currently playing an animation via the `action` CON command do not obey the y-flipping cstat bit (4).
The first screenshot is when the model is not playing any action with cstat 4 set, the second is the same model after it starts playing an action.
I created a very simple test bed here, running the latest EDuke32 as of this submission:
https://forums.duke4.net/topic/11815-eduke32-flipped-models-not-showing-correctly/page__view__findpost__p__365200
I did test x-flipping (cstat 8) and it does appear to obey that bit, even when both flipping bits are combined (cstat 12), screenshot 3
![duke0000](/uploads/28f0f7166a566ce2d7f88e9b43345bfc/duke0000.png)
![duke0001](/uploads/2b6204b617ec5a24664d505bee34c468/duke0001.png)
![duke0002](/uploads/18c32b9dbb29bc6bef3216dde71a85e3/duke0002.png)https://voidpoint.io/terminx/eduke32/-/issues/201M32: Opening console on quit prompt kinda sucks2023-05-21T13:54:30-07:00Max YlitaloM32: Opening console on quit prompt kinda sucksi.e.
- Go to 3D mode
- Press `ESC` for the quit prompt
- Press the official `consolebutton`
You will be stuck, unable to interact with quit dialogue as you have an invisible console open.
This continues until you press the official `co...i.e.
- Go to 3D mode
- Press `ESC` for the quit prompt
- Press the official `consolebutton`
You will be stuck, unable to interact with quit dialogue as you have an invisible console open.
This continues until you press the official `consolebutton` again.https://voidpoint.io/terminx/eduke32/-/issues/200Animating logo may be shown with the wrong palette2023-05-21T13:52:42-07:00NY00123Animating logo may be shown with the wrong paletteThis currently applies to the wip branch; Reproduced on Ubuntu 20.04 in case the game is started with the desktop resolution set as the window size, but with fullscreen being toggled off.
The problem was reproduced with the Classic and ...This currently applies to the wip branch; Reproduced on Ubuntu 20.04 in case the game is started with the desktop resolution set as the window size, but with fullscreen being toggled off.
The problem was reproduced with the Classic and Polymost renderers altogether.
It might be a side-effect of problems related to resizable and/or maximized windows, as described in issue #199.
![duke0000](/uploads/7354197ad51d39c6cc3634e485e171b7/duke0000.png)Richard Gobeillerichard@voidpoint.comRichard Gobeillerichard@voidpoint.comhttps://voidpoint.io/terminx/eduke32/-/issues/199SDL_SetWindowSize should probably not be used at all if the window is resizable2023-09-01T14:53:32-07:00NY00123SDL_SetWindowSize should probably not be used at all if the window is resizableThis is mostly relevant to the wip branch as of writing this. I'm not sure this can be reproduced on Windows.
To explain the problem in question:
- A resizable non-fullscreen window may be created, and its size might be set to be relati...This is mostly relevant to the wip branch as of writing this. I'm not sure this can be reproduced on Windows.
To explain the problem in question:
- A resizable non-fullscreen window may be created, and its size might be set to be relatively large by the user; Say, the desktop resolution.
- The window manager, say in Ubuntu, may decide to make the window maximized as a consequence.
- Therefore, when the user attempts to set a lower window resolution later, SDL_SetWindowSize will fail, as the window is maximized.
- Despite this, SDL_GetWindowSize may still report the user's last choice afterwards, rather than the actual window dimensions.
This issue might be related, albeit it's for macOS: https://github.com/libsdl-org/SDL/issues/3217Richard Gobeillerichard@voidpoint.comRichard Gobeillerichard@voidpoint.comhttps://voidpoint.io/terminx/eduke32/-/issues/196SW: Occasionally missing menu sounds2021-09-14T11:36:45-07:00NY00123SW: Occasionally missing menu soundsThis possibly became more noticeable after the migration from rand/RAND_MAX to wrand/WRAND_MAX, but it could occur beforehand.
The main reason is the way menu code decides if to play a sound in `MNU_OrderCustom`, `MNU_UpLevel` or `MNU_D...This possibly became more noticeable after the migration from rand/RAND_MAX to wrand/WRAND_MAX, but it could occur beforehand.
The main reason is the way menu code decides if to play a sound in `MNU_OrderCustom`, `MNU_UpLevel` or `MNU_DoMenu`. Pressing on up/down is a good example of this.
After calling `PlaySound`, a voice handle is returned and written to a static local variable. Before calling `PlaySound` again at the same spot, it is checked if the sound given by the handle is still active.
Problem is, the voice handle may later get invalidated, or become reused for a totally different sound.
The problem is more noticeable than with DOS version 1.2 due to changes to `MV_AllocVoice`. EDuke32's current implementation tries to use MV_MINVOICEHANDLE as the first candidate. In case it's already used, it continues to increment a local voice handle variable in a cyclic manner, until an unused voice handle is found.
The original implementation, however, stores the last assigned voice handle into a global variable named `MV_VoiceHandle`. Upon calling `MV_AllocVoice`, it begins the scan from the following handle value, rather than MV_MINVOICEHANDLE.
While reverting the behaviors in `MV_AllocVoice` should resolve the problem, a proper solution should involve a reset of the handles in SW's menus. This is expected to require moving their definitions out of the function bodies, possibly into a centralized struct.https://voidpoint.io/terminx/eduke32/-/issues/195Duke3D: CON_PALFROM with an intensity between 64 and 127 originally inverted ...2023-05-21T13:50:42-07:00Dino Bollingerdino.bollinger@gmail.comDuke3D: CON_PALFROM with an intensity between 64 and 127 originally inverted the screen colors in DOSA very interesting difference to DOS recently discovered by DragonLiner in the Addons Compilation thread:
https://forums.duke4.net/topic/7640-release-eduke32-addon-compilation/page__view__findpost__p__364568
In DOS Duke 1.5, if one us...A very interesting difference to DOS recently discovered by DragonLiner in the Addons Compilation thread:
https://forums.duke4.net/topic/7640-release-eduke32-addon-compilation/page__view__findpost__p__364568
In DOS Duke 1.5, if one uses the `palfrom` CON command with an intensity between 64 and 127 (inclusive), the game used to invert the colors displayed on screen, at least if a white RGB color was specified. Example command: `palfrom 127 63 63 63`
This property was carried over into eduke32, and lasted until r1623. Then, somewhere between r1623 and r1637, a change was made that disabled this behavior. Further bisection was not possible due to game crashes, but by analyzing the changes between these commits, I have come to the conclusion that it most likely originated from r1625 (bb45b28c201d498e153af3b28f448ff66458a917), based on the following diff:
```
-void G_FadePalette(int32_t r,int32_t g,int32_t b,int32_t e)
{
- int32_t tc;
- setpalettefade(r,g,b,e&127);
+void G_FadePalette(int32_t r,int32_t g,int32_t b,int32_t e)
+{
+ setpalettefade(r,g,b,e&63);
+
```
As you can see, after r1625, the intensity value (`e`) passed on to `setpalettefade()` was AND-ed by 63, rather than 127, thus reducing the maximum value the function would take to 63. The commit message indicates that this was a refactoring commit, and as such the change was likely unintentional.
This effect only existed in Classic mode, and not in Polymost. Unfortunately, Zaxtor used it in the Oblivion TC, as discussed in the thread linked above.
Moreover, the behavior of palettefade was later changed such that if the intensity is set above 63, the screen would simply remain at the maximum color value for a longer period of time, rather than inverting it, up to a maximum intesity of 255. Reverting the change would now break mods that rely on the new behavior.
As such, I believe this isn't really an issue that can be fixed, but it does deserve documentation.
Here's a video to demonstrate:
https://www.youtube.com/watch?v=lipxVnpSqi8https://voidpoint.io/terminx/eduke32/-/issues/194Duke3D: CON_SHOWVIEW results in a black screen when used in Polymer2023-05-21T13:50:13-07:00Dino Bollingerdino.bollinger@gmail.comDuke3D: CON_SHOWVIEW results in a black screen when used in PolymerAs the title says, as of commit bb01a139, while using the Polymer renderer, the `showview` command correctly renders the screen you define, but it results in the main camera view being entirely black.
Here's a small test script that dis...As the title says, as of commit bb01a139, while using the Polymer renderer, the `showview` command correctly renders the screen you define, but it results in the main camera view being entirely black.
Here's a small test script that displays a rear view window on the top left. Works properly in Classic and Polymost, breaks in Polymer:
[rearview.con](/uploads/e70e3d492025ccfe5459a912c3cd9b3c/rearview.con)https://voidpoint.io/terminx/eduke32/-/issues/190Polymer: HUD models are not affected by the chosen FOV, and are rendered too ...2023-05-21T13:50:01-07:00Dino Bollingerdino.bollinger@gmail.comPolymer: HUD models are not affected by the chosen FOV, and are rendered too close to the screenThis issue affects HUD 3D models such as the ones used by the HRP, and was introduced in r7329 (afdc7b52).
In Polymost, if the player increases the chosen FOV, the 3d model weapon will be drawn further away from the camera position, whi...This issue affects HUD 3D models such as the ones used by the HRP, and was introduced in r7329 (afdc7b52).
In Polymost, if the player increases the chosen FOV, the 3d model weapon will be drawn further away from the camera position, while in the case of Polymer the weapon remains at the same relative distance to the camera. Additionally, in r7329, the default position of the 3d model was moved closer to the camera in Polymer, breaking existing mods such as the HRP.
The following images show the model position at an FOV of 120. Note that in Polymost this works correctly, while in Polymer the 3D Model position is the same relative to the player, as if it were a 2D sprite. In Polymer the position is roughly equivalent to a FOV of 70.
This is probably a case of it just not having been implemented, rather than something introduced by that commit directly. The commit just exposes the problem.
Polymost:
![duke0131](/uploads/ac8a444fe814b8571ed2610051337c3e/duke0131.png)
Polymer:
![duke0132](/uploads/8b1ab375888147ba1c98bec425ace146/duke0132.png)
Test files: [pistol_hrp.zip](/uploads/2c672ed003cdc5db93d29c9cd0bf5a17/pistol_hrp.zip)https://voidpoint.io/terminx/eduke32/-/issues/189Duke3D: Maphack lights do not show up when changing from Polymost to Polymer2023-05-21T13:49:48-07:00Dino Bollingerdino.bollinger@gmail.comDuke3D: Maphack lights do not show up when changing from Polymost to PolymerThis only seems to be affecting the maphack lights. The same test map as in #173 can be used, and the effect is the same, so I will keep this issue short.
[maphack_bug.zip](/uploads/53ce771711d6767d77f6a97a6c54c4d3/maphack_bug.zip)
Sim...This only seems to be affecting the maphack lights. The same test map as in #173 can be used, and the effect is the same, so I will keep this issue short.
[maphack_bug.zip](/uploads/53ce771711d6767d77f6a97a6c54c4d3/maphack_bug.zip)
Simply load up E1L1 in Polymer, change the renderer to Polymost, and then back to Polymer again. You will notice that the floor texture renders flat now, indicating that the lights added by the maphack have disappeared. This does not affect any point or spotlight sector effectors, nor any lights emitted by sprites.https://voidpoint.io/terminx/eduke32/-/issues/187Duke3D: inconsistency with "bind" console command and the mouse controls2023-05-21T13:48:46-07:00Dino Bollingerdino.bollinger@gmail.comDuke3D: inconsistency with "bind" console command and the mouse controlsIt appears that using the `bind` console command to set up mouse controls assigns a hidden gamefunc to the mouse button that does not replace the binds in the mouse config menu, but instead takes precedence over them.
For instance, go t...It appears that using the `bind` console command to set up mouse controls assigns a hidden gamefunc to the mouse button that does not replace the binds in the mouse config menu, but instead takes precedence over them.
For instance, go to the mouse config and set the "Left" action to "Move Forward". Then go ingame, type `bind mouse1 gamefunc_fire` in the console, then click the left mouse button. You will notice that you now have primary fire assigned to the left mouse button, but if you visit the mouse config, the menu will still state that it is assigned to "Move Forward".
Moreover, typing `unbind mouse1` removes the `gamefunc_fire` keybind, but leaves the "Move Forward" keybind active.
This is potentially a leftover from older eduke32 builds, as the "mouse1" bind is actually written into "settings.cfg" if defined this way, while the mouse bindings seen in the menu are written to "eduke32.cfg".https://voidpoint.io/terminx/eduke32/-/issues/184Duke3D: Activating a door while opening causes the sound to play at the wrong...2021-08-03T02:33:11-07:00Dino Bollingerdino.bollinger@gmail.comDuke3D: Activating a door while opening causes the sound to play at the wrong timeThis is an issue that originates from DOS Duke3D.
Hitting "use" on a door that is in the process of opening will cause the sound to play at the endpoint of its motion, instead of on activation. Moreover, if this sound is set to loop, it...This is an issue that originates from DOS Duke3D.
Hitting "use" on a door that is in the process of opening will cause the sound to play at the endpoint of its motion, instead of on activation. Moreover, if this sound is set to loop, it will continue playing indefinitely after the door stopped moving.
[doorsound_bug2.map](/uploads/7c09def7c39ce9f7e5530efd9acb1fd5/doorsound_bug2.map)https://voidpoint.io/terminx/eduke32/-/issues/183Duke3D: Jump-crouch exploit still possible in certain areas2023-05-21T13:48:22-07:00Dino Bollingerdino.bollinger@gmail.comDuke3D: Jump-crouch exploit still possible in certain areasI mentioned this on Discord, and I'm aware that this is tough, maybe impossible to resolve -- but I wanted to document it anyways.
The original jump-crouch exploit from DOS involved holding both crouch and jump during landing, thus bein...I mentioned this on Discord, and I'm aware that this is tough, maybe impossible to resolve -- but I wanted to document it anyways.
The original jump-crouch exploit from DOS involved holding both crouch and jump during landing, thus being able to pass through incredibly tight spaces. The severity of this has been reduced, however it is still possible to get into certain passages by jumping and holding crouch when landing. Unfortunately, these are usually shrinker passages.
Demonstration (E2L11): https://cdn.discordapp.com/attachments/461290354726010891/870759546459664424/2021-07-30_22-06-40.mp4
Another instance of this can be found in E5L4 (Mirage Barrage) of World Tour, which also involves a shrinker puzzle:
![duke0004](/uploads/387d0fa79362e69c46a01c30217ed696/duke0004.png)
Note that by simply crouching, it is not possible to enter these passages.