Tint room floors with the owning seat's colour - #37
Open
Upabjojr wants to merge 1 commit into
Open
Conversation
One could not tell whose room a square was by looking at it: claimed ground carries its owner's colour, but a room floor looked the same whoever it belonged to, with only incidental hints like the shields on the training hall walls. Now that bridges change hands square by square - and rooms may follow - ownership has to be readable at a glance, per square. Room.frag, the fragment shader behind every room floor material, gains a seatColor uniform and blends the floor texture halfway towards the owner's colour. The stock material never sets the uniform and OpenGL zero-initialises uniforms at link time, so its alpha of zero keeps the tint off there; the per-seat clone RenderManager::colourizeMaterial already builds for claimed tiles sets it, exactly as it does for the claimed-ground cross pattern. Tile::shouldColorTileMesh() now lists the room visuals so those clones get made, and colourizeMaterial checks that a material's fragment program actually takes a seatColor before setting it, so a floor material that has not been taught the tint renders untinted instead of raising an exception. Treasury - also the dungeon temple's floor - was the one floor still on the fixed-function RTSS path with no shader to put a tint in, so it moves onto the shared Room shaders like every other room floor. Verified on a two-keeper level: in the editor, seat 1's temple and treasury floors shade red where seat 2's shade green; in a skirmish the local keeper's floors carry their colour under normal lighting and fog, with no material errors in the log. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014hrk8PiEUMgjYJnTxLF2PU
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses the concern raised on #35: "one cannot visually estimate which room belongs to whom when playing game". This makes room ownership readable at a glance, per square — which matters already today (enemy rooms seen through vision all look alike) and becomes essential if rooms ever change hands square by square.
How: the engine already has the machinery — claimed ground gets a per-seat material clone whose
seatColoruniform tints the cross pattern. This PR extends it to room floors:Room.frag(the shader behind every room floor material) gains aseatColoruniform and blends the floor texture halfway towards the owner's colour. The stock material never sets it — OpenGL zero-initialises uniforms at link time, so alpha 0 keeps the tint off — while the per-seat clone fromcolourizeMaterialsets it, exactly like the claimed-ground path.Tile::shouldColorTileMesh()now lists the room visuals so those clones get made for room floors.colourizeMaterialchecks that a material's fragment program actually takes aseatColorbefore setting it, so any floor material that hasn't been taught the tint renders untinted instead of raising an Ogre exception.Treasury.material(also the dungeon temple's floor) was the one floor still on the fixed-function RTSS path with nowhere to put a tint — it moves onto the sharedRoom.vert/Room.fraglike every other room floor.Verified on the two-keeper ForgottenTreasures2 level (the one from #34): in the editor, seat 1's temple + treasury floors shade red where seat 2's shade green; in a skirmish the local keeper's floors carry their colour under normal lighting and fog, and the log shows no material errors.
The 0.5 blend weight is one knob to taste — lower keeps more of the original texture, higher shouts the owner louder. Happy to tune it (or switch to the claimed-style cross-pattern overlay instead of a whole-floor tint) if you prefer another look.
🤖 Generated with Claude Code
https://claude.ai/code/session_014hrk8PiEUMgjYJnTxLF2PU