Выравнивание по 4. Очень критичная штука. Некоторые программы получают оффсет на палитру с конца файла, причём всегда имеют в виду, что выравнивание - есть.
Начал добавлять конвертер карт, пока что не проверенно, и добавлено только 2 варианта (Half Life/Blue Shift)
Post automatically merged:
@Дядя Миша если можно есть вопрос 29 формат не поддерживает палитру в встроенных текстурах?
Если между 30 и 29 сохранять, то нужно преобразовать все текстуры в палитру Quake и обратно?
Не поддерживает. Впрочем Ксаш вообще не смотрит на номер версии, как я уже и говорил - ориентируется по размеру текстуры, есть там палитра или нету. А преобразовать халфовские текстуры в квейковскую палитру проблематично. Будет деградация цветов. Сам преобразователь довольно простой, но качество станет ужастным.
Не поддерживает. Впрочем Ксаш вообще не смотрит на номер версии, как я уже и говорил - ориентируется по размеру текстуры, есть там палитра или нету. А преобразовать халфовские текстуры в квейковскую палитру проблематично. Будет деградация цветов. Сам преобразователь довольно простой, но качество станет ужастным.
Ну у меня в квантизаторе можно подставлять палитру нужную, и это работает даже
Код:
Quantizer* tmpCQuantizer = new Quantizer(256, 8);
tmpCQuantizer->SetColorTable(palette, 256); // установить свою палитру, если пропустить этот участок кода то остается новая на 256 цветов
tmpCQuantizer->ApplyColorTable((COLOR3*)data, width * height); // data исходное изображение
delete tmpCQuantizer;
// после чего в data будет уже преобразованное в другую палитру изображение
Просто уточнил, вдруг кто-то из 30 версии захочет сделать 29 или там bsp2
Вообще у тебя там логические ошибки:
1. Старый 32-х битный формат для квейка называется не 2BSP, а 2PSB. Кто-то не понимал как устроен Little-Endian и записал название кверхногами.
2. Квака не понимает цветное освещение внутри карты, единственный кто сможет это загрузить - Ксаш
Там освещение внешнее хранится в файликах qlit, поэтому его лучше записывать туда, а не в карту.
Ну я открывал карту какую-то из ксаша, очень страшная лайтмапа получалась(ребра и полосы какие-то, я кажется выше кидал скрин)
sponza.bsp или как там карта называлась, сейчас не могу написать точно название)
Нет, ничего абсолютно менять не надо, движок там сам на три умножает, если грузит внешний файл. Там спереди 8 байт - идентификатор QLIT и следующий за ним uint - номер версии 1.
А потом дата с цветными лайтмапами, как если бы она лежала в LUMP_LIGHTING.
Post automatically merged:
Может тебе долго будет разбираться что там к чему в Ксаше, дам подсказку.
C++:
typedef struct
{
float vecs[2][4]; // texmatrix [s/t][xyz offset]
int miptex;
int flags;
} dtexinfo_t;
Это исходная структура. Реально поле flags использует всего 1 бит. Т.е. 30 бит болтаются без дела.
Я распилил переменную flags на две 16 битных, вот так:
C++:
typedef struct
{
float vecs[2][4]; // texmatrix [s/t][xyz offset]
int miptex;
short flags;
short faceinfo; // -1 no face info otherwise dfaceinfo_t
} dtexinfo_t;
На совместимость это никак не повлияло. Теперь новая переменная faceinfo хранит в себе записанный номер дополнительных данных в расширенных лумпах BSP30ext. Обращается в LUMP_FACEINFO
к структуре
C++:
typedef struct
{
char landname[16]; // name of decsription in mapname_land.txt
unsigned short texture_step; // default is 16, pixels\luxels ratio
unsigned short max_extent; // default is 16, subdivision step ((texture_step * max_extent) - texture_step)
short groupid; // to determine equal landscapes from various groups, -1 - no group
} dfaceinfo_t;
landname и groupid - это для ландшафтов, тебе это не нужно.
max_extent - это использует компилятор.
texture_step - вот здесь и хранится разрешение лайтмапы. Дефолтное в халфе и кваке равно 16.
Чем ниже число - тем выше разрешение, т.к. оно определяет соотношение люкселей к текселю.
16 - это значит что на квадрат 4х4 текселя (то есть текстурных пикселей) приходится всего один люксель (т.е. пиксель лайтмапы). 1 - минимально возможное значение, когда каждому текселю соответствует 1 люксель и тени становятся чёткие как в дуум3. Дальше в движке в mod_bmodel.c ищи обращение к переменным texture_step и думаю сообразишь что к чему.
Расширенные лумпы в BSP30Ext есть ВСЕГДА! Даже если у лайтмапы дефолтное разрешение. Будет как минимум один faceinfo где и будет записано что разрешение 16.
BSP30ext не получится конвертировать в другие форматы, т.к. они не имеют его возможностей.
К тому же он сам по себе так устроен, чтобы его могли загружать любые движки, даже не подозревая о том, что формат - расширенный.
Я вот не помню, с тобой мы обсуждали или с Альбатроссом, но BSP30ext как раз и следует детектировать по сигнатуре XASH, которая следует сразу за dheader_t. Она там есть вообще всегда, даже если никакие из возможностей BSP30ext не используются.
Понял, а там формат достаточно сильно отличается от нормального BSP? Ну всмысле если лишнее убрать я его могу легко загрузить, или там слишком отличается и нельзя легко загрузить как обычный BSP?