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

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

Модератор: Apromix

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

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

Сообщение Apromix » 24 янв 2013, 08:06

По мне так использование terminal_options лучше того, что использует движок HGE. Просто сделать нужно это красиво: возможность вставлять пары параметров в произвольном порядке, возможность вызывать terminal_options несколько раз, возможность указать файл (скажем .xml или .ini), где эти параметры уже есть, get_terminal_option, возвращающая строкой определеное значение ключа и прочее :D

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

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

Сообщение Apromix » 24 янв 2013, 14:16

Когда будет новая версия либы, так сказать свежачок :)? Нашел на форуме версию с красивым бегающим освещением, хотел кое-что попробовать, но из дельфи не удалось поюзать, так как видимо много чего уже поменялось в параметрах. У меня все сдвинулось вверх, под полоску окна :) Освещение красивое! Руки все не доходили приделать такое освещение в рогалик. Источники света - только герой и факелы, ну может еще магия, скажем, летящий фаерболл :) Думаю было бы красиво. Я так понимаю тут еще и FOV нужен для героя и для каждого факела :)

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

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

Сообщение Cfyz » 24 янв 2013, 15:30

Apromix писал(а):Когда будет новая версия либы, так сказать свежачок :)? Нашел на форуме версию с красивым бегающим освещением, хотел кое-что попробовать, но из дельфи не удалось поюзать, так как видимо много чего уже поменялось в параметрах. У меня все сдвинулось вверх, под полоску окна :) Освещение красивое! Руки все не доходили приделать такое освещение в рогалик. Источники света - только герой и факелы, ну может еще магия, скажем, летящий фаерболл :) Думаю было бы красиво. Я так понимаю тут еще и FOV нужен для героя и для каждого факела :)
Будет >_< Вот в ближайший вечер обещать не могу, но до начала следующей недели выложу. Там (если полистать текущую ветку) запланировано поправить внутренний механизм обработки ввода и способ задания настроек. Если со временем будет так же не ахти, просто соберу что есть на выходных. По крайней мере со шрифтами работу подправил и пару багов убрал (ни у кого нет видео от AMD? должно было регулярно падать).

На самом деле просто так взять и не работать не должно. Основные вызовы и их сигнатуры не поменялись. Если несложно, вышли экзешник в котором видно неожиданное поведение.

А вообще, паскалевский биндинг я навскидку написал. Не уверен, что простые-то вызовы верно выполнены, а со строками вообще затрудняюсь. Например, String (которая паскаль-строка, с размером в "нулевой ячейке" -- ShortString?) и C-строка (с нуль-терминатором, AnsiString) -- насколько они взаимозаменяемы? Одинакова ли семантика и набор допустимых операций? Их кодировка берется прозрачно с кодировки файла-исходника или там есть какая-то магия? Тут дело в том, что часть интерфейса вынуждена быть на языке биндинга. Например, terminal_options или terminal_printf в C могут иметь переменное число параметров в стиле оригинального printf, что упрощает работу с ними. Однако просто смапить вызов 1-к-1 в другой язык нельзя, так как идиоматика форматирования строк отличается. Например, любой человек, использовавший сишный printf, насторожится при передаче в аналогичную функцию параметра-строки со случайным знаком "%", типа "Damage 25%" Процент -- это специальный знак здесь и просто так неэкранированным встречаться не должен. А для пишущего на паскале и C# в этом нет ничего подозрительного. Да и вообще не факт, что подобный маршаллинг в принципе возможен. Поэтому (а еще для сохранения привычного стиля другого яызка программирования) для форматирования и подстановки строк необходимо использовать механизмы целевого языка. Это точно везде возможно, но дьявол -- он в деталях. Поэтому если есть желание взвалить на себя вопрос взаимодействия "своего" языка программирования с C-интерфейсом библиотеки -- партия ждет вас с распростертыми объятиями =)

