Тема: LGL v2.0 - графическая библиотека, VGA 13h, 320x200x256.

Ну вот, мне потребовалось около 3 лет неспешной возни, проб и ошибок, чтобы наконец-то создать свою первую графическую библиотеку, которую можно назвать законченным творением, а не прикрепить ярлык "в разработке". Это радует. Возня с этим кодом затянулась на 10 месяцев примерно. Это не значит, что я все свое свободное время тратил на нее, хорошо, если это будет 10% только, но тем не менее. Когда я только начинал, то уж никак не ожидал, что эта задача окажется настолько недооцененной мной. Казалось - всего-то, работы на, от силы, месяц. И это так, если-бы не филонил
Я уже показывал эту библиотеку в действии, и со временем, собираюсь еще не раз показать, ибо идей для проектов довольно много, и при грамотной разработки, игрушки будут выглядеть неплохо и заработают даже на 386 процессорах, лишь-бы был VGA адапатер
LGL имеет не очень много фишек, которые отличают ее в положительную сторону от других графических библиотек, которых много под этот режим, но мне, даже просто для себя, требовалось что-то свое.

Плюшки

-Поддержка 32-битных инструкций процессоров выше 286. Библиотека автоматически определяет, какой процессор установлен на компьютере, и исходя из этого использует 16-бит, или-же доступные 32-битные аналоги для функций. Это не значит, что все станет в 2 раза быстрее, процентное соотношение прироста в скорости будет зависеть от многих факторов, это может быть и 80 процентов. Но в среднем - 10
-Поддержка сжатых по алгоритму RLE спрайтов. Сжатые спрайты не только занимают меньше памяти (иногда - существенно меньше) но также и выводятся, в общем случае, как ни парадоксально, быстрее своих несжатых собратьев. Везде, если используются спрайты, следует стараться исопользовать RLE спрайты, а не обычные.
-Библиотека способна рисовать загруженные изображения не только на главном экранном буфере, но также и на других изображениях формата OT_Img или OT_Spr. То-есть, вполне можно создать изображение размером 40x30 пикселей, и рисовать картинки прямо на нем.
-Библиотека полностью поддерживает вывод с отсечением. Картинки могут безболезненно забегать за край буфера экрана, или куда там они рисуются, и это не вызовет никаких проблем.
-Поддержка оптимизированных процедур масштабирования и поворота изображения. Это довольно ресурсоемкие алгоритмы для старого железа, особенно, если речь идет о том, чтобы делать это "на лету", поэтому я оптимизировал как мог. Тем не менее, не рекомендую применять эти процедуры на больших изображениях, или слишком часто за генерацию кадра, а то FPS серьезно пострадает.
-Модуль ввода поддерживает мышь, а также клавиатурный ввод, в том числе, свободно отлавливаются одновременные нажатия на несколько клавиш, что часто нужно для игр.
-Псевдоархивы помогут прибраться, если для проекта вдруг понадобилось 400 файлов, и уже не солидно таскать их одной здоровой кучей.
-Поддержка XMS-памяти будет полезна для жирных программ, которым не хватает места на данные. Нет, это не совсем халявные мегабайты полноценной памяти, а скорее удобный инструмент для временной выгрузки данных из основной памяти.
-Поддержка спрайтовых шрифтов. Они не очень шустрые, однако при использовании последних нет нужды в программе-русификаторе. Можно создавать новые, причем, размер символов может быть разным.
-До кучи: снятие скриншотов, замер FPS, операции с палитрами, простейшая графика (точки, линии, прямоугольники), удобная поддержка анимации, отражения картинок, и много других мелочей.

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

По описанию - сочно
Ещё одна библиотека в копилку VGA. Чтож спасибо за такой ценный вклад в downgrade-игродел и
демосцену под DOS-ом.

но мне, даже просто для себя, требовалось что-то свое.

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

P.S: 13h неубиваем

Посмотрел демки, нормально, шрифт только слишком мелкий. Я в DOSBox поставил настройку scaler=supereagle,
это что-то типа как в эмуляторах старых приставок, алгоритм увеличения разрешения. Просто размазывает.

Сообщение от >Quiet Snow<

Просто размазывает.

Имеете в виду, что такой мелкий шрифт нечитабелен из-за сильного размытия, вызванного скалером?
Да, проблемка. Но, в принципе, новые шрифты можно без проблем нарисовать, и, возможно, я сделаю себе парочку, когда пойму, что они нужны. А мне больше нравятся обычные скалеры по методу ближайшего соседа - большие квадратики, а большие квадратики мне симпатичны
Между тем, такой мелкий размер шрифта выбирался не случайно: если сделать его более крупным, то на экран будет помещаться очень мало информации, что совсем не радует

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

Тоже верно.

