BearLibTerminal - псевдоконсольное окно для рогалика

Форум библиотеки BeaRLib

Модератор: Apromix

Аватара пользователя
kipar
Сообщения: 2120
Зарегистрирован: 10 мар 2010, 13:16
Откуда: Москва

Re: BeaRLibTerminal - псевдоконсольное окно для рогалика

Сообщение kipar » 11 янв 2013, 19:57

Cfyz писал(а):Чуть выше уже ведется спор событийный vs потоковый ввод, сейчас ход kipar
Мне не жалко, если очередь можно будет свести к получению статуса, то все в порядке. Правда не совсем понимаю, как ты обойдешься без такой же монструозной структуры (скажем, как обрабатывать ctrl+click?).
Ну и для перемещения мыши (скажем, нужно подсвечивать пункты списка по мере наведения мыши) - не слишком ли много событий будет? Я просто собираюсь использовать библиотеку с Ruby, хехе. Так что если С и паскаль обработают пару десятков событий от перемещения в секунду без проблем, то со скриптовым языком я уже так не уверен. Хотя может он тоже справится.

Аватара пользователя
Cfyz
Сообщения: 776
Зарегистрирован: 30 ноя 2006, 10:03
Откуда: Санкт-Петербург
Контактная информация:

Re: BeaRLibTerminal - псевдоконсольное окно для рогалика

Сообщение Cfyz » 11 янв 2013, 21:07

kipar писал(а):Правда не совсем понимаю, как ты обойдешься без такой же монструозной структуры (скажем, как обрабатывать ctrl+click?).
Комбинация обработки того, что необходимо и пропуска того, не неинтересно =) Я за эту очередь и минимум функций цепляюсь в том числе и потому, что это дает некоторую гибкость, пусть и своей ценой.

Те, кому достаточно обработки нажатия клавиш (стрелочки и "нажмите i, чтобы открыть инвентарь") сделают terminal_get() и switch по коду.
Те, кому нужна тривиальная поддержка мыши (указать мышкой куда идти), добавят в switch пару констант.
Те кому нужно различать большие и маленькие буквы (уже редкость) заморочатся и сделают if ( key.code == VK_SHIFT ) { shift_pressed = key.flags & VK_FLAG_RELEASED; }
Те, кому нужен Shift, но лишь последнее положение мыши, должны сделать то же самое, но попросту положение взять из переменной после цикла.
И т. д., потихоньку до самых извратных ситуаций.

Например:

Код: Выделить всё

void ProcessInput()
{    
    int mx, my;
    bool ctrl, lmb;
    
    do
    {
        input_t key = terminal_get();
        if ( key.code == VK_LBUTTON ) lmb = key.flags & VK_FLAG_RELEASED;
        if ( key.code == VK_CONTROL ) ctrl = key.flags & VK_FLAG_RELEASED;
        else if /* ... обработка прочего клавиатурного ввода ... */
        mx = key.x; my = key.y;
    }

    /* ...обработка мыши исходя из x, y, ctrl и lmb... */
}
Похоже и есть, с функциональной точки зрения, необходимая тебе обработка ввода.

Но вот по поводу отдельных перемещений указателя мыши... тут два варианта:
1. Забить. Те, кому нужно так динамично обрабатывать ввод пусть берут неблокирующий ввод и обрабатывают его так часто, как вздумается. Напомню, предполагается, что положение курсора мыши всегда в наличии.
2. Сделать некоторую опцию типа учитывать движение мыши как отдельные события или только клавиши.



AAА ВООБЩЕ МНЕ ПРЯМО СЕЙЧАС ИДЕЯ ПРИШЛА

Я даже обдумать не успел, но я ее все равно напишу, потому что дискуссия это весело.

У меня же вводом заведует весьма сложная конструкция. И очередь всегда есть. И терминал всегда знает, выбрано уже или еще нет то или иное событие в данный конкретный момент времени. И, соответственно, может самостоятельно подсчитывать нажат ли, например, Shift сейчас или нет. Или Ctrl. Не, надо проиллюстрировать:

Допустим, в очередь попали: I, SHIFT_pressed, Z, SHIFT_released, LEFT... Как это будет обрабатываться?
1. 'I': открываем инвентарь.
2. SHIFT_pressed: запоминаем, что шифт нажат.
3. 'Z': ага, так как шифт нажат, это большая Z, значит это не зеркальце, на Зонт; юзаем.
4. SHIFT_released: запоминаем, что шифт отжат.
5. LEFT: идем влево (зачем доставали зонт?)