А в той "демке" все освещение реализовано через terminal_color и terminal_put. Совершенно тривиальным способом рассчитывается карта освещения (цветов от источников света), а потом при выводе цвета ячеек просто вручную множатся на цвета символов. Единственная "хитрость" в том, что цвета нужно держать покомпонентно во float и отсекать переполнение при конвертации обратно в целочисленное RGBA. BearLibТерминал только для полноцветности и скорости =)

Если делать честный свет, то ты прав, нужен FOV, но логика выйдет не сильно сложнее. При складывании света от источников при генерации карты освещения и умножении цветов при выводе надо просто игнорировать все не видимые (с точки зрения FOV) ячейки.
Пытается раскуклиться

Аватара пользователя
Uvadzucumi
Сообщения: 365
Зарегистрирован: 29 ноя 2011, 07:13
Откуда: Дубай, ОАЭ (Минск, Беларусь)
Контактная информация:

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

Сообщение Uvadzucumi » 24 янв 2013, 20:34

Cfyz писал(а):Если делать честный свет, то ты прав, нужен FOV, но логика выйдет не сильно сложнее. При складывании света от источников при генерации карты освещения и умножении цветов при выводе надо просто игнорировать все не видимые (с точки зрения FOV) ячейки.
не достаточно. так как персонаж будет видеть освещенную стену, если на нее светит источник с другой стороны. т.е. еще нужно проверять с кокой стороны стена освещена. а в какой смотрит персонаж.

но можно сделать прикольней. считать расстояние до 4-х точек ячейки. при этом соответственно, все точнки освещать отдель. в результате невидимая сторона не будет вообще освещена, а переход света будет плавным, а не дискретным в пределах ячейки.
Меня окружали милые, добрые люди... медленно сжимая кольцо

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

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

Сообщение Cfyz » 24 янв 2013, 21:31

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

Причем на последней ситуации я остановлюсь поподробнее. Это вообще по-моему злая подстава на пути к свету и истине.

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

........
...2....
R..#,...
1..#,...
...#,,,B
...#####
...#....
Итак, приступим. Стена освещается красным источником света (R) и глядя из точки (1) должна быть красной. Однако с другой стороны на стену светит синий источник света (B). Клином же свет сходится на ячейках, отмеченных запятыми.
-- Если, исходя из положения игрока в (1), не учитывать эти ячейки в силу того, что игрок их не видит, то часть стены ВНЕЗАПНО поменяет цвет как только игрок переместится в такую точку, откуда он их видит, например (2).
-- Если всегда учитывать все прилегающие к стене ячейки при расчете цвета стены, то глядя из точки (1) стена будет иметь странный фиолетовый кусок.

Если минимальная единица пространства -- клетка, то нормального освещения не выйдет. У точки не может быть правой и левой стороны. Насколько я вижу, задача отрисовки полноцветного освещения при стенах в одну неделимую клетку шириной не имеет решения "по построению". edit: Причем, прошу заметить, плавная раскраска углов не поможет, так как это просто более сложна форма раскраски все той же единой и неделимой клетки.

Отсюда есть два выхода (подскажете еще?):
1. Делать стены в две клетки. Теперь у стены в самом деле есть две стороны.
2. Дробить пространство вплоть до пикселя. Тут возможностей больше, но и механизмы сложнее.

В BearLibTerminal из коробки есть возможность рисовать клетки четвертинками. В интерфейсе есть метод terminal_put_over, который кладет тайл поверх уже помещенных в эту клетку. Таким образом код вида

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

terminal_color(0xFFFF0000); terminal_put_over(1, 1, 0x2598); // top-left: red
terminal_color(0xFF00FF00); terminal_put_over(1, 1, 0x259D); // top-right: green
terminal_color(0xFF0000FF); terminal_put_over(1, 1, 0x2596); // bottom-left: blue
terminal_color(0xFFFFFF00); terminal_put_over(1, 1, 0x2597); // bottom-right: yellow
выведет в ячейке логотип Microsoft Windows времен 98 в современном прямоугольном metro-стиле =)
В принципе, можно приспособить этот механизм. Можно даже 4x4 ячейку разбить при большом желании =)
Пытается раскуклиться