Что такой мелкий шрифт нечитабелен из-за сильного размытия, вызванного скалером?

Да скалер использует какой-то хитрый алгоритм из-за чего происходит такое смешивание. Причём графика вроде бы нормально.
Ну т.е. я как то специально сидел тестил все эти значения в DOSBox-e, подбирая более менее качественный алгоритм, однако
понятно, что информация не берётся просто так из воздуха, это как сравнивать интерполяцию и реальный сигнал. Что-то
алгоритм делает хорошо, что-то плохо. Короче не суть. Шрифт да дело десятое, главное есть основа - сама библиотека.

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

Это можно исправить, нажав ctrl (сменив язык))

Это происходит если перехватывать вектор 9 и НЕ передавать управление старому обработчику.
Для современных тачек некритично передавать управление, даже для 386-х некритично.
Но абадябер видимо решил сэкономить немного тактов, чтобы не обрабатывать старый 9h и 16h.

Во всяком случае, только в такой ситуации наблюдал подобный "эффект", вырубающийся CTRL-ом.

Это происходит если перехватывать вектор 9 и НЕ передавать управление старому обработчику.
Но абадябер видимо решил сэкономить немного тактов, чтобы не обрабатывать старый 9h и 16h

Действительно, у меня в новом обработчике Int 9 вызов старого в конце не происходит, а по хорошему - должен происходить. Kakos_nonos, спасибо за багрепорт. Будет исправлено. Кстати, можете попробовать проверить, не происходит-ли тоже самое с русификатором keyrus? Насколько помню, я тестировал клавиатурный модуль под чистой DOS, и у меня такой проблемы не было. Может быть, что-то специфичное для этого русификатора проявляется?... Ну, не суть, исправить все-равно нужно.

Абадябер, можете написать наипростейший пример вывода одного спрайта на экран.

Окей, сделаю, и выложу.

Вот пример, прикрепил к сообщению.
Основная идеология тут такая: чтобы картинку на экране нарисовать, ее сначала нужно загрузить из файла. И не забыть про 8-битную палитру. Как получить картинку и палитру, показано внутри архива, при условии, что все, что у нас есть - это 24-битная картинка BMP, и все нужные утилиты. Потом, когда у нас есть файл с палитрой, и файл с картинкой, можно загрузить их стандартными операторами в программе, и нарисовать на экране. Тут реально следует писать гайд, по процедурам и объектам с их методами, а то я представил себя на месте человека, который видит все это первый раз, и понял, что тоже ничего-бы не понял.

Если в паскале запускать

Кстати, вполне можно запускать из паскаля, однако он отъедает себе около 300Кб памяти, из-за чего на данные для нашей программы остается мизер, и это следует учитывать. Поэтому, как только программа вместо запуска напишет что-то вроде "Unable to create memory buffer..." (лол, вспомнил, как она выдала эту строчку во время третьего по счету запуска моей демки DOZ на Chaos Constructions - сделал жутчайший фейспалм, а потом вообще обнаружил почему - в той версии библиотеки был баг, из-за которого вероятность успешного запуска зависела от состояния оперативной памяти - иными словами, была возможность, что она вообще-бы ни разу не запустилась), то это значит, что все дальнейшие тесты нужно делать уже вне паскаля.

Также. Прицепил архив с исправленной версией модуля LInput. Там, по сути, только 2 команды добавлено, для вызова старого обработчика. Вроде, работает. Нужно заменить старый LINPUT.PAS этим файлом, а потом загрузить главную программу, с которой проблема, и сделать полный Build, чтобы перекомпилировались измененные модули. Буду благодарен, если вы, Kakos_nonos, расскажете, стало-ли лучше после этих изменений

Сообщение от >Quiet Snow<

Это происходит если перехватывать вектор 9 и НЕ передавать управление старому обработчику.

Забавно, я тут лазал по сети в поисках подробной информации о работе с клавитурой, и наткнулся на как раз таки описание именно этого случая. Вы были предельно правы, и вот в чем именно заключалось дело:
Информация взята [Ссылки могут видеть только зарегистрированные пользователи. ]

When I was writing a simple handler to test the info in this file I did
something REALLY stoopid which I would like to share with the world. I
thought that my program was stuffing the keyboard up because when I exited
the program my editor (Borland Pascal 7.0) would act as though the control
button was being held down (I'm sure some of you have already started
laughing by now). I had to press it after each time I ran the program
just to sort it out. After spending a few hours looking all over the place
for info on what could possibly be wrong I realised what I was doing. I was
pressing CTRL-F9 to compile the program which would also immediately make it
run and I was releasing the control key when my program was running, ie the
regular BIOS handler was not getting the control key's "key up" command and
still thought it was being held down when my program returned control to
it. Moron.....