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

Factor out more rendering logic into separate renderers #4538

Merged

Conversation

kwvanderlinde
Copy link
Collaborator

@kwvanderlinde kwvanderlinde commented Dec 7, 2023

Identify the Bug or Feature request

Progresses #3691
Fixes #4429

Description of the Change

Rendering of lights, auras, player darkness, fog of war, vision, and debug shapes are now handled by separate renderer classes. For the most part, logic was simply copied over, but some simplifications and alterations were made.

Points of interest:

  • The new RenderHelper takes care of setting up Graphics2D with initial clips and transforms. It can optionally use a temporary buffer as a render target. Each of the new renderers uses the RenderHelper.
  • Fog rendering case work has been consolidated and simplified to make it a bit more direct in terms of what is happening.
  • The player-specific logic for vision overlays has been eliminated. The clip set there was not used (it was always overwritten prior to use), and the logic was broken anyways due to mixing screen space and world space areas.
  • The debug shape renderer shows that shapes are translucent so they don't completely occlude what is rendered behind it.

Possible Drawbacks

Should be none.

Documentation Notes

N/A

Release Notes

  • More modularization of the zone renderer for fog, lights, and vision.

This change is Reviewable

@kwvanderlinde kwvanderlinde force-pushed the refactor/3691-additional-renderers branch from 9d555fe to aa8202b Compare December 7, 2023 08:49
The `RenderHelper` can be used by renderers to create a new graphics context transformed according to the current zoom
and pan. It can optionally also create a buffer to render as a layer before composing with the background.
`LightOverlayClipStyle` is rmeoved since only `CLIP_TO_VISIBLE_AREA` is ever used. Instead, can check
`PlayerView.isGMView()`.
Commonalities in the case work for these methods were pulled out, and the remaining case work was refactored to be
easier to follow. With this done, the logic for fog rendering fits naturally in a single linear method.
This change involves a few subtleties:
1. The check for `showVisionAndHalo` was moved to the top of the logic so we can avoid expensive geometry manipulation
   when we aren't even going to use it. This also makes the condition more visible to the reader.
2. The clipping logic in `renderPlayerVisionOverlay()` was removed. This clip was broken due to the mixing of world
   space (`ExposedAreaMetaData`) and screen space (`exposedFogArea`). But that didn't really matter since the clip is
   overwritten anyways with a correct version in `renderVisionOverlay()`.
3. Getting the exposed area can be simplified by using ZoneView instead of enumerating the `PlayerView` ourselves. This
   has the nice perk of automatically caching the results.
@kwvanderlinde kwvanderlinde force-pushed the refactor/3691-additional-renderers branch from aa8202b to 17e71aa Compare December 7, 2023 17:30
@bubblobill
Copy link
Collaborator

bubblobill commented Dec 8, 2023

Personal preference, when defining colours, include alpha. That way it's more universally applicable and a little bit future-proofed.
From
palette = new Color[] {Color.red, Color.green, Color.blue};
to
palette = new Color[] {Color.red, Color.green, Color.blue, Color.alpha};

From
var fillColor = color.darker(); fillColor = new Color(fillColor.getRed(), fillColor.getGreen(), fillColor.getBlue(), 76);
to
var fillColor = color.darker(); fillColor = new Color(fillColor.getRed(), fillColor.getGreen(), fillColor.getBlue(), fillColor.getAlpha() / 3f );

@kwvanderlinde
Copy link
Collaborator Author

kwvanderlinde commented Dec 8, 2023

Sure, makes sense, made the change. Though I'll point out palette is just a sequence of colours to cycle through, not itself a color with an alpha.

@kwvanderlinde kwvanderlinde force-pushed the refactor/3691-additional-renderers branch from fc0dd5a to 27e509e Compare December 8, 2023 10:48
This could be refined, but for now is sufficient to render the two shapes supported by ZoneRenderer. It also renders
using a transformed graphics context rather than transforming the shapes when they are set.

Some liberties were taken with the renderer vs the existing behaviour:
1. The renderer supports any number of shapes and just cycles through a palette.
2. The shapes are rendered with an opaque border but a translucent fill so they don't complete obscure what is behind
   them.
@kwvanderlinde kwvanderlinde force-pushed the refactor/3691-additional-renderers branch from 27e509e to a91e9e6 Compare December 9, 2023 07:43
@cwisniew cwisniew added this pull request to the merge queue Dec 9, 2023
Merged via the queue into RPTools:develop with commit 9262ab7 Dec 9, 2023
4 checks passed
@kwvanderlinde kwvanderlinde deleted the refactor/3691-additional-renderers branch December 9, 2023 22:41
@cwisniew cwisniew added the code-maintenance Adding/editing javadocs, unit tests, formatting. label Mar 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code-maintenance Adding/editing javadocs, unit tests, formatting.
Projects
Development

Successfully merging this pull request may close these issues.

[Bug]: Soft FOW outline is rendered overtop hard FOW
3 participants