Аватара пользователя
Uvadzucumi
Сообщения: 365
Зарегистрирован: 29 ноя 2011, 07:13
Откуда: Дубай, ОАЭ (Минск, Беларусь)
Контактная информация:

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

Сообщение Uvadzucumi » 25 янв 2013, 01:50

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

зы. так как был вопрос про другие решения.
1) не делать клетки в 4 клетки (если это только для освещения, то незачем). а просто учитывать направление взгяда игрока и направление источника света (я это описывал около недели назад, когда в своей демке динамическое освещение показывал). но, так как в конкурсе учавствовал, то времени как бы осо небыло писать код, хотя мне представляется все достаточно просто.

1) у меня в тайле есть поле, "попадает" в LOS. - выкинуть нафиг. жрет зря памяти. оставить только - "попадало" в LOS. для рассчета - что сейчас в поле зрения - виртуальный вьюпорт, на размер экрана (или больше - если за экраном может видеть персонаж). так как нам на самом деле не нужно для всей локауии хранить инфу что игрок видит в данный момент. структура массива примерно такая

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

viewport {
    bool is_see:1, nort:1, south:1,weast:1, east:1;
    unsigned loght:3;
}
- заполняется при рассчете видимости персонажа. поля по направлениям света - какую стену видит персонаж. (is_see - избыточно, но для быстродействия лучьше иметь, так как памяти не сожрет лишней.

2) перебираем все источники на уровне. и если расстояние от источника+дланна его отбрасываемого света меньше чем дальность видимости персонажа, то считаем уже LOS от источника до видимых персонажем клеток (LOS персонажа, разумеется первым считаем и заполняем массив). если источник с той же стороны - которую видит персонаж и поле light( интенсивность света в этой ячейке) < интенсивности света от источника (зависящей и от расстояни до него), то интенсивность от источника присвоить освещенности ячейки.

3) так как все равно будут артефакты, нужна постаброботка, рассматривающая чяастные случаи.

в общем, алгоритм примерно такой. но у мня пока не реализовано. пока обычный лос добавил для источник всета (пару строчек кода всего, и, как результат, пропускающие свет стены).

это, разумеется, для однородного цвета источников света, хотя для различных цветов, просто придется поменять структуру вьюпорта виртуального и смешивать цвета.
Меня окружали милые, добрые люди... медленно сжимая кольцо

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

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

Сообщение Cfyz » 25 янв 2013, 08:49

Uvadzucumi писал(а):про плавную раскраску, немного ты меня не так понял. в общем виде, нужно рассчитать видимость каждой из 4-х точек ячейки (попиксельно а не потайлово). если точка не видна - черный цвет освещения. тогда все будет ок. при этом, даже угловые ячейки комнаты должны правильно подсвечиваться (при видемости только одной точки из 4-х). вот только делать это проще в пиксельном шейдере.
Не, мне кажется я верно понял. И если сводить результаты расчета к освещению углов, то тут даже пиксельных шейдеров не надо, я такое на текущей сборке BearLibTerminal запросто сделаю (правда еще чуть хитрее, чем четвертинками). Но проблема, которую я описал никуда не девается, как ни считай, ибо как ты верно заметил...
Uvadzucumi писал(а):это, разумеется, для однородного цвета источников света
Это ключевой момент. Действительно можно оперировать вымышленными сторонами падения света и сторонами взгляда, но только до тех пор, пока нам в итоге не особо важно, кто именно, как именно и с какой стороны освещает ячейку, достаточно ее кумулятивного значения освещенности.

