Skip to content

Update the menu logo and Windows application icon - #92

Closed
Rokk001 wants to merge 3905 commits into
tomluchowski:shaders-improvementfrom
Rokk001:pr/application-branding-complete
Closed

Rokk001 wants to merge 3905 commits into
tomluchowski:shaders-improvementfrom
Rokk001:pr/application-branding-complete

Conversation

@Rokk001

@Rokk001 Rokk001 commented Sep 8, 2026

Copy link
Copy Markdown

Use the supplied transparent main-menu logo and application artwork, including a multi-resolution Windows executable icon. Keep the existing menu arrangement and resource mechanism.

Depends on #47 for Windows resource packaging. GitHub's comparison includes that prerequisite until it merges; the focused artwork contribution is the final commit. Merge the prerequisite separately and recheck the remaining diff. No matching open issue was identified.

Validation: all seven embedded icon sizes match the ICO payloads and load through the native Windows icon API; the source PNG matches the supplied artwork byte for byte. The Windows x64 Release integration build and runtime preparation passed. The executable was opened as a data resource only; no game launch or other-platform appearance verification is claimed. A separate static-background contribution changes how the menu background is presented.

use command enableZPrePass and then pressCapsLock
New TileVisual types for all the rooms, and tileset.cfg modifed to allow proper config of neighbouring tiles, for example for TileVisual::hatcheryRoom the code shall compute the neighbouring index e.g. 1010 and give an appropriate tile
Minor bug not allowing the destruction of rooms also fixed
Upabjojr and others added 25 commits August 15, 2026 08:29
colourizeMaterial() names its colourized copy by appending the colour
suffix to the material it was given, and colourizeEntity() recovers the
original material by cutting the name at a "##" separator. The separator
went away when the Z pre-pass work commented it out of the append (the
outliner and brighter suffixes use "##" too, and a generic find("##")
strip would eat theirs), so every recolour has been cloning the already
colourized material and growing the name by one more suffix:
WoodBridge, WoodBridgeColor_1_, WoodBridgeColor_1_Color_2_, and so on,
one fresh Ogre material per refresh.

A tile that rarely changes colour hides this well enough. Claiming
enemy squares walks right into it: every handover refreshes the tile
and its neighbours, the chain of clones grows by one link each time,
and a few claims in, the cloned material no longer renders - the
square's bridge planks disappear from the map while the server keeps
saying, correctly, that the bridge is there. The claim-a-bridge level
from the review of the square-by-square claiming change shows exactly
that: bridge tiles wink out one by one as the enemy workers dance.

Bring the separator back as "@@", which nothing else uses, so the
recolour replaces the suffix instead of stacking it and never touches
the "##_Outliner"/"##_Brighter" names: colourizeEntity() only ever
serves tile and bridge meshes, and the set of materials stays bounded
at one per (material, seat colour, dig mark, vision) combination.

Verified on ForgottenTreasures2 with enemy workers claiming a bridge:
unfixed, five claimed squares lost their planks within a minute;
fixed, all 27 squares stay drawn through 14 handovers, recoloured to
the claimer's colour, and the material name stays WoodBridge@@Color_2_
instead of growing without bound.

Claude-Session: https://claude.ai/code/session_014hrk8PiEUMgjYJnTxLF2PU
…er-tile


Claim bridges square by square instead of all at once
…material-leak


Stop tile recolouring from stacking material clones until tiles vanish
"Quit Game" in the in-game options never quit the game: it dropped the
player back at the main menu, which is misleading enough that it came
up in the interface review (issue tomluchowski#6). There was no way to leave to
the desktop from inside a game at all short of the window manager.

The button is now labelled "Quit to Menu" and keeps its behaviour, and
an "Exit OpenDungeons" button below it leaves to the desktop, both
through the existing confirmation popup. Which of the two the popup
confirms is remembered when it opens, and the Escape shortcut arms the
menu path, so a confirmation abandoned with "No" cannot make a later
Escape-quit fall out of the program.

Claude-Session: https://claude.ai/code/session_014hrk8PiEUMgjYJnTxLF2PU
Losing the dungeon temple already makes the creatures stop obeying,
but the rest of the game carried on as if nothing had happened: the
keeper kept announcing "we are under attack" (with battle music) for
fights that were no longer the player's business, kept nagging about
missing beds, food, workers, treasury space and an empty skill queue,
and the server kept accepting build and cast orders - a defeated
player could go on summoning workers, which reads as "maybe I can
still come back" when there is no way back (issue tomluchowski#5).

The advisory notifications and the team-fighting alarm now return
early for a player who has lost, and the server refuses room builds,
trap builds and spell casts from one, answering with a clear "You have
been defeated and can no longer give orders" message instead of
silently obeying.

Claude-Session: https://claude.ai/code/session_014hrk8PiEUMgjYJnTxLF2PU
Two camera complaints from the interface review (issue tomluchowski#11), both of
which had been offered as options in the discussion there:

The arrow keys and autoscroll panned at one fixed speed, too fast for
some tastes and unadjustable. The speed cap the camera derives from
its height now goes through a user multiplier, set from a slider on
the settings window's Input tab (10% to 300%, default 100% keeps the
historic speed), applied live while the window is open and saved with
the rest of the input settings.

Zooming moved the camera straight down, and since the camera looks
ahead at an angle, whatever sat in the middle of the screen slid away
while zooming - "zooming in zooms to the bottom instead of the
middle". The zoom now keeps the ground point at the screen centre
fixed: the camera base shifts by the difference of its ground offsets
at the old and new heights, so what you zoom at is what you get. The
height clamps are applied to the target height first so hitting the
floor or ceiling of the zoom range cannot shear the view sideways.

Verified in a running game: the portal at the screen centre stays
centred through a full zoom-in where it previously slid off towards
the bottom, and the new slider shows and applies on the Input tab.

Claude-Session: https://claude.ai/code/session_014hrk8PiEUMgjYJnTxLF2PU
Make the camera pan speed adjustable and zoom towards the screen centre
Every caller of the advisory notifications already tested getHasLost()
before calling, so the guards added inside Player::notify*() were a
second check of the same thing (and the trap handler tested it a third
time after refuseIfDefeated()).

Keep the check in the callee, where it cannot be forgotten, and drop it
from the callers.

Claude-Session: https://claude.ai/code/session_014hrk8PiEUMgjYJnTxLF2PU
…feat


Stop nagging and taking orders from a defeated player
Issue tomluchowski#42 asks for explicit types instead of auto. The fourteen auto
declarations added by the last month's merged changes (room split,
per-tile bridge claiming, the seat tile-state lookup and the console
test) now name their iterator, std::function or Command::Result type.
No behaviour changes.

A CLAUDE.md at the repository root records the rule, along with the
C++11 baseline and the surrounding style conventions, so the assistant
keeps to it in future sessions.
Issue tomluchowski#42 asks for explicit types instead of auto.
Spell out the types that the recent changes had left to auto
With rooms both claimable and destructible, fighters at the spearhead
still reach enemy rooms first and destroy them, so in practice little
changed. RoomsClaimableByEnemies now takes three values: 0 keeps the
historical behaviour (destroy only), 1 allows both, and 2 lets only
workers take a room, tile by tile — rooms in that mode are not
attackable, so fighters skip them when choosing targets, and damage that
bypasses target selection is dropped in Room::takeDamage. The dungeon
temple, which cannot be claimed, stays destructible in every mode since
destroying it is how a player is defeated.
The loadLevel message rebuilt the map with createNewMap, which only
recreates the tiles and trusts whoever started the connection to have
cleared everything else. Any path that broke that promise - pressing
Launch a second time from the same menu screen, or reconnecting after a
failed start - piled a second copy of every creature class, seat and
weapon onto the old ones. The editor then aborted while filling its
Creatures menu, because CEGUI refuses two menu items with the same name:

  CEGUI::AlreadyExistsException : Failed to add Element named:
  Adventurer to element at: EDITORGUI/Menubar/Creatures/PopupMenu4

Clear the map in the handler itself, the same way the newMap message
already does. Also make the editor load menu stop when the server could
not be started instead of connecting to whatever server was already
running; every other menu already returned there.
Let enemy workers claim room tiles (DK2-style), behind a config switch
"Exit OpenDungeons" did not fit the button well, and reads even longer once the
game is called OpenDungeonsPlus. "Exit to System" pairs with "Quit to Menu"
above it and says where the player ends up without assuming they know what an
OS is. The tooltip still spells out that it leaves to the desktop.

Claude-Session: https://claude.ai/code/session_01JiKh7f4nenYBTjhJfAGa3y
The editor's P shortcut refused to ask about any tile the client did not
believe looked like a wave portal, and that belief proved wrong: the check
compared against the tile visual, and the window then never opened at all,
with the "Point at a wave portal" hint shown even over a portal.

The client is only ever told what its tiles look like, never which room
covers them, so it has no reliable way to tell. The server does, and it is
also the only side that knows the waves. So the editor now always asks, and
the server answers with the waves, or with an empty room name when the tile
holds no wave portal, in which case the editor shows the hint.

Claude-Session: https://claude.ai/code/session_01JiKh7f4nenYBTjhJfAGa3y
…ttons


Say what the quit buttons do, and add one that actually exits
The editor offers two rooms of its own, a dungeon temple and a portal, so a
wave portal could only ever be edited in a level that already had one. Add a
third button for it, next to the portal, drawn with the portal's glyph in red
so the two cannot be confused.

Claude-Session: https://claude.ai/code/session_01JiKh7f4nenYBTjhJfAGa3y
…ments


Editor improvements: creature levels, help window, wave portal editing and more
Clear the client game map before loading a level into it
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.

6 participants