glVertex3fv( WorldModel->vertexes[ WorldModel->edges[ i ].v[ 0 ] ].position );
7
glVertex3fv( WorldModel->vertexes[ WorldModel->edges[ i ].v[ 1 ] ].position );
8
}
9
glEnd( );
Все прекрасно рисуется, но когда я пытаюсь работать с leaf'ами noda'ми и surface'ми то получается лабудень. В начале попробовал просто пройтись по всем ребрам фейсов, код:
C++ Source Code:
1
for( int i = 0; i < WorldModel->numsurfaces; i++ )
2
{
3
msurface_t *pface = &WorldModel->surfaces[ i ];
4
5
for( int o = 0; o < pface->numedges; o++ )
6
{
7
...
8
}
9
}
Но получил зависон. Выяснил что pface->numedges выдает то милиарды, то вообще минус. С листами и нодами тоже самое. Тут я подумал, что получил криво модельку, но однако с рёбрами, которые беруться из той-же модельки проблем нет. Полазил в паронойе, там вроде бы точно такой-же код работает на ура. Подскажите пожалуйста в чем моя ошибка, уменя уже совсем мысли кончились.
листы и ноды линкуются в один список. Поэтому сначала убедись что именно перед тобой mleaf_t или mnode_t. Проще всего это делать по контентсам. Но в даркплейсе, к примеру делают указатель на mplane_t нулевым. Впрочем это дело вкуса, оба варианта идентичны.
Всё заработало после того как я вытащил из паранои com_model.h
В сдк структуры нодов, листов и тд для програмного рендера, а они оказывается отличаются от аппаратного.
Я в шоке от такой подляны...
А вот интересно, в паранйе они этот файлик сами обновляли, или гдето надыбали?
Там даже комментарий сверху:
// 06/25/2002 MAH
// This header file has been modified to now include the proper BSP model
// structure definitions for each of the two Quakeworld client renderers:
// software mode and GL mode. Originally, Valve only supplied it with
// the software mode definitions, which caused General Protection Fault's
// when accessing members of the structures that are different between
// the two versions. These are: 'mnode_t', 'mleaf_t', 'msurface_t' and
// 'texture_t'. To select the GL hardware rendering versions of these
// structures, define 'HARDWARE_MODE' as a preprocessor symbol, otherwise
// it will default to software mode as supplied.
Почему время хранят во флоатах? просто я сейчас наткнулся на сервер, на котором карта не менялась 1 - 2 недели, так там изза переполнения флоата все жутко дергалось... Почему бы не хранить время в интах в миллисекундах?
Работать будет 49,710269(629) дней, с точностью в миллисекунду
можно и в интегере хранить, почему нет. Начиная со второй кваки, Кармак так и сделал. Только не обольщайся насчет 49 дней. Разрешение таймера ставят таким образом, чтобы на одну еденичку приходилась одна миллисекунда, и общее время работы таким образом составляет те же самые 23 дня. По уму карту надо рестартить при переполнении переменной, пример реализации такого рестарта можно подглядеть в ку3.
Вообще говоря в первой кваке время хранится не во флоате, а в дабле, просто серверное и клиентское время хранится во флоате по каким-то причинам, вероятно связанным с ограничениями виртуальной машины.
В целом особой разницы нету, но, допустим, если принудительно перевести ксаш на целочисленный отсчет времени, начнет глючить мовевитч в спирите и еще некоторые моменты - не хватит точности таймера. Впрочем если код изначально точился под максимальное разрешение в 1 мллисекунду, то проблем не будет.
Предиктинг опять же реализуется попроще.
Я тут над квейком 2 издевался, решил все ускорить, заменил:
C++ Source Code:
curtime = timeGetTime() - base;
на:
C++ Source Code:
curtime = timeGetTime() * 100 - base;
Все получилось, все заметно ускорилось, и загрузка тоже...
Просто так грузит первый уровень за 4 секунды, а с ускорением меньше чем за половину. Это что, ошибка в коде, сам код глючный, или это специально сделано было?