Apromix писал(а):К примеру, недавно мне случилось запустить DiabloRL на Windows 98 с Pentium 166MX. Тормоза были жуткие, <...> А ведь старкрафт с 4 игроками по сетке бегает шустро даже при макс. лимите 200!
Это вы больно в крайности ударяетесь =) Я нагрузочное тестирование не проводил да и есть пара мест, которые еще можно, если задаться целью, оптимизировать, так что не могу сказать где именно нижний предел системных требований, но Pentium 166MX это явный перебор. На ~1GHz тормозить не будет, далее -- по обстоятельствам. Кроме того, Starcraft и достаточно абстрактная либа написаны по-разному. Во-первых, у меня банально не стоит задача "сделать любой ценой и плевать на суммы и сроки". Во-вторых, ПО тех времен логически строится несколько по-иному. Например тот же текст, как правило, сразу рендерится (хотя скорее всего просто загружается уже подготовленный) в некоторую область памяти, сколько подготовлено, столько и используется, никакого юникода. Для современного ПО является нормой отложенное исполнение: когда происходит вызов terminal_put(0, 0, 0x2560), символ просто заносится в массив. При следующей отрисовке происходит растеризация новых, еще не растеризованных, глифов, если необходимо, переразмерение текстуры, обновление ее в памяти, и только потом сам рендер. Это недолго, на умеренно современном железе это незаметно даже при быстрой перерисовке, но позволяет не тратить память попусту и при этом иметь весь Unicode в распоряжении. Но если перейти некоторую черту, все становится заметно.
Ну и да, забудьте про Windows 98. Я даже не думаю делать поддержку этого. Windows начиная с XP, чуть позже Linux начиная с 2.6.
Apromix писал(а):Чтобы повысить интерес к играм на терминале в нем должно быть реализовано следующее (ну или опиши как это реализовать на существующем терминале)
Эко вас понесло =) Я не с пустого места выбрал слово "terminal" в названии. Вспомни gnome-terminal, PuTTY или cmd.exe, это дает неплохое интуитивное представление того, что именуется терминалом в IT-просторечии. Окно с моноширинным текстовым выводом. Окно с сеткой символов. Плюс-минус немного плюшек типа цвета. Но настоящие терминалы вынуждены развиваться в исторически сложившихся условиях, и выходит, что касаемо бегающей по экрану собачки куда ни ткни, какая-нибудь да заморочка. Вот на этом поле BearLibTerminal и играет. А то, что ты предлагаешь -- это не терминал, а уже больше в сторону полноценного 2D движка. Поэтому я сейчас пробегусь по оглашенному списку и прокомментирую.
Apromix писал(а):Изменение размеров символов. Я не говорю о смешивании шрифтов, хотя это тоже было бы полезно Например, маленькая крыса r имеет размер 8, а обычная крыса r - 10. Или босс кроме того, что он показан большой буковкой, так еще шрифт его крупнее - 12. Литеры должны центрироваться в своей ячейке.
Не будет. В одно время -- один шрифт. Если как-то нужно выделить отдельные объекты, то к вашим услугам:
* Цвет символа целиком.
* Возможность поставить над буквой диакритику другого цвета (белый символ 'a' с красным или зеленым умлаутом над ним). Или не диакритику, а что-то другое.
edit: Не, про диакритику я наверное немного загнул, там положение от обоих символов зависит, так что не все так просто. В наличии же возможность положить в ячейку белый символ 'a', а потом перечеркнуть его красным символом '/'. В некоторых шрифтах типа Fixedsys Excelsior диакритика в наличии, но располагается так, что простым наложением она нормально скомбинируется только с маленькими буквами: a, e, r, u, s и т. д. А в Ubuntu Mono вообще отдельной диакритики нет, только готовые символы типа 'Ű' (U+0170 Latin Capital Letter U With Double Acute) >_<
* Литеры других языков (боссы могут браться из редкой кириллицы (Ѧ), греческого (Ω) или еще какого набора).
* Возможность задать свой шрифт картинкой и уже в нем нарисовать все, что душе угодно.
Apromix писал(а): Изменение фона под литерой. Пример, комманда Look, или прицел для стрелкового оружия.
"Из коробки", просто сейчас дебага ради это выключено. За исключением растеризации TrueType с субпикселизацией, там фон всегда будет черный.
Apromix писал(а):Изменение цвета литеры. Например, существо отравили или заморозили.
"Из коробки", это ты и сейчас в той демке видеть можешь. В распоряжении весь TrueColor.
Apromix писал(а):Использование линий и прямоугольников. Для рамок, красивого отделения текста и прочего. В десе используется часто. Пример, лайфбары над монстрами и героем. Или окно диалога с NPC.
Будет. Я думаю сделаю так, что независимо от выбранного шрифта всегда будет в наличии полный диапазон Unicode Box Drawing (
ссылка).
Apromix писал(а):Мигание литеры, причем регулируемое. Пример, после удара по монстру <...>
Не будет. Таких эффектов можно напридумывать миллион, терминал здесь ни при чем. Если нужна анимация, просто используем terminal_get_nonblocked(1000/25) и обновляем цвета исходя из отрисовки не реже, чем 25 раз в секунду.
Apromix писал(а):Смещение литеры на несколько пикселей в нужную сторону, а затем возврат на место.
Технологически реализуемо, но пока затея мне не нравится. Я подумаю.
Apromix писал(а):Летающие затухающие циферки.
Apromix писал(а):Полет символа от точки А до точки Б по пиксельной прямой, игнорируя сетку символов.
Не будет. Я не уверен насчет реализации статусов и пр., но текста в произвольном месте не будет.
Apromix писал(а):Перемещение существ плавно по сетке, а не скачкообразно, как обычно в рогаликах
Не будет. Во-первых, про произвольное положение написано выше. Во-вторых, сомнительная затея. Плавно тогда должно быть вообще все или выглядеть будет неоднородно.
Apromix писал(а):Расчет освещения сцены. Герой - факел Но еще могут быть источники света и в подземелье. Чем ближе источник света - тем ярче освещен тайл. Согласен, можно выполнить за стенами быблиотеки, но можно перегрузить и на плечи терминала.
Освещение можно задавать сколько вздумается, у каждой ячейки есть цвет фона и символа. Хоть факел, хоть система направленных источников. Но -- руками или другой библиотекой. Это не задача терминала. Кроме того, моделей освещения можно придумать кучу.
Apromix писал(а):Использование графических тайлов или использование букофф. В десе переключается из меню настроек. Тайлсет взят из DwarfFortress.
"Из коробки". Можно TrueType шрифт, можно тайловый из картинки. Из Dwarf Fortress, еще откуда или свой. Со всеми привычными плюшками типа цвета, наложения несколькоих тайлов/глифов на одну ячейку и пр. Со сменой в процессе работы. Но не забываем -- один шрифт в одно время.
Apromix писал(а):Наконец расчет FOV тоже можно запихнуть в терминал (для пс и существ).
Это не задача терминала. Давайте не будем делать из относительно легковесной (в плане интерфейса) и вполне специализированной библиотеки еще один libtcod.
Многое из того, что тобою описано, это уже несколько иного уровня функциональность. Десятью тривиальными вызовами, где все параметры int, уже не сделаешь. Это надо контексты шрифтов, функции их измерения (уже нельзя сказать, что "Hello" займет ровно пять ячеек), форматирования (как вывести "Hello, Apromix" так, чтобы первое слово белым, а второе -- зеленым? а если это надо вписать в прямоугольник с переносом? а выравнивание по левому или правому краю?). Надо или переходить к модели "перерисовка всего каждый кадр" или вводить какие-то механизмы, позволяющие убрать лишь одну из нескольких (возможно, пересекающихся) строк. Для анимированных событий вводить контексты с настройками, таймеры и механизмы отмены. Делать зоны отсечения и Z-уровни (нехорошо будет, если всплывающая подсказка с именем монстра заедет на окно инвентаря при скролле).
Это, так сказать, BearLibViewport =) Но сначала давайте доделаем BearLibTerminal.
edit: Я не говорю, что это невозможно или дико сложно, отнюдь. Тут самая сложная часть -- сделать по возможности минимальный и простой, но обязательно логичный интерфейс всего этого веселья. И чтобы он еще из разных языков легко цеплялся. Если просто накидать вызовов на каждый случай, когда хочется вот именно такой эффект, то и получится невнятная пыжня, в которой с трудом можно сделать что-то кроме этих конкретных эффектов. Если у вас достаточно энтузиазма для долгих дискуссий, то я открыт к диалогу =)
kipar писал(а):Ну, если код более-менее обобщенный, то функция получения события от клавиатуры будет возвращать целиком событие, выполняя все вызовы getstate до начала собственно обработки. <...> И для демки - тоже, как я понимаю, надо хранить очередь всех пришедших от игрока событий, т.е. упаковывать все состояние в свой формат.
Согласен, но мне кажется, что это все-таки пограничный случай. Не вижу ничего противоестественного в том, что для специфичной задачи (реализация адаптера к библиотеке) придется написать немного кода (сам адаптер).