Для такого случая приведенный тобой алгоритм вполне подходит, правда мне кажется там проглядывает преждевременная оптимизация: проверки расстояний, наложение масок FOV/LOS =) Освещение здесь весьма неинтуитивная штука и лучше сначала сделать его невзирая на всякие лишние расчеты, а оптимизировать уже имея на руках эталонный результат работы алгоритма.
Uvadzucumi писал(а):для различных цветов, просто придется поменять структуру вьюпорта виртуального и смешивать цвета.
Увы. Пробегись по приведенному чуть выше мною примеру (где я кусочек карты нарисовал). Не рассматривая какой-либо конкретный алгоритм вообще, вот какая проблема: одна и та же ячейка, например самая верхняя "#", в зависимости от положения игрока должна быть:
1. одного сплошного цвета: положение игрока -- точка (1), [#] красного цвета от источника (R)
2. двойного цвета: положение игрока -- точка (2), [#] красно-синяя от источников (R) и (B)

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

Это не проблема алгоритма; человек, расчертив листок бумаги и взяв в руки цветные карандаши, также не сможет нарисовать "правильный" вариант.

И я еще раз акцентирую внимание, что какая-либо плавная заливка никаким образом не исправит ситуацию. Четырехцветный градиент цельной ячейки это тоже, фактически, один хитрый "цвет". По первым же пикселям вглубь клетки будет ясно какой цвет с противоположной стороны. А нам нужно вообще скрыть факт наличия какого-либо (любого!) цвета с той самой противоположной стороны. Тобою высказываются предположения вида "невидимая сторона не будет вообще освещена" и "если точка не видна - черный цвет освещения". Это все также не поможет, черный -- это тоже обычный цвет. Какая разница, будет ли артефакт от смешения красного и синего (градиент или фиолетовый цвет) или от смешения красного и черного (градиент или темно-красный цвет)?

Нужна техническая возможность нарисовать только "реально видимую" часть клетки. Четвертинками, попиксельно (стены толщиной в пару пикселей по краям ячейки) или еще как.
Пытается раскуклиться

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

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

Сообщение Apromix » 25 янв 2013, 12:40

Ну вообщем я жду свежачка, чтобы потестровать как следует :)

Аватара пользователя
Uvadzucumi
Сообщения: 365
Зарегистрирован: 29 ноя 2011, 07:13
Откуда: Дубай, ОАЭ (Минск, Беларусь)
Контактная информация:

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

Сообщение Uvadzucumi » 25 янв 2013, 16:00

Cfyz писал(а):И я еще раз акцентирую внимание, что какая-либо плавная заливка никаким образом не исправит ситуацию. Четырехцветный градиент цельной ячейки это тоже, фактически, один хитрый "цвет". По первым же пикселям вглубь клетки будет ясно какой цвет с противоположной стороны. А нам нужно вообще скрыть факт наличия какого-либо (любого!) цвета с той самой противоположной стороны. Тобою высказываются предположения вида "невидимая сторона не будет вообще освещена" и "если точка не видна - черный цвет освещения". Это все также не поможет, черный -- это тоже обычный цвет. Какая разница, будет ли артефакт от смешения красного и синего (градиент или фиолетовый цвет) или от смешения красного и черного (градиент или темно-красный цвет)?
имеется ввиду вот что:
Изображение
т.е. только нужная сторона и будет отображаться. если же будут видны одновременно обе, ну - будет градиент... в других случаях, отображается только видимая сторона. причем гражиент будет считаться относительно каждой вершины тайла... т.е. ели одна вершина не видна, она не будет видея - цвет фона (черный в данном случае). отальные в зависимости от удаленности и цвета действующих на них источников света.
Меня окружали милые, добрые люди... медленно сжимая кольцо

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

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

Сообщение Cfyz » 25 янв 2013, 16:45

Uvadzucumi
Блин, если бы у меня было время, я бы сочинил гифку =)

У тебя верно показаны три отдельных статических случая. Теперь давай взглянем, что произойдет в процессе. Положим, игрок перемещается из положения (3) (рисунок 3, красно-синий) влево и вниз, в положение (1) (рисунок 1, красно-черный). Медленно, шаг за шагом, как и пристало игроку в roguelike. Внимание же -- на раскрашенную клетку.