Но! В любой момент, например на шаге 3, терминал у себя внутри тоже знает, что SHIFT_pressed было обработано, а SHIFT_released еще нет, значит можно ввести что-то типа функции teminal_keystate(int code) и делать уже так:

Код: Выделить всё

if ( key.code == 'Z' )
{
    if ( terminal_keystate(VK_SHIFT) ) 
        Zap();
    else
        ZigzagOuttaHere();
}
Вы таки заметили потенциал такого финта ушами? Мало того, что необязательно следить за состоянием регистровых клавиш, сюда же можно приляпать и координаты мыши. И аналогового джойстика, у которого вообще событий нет.

Ну а любителям опрашивать клавиатуру по месту достаточно будет

Код: Выделить всё

inline void terminal_purge_input() { while ( terminal_kbhit() ) terminal_get(); }

/* ... */
terminal_purge_input();
if ( terminal_keystate(VK_LBUTTON) )
{
    HandleMouseClick(terminal_keystate(VK_MX), terminal_keystate(VK_MY), terminal_keystate(VK_SHIFT));
}
/* ... */
Ну только названия функций не то, чтобы идеально подходят, но это мелочи.

Надо это переварить. Потому что или я туплю сейчас или тупил до этого >_<
Пытается раскуклиться

Аватара пользователя
kipar
Сообщения: 2120
Зарегистрирован: 10 мар 2010, 13:16
Откуда: Москва

Re: BeaRLibTerminal - псевдоконсольное окно для рогалика

Сообщение kipar » 11 янв 2013, 21:19

Cfyz писал(а):Напомню, предполагается, что положение курсора мыши всегда в наличии.
А состояние кнопок мыши - в наличии? А то могут быть глюки если мы схватили предмет в окне, потом вышли курсором из окна, там отпустили, потом вернулись в окно.

А с идеей - по-моему идеальный вариант, но по сути эквивалентно мегаструктуре состояния кнопок. Просто вместо обращения к полям будут вызовы функций. С одной стороны если большая часть не нужна, то код упрощается. А с другой - если большая часть нужна, скажем, для записи демки, в каком-нибудь хаскеле, да и просто для абстрагирования от либы, потребуется сохранить состояние в своей структуре и потом уже передавать ее на обработку.

Аватара пользователя
Cfyz
Сообщения: 776
Зарегистрирован: 30 ноя 2006, 10:03
Откуда: Санкт-Петербург
Контактная информация:

Re: BeaRLibTerminal - псевдоконсольное окно для рогалика

Сообщение Cfyz » 11 янв 2013, 21:52

kipar писал(а):А то могут быть глюки если мы схватили предмет в окне, потом вышли курсором из окна, там отпустили, потом вернулись в окно.
А вот за этим и нужна очередь, очередность событий ввода. И тут уж выбирайте, либо последовательная обработка истории произошедшего, либо быстрая -- актуального состояния. Заметь, тут проблема логическая: везде, где есть get_state() --> { lmb, x, y } можно запросто словить моменты, когда lmb только только-только успела отжаться или наоборот вот миллисекундой позже бы и было бы считано нажатие, но не судьба; а x и y, зараза, всегда верные. Тут поможет только OnMouseClick, но никак не считывание статуса.
kipar писал(а):по сути эквивалентно мегаструктуре состояния кнопок. Просто вместо обращения к полям будут вызовы функций
Да, действительно похоже. Но с нюансом: это можно легко прозрачно комбинировать с обычной обработкой. Ключевой момент в том, что эта виртуальная мегаструктура описывает состояние не в данный момент времени, а в данный момент обработки ввода. Ни одно событие никуда не денется и порядок их не собьется, хотя простота опроса в наличии. Иллюстрируя, можно не торопясь обработать очередь I, SHIFT↑, Z, SHIFT↓, CTRL↑, LEFT, CTRL↓ не боясь спутать Shift+Z с просто Z или Ctrl+Z, или Ctrl+LEFT и Shift+LEFT. И даже если опрашивать достаточно часто для реалтайма, все эти флаги никогда не будут в несогласованном состоянии.
kipar писал(а):А с другой - если большая часть нужна, скажем, для записи демки, в каком-нибудь хаскеле, да и просто для абстрагирования от либы, потребуется сохранить состояние в своей структуре и потом уже передавать ее на обработку
Ну тут уж извините, завсегда можно найти какой-нибудь крайний случай. Я думаю, что на деле не составит большого труда завернуть это в отдельную функцию. Или что там в Haskell отвечает за реиспользование кода, я сам как-то более по императивным языкам =( К слову, если нужно шустро сохранить вообще все состояние в текущий момент, можно воспользоваться тем фактом, что коды клавиш и псевдоклавиш -- это попросту целые числа в диапазоне, скажем, от 0 до 255 =).

