Извините, ничего не найдено.

mr.DIMAS · 06.12.2014, 18:36

Как правильно организовать перемещение персонажа? Сейчас у меня метод "в лоб". Создаем капсулу вокруг игрока и задаем ей линейную скорость в нужно направлении, отсюда всякие косяки в виде плохого перемещения по лестницам и наклонным поверхностям( даже когда трение выставлено в ноль ). Поэтому появилась идейка сделать перемещение на рейкастинге. Замысел такой: бросаем луч вниз под игроком, находим точку пересечения и перемещаем в нее игрока, затем кидаем еще луч перед игроком на небольшом расстоянии от него тоже вниз но с начальной точкой чуть выше точки пересечения первого луча( то бишь - высота шага ), если есть пересечение то можно сделать шаг -> делаем интерполяцию между двумя полученными точками. В принципе, такой подход работает и довольно неплохо. Но как делают труЪ пацаны?

Mr_F_ · 06.12.2014, 18:51

но с начальной точкой чуть выше точки пересечения первого луча( то бишь - высота шага )

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

ARA · 06.12.2014, 18:57

Но как делают труЪ пацаны?

Делать коллайдеры лестниц и всех непонятных мест для столкновений с гг в виде наклонённой сплошной плоскости.

Вован · 07.12.2014, 01:12

L.D.M.T. Выкладывал исходники для Blitz3D и среди прочих, лежал ничем не примечательный - fpstest. Вот в нём, идеальное управление, мне так кажется. Думаю, тебе не составит труда адаптировать его под C++

Вот кусок.

Function UpdatePlayer()

;look
mxspd=MouseXSpeed()*0.25
myspd=MouseYSpeed()*0.25
MoveMouse GraphicsWidth()/2,GraphicsHeight()/2
pitch=pitch+myspd
yaw=yaw-mxspd
If pitch<-90 Then pitch=-90
If pitch>90 Then pitch=90
RotateEntity camera,pitch,yaw,0
RotateEntity player,0,yaw,0