Раз шажок -- все нормально, красно-синяя, без изменений.
Два шажок -- все еще нормально, красно-синяя, без изменений.
Три шажок -- оппа! Клетка внезапно и без объяснения причин превратилась в красно-черную. Клетки (точки, углы, ect.), освещенные синим цветом, ушли из FOV/LOS игрока, исключились из алгоритма расчета и ситуация из случая (3) перешла в случай (1).
Шажок назад -- снова красно-синяя.
Шажок вперед -- опять красно черная.

Это одна раскрашенная тобою клетка. А на реальном уровне клетка не одна, там целая стена. А у стены с той и этой стороны ответвления, усложняющие конфигурацию FOV и превращающие описанное мигание в полноформатную цветомузыку из кусков стен.

Возможно я слишком общно выразился "расчертив листок бумаги ... человек не сможет нарисовать", надо было предельно уточнить "...нарисовать согласованное и непротиворечивое освещение для каждого шага на всем пути из одной крайней точки в другую крайнюю точку" >_<

Градиент в данном случае, повторюсь, лишь несколько более хитрый цвет, нежели простой сплошной. Тут вообще никакой цвет, хоть попиксельный, хоть какой, не поможет. Надо осознанно выделить у высокоуровнего объекта (в данном случае -- стены) разные стороны и рисовать их отдельно. В две клетки шириной, в одну клетку, в одну пятую -- непринципиально. Главное -- уйти от предположения, что клетка карты это такая безразмерная точка, а что точки в линии складываются, так это лишь благодаря картинкам тайлов и воображению игрока.

Если ты думаешь, что расчет по углам что-то принципиально меняет, то и тут вынужден разочаровать. Углы четырех ближайших ячеек совпадают. Мало того, что мест для расчета освещения больше не становится, так еще и не меняется физический смысл точек: не имеющих размер, но редко расставленных в пространстве.

Предвосхищая аргумент, нет, тонкости расчета FOV/LOS до центра или до углов не играют роли. Это, возможно, повысит точность, но не изменит ситуацию с фундаментальными проблемами, наглядно видимыми и при погрешностях плюс-минус лапоть.
Пытается раскуклиться

Аватара пользователя
Uvadzucumi
Сообщения: 365
Зарегистрирован: 29 ноя 2011, 07:13
Откуда: Дубай, ОАЭ (Минск, Беларусь)
Контактная информация:

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

Сообщение Uvadzucumi » 25 янв 2013, 17:15

то что исчезнет красный и останется только синий - это вполне логично и нормально! так и должно быть! (я так считаю), так каак игрок уже их не видит. и выгляжеть будет нормально... сейчас бы набросал пример, но я разобрал свою демку, прям как в стишке про шалтая-болтая... хоть ты из гита старую версию восстанавливай...
Меня окружали милые, добрые люди... медленно сжимая кольцо

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

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

Сообщение Cfyz » 27 янв 2013, 19:46

Начнем с меньшего по размеру ответа:
Uvadzucumi писал(а):то что исчезнет красный и останется только синий - это вполне логично и нормально! так и должно быть! (я так считаю)
Вот тут-то наши мнения и расходятся. Моя официальная позиция: подобное мигание цвета есть сущая порнография и лучше вообще никакого цвета, чем такой >_< Впрочем, демка моего видения освещения еще будет.


А продолжим обновлением BearLibTerminal.

Мыши нет, автоматического отслеживания ctrl/shift/etc. нет, смены иконки окна нет. Будет, но не успел.

Вызов инициализации terminal_open теперь принимает не строку, а целое число — номер "кодовой страницы". Для Unicode можно использовать 0 или 65001, для ANSI/OEM просто указывается ее номер, например 1251 для Windows-1251/Cyrillic. В bearlibterminal.h для юникода есть константа CODEPAGE_UNICODE (да, я знаю, что Unicode это не codepage, а encoding), но с паскалем фейл (попытка использовать соответствующую константу крашит приложение, я хз что это).