И да, что значит "большая часть нужна для записи демки"?
Пытается раскуклиться

Аватара пользователя
Apromix
Мастер
Сообщения: 1236
Зарегистрирован: 04 июл 2011, 10:44
Откуда: Украина, Черновцы
Контактная информация:

Re: BeaRLibTerminal - псевдоконсольное окно для рогалика

Сообщение Apromix » 11 янв 2013, 22:25

Кстати, а как быть с иконкой для окна (ну и ярлыка)? Можно добавить свою или как?

Аватара пользователя
Cfyz
Сообщения: 776
Зарегистрирован: 30 ноя 2006, 10:03
Откуда: Санкт-Петербург
Контактная информация:

Re: BeaRLibTerminal - псевдоконсольное окно для рогалика

Сообщение Cfyz » 11 янв 2013, 22:35

Apromix писал(а):Кстати, а как быть с иконкой для окна (ну и ярлыка)? Можно добавить свою или как?
Разумеется. Разумеется должна быть возможность добавить =) Сменить иконку у окна, взяв ее из .ico, технически несложная задача. Я, среди прочего, смотрю как можно еще автоматом подцепить иконку, упакованную в сам .exe. С частью "ну и ярлыка" (т. е. именно самого .exe-файла) несколько сложнее -- тут что ваш компилятор/IDE позволит, то и будет. Сторонняя динамическая библиотека ну никак на это повлиять не может.

Как думаете, кому-нибудь вообще может потребоваться менять иконку в процессе работы? Просто если да, то оно пойдет отдельным вызовом terminal_icon(...), если нет, то константным (несменяемым) параметром в terminal_open(...).
Пытается раскуклиться

Аватара пользователя
Apromix
Мастер
Сообщения: 1236
Зарегистрирован: 04 июл 2011, 10:44
Откуда: Украина, Черновцы
Контактная информация:

Re: BeaRLibTerminal - псевдоконсольное окно для рогалика

Сообщение Apromix » 12 янв 2013, 06:56

Cfyz писал(а):Как думаете, кому-нибудь вообще может потребоваться менять иконку в процессе работы? Просто если да, то оно пойдет отдельным вызовом terminal_icon(...), если нет, то константным (несменяемым) параметром в terminal_open(...).
Думаю нет, не потребуется :D Но нагружать параметрами terminal_open, имхо, нет смысла. В моем видении лучше: terminal_icon и использовать его лишь раз где-то вначале.

Аватара пользователя
Apromix
Мастер
Сообщения: 1236
Зарегистрирован: 04 июл 2011, 10:44
Откуда: Украина, Черновцы
Контактная информация:

Re: BeaRLibTerminal - псевдоконсольное окно для рогалика

Сообщение Apromix » 12 янв 2013, 07:13

Cfyz писал(а):
Apromix писал(а):Я за Ubuntu :) Красивый шрифт и современный, недавно читал новость на ЛОРе, что обновились шрифты для убунты. Сам думаю в дес взять этот шрифт.
Да, шрифт весьма приятный. Ну и тут еще немаловажный момент (ну, кому как, мне немаловажный), что лицензия на шрифты Ubuntu позволяет вот так взять и вложить растеризованную битмапку в свое приложение/либу =)
Apromix писал(а):Еще в дес возьму терминал, если он будет не тяжелее того, что исп. сейчас в дес :)
Таки что значит -- тяжелее? =) Я вот не помню, дебажная или релизная лежит во вложении чуть выше по треду, но даже если примерно 1 Мб -- это несерьезно в наше время.

