xrModder,
Спасибо! Т.е. ни в каких исходниках релизного кода нет, ни в ТЧ ни в ЧН ни в ЗП? Ну не считая 1.0007. А как на счёт патча 1.0004?
Полная версия этой страницы: Редактирование движка
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97
Цитата(XinnogeN @ 11.11.2019, 14:01) 
xrModder, Спасибо! Т.е. ни в каких исходниках релизного кода нет, ни в ТЧ ни в ЧН ни в ЗП? Ну не считая 1.0007. А как на счёт патча 1.0004?
Тут в связанных темах есть исходники релизной ЧН и ЗП, а v1.0007rc1 - это практический тот же 1.0006.
xrModder,
gold-1.5.00 и gold-1.6.00 ?
gold-1.5.00 и gold-1.6.00 ?
Цитата(ForserX @ 10.11.2019, 19:33)
XinnogeN, 2005. Но нужно ли оно тебе? Тут сейчас на 2015-2019 народ сидит...
Ты можешь взять уже готовый вариант. Тот же Oxygen на 2017-2019 студии собирается
Цитата(DiaWorld @ 10.11.2019, 17:10)
Если собрать двигло на 2019 версии студии, проблем не будет ?
Ибо помнится мне, что я собирал на 2017 версии, и там если не ошибаюсь что то с рендером не ладно было, будет ли такое на 2019 версии, кто нибудь знает ?
Ибо помнится мне, что я собирал на 2017 версии, и там если не ошибаюсь что то с рендером не ладно было, будет ли такое на 2019 версии, кто нибудь знает ?
Ты можешь взять уже готовый вариант. Тот же Oxygen на 2017-2019 студии собирается
Да с оксиком то и коту понятно. Я имел виду про ТЧ движок, просто забыл уточнить.
atanda,
Не совсем так. У студий разная база инклудов. Сейчас парился в КрайЭнгине с ресурсами кода.
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include\afx............... их нет в других визуалках.
Кнопки гуи вообще в каждой версии по новой заново сделаны. И никакие винресы и еще уесы -1 всякие не подходят, кроме афхресов.
Если проект сделан на 2008, то шансов переехать на 2013 почти ноль (по крайей мере у меня).
Еще на Toolkit Pro всё взяли завязали, а там надо еще и эту ToolkitPro собрать в новой визуалке, а эта ToolkitPro манала собираться.
Цитата(atanda @ 11.11.2019, 09:45)
Имхо, если и переносить, то как минимум на 2013 студию. Ибо перенос на 2013 осуществляется +- как и на 2010.
Не совсем так. У студий разная база инклудов. Сейчас парился в КрайЭнгине с ресурсами кода.
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include\afx............... их нет в других визуалках.
Кнопки гуи вообще в каждой версии по новой заново сделаны. И никакие винресы и еще уесы -1 всякие не подходят, кроме афхресов.
Если проект сделан на 2008, то шансов переехать на 2013 почти ноль (по крайей мере у меня).
Еще на Toolkit Pro всё взяли завязали, а там надо еще и эту ToolkitPro собрать в новой визуалке, а эта ToolkitPro манала собираться.
Цитата(xrModder @ 11.11.2019, 15:20)
Цитата(XinnogeN @ 11.11.2019, 14:01)
xrModder, Спасибо! Т.е. ни в каких исходниках релизного кода нет, ни в ТЧ ни в ЧН ни в ЗП? Ну не считая 1.0007. А как на счёт патча 1.0004?
Тут в связанных темах есть исходники релизной ЧН и ЗП, а v1.0007rc1 - это практический тот же 1.0006.Код чистого неба точно не релизный - разные рендеры. В коде доступном баг с кубической тенью вокруг ГГ.
Дизель,
В релизе ЧН используется dxsdk за 2009 год?
В релизе ЧН используется dxsdk за 2009 год?
XinnogeN, 2008-2009 - смотря какая версия. 1510 - 2009 однако на R3
Дизель,
Я когда собирал 1.5.10 в 2005 студии-он у меня просил либу которая есть только в 2008-м. Так как быть-взять за 2009 год и к нему доложить либу из 2008 года?
Если, что я извеняюсь за нубские вопроссы-я ток учусь
Я когда собирал 1.5.10 в 2005 студии-он у меня просил либу которая есть только в 2008-м. Так как быть-взять за 2009 год и к нему доложить либу из 2008 года?
Если, что я извеняюсь за нубские вопроссы-я ток учусь
Нашел причину, почему дрожат объекты. Это чуть ранее здесь обсуждалось. Оказалось, причина в фпс: чем он больше частоты монитора, тем сильнее дрожит. С включенным всинк порядок. Например, снижение фов вызывает увеличение фпс, объекты сильнее дрожат. Перемещение на край локации тоже повышает фпс из-за снижения кол-ва геометрии и т.д. А вот почему из-за повышенного фпс начинается дрожание, тут хотелось бы разобраться, очень интересно. Может вообще драйвер дурит? Или это банальный артефакт из-за превышения фпс выше частоты монитора?
upd.
Даже не выше частоты монитора, а выше 60 Гц. У меня моник 120 Гц, так что разница заметна. При 120 фпс практически незаметные микро-подергивания остаются, как будто у матрицы проекции сдвиг меняется, а при 60 фпс все абсолютно стабильно. И не то чтобы дрожание при 120 фпс было, а смещение объекта туда-сюда раз в 1-3 сек.
Может там с анимацией или обновлением физики какие-то неувязки получаются? И то и другое вроде с частотой 30 Гц обновляется.
upd.
Даже не выше частоты монитора, а выше 60 Гц. У меня моник 120 Гц, так что разница заметна. При 120 фпс практически незаметные микро-подергивания остаются, как будто у матрицы проекции сдвиг меняется, а при 60 фпс все абсолютно стабильно. И не то чтобы дрожание при 120 фпс было, а смещение объекта туда-сюда раз в 1-3 сек.
Может там с анимацией или обновлением физики какие-то неувязки получаются? И то и другое вроде с частотой 30 Гц обновляется.
XinnogeN, я не помню точно. Там разница только в 2009-2010 из-за dxerr и dxerr9
Дизель,
Да, dxeer9 нет ни 2009 ни 2010. А он то её и просил.
Да, dxeer9 нет ни 2009 ни 2010. А он то её и просил.
XinnogeN, тогда 2008 - просто я давно на 2010 директе сижу, потому запамятовал. Извиняюсь.
Цитата(XinnogeN @ 12.11.2019, 01:15)
Да, dxeer9 нет ни 2009 ни 2010. А он то её и просил.
dxeer9 спокойно меняется на dxeer, который есть DXSDK 2010.
xrModder,
Он у меня наоборот просит dxeer9 который есть в 2008-м а не dxeer.
Он у меня наоборот просит dxeer9 который есть в 2008-м а не dxeer.
Цитата(XinnogeN @ 12.11.2019, 16:41)
xrModder, Он у меня наоборот просит dxeer9 который есть в 2008-м а не dxeer.
xrModder,
Ок! Не подскажешь в чём загвоздка, установил vs 2005 pro rus sp1 компилю но с кучами ошибок и предупреждений а компилю в vs 2005 team suite sp1 всё Ок! Это чё глюк студии?
Ок! Не подскажешь в чём загвоздка, установил vs 2005 pro rus sp1 компилю но с кучами ошибок и предупреждений а компилю в vs 2005 team suite sp1 всё Ок! Это чё глюк студии?
Цитата(XinnogeN @ 12.11.2019, 17:40)
xrModder, Ок! Не подскажешь в чём загвоздка, установил vs 2005 pro rus sp1 компилю но с кучами ошибок и предупреждений а компилю в vs 2005 team suite sp1 всё Ок! Это чё глюк студии?
Хз, никогда не связывался с Visual Studio 2005. Советую перейти в более новую версию Visual Studio.
xrModder,
Пробывал включить dxerr из 2010-го но нечего не получается-выдаёт ошибку а вот из 2009 года берёт. Судя по всему надо менять студию так сказать для современных dxsdk.
Пробывал включить dxerr из 2010-го но нечего не получается-выдаёт ошибку а вот из 2009 года берёт. Судя по всему надо менять студию так сказать для современных dxsdk.
Цитата(XinnogeN @ 12.11.2019, 22:31)
xrModder, Пробывал включить dxerr из 2010-го но нечего не получается-выдаёт ошибку а вот из 2009 года берёт. Судя по всему надо менять студию так сказать для современных dxsdk.
Хоть бы выложил лог ошибки.
xrModder,
Compiling...
stdafx.cpp
Compiling...
xrSyncronize.cpp
os_clipboard.cpp
rt_lzo_init.cpp
rt_lzo1x_d3.cpp
rt_lzo1x_d2.cpp
rt_lzo1x_d1.cpp
rt_lzo1x_9x.cpp
rt_lzo1x_1.cpp
LzHuf.cpp
rt_compressor9.cpp
rt_compressor.cpp
ppmd_compressor.cpp
memory_monitor.cpp
xrstring.cpp
xrsharedmem.cpp
xr_shared.cpp
crc32.cpp
xrDebugNew.cpp
xrMemory_subst_msvc.cpp
xrMemory_subst_borland.cpp
Compiling...
xrMemory_pso_Fill32.cpp
xrMemory_pso_Fill.cpp
xrMemory_pso_Copy.cpp
xrMemory_POOL.cpp
xrMemory_debug.cpp
xrMemory_align.cpp
xrMemory.cpp
memory_usage.cpp
memory_allocation_stats.cpp
file_stream_reader.cpp
stream_reader.cpp
Xr_ini.cpp
NET_utils.cpp
log.cpp
LocatorAPI_defs.cpp
LocatorAPI_auth.cpp
LocatorAPI.cpp
FS.cpp
FileSystem_borland.cpp
FileSystem.cpp
Compiling...
xr_trims.cpp
string_concatenations.cpp
clsid.cpp
_std_extensions.cpp
cpuid.cpp
_sphere.cpp
_math.cpp
_compressed_normal.cpp
xrCore.cpp
FTimer.cpp
Compiling...
Model.cpp
TLHELPProcessInfo.cpp
NT4ProcessInfo.cpp
IsNT.cpp
GetLoadedModules.cpp
CrashHandler.cpp
BSUFunctions.cpp
BlackBoxUI.cpp
Compiling...
stdafx_.cpp
Compiling resources...
Linking...
Creating library ..\..\..\libraries\xrCore.lib and object ..\..\..\libraries\xrCore.exp
Generating code
Finished generating code
dxerr.lib(dxerra.obj) : fatal error LNK1103: debugging information corrupt; recompile module
Лог
Compiling...
stdafx.cpp
Compiling...
xrSyncronize.cpp
os_clipboard.cpp
rt_lzo_init.cpp
rt_lzo1x_d3.cpp
rt_lzo1x_d2.cpp
rt_lzo1x_d1.cpp
rt_lzo1x_9x.cpp
rt_lzo1x_1.cpp
LzHuf.cpp
rt_compressor9.cpp
rt_compressor.cpp
ppmd_compressor.cpp
memory_monitor.cpp
xrstring.cpp
xrsharedmem.cpp
xr_shared.cpp
crc32.cpp
xrDebugNew.cpp
xrMemory_subst_msvc.cpp
xrMemory_subst_borland.cpp
Compiling...
xrMemory_pso_Fill32.cpp
xrMemory_pso_Fill.cpp
xrMemory_pso_Copy.cpp
xrMemory_POOL.cpp
xrMemory_debug.cpp
xrMemory_align.cpp
xrMemory.cpp
memory_usage.cpp
memory_allocation_stats.cpp
file_stream_reader.cpp
stream_reader.cpp
Xr_ini.cpp
NET_utils.cpp
log.cpp
LocatorAPI_defs.cpp
LocatorAPI_auth.cpp
LocatorAPI.cpp
FS.cpp
FileSystem_borland.cpp
FileSystem.cpp
Compiling...
xr_trims.cpp
string_concatenations.cpp
clsid.cpp
_std_extensions.cpp
cpuid.cpp
_sphere.cpp
_math.cpp
_compressed_normal.cpp
xrCore.cpp
FTimer.cpp
Compiling...
Model.cpp
TLHELPProcessInfo.cpp
NT4ProcessInfo.cpp
IsNT.cpp
GetLoadedModules.cpp
CrashHandler.cpp
BSUFunctions.cpp
BlackBoxUI.cpp
Compiling...
stdafx_.cpp
Compiling resources...
Linking...
Creating library ..\..\..\libraries\xrCore.lib and object ..\..\..\libraries\xrCore.exp
Generating code
Finished generating code
dxerr.lib(dxerra.obj) : fatal error LNK1103: debugging information corrupt; recompile module
Всем привет. Небольшой вопрос, касательно оружия. Подскажите, как сделать в движке, чтобы при помещении оружия(\бинокля\гранаты) в слот, этот предмет не брался в руки сам по себе ? Т.е просто переместить оружие в слот, а доставать только по вызову
А никто случайно не делал такую дичь, как взгляд на мир со стороны НПС? Чтобы можно было подрубить какой-нибудь мод на свободный алайф, и смотреть на все это от лица НПС?
Возможно, с отображением различных путей, показа "чувств" нпс (звуки, реакция на убийства, стрельбу, монстров) и так далее. В 1935, вроде, можно было включать всю эту тех. информацию.
Возможно, с отображением различных путей, показа "чувств" нпс (звуки, реакция на убийства, стрельбу, монстров) и так далее. В 1935, вроде, можно было включать всю эту тех. информацию.
Цитата(DoberBull @ 14.11.2019, 13:09)
Небольшой вопрос, касательно оружия. Подскажите, как сделать в движке, чтобы при помещении оружия(\бинокля\гранаты) в слот, этот предмет не брался в руки сам по себе ? Т.е просто переместить оружие в слот, а доставать только по вызову
Так там это уже есть - аргумент bNotActivate в функции ActivateSlot инвентаря (ЕМНИП).
Цитата(zibit_93 @ 15.11.2019, 00:15)
А никто случайно не делал такую дичь, как взгляд на мир со стороны НПС? Чтобы можно было подрубить какой-нибудь мод на свободный алайф, и смотреть на все это от лица НПС?
В каком-то билде было точно
А вообще присобачить камеру нетрудно, взять хотя бы вполне работоспособный в финалке "alien mode" у кровососа.
Цитата(zibit_93 @ 15.11.2019, 03:15)
А никто случайно не делал такую дичь, как взгляд на мир со стороны НПС? Чтобы можно было подрубить какой-нибудь мод на свободный алайф, и смотреть на все это от лица НПС?
Возможно, с отображением различных путей, показа "чувств" нпс (звуки, реакция на убийства, стрельбу, монстров) и так далее. В 1935, вроде, можно было включать всю эту тех. информацию.
Всё это есть в debug или mixed-версии движка (как минимум в ТЧ).
Возможно, с отображением различных путей, показа "чувств" нпс (звуки, реакция на убийства, стрельбу, монстров) и так далее. В 1935, вроде, можно было включать всю эту тех. информацию.
Цитата(xrModder @ 15.11.2019, 06:04)
Всё это есть в debug или mixed-версии движка (как минимум в ТЧ).
да, поддерживаю. 1.007 имел весь код для этого, только вид какой то странный - как из трубы
Цитата(Winsor @ 18.11.2019, 17:28)
да, поддерживаю. 1.007 имел весь код для этого, только вид какой то странный - как из трубы
Все, как в симуляции: какой фов у нпц - такой и у камеры
Подскажите пожалуйста, почему в vs 2019 не прописуются доп. пути lib и include - он всё равно лезет по стандартным путям в студию а то что я указал никак не видет. Заранее благодарен!!!
Возвращаясь к теме подёргивания худа оружия в руках (когда игрок стоит на месте и не крутит камеру) - кажется нашёл одну из его причин (в ЗП).
Позиция камеры зависит от позиции объекта игрока. Даже когда игрок стоит - его позиция незначительно меняется (4\5 знак после запятой), издалека это не заметно, но когда мы близко приближаем модель - именно эта погрешность и даёт дрожание худа в покое.
В моём случае источник дрожания оказался в:
1) В void CActor::g_Physics(Fvector& _accel, float jump, float dt) есть вызов character_physics_support()->movement()->Calculate(...)
2) Это void CPHMovementControl::Calculate(...). В этой функции есть есть m_character->IPosition(vPosition); --> она возвращает интерполированную позицию объекта и именно она содержит погрешности на каждом кадре.
3) Если заменить её например на m_character->GetPosition(vPosition); то погрешность исчезает и вместе с ней дрожание камеры.
Каких либо отличий в передвижении игрока после её замены я не заметил (возможно она видна только в мультиплеере), как вариант можно делать такую подмену только во время прицеливания. В дебри кода IPosition() лезть уже не стал (это void CPHSimpleCharacter::IPosition(Fvector& pos)).
Помимо этого осталась проблема с дрожанием худа во время кручения камеры.
Но когда игрок стоит на месте и не крутит камерой - вектора поворотов тоже статичны (в отличии от позиции). Я полагаю тут дело тоже в погрешности, просто искать её надо в других функциях, которые отвечают за перерасчёт поворота камеры.
Плюс надо учесть что эта погрешность от поворота не исчезает когда игрок перестаёт крутить камеру. Это хорошо заметно как раз на прицелах - при разном повороте прицельная сетка на модели временами будет чуть левее или правее центра экрана.
Позиция камеры зависит от позиции объекта игрока. Даже когда игрок стоит - его позиция незначительно меняется (4\5 знак после запятой), издалека это не заметно, но когда мы близко приближаем модель - именно эта погрешность и даёт дрожание худа в покое.
В моём случае источник дрожания оказался в:
1) В void CActor::g_Physics(Fvector& _accel, float jump, float dt) есть вызов character_physics_support()->movement()->Calculate(...)
2) Это void CPHMovementControl::Calculate(...). В этой функции есть есть m_character->IPosition(vPosition); --> она возвращает интерполированную позицию объекта и именно она содержит погрешности на каждом кадре.
3) Если заменить её например на m_character->GetPosition(vPosition); то погрешность исчезает и вместе с ней дрожание камеры.
Каких либо отличий в передвижении игрока после её замены я не заметил (возможно она видна только в мультиплеере), как вариант можно делать такую подмену только во время прицеливания. В дебри кода IPosition() лезть уже не стал (это void CPHSimpleCharacter::IPosition(Fvector& pos)).
Помимо этого осталась проблема с дрожанием худа во время кручения камеры.
Но когда игрок стоит на месте и не крутит камерой - вектора поворотов тоже статичны (в отличии от позиции). Я полагаю тут дело тоже в погрешности, просто искать её надо в других функциях, которые отвечают за перерасчёт поворота камеры.
Плюс надо учесть что эта погрешность от поворота не исчезает когда игрок перестаёт крутить камеру. Это хорошо заметно как раз на прицелах - при разном повороте прицельная сетка на модели временами будет чуть левее или правее центра экрана.
Hello everyone.
I compiled XRay 1.5.10 from this repository:
Everything seems to be "a okay" (there's a few problems with sound, weird lines around screen).
But, there's also groundbreaking problem.
While i try to use Dark Valley to Garbage level changer, actor spawns under map.
I'm using clean 1.5.10 game, engine compiled without any errors. I don't understand where's the problem.
I compiled XRay 1.5.10 from this repository:
Everything seems to be "a okay" (there's a few problems with sound, weird lines around screen).
But, there's also groundbreaking problem.
While i try to use Dark Valley to Garbage level changer, actor spawns under map.
I'm using clean 1.5.10 game, engine compiled without any errors. I don't understand where's the problem.
Цитата(Fizzed @ 27.11.2019, 22:52)
While i try to use Dark Valley to Garbage level changer, actor spawns under map.
I'm using clean 1.5.10 game, engine compiled without any errors. I don't understand where's the problem.
I'm using clean 1.5.10 game, engine compiled without any errors. I don't understand where's the problem.
Most likely this is due to this . Try to revert it.
In this commit, an players`s offset relative to the center of the level changer is added to the destination point.
Цитата(abramcumner @ 28.11.2019, 10:53)
Цитата(Fizzed @ 27.11.2019, 22:52)
While i try to use Dark Valley to Garbage level changer, actor spawns under map.
I'm using clean 1.5.10 game, engine compiled without any errors. I don't understand where's the problem.
I'm using clean 1.5.10 game, engine compiled without any errors. I don't understand where's the problem.
Most likely this is due to this . Try to revert it.
In this commit, an players`s offset relative to the center of the level changer is added to the destination point.
Thank you for the reply.
I will revert this commit and check.
Всем привет! Может кто рассказать за что отвечают значения в net_flags? Понимаю что первые три параметра это параметры direct play, но четвертый мне не очень понятен.
Кто-нибудь в курсе в какой последовательности читаются db-архивы в ЧН/ЗП?
Цитата(xrModder @ 13.12.2019, 21:30)
Кто-нибудь в курсе в какой последовательности читаются db-архивы в ЧН/ЗП?
А разве не по порядку как раньше? Изменили только то, что архивы разбиты на уровни, локализацию, ресурсы и патчи. А ну и мультиплеер еще. Патчи поверх всего разумеется.
Только не понятно когда локализация подгружается
Цитата(chriotmao @ 13.12.2019, 22:33)
Только не понятно когда локализация подгружается
А разве это не прописанно в файле fsgame.ltx:
Цитата(xrModder @ 13.12.2019, 21:30)
Кто-нибудь в курсе в какой последовательности читаются db-архивы в ЧН/ЗП?
У меня ЧН нормально работает, только когда xpatch_10.db кладу в \resources. Намудрили они с этими каталогами.
Порядок загрузки архивов зависит от fsgame.ltx: строки оттуда читаются по порядку.
macron, я по коду LocatorAPI смотрел, там особо мудрёности нет и файловая система даже не знает ни о чём, она только из fsgame.ltx узнаёт что-то)
Путь $arch_dir_patches$ должен быть самым последним из всех $arch_dir_***$. Может, он у тебя идёт не самым последним?
macron, я по коду LocatorAPI смотрел, там особо мудрёности нет и файловая система даже не знает ни о чём, она только из fsgame.ltx узнаёт что-то)
Путь $arch_dir_patches$ должен быть самым последним из всех $arch_dir_***$. Может, он у тебя идёт не самым последним?
Цитата(Xottab_DUTY @ 14.12.2019, 07:24)
Путь $arch_dir_patches$ должен быть самым последним из всех $arch_dir_***$. Может, он у тебя идёт не самым последним?
Точно. У меня этой строчки вообще не было.
Ну что товарищи мододелы двигоправы тащите шампанское вчера ночью мне удалось исправить баг пятилетнего(Почти) возраста на x64
Все кто в теме знает в x64 проваливаются некоторые объекты ,есть способ починить , поставить костыль типа большой точности на release(воде обязательно) это помогает ,но костыль так себе.
вот пример как возле скелета нет пда
Так вот перехожу к сути, проблема физики заключается в том что не работает коррекция позиции объекта.
пда привязано к сетке ,а сетка проваливается под терей совсем немного.
-интересный факт если отключить физики то пда будет под торрейном и на x32
В x32 физика фиксет в x64 нечего не делает.
Это пда стало краеугольным камнем решением проблемы физики на x64.
Когда рыл тоны когда я пришёл в тому что сломано:dSortTriPrimitive.h, PHIsland.cpp
Так вот в чём заключался баг он связан с nan(ing) (это неопределенность 0/0) то есть не с точностью как многие думали.
В коде есть момент когда некий флоат сравнивается с <0.
Флоат имеет несколько неопределенностей:nan и nan(ing).
Они ведут по разному себя на разных платформах
Вот как это выглядит тест сравнения !(неопределенностей<0.f)
x32 любая точность SSE2
x64 быстрая точность SSE2
Опа
nan(ing) уже по другому ведёт себя
x64 большая точность SSE2
Всё вернулось на свою орбиту
Как исправить баг ?
очень просто
Добавить проверку на nan(функция isnan) в dSortTriPrimitive.h
Как Было:
Как Надо:
Всё!!!
Баг который создал секту "большой точности" я хотел подать петицию чтоб добавили это организацию список запрещенных на территории рф и прировняли к ИГ(запрещенная на территории РФ организация)
Достали со своей большой точностью и FPU по полной программе.
Баг который существовал 4 года исправляется вот так просто
Детский сад
Жду вопросы!!!
Все кто в теме знает в x64 проваливаются некоторые объекты ,есть способ починить , поставить костыль типа большой точности на release(воде обязательно) это помогает ,но костыль так себе.
вот пример как возле скелета нет пда
Так вот перехожу к сути, проблема физики заключается в том что не работает коррекция позиции объекта.
пда привязано к сетке ,а сетка проваливается под терей совсем немного.
-интересный факт если отключить физики то пда будет под торрейном и на x32
В x32 физика фиксет в x64 нечего не делает.
Это пда стало краеугольным камнем решением проблемы физики на x64.
Когда рыл тоны когда я пришёл в тому что сломано:dSortTriPrimitive.h, PHIsland.cpp
Так вот в чём заключался баг он связан с nan(ing) (это неопределенность 0/0) то есть не с точностью как многие думали.
В коде есть момент когда некий флоат сравнивается с <0.
Флоат имеет несколько неопределенностей:nan и nan(ing).
Они ведут по разному себя на разных платформах
Вот как это выглядит тест сравнения !(неопределенностей<0.f)
x32 любая точность SSE2
x64 быстрая точность SSE2
Опа
nan(ing) уже по другому ведёт себяx64 большая точность SSE2
Всё вернулось на свою орбиту
Как исправить баг ?
очень просто
Добавить проверку на nan(функция isnan) в dSortTriPrimitive.h
Как Было:
Код
if((!(last_pos_dist<0.f))||b_pushing)
Как Надо:
Код
#ifdef X64(дефайн x64 платформы)
bool test_nan = isnan(last_pos_dist);
#else
constexpr bool test_nan = false;
#endif
if((!(last_pos_dist<0.f))||b_pushing|| test_nan)
bool test_nan = isnan(last_pos_dist);
#else
constexpr bool test_nan = false;
#endif
if((!(last_pos_dist<0.f))||b_pushing|| test_nan)
Всё!!!
Баг который создал секту "большой точности" я хотел подать петицию чтоб добавили это организацию список запрещенных на территории рф и прировняли к ИГ(запрещенная на территории РФ организация)
Достали со своей большой точностью и FPU по полной программе.
Баг который существовал 4 года исправляется вот так просто
Детский сад
Жду вопросы!!!
isobolevskiy, занопить часть логики работы функции != исправить. Ты уверен, что новых проблем не завёз? Тут надо более детально разобраться, IMHO
ForserX, я в вчера с 14:00 до 4:00 занимался этой темой хотел подробно выложить где все точки над но мне лень может потом на хабр выложу.
Баг легенда как не крути.
Баг легенда как не крути.
Тот же dSortTriPrimitive.h:
Replace:
По опыту прошлого бага с физикой, могу предположить (а проверь не могу, привет из армейки), это решит проблему. FLT_MAX более безопасен в x64
Код
dReal neg_depth = dInfinity, b_neg_depth = dInfinity;
-----
if (intersect)
{
if (neg_depth < dInfinity)
-----
if (b_neg_depth < dInfinity)
{
-----
if (intersect)
{
if (neg_depth < dInfinity)
-----
if (b_neg_depth < dInfinity)
{
Replace:
Код
dReal neg_depth = FLT_MAX, b_neg_depth = FLT_MAX;
-----
if (intersect)
{
if (neg_depth < FLT_MAX)
-----
if (b_neg_depth < FLT_MAX)
{
-----
if (intersect)
{
if (neg_depth < FLT_MAX)
-----
if (b_neg_depth < FLT_MAX)
{
По опыту прошлого бага с физикой, могу предположить (а проверь не могу, привет из армейки), это решит проблему. FLT_MAX более безопасен в x64
ForserX, Вещи больще не проваливаються трупы не растягивает ,что ещё надо.
ForserX, Вы этой правкой сломали наоборот,там не определёность должна быть.
ForserX, Вы этой правкой сломали наоборот,там не определёность должна быть.
Цитата(isobolevskiy @ 14.12.2019, 20:02)
ForserX, Вы этой правкой сломали наоборот,там не определёность должна быть.
Ну откати surface.mu Обратно и посмотри, как без этой правки.
ForserX, Зачем мне это,моё решение работает ,а float_max зачем ,как он поможет определить nan.
и как понимать откати ,у меня чистый пыс?
и как понимать откати ,у меня чистый пыс?
А по поводу:
Проблема случаем не в значении nj? Если так, то это привет от компилятора в x64. Решается обычным занулением в конструкторе.
Код
void CPHIsland::Step(dReal step)
{
if (!m_flags.is_active())
return;
if (m_flags.is_exact_integration_prefeared() && nj < max_joint_allowed_for_exeact_integration)
dWorldStep(DWorld(), fixed_step);
else
dWorldQuickStep(DWorld(), fixed_step);
}
{
if (!m_flags.is_active())
return;
if (m_flags.is_exact_integration_prefeared() && nj < max_joint_allowed_for_exeact_integration)
dWorldStep(DWorld(), fixed_step);
else
dWorldQuickStep(DWorld(), fixed_step);
}
Проблема случаем не в значении nj? Если так, то это привет от компилятора в x64. Решается обычным занулением в конструкторе.
ForserX, Вы баг с физикой исправили?
ForserX, nj одинаковый потому что коллайдер теперь робит на x64
и специально для вас чтоб показать что на фатальном dWorldQuickStep x32 робит
x64 уже нет потому что там возникает nan(ing)
в x64(быстрой точности) если вы внимательно читали другая политика к отношение nan(ing)
ForserX, nj одинаковый потому что коллайдер теперь робит на x64
и специально для вас чтоб показать что на фатальном dWorldQuickStep x32 робит
x64 уже нет потому что там возникает nan(ing)
в x64(быстрой точности) если вы внимательно читали другая политика к отношение nan(ing)
isobolevskiy,
Первоначальный фикс, исправивший почти все проблемы.
Первоначальный фикс, исправивший почти все проблемы.
ForserX, " почти все проблемы.",но предметы проваливались ?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.