2009-12-16 4 views
4

Я пишу игровой движок для iPhone на основе плитки, и он работает, в общем, помимо следующего сбоя. В принципе, камера всегда будет держать плеер в центре экрана, и он перемещается, чтобы правильно следить за игроком и правильно рисует, когда он неподвижен. Однако в то время как игрок двигаются, плитки на поверхности игрок ходит по глюку, как показано:Сбой при перемещении камеры в OpenGL

http://img41.imageshack.us/img41/9422/movingy.png

По сравнению с неподвижным (правильным):

http://img689.imageshack.us/img689/7026/still.png

Кто-нибудь есть любая идея, почему это может быть?


Спасибо за ответы. Ошибка с плавающей запятой была моей первой мыслью, и я попытался немного увеличить размер плитки, но это не помогло. Изменение glClearColor на красный все еще оставляет черные зазоры, поэтому, возможно, это не ошибка с плавающей запятой. Поскольку плитки вообще будут использовать разные текстуры, я не знаю, можно ли использовать вершинные массивы (я всегда думал, что одна и та же текстура должна быть применена ко всему массиву, исправьте меня, если я ошибаюсь), и я не думаю, что VBO доступен в OpenGL ES. Настройка фильтрации для ближайшего соседа улучшила ситуацию, но сбой все равно происходит каждые десять кадров или около того, а результат pixelly означает, что это решение не является жизнеспособным в любом случае.

Основное различие между тем, что я делаю сейчас, и тем, что я делал в прошлом, заключается в том, что на этот раз я перемещаю камеру, а не неподвижные объекты в мире (т. Е. Плитки, игрок все еще переехал). Код, я использую для перемещения камеры является:

void Camera::CentreAtPoint(GLfloat x, GLfloat y) 
{ 
glMatrixMode(GL_PROJECTION); 
glLoadIdentity(); 
glOrthof(x - size.x/2.0f, x + size.x/2.0f, y + size.y/2.0f, y - size.y/2.0f, 0.01f, 5.0f); 
glMatrixMode(GL_MODELVIEW); 
} 

Есть проблема с делать вещи таким образом, и если да, есть ли решение?

+0

Просто хотел убедиться, что вы понимаете, что GL_NEAREST применяется к параметрам фильтра, но GL_CLAMP_TO_EDGE применяется к параметрам текстурной упаковки, поэтому вы все равно можете попробовать. Не обращайте внимания на это, если вы уже это пробовали. –

+0

Я должен был упомянуть, я уже пробовал. –

ответ

2

Мое первое предположение было бы floating point rounding error. Это может привести к тому, что координаты для ваших квадроциклов будут немного меньше, что приведет к появлению пробелов. Чтобы проверить это, вы можете попробовать изменить glClearColor() и посмотреть, не изменились ли с ним пробелы.

Одним из решений этого было бы сделать плитки немного большими. Требуется очень небольшое приращение (например, 0,0001f), чтобы покрыть эту ошибку.

В качестве альтернативы вы можете попробовать использовать Vertex Array или VBO для хранения вашей наземной сетки (гарантируя, что смежные квадраты разделяют вершины). Я ожидаю, что это решит проблему, но я не уверен на 100% - и она также должна быть быстрее.

+0

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

0

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

0

Его из-за фильтрации .. использование хомута до края и оставить границу с 1 или 2 пикселя .. поэтому у нас есть возможность для ГРАНИЦЫ в glTexImage вызове ..


4-ое изменение параметра из 0 до 1

Смежные вопросы