Либа, чисто технически, могла быть и тоньше, но в силу очевидных причин она делается без зависимостей от всяких msvcrtXYZ.dll и пр., а за это приходится платить. Не забываем, там внутри помимо CRT еще zlib, libpng и freetype. Если приложением уже для своих собственных целей используются эти либы (и автор не против в установщик вложить Microsoft Visual C++ 2012 Redistributable, лол), то можно сделать тонкую сборку. Иначе бестолку, какая разница одним куском либ на метр или в сумме скопом?

Алсо, выбор шрифта в моем вопросе -- это не в контексте "думаю эту либу использовать, вот этот шрифт мне как раз придется". Лучше просто взять и положить .ttf рядом, зато и размер в любой момент поменять можно и юникод почти полный. А тот, что дефолтный -- это для демок, тех же быстрых набросков или где попросту не очень важно.
Имелась ввиду нагрузка на процессор :) Размер не важен, хоть 10 мб :) Ведь кроме терминала еще работают и другие либы (скажем FOV) и чтоб не получились тормоза на слабом компе.
Скрытый текст: ПОКАЗАТЬ
К примеру, недавно мне случилось запустить DiabloRL на Windows 98 с Pentium 166MX. Тормоза были жуткие, невозможно играть, один ход забирал 5 - 10 секунд. Как оно так написано на FreePascal'e до сих пор не понятно. А ведь старкрафт с 4 игроками по сетке бегает шустро даже при макс. лимите 200!

Аватара пользователя
Apromix
Мастер
Сообщения: 1236
Зарегистрирован: 04 июл 2011, 10:44
Откуда: Украина, Черновцы
Контактная информация:

Re: BeaRLibTerminal - псевдоконсольное окно для рогалика

Сообщение Apromix » 12 янв 2013, 07:24

Чтобы повысить интерес к играм на терминале в нем должно быть реализовано следующее (ну или опиши как это реализовать на существующем терминале):
* Изменение размеров символов. Я не говорю о смешивании шрифтов, хотя это тоже было бы полезно :) Например, маленькая крыса r имеет размер 8, а обычная крыса r - 10. Или босс кроме того, что он показан большой буковкой, так еще шрифт его крупнее - 12. Литеры должны центрироваться в своей ячейке.
* Изменение фона под литерой. Пример, комманда Look, или прицел для стрелкового оружия.
* Изменение цвета литеры. Например, существо отравили или заморозили.
* Использование линий и прямоугольников. Для рамок, красивого отделения текста и прочего. В десе используется часто. Пример, лайфбары над монстрами и героем. Или окно диалога с NPC.
* Мигание литеры, причем регулируемое. Пример, после удара по монстру буква монстра на 50 мс становится красной. Аналогично с персонажем. Если герой лечится магией, его иконка медленно становится голубой и так же медленно возвращается в обычный цвет. Паузы в игре в это время не должно быть и герой может перемещаться, а еффект действовать. Если при лечении персонажа ударили, то действие первого эффекта прекращается и действует еффект удара (тот, что 50 мс). Сразу же после него цвет собачки приходит в норму.
* Смещение литеры на несколько пикселей в нужную сторону, а затем возврат на место. В десе в бою при атаке собачка персонажа кидается в сторону врага, а вражеский символ от нее. Затем все меняется наоборот. Визуально видно попал-непопал.
* Летающие затухающие циферки. Пример, после удара по существу (не важно кто: монстр или персонаж) над ним летит и затухает (пока не исчезнет) красная цифра урона со знаком минус (сколько мы снесли здоровья врагу). Когда существо лечится, то голубая цифра со знаком плюс. Желтая - после смерти врага, показывает приобретенный опыт.
* Полет символа от точки А до точки Б по пиксельной прямой, игнорируя сетку символов. Можно сделать булевый флаг, указывающий по-умолчанию обычный полет по сетке, как есть во всех рогаликах.

Опционально еще вот:
* Перемещение существ плавно по сетке, а не скачкообразно, как обычно в рогаликах (в десе нет, но делал такое раньше, на движке love, если исх. сохранился, продемонстрирую, смотрится красиво). Регулируется скорость. К примеру, если используется быстрое перемещение по корридору, пока не встретился монстр, то лучше пусть это будет быстро, во много раз быстрее обычного, иначе теряется смысл фичи и игрок будет наблюдать бег раненной лошади :)
* Расчет освещения сцены. Герой - факел :) Но еще могут быть источники света и в подземелье. Чем ближе источник света - тем ярче освещен тайл. Согласен, можно выполнить за стенами быблиотеки, но можно перегрузить и на плечи терминала.
* Использование графических тайлов или использование букофф. В десе переключается из меню настроек. Тайлсет взят из DwarfFortress.
* Наконец расчет FOV тоже можно запихнуть в терминал (для пс и существ).

