Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Heretic: small visual improvements #1117

Merged
merged 6 commits into from
Dec 2, 2023
Merged

Heretic: small visual improvements #1117

merged 6 commits into from
Dec 2, 2023

Conversation

JNechaevsky
Copy link
Collaborator

This is a small collection of small visual improvements. Nothing critical, until you'll see them or know about them. 🙃 To clarify:

1. Weapons drawn 1 pixel too high when player is idle. Fixes notable moving weapon for one pixel down even while small movement/momentum. Formula FRACUNIT / 4 comes directly from Doom and it's working fine.

2. Fix 1px gap between translucent PSPrite and STbar. Fixes missing one pixel line above status bar for translucent columns.

image

3. Allow translucent weapons to be affected by invul colormap. Just a small vanilla oversight, fix does not affect sky of course.

image

@ceski-1
Copy link
Collaborator

ceski-1 commented Dec 1, 2023

For (2), does the translucency effect in Heretic depend on the pixels above or below the current one (like fuzz) or is that just left over from the Doom code? The reason I ask is that I encountered a similar problem for Strife and the fix was very simple.

@JNechaevsky
Copy link
Collaborator Author

Oh, it does, really seems to be a leftover. Thanks @ceski-1, your approach is far simpler.

@JNechaevsky
Copy link
Collaborator Author

I also added smooth flat scrolling code from Crispy Hexen. Thanks @mikeday0, this implementation is far simpler and better than one I wrote few years ago, as no external calculations and assumed speeds are needed, and it works fine with 36-59 fps.

However, unlike Hexen, here in Heretic visual scrolling effect is limited to east only direction. Should I keep it such conservative way, or should I extend scrolling to any direction? Really don't know which is better. 🫢

@JNechaevsky
Copy link
Collaborator Author

Scrolling is any direction is possible, but almost immediately this happens:

image

This is because of Raven's scrolling implementation itself is not exactly "scrolling", but reading flat lump contents, shifting it and adding interpolated offsets in uncapped mode. And that's why flowing water flats are having 65x64 size. To fix it, lump contents must remain same, and instead scrolling offsets must be shifted. Doable, but will require some extra work like proper speed formulas and external scroll deltas, since we need to modify offsets not every frame tic, but every game tic. This could also fix barely notable jittering effect when flat passes full 64 pixel scroll.

However, I have double checked GZDoom, and only east-direction scrolling is implemented there, so probably it is worth to leave scrolling "as is" for some mapping and cross-port standards. Jittering is barely noticeable and literally requires starring to scrolling texture.

Guess it's all done in this PR.

Small idea for future: externalize fractionaltic to v_video.h. All four games now have uncapped framerare, and it's scattered a lot in heretic/hexen .c files as extern fixed_t fractionaltic.

Copy link
Owner

@fabiangreffrath fabiangreffrath left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very welcome additions, thank you very much!

@fabiangreffrath
Copy link
Owner

Re fractionaltic: yes, please.

@JNechaevsky JNechaevsky merged commit dcb8585 into master Dec 2, 2023
6 checks passed
@JNechaevsky JNechaevsky deleted the htic_improve branch December 2, 2023 16:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants