Oleksandr Vlasiuk
114 lines
10 KiB
Markdown
114 lines
10 KiB
Markdown
# Day 8 (продовження): WeaponHudC, ZombieInvasionHudC, InstallBanner-рестайл, шрифт, ротація (2026-08-13)
|
||
|
||
Усе нижче — **ще не закомічено** (тільки `4a22a9b`/`63609ee` в git; це
|
||
робота вже після другого коміту). `npm run export` вже прогонявся раз
|
||
успішно (з побічним авто-встановленням `three.quarks`, бо в `export.cjs`
|
||
своя мережева воркфлоу — див. окремий output_export_browser_en.html).
|
||
|
||
## `WeaponHudC.ts`/`ZombieInvasionHudC.ts` — нові статичні/напівстатичні юайки
|
||
Реалізовані аналогічно `HudC` (окремий контролер на юайку, `init()` з
|
||
`TestSceneC`). Ассети: `ZombiePunk_Icon-Bottom.webp`+`Tool_2.webp` для
|
||
зброї, `REF_1.png` (**насправді webp**, розширення джерела — брехня,
|
||
перевірено по сирих байтах RIFF/WEBP заголовку) для голови зомбі.
|
||
|
||
**ZombieInvasionHudC пройшов кілька раундів фідбеку**:
|
||
1. Спочатку `.zombie-invasion__bar` мав суцільний зелений `background`
|
||
(статично "повний" від t=0) — користувач: "WARNING_FRACTION чомусь
|
||
почався тільки коли шкала повністю заповнилась". Причина НЕ в
|
||
таймінгу (`114000мс з 120000мс` — точно останні 5%, перевірено), а в
|
||
тому, що шкала і так ЗАВЖДИ виглядала на 100% — різницю "майже" vs
|
||
"повна" було неможливо побачити. **Фікс**: реальна заливка
|
||
(`.zombie-invasion__track` з `overflow:hidden` + `.zombie-invasion__fill`,
|
||
росте `width:0%->100%` з `right:0`, стартує в ТОЙ САМИЙ тік з тією ж
|
||
тривалістю, що й голова — їхні межі математично завжди збігаються, без
|
||
пофреймової синхронізації).
|
||
2. Голова мала бути БІЛЬШОЮ за саму шкалу (`0.24 * width` проти
|
||
`0.15 * width` висоти бару) — але `.zombie-invasion__bar` мав
|
||
`overflow:hidden` для заливки, що обрізало б і голову. **Фікс**: голова
|
||
винесена сиблінгом `.zombie-invasion__track` (не її дитиною) — обрізає
|
||
тільки заливку/флеш, не голову.
|
||
|
||
## InstallBanner (SDK-компонент) — свідомо НЕ переписаний, лише CSS-рестайл
|
||
Круглий портрет персонажа + кнопка "INSTALL" знизу — це **не наша**
|
||
юайка, а SDK `InstallBanner` (`node_modules/@hitplay/playable_template`,
|
||
підключений в `beforeResourcesLoadedCb.ts`) з реальним кліком
|
||
(`AnalyticsC.sendDownload()` -> `Template.end()`) і власною
|
||
конфіг-системою (`src/configUIParams/installBanner.ts`, `upload_file`
|
||
+ X/Y/scale-відсотки окремо для portrait/landscape — реальні значення це
|
||
**треті числа** в кожному `values: [min, max, default]`). Користувач
|
||
попросив "уніфікувати" з іншими юайками — явно спитав через
|
||
`AskUserQuestion`, чи переписувати логіку самому, чи тільки CSS —
|
||
**вибрав тільки CSS-рестайл** (безпечний варіант). Додано лише
|
||
адитивні властивості (`filter: drop-shadow`, `-webkit-text-stroke` на
|
||
`.bannerButtonText`) — нічого, що конфліктувало б з інжектованим SDK-стилем.
|
||
|
||
**⚠️ Знахідка: purgecss мовчки вирізає `.bannerButton`, але не `.bannerLogo`/`.bannerButtonText`**
|
||
При білді (не тільки в dev) `purgecss` скановує лише `src/**/*.{js,ts,tsx}`
|
||
+ `**/*.html` на предмет "чи цей клас реально використовується" — а
|
||
`InstallBanner`'s класи призначаються в JS всередині ВЖЕ мінифікованого
|
||
SDK dist-бандла (не в нашому `src/`). Емпірично перевірено в реальному
|
||
білд-виводі (`export/index.html`): `.bannerLogo{filter:...}` і
|
||
`.bannerButtonText{...}` виживають, а `.bannerButton{filter:...}` — ні,
|
||
навіть як окреме правило. Ймовірна причина: мінифікатор пакета
|
||
де-дублював рядок `"bannerButton"` (4 похідні: сам +
|
||
`Holder`/`Img`/`Text`) на спільний префікс, тож він більше не існує
|
||
цілим рядком у бандлі — `"bannerLogo"` (лише 2 похідні) не досяг порогу
|
||
для такої оптимізації. Поза нашим контролем (сторонній пакет) — просто
|
||
не писати CSS-правила під `.bannerButton` окремо, вони будуть мертвим кодом.
|
||
|
||
## `gameFont` нарешті став реальним шрифтом
|
||
`font-family: gameFont, sans-serif` використовувався в `main.css`/`ui.css`
|
||
з самого початку проєкту, але `gameFont` НІКОЛИ не був заведений через
|
||
`@font-face` — тихо відкатувався на дефолтний sans-serif усюди. Користувач:
|
||
"весь юай має використовувати шрифт PassionOne-Black, він у нас є в
|
||
temp". Додано `@font-face` в `main.css` (`src/resources/fonts/PassionOne-Black.otf`)
|
||
під іменем `gameFont` — усі існуючі посилання почали резолвитись сами,
|
||
без жодної іншої зміни. Технічний нюанс: для шрифтів (на відміну від
|
||
`images.ts`/`ConvertToBase64WhenRelease`-паттерна) НЕ треба нічого
|
||
особливого — `assetsInlineLimit: 100000000` в `vite.config.js`
|
||
(через `defineConfigTemplate`) вже інлайнить будь-який `url()` в CSS як
|
||
base64 і в dev, і в білді. Перевірено прямо в білд-виводі (не на око).
|
||
|
||
## `--lvh`/`--lvw` замість сирого `vh`/`vw`/`vmin` — ротація/адаптивність
|
||
Користувач (Day 8 чекліст, "All UI elements must be adaptive to changing
|
||
device rotation"): розвернув екран — нічого не змінилось. **Знахідка**:
|
||
SDK має `OrientationC` (`node_modules/@hitplay/playable_template`), який
|
||
під лок-режимом орієнтації обгортає сторінку в
|
||
`transform: rotate(-90deg)...`, щоб контент лишався візуально портретним
|
||
навіть на фізично горизонтальному екрані. Сирі `vh`/`vw`/`vmin`
|
||
**ігнорують transform батьків** і завжди рахуються від фізичного
|
||
(неповернутого) вьюпорта — тож будь-який розмір у `vh` стає неправильним
|
||
щойно лок реально спрацює. `OrientationC` для цього тримає `--lvw`/`--lvh`
|
||
("логічні" версії, коректно стежать за поворотом; в Adaptive-режимі без
|
||
локу — просто дорівнюють фізичним vw/vh, тобто нічого не коштують) —
|
||
той самий підхід, що вже й в `InstallBanner.ts` (`--lvw` в коментарях
|
||
"physical vw doesn't follow the orientation lock"). Усі `--*-width` в
|
||
`ui.css` тепер `calc(var(--lvh, 100vh) * ratio)`.
|
||
|
||
**⚠️ Важливо**: дефолт в `src/configUIParams/orientation.ts` — **"Adaptive"**,
|
||
НЕ лок. У цьому режимі `--lvh == vh` і фікс вище нічого не змінює
|
||
візуально прямо зараз — це радше "правильно про запас", коли/якщо
|
||
проєкт зрештою поставлять на Portrait Lock (майже неминуче для
|
||
вертикального плейбла). Коли користувач після цього фіксу все одно
|
||
сказав "нічого не змінилось, юайка так само зосереджена в центрі" —
|
||
попросив **медіа-правила** замість покладання на `--lvh`/лок-механізм.
|
||
**Фінал**: кожна з трьох юайок (`resource-hud`/`weapon-hud`/`zombie-invasion`)
|
||
тепер має власний `@media (orientation: landscape) { ... }` блок одразу
|
||
після portrait-правила, що перевизначає `top`/`left`/`right`/`bottom` і
|
||
`--*-width` — незалежно від `OrientationC`/локу, реагує на реальне
|
||
співвідношення сторін вьюпорта. Значення в landscape-блоках зараз лише
|
||
дублюють portrait як стартову точку — **ще НЕ підтверджені користувачем
|
||
візуально**, він вже почав підкручувати `.resource-hud`'s landscape
|
||
`--hud-width` (з `0.09` на `0.19` — бачив у diff, не сам робив).
|
||
|
||
## Стан на кінець цієї сесії
|
||
- Working tree: `src/configUIParams/installBanner.ts` (можливо просто
|
||
line-ending, не досліджував — не моя зміна), `TestSceneC.ts`,
|
||
`main.css`, `ui.css`, `images.ts` — модифіковані; `WeaponHudC.ts`,
|
||
`ZombieInvasionHudC.ts`, `resources/fonts/`, три нові `.webp` — нові.
|
||
**Не закомічено.**
|
||
- `stats.html` — як завжди, build-артефакт, свідомо не в git.
|
||
- Наступний крок, якщо буде запит: підтвердити/підкрутити landscape
|
||
`@media`-значення разом з користувачем, коли він реально побачить це
|
||
на розгорнутому екрані.
|