Аватара пользователя
kipar
Сообщения: 2120
Зарегистрирован: 10 мар 2010, 13:16
Откуда: Москва

Re: BeaRLibTerminal - псевдоконсольное окно для рогалика

Сообщение kipar » 12 янв 2013, 10:18

Cfyz писал(а):Да, действительно похоже. Но с нюансом: это можно легко прозрачно комбинировать с обычной обработкой. Ключевой момент в том, что эта виртуальная мегаструктура описывает состояние не в данный момент времени, а в данный момент обработки ввода. Ни одно событие никуда не денется и порядок их не собьется, хотя простота опроса в наличии.
Ну т.е. как если бы эта структура хранилась в очереди сообщений. Собственно это (что это эквивалентно структуре хранящейся в очереди сообщений) я и имел в виду.
Cfyz писал(а): И да, что значит "большая часть нужна для записи демки"?
Ну, если код более-менее обобщенный, то функция получения события от клавиатуры будет возвращать целиком событие, выполняя все вызовы getstate до начала собственно обработки. И потом это событие будет отправляться в дерево обработчиков, которое об особенностях библиотеки не в курсе. Хаскель я привел как экстремальный пример, там по-другому никак и не выкрутишься, там ведь нельзя вызывать внешние функции просто в коде, только в монаде.
И для демки - тоже, как я понимаю, надо хранить очередь всех пришедших от игрока событий, т.е. упаковывать все состояние в свой формат.

Аватара пользователя
Cfyz
Сообщения: 776
Зарегистрирован: 30 ноя 2006, 10:03
Откуда: Санкт-Петербург
Контактная информация:

Re: BeaRLibTerminal - псевдоконсольное окно для рогалика

Сообщение Cfyz » 12 янв 2013, 12:14

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 до начала собственно обработки. <...> И для демки - тоже, как я понимаю, надо хранить очередь всех пришедших от игрока событий, т.е. упаковывать все состояние в свой формат.
Согласен, но мне кажется, что это все-таки пограничный случай. Не вижу ничего противоестественного в том, что для специфичной задачи (реализация адаптера к библиотеке) придется написать немного кода (сам адаптер).
Пытается раскуклиться

Аватара пользователя
Феникc
Сообщения: 679
Зарегистрирован: 27 ноя 2010, 15:01
Откуда: Челябинск

Re: BeaRLibTerminal - псевдоконсольное окно для рогалика

Сообщение Феникc » 12 янв 2013, 13:09

А почему в архиве отсутствует .lib файл? Насколько я знаю, при написании dll lib генерируется сам (или это только в MVS?).
В любом случае, неплохо было бы его выложить. Как раз хочу реализовать небольшую задумку и этот терминал отлично для этого подходит (особенно если будет изменение цвета фона).
Всё вышесказанное - ИМХО, если не указано обратное.

Аватара пользователя
Cfyz
Сообщения: 776
Зарегистрирован: 30 ноя 2006, 10:03
Откуда: Санкт-Петербург
Контактная информация:

Re: BeaRLibTerminal - псевдоконсольное окно для рогалика

Сообщение Cfyz » 12 янв 2013, 13:24

Феникс писал(а):А почему в архиве отсутствует .lib файл? Насколько я знаю, при написании dll lib генерируется сам (или это только в MVS?).
В любом случае, неплохо было бы его выложить. Как раз хочу реализовать небольшую задумку и этот терминал отлично для этого подходит (особенно если будет изменение цвета фона).
В архиве отсутствует потому, что то была сборка в спешке для человека с паскалем. Сегодня-завтра (или на днях >_< кавардак со временем) сделаю следующую сборку, по меньшей мере с фоном =) Туда и .lib с .h вложу. Однако, позже я собираюсь сделать C-интерфейс к библиотеке без .lib. По аналогии с паскалем и С#, где достаточно указать что и откуда импортировать, на С/С++ также можно сделать динамическую подгрузку. Отдельный .lib-файл здесь излишен, можно обойтись одним хидером.

