KiQ писал: Проверь, нет ли такой фигни в Dedicated server
Дедик не запустится в любом случае, он поломан.
Цитата:
ncuxonaT писал: Нет, не держит. Впрочем, как и другие распространенные форматы
Хы. А вот третьедуумовский Roq - держит. Я об этом узнал совсем недавно. Они его еще использовали в качестве анимированной кубемапы для неба. Спустя 10 лет эта же мысль пришла в голову нашему Рейду.
Цитата:
KiQ писал: а что если рисовать все меню в FBO и потом рисовать его растянутым во весь экран, при этом делая скейл только координат объектов для корректных попаданий мышкой?
Да, это было первое что мне пришло в голову, но. Не взлетит. Для меню важен pixel perfect, а это замылит все шрифты нахрен, кроме виртуального разрешения.
По багам:
Если поменять в графических опциях конфигурацию, то все остальные опции не меняются. Даже если переоткрыть меню. Движок перезапускать не пробовал.
Обрезание в текстовых полях работает некорректно, попробуй вбить много коротких по ширине символов, например l. Иногда съедает последний символ, у меня получилось если забить поле цифрами а потом вводить какой-нибудь широкий символ(например w) и средний (a).
Есть такой же баг как был у меня, нельзя вбить единичку первой в поле max players, сразу на двойку меняет. Получается невозможно сделать сервер на 10-19 игроков.
Чекбоксы иногда странно себя ведут, если два раза на них быстро нажать, он может не отреагировать на второе нажатие.
Если стрелочками переключаться на табличку, то невозможно переключиться на другие.
По UX:
Хорошее меню выбора разрешения. Утащу его себе в форк! :3
У ползунков отсутствует анимация выбора ползунка.
У спинконтролов не работает выбор стрелочками. Получается что можно переключаться только на одну стрелочку и нажимать Enter.
Если свернуть игру кнопкой в меню, то при разворачивании она возвращается на старое место.
Понятно, что всё вышеперечисленное так и должно быть, но это всё же неудобно.
По багам движка:
Движок проигрывает один и тот же семпл, если перетаскивать окно. Получается забавно, учитывая пам-пам-пам в меню, но по-моему так быть не должно.
А если кегль шрифта подбирать деномически в процентном соотношении от высоты экрана? А для вайдскринов я ж говорю, использовать отдельный фбо и свою схему расположения. Но надо ещё подумать
Добавлено 05-05-2020 в 17:40:
Цитата:
a1batross писал: Движок проигрывает один и тот же семпл, если перетаскивать окно. Получается забавно, учитывая пам-пам-пам в меню, но по-моему так быть не должно.
Тот же самый курьез, что и с F10, это не баг движка, это OPENAL артачится, когда фокус с контекста выпадает на хидер виндового окна, а когда ты таскаешь окно, ты как раз мышкой и берёшь в фокус этот хидер
Кстати, насчет масштабирования, а что если рисовать все меню в FBO и потом рисовать его растянутым во весь экран, при этом делая скейл только координат объектов для корректных попаданий мышкой? По идее решит проблему с невлезанием части контента. Ну естественно для widescreen придется перестраивать FBO, но это просто. И тогда, скажем можно будет ограничится двумя файликами с координатами элементов, грубо говоря - для 4:3 и widescreen (16x9, 16:10 большой роли не играет, разница там практически незаметна).
KiQ НЕТ. Нельзя так делать. Попробуй на своём мониторе(с учётом что у тебя LCD монитор) поменять разрешение винды с родного на что-нибудь поменьше. Видишь мыло? Вот и тут так же будет с FBO.
В Android такого нет. Там Device Independent Pixel, грубо говоря логические координаты которые в зависимости от настроек девайса отшакаливаются в физические. Выглядит одинаково вне зависимости от размеров экрана и более того соотношения сторон.
В моём меню примерно точно так же, за baseline я взял высоту экрана в 768px(потому что 1024x768). Разработчик меню всё раскидывает на 768 пикселях, а потом считается скейл по высоте. Тоже выглядит одинаково везде.
OGV это кстати прекрасно. С ним хотя бы можно ориентироваться, что внутри ожидается только Theora/Vorbis, в отличие от AVI, в котором может быть что угодно. Ну так исторически сложилось.
a1batross писал: В моём меню примерно точно так же, за baseline я взял высоту экрана в 768px(потому что 1024x768). Разработчик меню всё раскидывает на 768 пикселях, а потом считается скейл по высоте. Тоже выглядит одинаково везде.
Ну а с вайдскрином то шо делать?
Добавлено 05-05-2020 в 17:50:
a1batross так в форке SDL и созданием окна занимается, может там хэндлеры какие-нибудь хитрые в отличии от WinAPI
KiQ по-хорошему нужен менеджер layout-ов, который автоматически раскидает элементы по экрану исходя из их размера и по тому, как ты хочешь, относительно друг друга, относительно углов, просто по вертикальному/горизонтальному списку. Но это работает в обычном прикладном софте, но не будет в игровых меню, которые просто сами по себе не укладываются в подобную логику.
Если координата X меньше нуля после расчёта становится <ширина экрана> - abs(X). Точно так же и с Y, только там высота.
Добавлено 05-05-2020 в 18:13:
С размерами кстати даже так: если размер отрицательный, то он считается исходя из <ширина экрана> - <реальная координата по ширине> - abs(width). Ну, аналогично для высоты.
a1batross так и не понял, зачем эти отрицательные координаты и их клампинг. Смутно припоминаю, что у меня что-то такое было для UIText в поле ввода, когда нужно было смещать символы влево. Но у меня каждый элемент проходит проверку
C++ Source Code:
1
void checkClipBounds() {
2
if (hasParent()) {
3
if (clip_x < getParent().x) {
4
clip_x = getParent().x;
5
clip_w -= getParent().x - x;
6
}
7
if (clip_y < getParent().y) {
8
clip_y = getParent().y;
9
clip_h -= getParent().y - y;
10
}
11
if (x + clip_w > getParent().getBoundWidth())
12
clip_w = (getParent().getBoundWidth() - x);
13
if (y + clip_h > getParent().getBoundHeight()) {
14
clip_h = (getParent().getBoundHeight() - y);
15
}
16
} else {
17
clip_x = x;
18
clip_y = y;
19
clip_w = width;
20
clip_h = height;
21
}
22
}
Потом значения clip_x, clip_y, clip_w и clip_h пихаем в glScissor, например, и вот уже ненужные части не рисуются
a1batross писал: В моём меню примерно точно так же, за baseline я взял высоту экрана в 768px(потому что 1024x768). Разработчик меню всё раскидывает на 768 пикселях, а потом считается скейл по высоте.
То есть исходные координаты из диапазона 1024x768 представляются в виде процентов от 0 до 100, а потом эти проценты приводятся к целевому диапазону, ну например, 1600x800
Это работает примерно так, или там всё сложнее?