Окно, холст и Layout

Первый шаг к порядку в голове — разделить три величины, которые в разговоре все называют словом «размер». Первый — размер окна операционной системы в device-independent пикселях: именно его движок передаёт в Layout как outsideWidth и outsideHeight. Второй — логический размер холста вашей игры: то, что Layout возвращает, и то, в каких координатах живёт ваш Draw. Третий — физические пиксели монитора, которых на HiDPI-экране в два или полтора раза больше, чем логических точек; ими движок занимается сам. Документация формулирует контракт аккуратно: Layout принимает внешний размер в device-independent пикселях и возвращает логический размер экрана; масштаб от холста к итоговому окну движок подбирает автоматически.

Зачем нужен этот средний слой — логический холст? Затем же, зачем художник рисует кадр фиксированного формата: геймплей не должен зависеть от того, развернул ли игрок окно на весь 4K-монитор или запустил в уголке ноутбука. Вы проектируете игру в своих координатах, а проблему «как это вписать в произвольное окно» решает движок. Плата за удобство — необходимость понимать, что screen в Draw — это не окно ОС: когда вы захотите узнать «размер экрана», сначала решите, какой из трёх размеров вам на самом деле нужен.

Layout — самый короткий метод интерфейса ebiten.Game, и в нём больше решений, чем кажется. Два полюса. Полюс первый — фиксированный холст: return 320, 240 в любом случае, что угодно творится с окном. Это выбор пиксель-арт игр: пропорции стабильны, масштаб предсказуем, координаты никогда не меняются. Полюс второй — резиновый холст: return outsideWidth, outsideHeight, и тогда ваша игра получает в Draw столько же места, сколько занимает окно. Так делают стратегии и головоломки с интерфейсом, который должен растягиваться вместе с окном.

Между полюсами есть и компромиссы: возвращать outside, поджатый под минимальную ширину, или фиксированную высоту с плавающей шириной. Два технических факта завершают контракт. Layout вызывается почти каждый кадр — это не одноразовая настройка, поэтому тяжёлые вычисления внутри него дурной тон. А возврат неположительных чисел недопустим: документация предупреждает, что вызывающий код может запаниковать, — холста размером ноль не бывает. Из тех же документов следует и гарантия первого кадра: Layout вызывается до первого Update, поэтому даже расчётный холст уже знает свои размеры, когда логика делает первый шаг. Обратите внимание и на сигнатуру: из трёх методов интерфейса только Layout не возвращает ошибку — ему нечего сообщать о сбое, он описывает мир, а не выполняет рискованную работу. Для тонких случаев с дробными размерами существует и float-версия интерфейса LayoutF: она подключается отдельным интерфейсом LayoutFer, о котором знать достаточно, пока вы не упёрлись в полупиксельные границы.

Что происходит между холстом и окном? Движок считает масштаб: во сколько раз логические пиксели вырастают до размеров окна. Окно 640 на 480 при холсте 320 на 240 даёт масштаб ровно два — и это идеальный случай для пиксель-арта: каждый логический пиксель становится аккуратным квадратом два на два. Стремитесь к таким целым множителям: делайте окно кратным холсту через SetWindowSize или холст кратным ожидаемому окну. Когда пропорции не совпадают — скажем, окно 640 на 400 при холсте 320 на 240, — движок вписывает холст в окно, сохраняя пропорции картинки, и лишнее место окна остаётся незанятым.

Нецелый масштаб — тихий враг пиксель-арта. При множителе 1,5 один логический пиксель то занимает два физических, то один, и на экране появляются пиксели разной толщины — «грязная» картинка, в которой художник узнаёт свой арт с трудом. Движок при этом ничего не предупредит: он честно отрисует дробные пиксели, и заметить размытость можно только глазами на реальном мониторе — скриншоты, пересжатые браузером, артефакт легко скрывают. Отсюда практическое правило ретро-игр: выбирайте холст так, чтобы он делил типовые окна без остатка, 320 на 240 и 640 на 360 — проверенные классики. А если окно меняет размер, движок пересчитывает масштаб на лету: Layout вызывается почти каждый кадр именно поэтому.

По умолчанию окно Ebitengine имеет фиксированный размер: пользователь не может его растянуть мышью. Разрешение даёт ebiten.SetWindowResizingMode: режим WindowResizingModeEnabled разрешает менять размер за рамку, режим по умолчанию WindowResizingModeDisabled запрещает, а WindowResizingModeOnlyFullscreenEnabled разрешает только переключение в полноэкранный режим — последний работает, как честно говорит документация, пока только на macOS. Включённый ресайз не отменяет ваш Layout: вы по-прежнему решаете, холст ли следует за окном, или окно вписывает фиксированный холст. Отключить рамку окна целиком умеет отдельная функция SetWindowDecorated, а лимиты min и max для ресайза ставит SetWindowSizeLimits.

Полноэкранный режим — пара IsFullscreen и SetFullscreen: вторая принимает true или false и переключает режим в любой момент, хоть из Update по нажатию F11. Здесь спрятана ловушка, о которой документация предупреждает прямо: WindowSize продолжает возвращать исходный размер окна даже в фулскрине — размеры монитора дают Monitor().Size(), а целевое разрешение для честного фулскрина считает ScreenSizeInFullscreen. Если игра должна заполнять весь экран без полей, спросите ScreenSizeInFullscreen и подстройте Layout под неё — это ровно тот случай, когда Layout стоит сделать расчётным, а не фиксированным.

Последний слой — плотность пикселей. На Retina-экране одна логическая точка занимает два физических пикселя, и это отношение называется device scale factor. Движок применяет его автоматически: картинка рендерится в полную физическую плотность, и на 2x-экране выглядит резко. Спросить текущий множитель у кода можно через Monitor().DeviceScaleFactor(); историческая пакетная функция ebiten.DeviceScaleFactor считается устаревшей с версии 2.6 — в старых туториалах вы встретите именно её, так что знайте обе.

Зачем этот множитель вручную? Для режима повышенной чёткости пиксель-арт-игр. По умолчанию резкий пиксель-арт на Retina может выглядеть замыленным: движок масштабирует холст с учётом дробных множителей окна. Официальный рецепт из FAQ: пусть Layout вернёт outside, умноженный на device scale factor, — тогда холст совпадёт с физическими пикселями, и картинка станет пиксель-в-пиксель; готовый пример так и называется highdpi. На мониторах без HiDPI множитель просто равен единице — рецепт от этого не ломается, просто ничего не умножает. Плата за высшую чёткость — больше работы на кадр, поэтому в браузерных сборках есть и обратная опция DisableHiDPI, отключающая HiDPI-рендер ради производительности. Решайте по своей игре: арты с крупным пикселем обычно выигрышнее выглядят с честным масштабом и целыми множителями.