edit: Вообще, честно говоря, у меня есть легкие сомнения. Либа написана на С++11 под MSVS2012 и я хз что они там с ABI сотворили и каждый ли компилятор эту .lib подцепит. Возможно имеет смысл сразу заморочиться на header-only интерфейс.
Пытается раскуклиться

Аватара пользователя
Феникc
Сообщения: 679
Зарегистрирован: 27 ноя 2010, 15:01
Откуда: Челябинск

Re: BeaRLibTerminal - псевдоконсольное окно для рогалика

Сообщение Феникc » 12 янв 2013, 13:35

Сегодня-завтра (или на днях >_< кавардак со временем) сделаю следующую сборку, по меньшей мере с фоном
У меня просто творческий зуд, вынуждающий начать писать как можно раньше, так что искренне прошу попробовать выложить сегодня, даже если и без фона.
Либа написана на С++11 под MSVS2012 и я хз что они там с ABI сотворили и каждый ли компилятор эту .lib подцепит.
Ну во всяком случае у меня тоже MVS2012, так что проблем быть не должно. Судя по тому, что вроде никто пока этот терминал через С юзать не собирается - можешь сделать пока только .lib, благо займёт это пару минут, а уже потом сделать всё по уму.
Всё вышесказанное - ИМХО, если не указано обратное.

Аватара пользователя
Cfyz
Сообщения: 776
Зарегистрирован: 30 ноя 2006, 10:03
Откуда: Санкт-Петербург
Контактная информация:

Re: BeaRLibTerminal - псевдоконсольное окно для рогалика

Сообщение Cfyz » 12 янв 2013, 18:37

Феникс писал(а):искренне прошу попробовать выложить сегодня, даже если и без фона
Держи. Даже с фоном. Уж что-что, а сплошные прямоугольники под буквами -- далеко не самая сложная часть этой затеи =)
Феникс писал(а):Ну во всяком случае у меня тоже MVS2012, так что проблем быть не должно.
Если попытаться -- так это всегда пожалуйста. Я просто гарантировать ничего не могу. Хотя я собираю специальным тулсетом для обратной совместимости, так что шансы, что все везде будет ок, все-таки высоки.

В качестве бонуса в архиве демка некоторой работы со шрифтами. Слева-сверху четыре переключаемых параметра, стрелками вверх-вниз выбирается параметр, стрелками влево-вправо он модифицируется. Прошу заметить, как, во-первых, несмотря на характер шрифта, все символы на своих законных местах по юникоду; и, во-вторых, для всех без исключения шрифтов в наличии диапазоны Unicode Box Drawings и Unicode Block Elements (к моменту просьбы мол неплохо бы рамочки я уже кое-что в этом направлении сделал; там не все гладко, но на первое время сгодится).

Чтобы полностью прочувствовать работу с юникодом, параметры в terminal_open надо оставить пустой строкой (юникод -- кодировка по умолчанию) и впредь в программе использовать строки в UTF-8. В MSVС для этого достаточно сохранить свои исходники в кодировке "Unicode (UTF-8 without signature)", причем очень похожая "UTF-8 with signature" не прокатит, компилятор спотыкается. Вообще, все будет ок и если исходник в Windows-1251, но тогда эту кодировку надо указывать при инициализации терминала и еще там свои нюансы и мне лень >_<

edit: А еще я сменил (и нигде не прокомментировал) параметр type=freetype на type=truetype в описании шрифта. FreeType это все-таки библиотека, а поддерживаемый тип шрифта -- TrueType. И раз уж затронули эту тему, в качестве напоминания (документации-то нет), описания шрифтов для terminal_font выглядят так:
"type=truetype; filename=somename.ttf; size=10"; размер -- это размер буквы, ячейка выйдет больше в зависимости от гарнитуры.
"type=bitmap; filename=somename.png; size=8x16; codepage=windows-1251"; размер -- это размер тайла целиком; codepage -- это кодировка, по которой расставлены символы в картинке, для шрифтов от Dwarf Fortress это dos-437.
Вложения
bearlibterminal-beta2.zip
(1.52 МБ) 108 скачиваний
Пытается раскуклиться

Ответить

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 18 гостей