Переделан механизм указания опций с отдельных вызовов на единый terminal_options. В эту функцию передается строка вида "name1=value1; name2=value2; name3=value3". Количество и порядок параметров в строке произволен. Можно задать все сразу, можно задать один конкретный. В случае, если происходит ошибка в установке какого-либо параметра, весь вызов со всеми параметрами "откатывается обратно", не производя изменений. Доступные параметры:
size — размер окна в знакоместах, вида "80x25";
title — заголовок окна;
font.name — "имя" шрифта¹;
font.size — размер шрифта, вида "8x16" (для тайлового) или "12" (для TrueType);
font.codepage — только для тайлового, "кодировка" шрифта;
font.mode — только для TrueType, режим растеризации: monochrome, normal или lcd.

¹) В очередной раз изменен (упрощен) формат задания имени-типа шрифта. Теперь так:
1. font.name=default для дефолтного вложенного в .dll тайлового шрифта;
2. font.name=somename.ttf для TrueType;
3. font.name=somename.png для тайлового.

Упразднен дуализм tetminal_puts/terminal_printf. Теперь только printf, что для С/С++ должно быть фиолетово. На случаи, когда форматирование передаваемой строки нежелательно (маршалинг из другого ЯП), предусмотрены вызовы terminal_printf_noformat и terminal_options_noformat (они легко сокращаются в имени до желаемых при описании импортируемых из .dll вызовов).

Аналогично паре terminal_put/terminal_put_over, вызов terminal_printf дополнен симметричным terminal_printf_over. Это позволяет творить всякие забавные ништяки, см. cpp/demo.exe в архиве.

Ввод дополнен вызовом terminal_get_nonblocked, который ждет события ввода не вечно, а лишь указанное количество миллисекунд, после чего возвращает 0.

Вроде все.


В архиве две части -- для паскаля и для С++. Для паскаля, на котором я разговариваю лишь со словарем, все та же "демка" с одной только собачкой и все. Разве что обновлен биндинг (bearlibterminal.pas, который теперь везде использует AnsiString) и вызовы в самой программе скорректированы на новые.

Демо для C/C++ веселее, рекомендую ознакомится всем, независимо от лингвистических предпочтений. Там пять подпунктов, демонстрирующих те или иные моменты. Какие-то уже были, какие-то новые.


edit: Поправил архив, который не включал .lib-файл для C/C++.
Вложения
beta3v2.zip
(1.55 МБ) 109 скачиваний
Последний раз редактировалось Cfyz 27 янв 2013, 20:14, всего редактировалось 2 раза.
Пытается раскуклиться

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

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

Сообщение Apromix » 27 янв 2013, 20:08

Замечательно :) Берусь тестить в винде и линуксе :)

Давно хотел спросить, а почему cdecl используешь а не stdcall?

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

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

Сообщение Cfyz » 27 янв 2013, 20:22

Apromix писал(а):Замечательно :-) Берусь тестить в винде и линуксе :-)
В линуксе О_о? Его версии пока нет, хотя она обязательно появится.
Apromix писал(а):Давно хотел спросить, а почему cdecl используешь а не stdcall?
Cdecl позволяет делать вызовы с переменным числом параметров в отличие от stdcall. Кроме этого особых причин нет. Каких-либо причин против — тоже, во всех языках/платформах если уж разрешается импорт из .dll, так всегда со всеми основными соглашениями вызовов.
Пытается раскуклиться

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

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

Сообщение Apromix » 27 янв 2013, 20:26

Cfyz писал(а):В линуксе О_о?
Ну я через вайн. Пошло :) Классно вобщем сделано :) Сначала не понял, почему окно начало перегружаться при выборе кодировок, но потом въехал)) А как с шрифтом-картинкой обстоят дела? Вроде стены какие-то там видел в ресах :)

Ответить

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

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