Skip to content
Snippets Groups Projects

Software - Fake contrast fix

Closed Sryder requested to merge Sryder/SRB2:fake-contrast-fix into master

Some background: Doom has a simple fake contrast that it applies on walls, but only on walls that are perfectly horizontal or vertical. SRB2 has kept this.

This leads to only very specific walls currently applying this, and when it does apply it can often look very strange in levels because of SRB2 more often using more diagonals for walls. This fixes the fake contrast so that it's applied to all walls based on their angle (walls facing further to the north/south are 1 light level brighter, walls facing further to the east/west are 1 light level darker, and the more diagonals are not changed).

Unfortunately, this too can present some oddities in levels where it obviously wasn't built for it. My recommendations are: decide whether you want this always on, or always off (which would require just removing the parts which do the fake contrast) and go with that. Or add an option to choose between on or off on a per level, and per linedef basis for mappers. Either way, this branch shows a way to enable it on all walls if desired.

Edited by Sryder

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Sryder changed the description

    changed the description

  • Sryder added 1 commit

    added 1 commit

    Compare with previous version

  • Contributor

    NB: Since this was just an experiment on your part, I am not treating this as a serious proposal to be merged in directly and instead commenting on what may need to change technically, especially since otherwise we'd have to have an extremely large discussion probably involving Mystic about the consequences it may have for the game's appearance.

    I figure it's important for me to explain why I did a minusone here when I previously expressed a positive response on Discord.

    This adds a bunch of fixed-point arithmetic to standard line drawing where none currently exist. Given that we're currently having performance issues in some internal maps (which we are working hard to fix...), I cannot condone this branch in its current state.

    (It MAY be feasible to store the value of the extralight calculation on the line_t struct, generated at linedef load time. In this instance, it may actually be more performant than the original, being a single unconditional addition rather than an else clause of increment/decrement. The space impact may need to be assessed, though.)

  • Author Contributor

    Fair, I doubt I'll do anything else to make this better as it was mostly an experiment and demo to show what it being "fixed" would look like.

    That said I still suggest this either be fixed or removed, as it leads to strange results sometimes, especially with SRB2 using a lot more curved geometry than DOOM.

  • I'm sure this has already been said before, but it's kind of unlikely this is going to be merged in any time soon IMO. The idea is interesting of course, but it would change the SRB2 experience a bit too much for 2.1 and perhaps even 2.2 (?). But who knows for after those. =P

    (but for now I won't touch this perhaps)

  • I'm going to close this for the time being. If we have interest in implementing this later on we can always reopen it.

Please register or sign in to reply
Loading