;movement
If KeyDown(200)
vz=vz+0.05
ElseIf KeyDown(20

<-- Это скобка.
vz=vz-0.05
EndIf
vz=vz*0.9
If KeyDown(203)
vx=vx-0.05
ElseIf KeyDown(205)
vx=vx+0.05
EndIf
vx=vx*0.9

;steps and floor collisions
pick=LinePick (EntityX(player),EntityY(player),EntityZ(player),0 ,-playerheight,0)
If pick
PositionEntity player,EntityX(player),PickedY()+playerheight,Enti tyZ(player)
vy=0
EndIf
vy=vy-0.2
vy=vy*0.9

;move player pivot
MoveEntity player,vx,0,vz
TranslateEntity player,0,vy,0

;move camera + player meshes smoothly
PositionEntity camera,EntityX(player),EntityY(camera),EntityZ(pla yer)
TranslateEntity camera,0,(EntityY(player)-(EntityY(camera)-cameraheight))*0.1,0

Весь.

А вообще, игра нормально идёт. Умудрился провалиться со второго этажа сквозь пол, а так всё норм. Cтелс как в Skyrim, темно как Alone in the Dark, страшно как в кино, только графику подправить бы. Ты игры делаешь и ракеты запускаешь, мне бы твои таланты...

mr.DIMAS · 14.12.2014, 00:59

Исправил много багов и поправил прозводительность. В общем в каждой части рендера было много CreateStateBlock() и таким образом я доверял стейты директу, как выянилось после профайлинга на этих стейтблоках падает до 15 процентов производительности, выпилив их в взял контроль над стейтами в свои руки я повысили производительность на 20 процентов( убрав лишние изменения стейтов - у меня Pure-device ). Сделал выбор с вертикальной синхронизацией или без. Максимальный фпс на моей машине - 90 к\с в шахте( тени от спотов и FXAA ).

Так вот тут сразу вопрос. Обычно я считал дельта-тайминг и просто домножал все значения на него чтобы игра шла нормально при любом фпс. Когда фпс от 30 до 60 кадров то все нормас работает, когда выходит из этих границ начинается ебала. В общем игра начинает работать не стабильно и физика тупить начинает. Как труЪ пацаны делают дельта тайминг? Читал это , но мне тамошние подходы не помогают.

pax · 14.12.2014, 03:35

Я бы так сделал (в Unity ограничение по времени работы физики на кадр задается):



var physicsStep = 1f/100f;  // 100 раз в секунду обновлять физику
var maxPhysicsTimePerFrame = 0.15f; // максимальное время работы физики за кадр
var lastTime = Now();
var physicsTimer = 0; // накопитель времени физики

while(true){
   var currentTime = Now();
   var deltaTime = currentTime - lastTime;
   lastTime = currentTime;

   physicsTimer += deltaTime;

   Update(deltaTime); 
   Render();

   var physicsSteps = (int)(physicsTimer / physicsStep); // число шагов физики
   physicsTimer -= physicsStep*physicsSteps; // сбрасываем таймер физики (оставляем остаток)

   var physicsWorkTime = 0;
   var physicsStartTime= Now(); 

   for(int i = 0; i < physicsSteps; i++){
      UpdatePhysics(physicsStep); // обновление физики
      var physicsEndTime = Now();
      physicsWorkTime += physicsEndTime - physicsStartTime;
      physicsStartTime = physicsEndTime;

      // ограничение по времени работы физики
      if(physicsWorkTime >= maxPhysicsTimePerFrame )
         break;
   }
}

pax · 14.12.2014, 13:35

Я тут подумал, скорее всего Render() в самый конец надо бы поставить, после цикла физики... и в Unity 50 раз по умолчанию в секунду физика работает, т.е. шаг физики 0,02 с (1/50)

mr.DIMAS · 14.12.2014, 14:01

Попробую так сделать.

Вопрос теперь по графическому конвейру. Вызов SetRenderState( D3DRS_COLORWRITEENABLE, 0 ) выключает запись цвета в буфер кадра, исключает ли он при этом работу пиксельного шейдера? Иными словами, при выключенной записи в буфер кадра будет ли работать пиксельный шейдер?

Mr_F_ · 14.12.2014, 14:10

Иными словами, при выключанной записи в буфер кадра будет ли работать пиксельный шейдер?

не факт.
советуют ставить NULL на PS: http://www.gamedev.net/topic/641257-...pass-worth-it/

не факт, потому что, к примеру, ты можешь делать clip/discard в шейдере, что повлияет на глубину тоже.
мне думается, что умный драйвер может не выполнять шейдеры, если дискарда точно нет, и запись выключена, но я не проверял.

mr.DIMAS · 14.12.2014, 14:20

Я просто оптимизациями занимаюсь, и пока довольно успешно( ибо уже выжал 30% ). Так вот деферед у меня организован хорошо, но есть один момент.

для каждого источника света
{
     ставим простейшие шейдеры для отрисовки в трафарет
    рисуем  ограничивающий меш в трафарет 
    ставим шейдеры для фулскрин квада( пиксельный отвечает за освещение )
    рисуем квад
}

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

bool boundingVolumeRender;
...
if( boundingVolumeRender )
   return float4( 1, 1, 1, 1 );
else
   calculateLighting

получается в пиксельном шейдере статическое ветвление, оно практически бесплатно, вершинный шейдер тоже не проблема, ибо разница только в матрицах - для ограничивающего объема это worldViewProjection, а для квада это просто projection.

mr.DIMAS · 14.12.2014, 15:14

2pax, плохо работает, физику все равно начинает шатать, что аж улетаю в небеса. буду сидеть разбираться, может найду выход из этой тупой ситуации.

нашел это - http://bulletphysics.org/mediawiki-1...ical_Game_Loop
попробую реализовать

mr.DIMAS · 14.12.2014, 16:03

Наконец-то все работает так как должно. Нужно было сразу загуглить bullet physics low fps.

В общем одной проблемой меньше

pax · 14.12.2014, 16:23

Сообщение от mr.DIMAS

2pax, плохо работает, физику все равно начинает шатать, что аж улетаю в небеса. буду сидеть разбираться, может найду выход из этой тупой ситуации.

я предположил как работает физика Unity. В Unity есть еще FixedUpdate (для применения сил к телам), он срабатывает ровно столько же раз, сколько и обновление физики, т.е. перед каждым UpdatePhysics(physicsStep) из моего примера, а Update используется для логики игры. Но это было всего-лишь мое предположение

как оно устроено.

mr.DIMAS · 14.12.2014, 16:30

Все равно спасибо за то, что помогаешь.

MiXaeL · 14.12.2014, 23:22