Комментарии 13
Неплохо было бы добавить, что изначально блиттинг - калька с названия ddraw функции, которая мгновенно копирует предзагруженную текстуру, или чаще спрайт, в видеокарте в нужное место заднего буфера - буфер экрана на следующий кадр. А то не все поймут.
Добавил, спасибо.
Это название функции идёт ещё с Xerox Alto, её чуть ли не в микрокод добавили чтобы окошки было удобно рисовать. Тогда это была ещё даже не функция, а операция в микрокоде под мнемоникой BitBlT, которая расшифровывалась примерно как Bit Block Transfer, т.е. передача блока битов.
Операция брала прямоугольную область, копировала её в память экрана, попутно применяя к ней какие-то логические преобразования, то ли для прозрачности, то ли ещё для каких-то целей, например инверсии.
https://en.wikipedia.org/wiki/Bit_blit
https://research.swtch.com/bitblt - вот по этой ссылке лежит PDF, там всё описано применительно к Xerox Alto.
Т.к. битблт произносить неудобно, то добавили гласную, получился битблит. А дальше функции и железо, занимающиеся копированием и логическими преобразованиями окрестили блиттером.
А как хранились "Ромбы без углов"? Ну т.е. блиттеру нужно же знать не только сколько пикселей нарисовать, но и сколько пропустить? Или это просто частный пример "RLE, из которого можно рисовать", т.е. хранили число пропущенных пикселей, потом сколько нужно нарисовать, опять сколько пропустить и т.п.?
Там два случая, ромбы можно рисовать без rle просто зная математику, я описал её. А все что сверху рисуем уже с помощью 0xFF..X. фигры, верхние части зданий, анимации. В статье есть текстура фараона с понятной (надеюсь) разлиновкой, как это работает
Не, с RLE то понятно было, а вот с ромбами не сразу. Сейчас дошло:
в файле с метаданными хранится, что этот вот файл - ромб X на Y пикселей
в самом файле просто пиксели подряд
а дальше код считает, сколько на какой строке каких пикселей рисовать с учётом формы
По ходу дела в статье так и написано, просто не сразу осознал)
Судя по картинке там используется color key: первый цвет в текстуре, часто розовый для наглядности, воспринимается как прозрачный и не рисуется.
а любой другой байт N означает «дальше идут N обычных 16-битных пикселей».
по логике предполагаю, что тут имелось в виду "а любой другой байт K вместо 0xFF означает K цветных пикселей"? Просто потому что флагом прозрачности упомянут именно 255-ой "цвет" FF, а не его количество N.
игра достойная прохождения и через четверть века. Современный вариант с плоской графикой не так радует глаз.
Ограничения заставляют думать, в этом плане всегда нужно ставить границы и рамки.
Да, умели раньше… Мой фаворит — Carmageddon, который на процессоре 75 МГц умудрялся вообще в 8 мегабайт (!!!) вместить полигональный микрорайон города, полигональные машины и сотни спрайтовых бешеходов. И в наши дни совершенно не выглядит устаревшим (через nGlide).
Периодически приходится ставить Фараона (по моему в последний раз версию с gog). Мне тоже нравятся вот эти фишки производительности графики для старого железа.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как Фараон жил в 16 мегабайтах памяти