Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • EDuke32 EDuke32
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 96
    • Issues 96
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 12
    • Merge requests 12
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Richard Gobeille
  • EDuke32EDuke32
  • Issues
  • #195

Closed
Open
Created Sep 03, 2021 by Dino Bollinger@dibollingerDeveloper

Duke3D: CON_PALFROM with an intensity between 64 and 127 originally inverted the screen colors in DOS

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 (bb45b28c), 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=lipxVnpSqi8

Edited Sep 04, 2021 by Dino Bollinger
Assignee
Assign to
Time tracking