Просмотр полной версии : [Вопрос] Совет по поводу чекпоинтов и IsPlayerInRageOfPoint
Приветствую. Имеется мод в котором есть ~130 чекпоинтов создаваемые с помощью стримера (CreateDynamicCP). Когда игрок встал на чекпоинт все проверки идут не по ID чекпоинта, а по координатам метки (IsPlayerInRangeOfPoint), то есть проверяется находится ли игрок у чекпоинта. Так вот понимаю что всё это очень печально и надо бы переделать. Но дело в том что практически ни один чекпоинт не подписан что затрудняет придумывание для него название переменной, если телепортироваться по каждым координатам и смотреть что куда - уйдёт нереальная куча времени, которой нет. Есть вариант с check1,check2,check3 и тд но и тут не без проблем, координаты указанные при создании чекпоинта (CreateDynamicCP) и координаты в самой проверке (когда игрок встал на чекпоинт) немного отличаются друг от друга что опять же усложняет поиск по коду...нужно в ручную искать среди всех 130 чекпоинтов подобные координаты и опять же нужна куча времени...Прошу помочь советом, как мне быть? Оставлять так? Но ведь это лишнее время на кучу проверок координат. Быть может есть какое-то другое решение?
Надо было изначально нормально писать. Но, раз уж так, то все эти чекпоинты можно объединить в массив (для каждого типа чекпоинта (фастфуд, ворота и т.д.) создать свой массив), проблема с переименованием решается. Проблему с координатами можно решить написанием скрипта, который будет читать координаты и искать эти координаты с небольшим отклонением в исходнике.
Надо было изначально нормально писать. Но, раз уж так, то все эти чекпоинты можно объединить в массив (для каждого типа чекпоинта (фастфуд, ворота и т.д.) создать свой массив), проблема с переименованием решается. Проблему с координатами можно решить написанием скрипта, который будет читать координаты и искать эти координаты с небольшим отклонением в исходнике.
Дело в том что не я этот бред писал, увы. Но это ведь не решит проблему, мы получим всё те же проверки координат, только браться они уже будут с массива да и еще и дополнительное время будет затрачено каждый раз на поиск схожих координат (если я правильно тебя понял). Может есть еще варианты? Варианты как можно отказаться от проверок координат вообще и при этом не сидеть неделю переделывая их.
Хотя можно же и вправду сделать 1 массив на все 130 чекпоинтов, потом сделать перехват функции IsPlayerInRangeOfPoint, в новой функции уже использовать поиск системой подобных координат в массиве с теми что были переданы только что в функции и вывести в консольку (к примеру) номер ячейки массива в которой совпали координаты. Один раз "прогнать" OnPlayerEnterCheckPoint для игрока и получаем целый список нужных нам ID, далее просто меняем проверки координат при поднятии чекпоинта на полученные ID, по списку. То есть таким образом не надо будет самому выискивать координаты схожие. А само создание чекпоинтов можно сделать через цикл, в одну строку буквально. Да всё так же не ясно будет какой чекпоинт к чему относится, но это по сути и не столь важно, главное что не надо будет искать в ручную все эти координаты, ведь это реально уйма времени нужна. В общем благодарю за помощь :)
Дело в том что не я этот бред писал, увы. Но это ведь не решит проблему, мы получим всё те же проверки координат, только браться они уже будут с массива да и еще и дополнительное время будет затрачено каждый раз на поиск схожих координат (если я правильно тебя понял). Может есть еще варианты? Варианты как можно отказаться от проверок координат вообще и при этом не сидеть неделю переделывая их.
Я имею ввиду отдельный скрипт, код которого не будет включён в твой проект. Он бы тебе помог сопоставить точки с чекпоинтами.
А чем тебя так пугает IsPlayerInRangeOfPoint? Разница между пикапом и IsPlayerInRangeOfPoint будет секунд в 20 при миллионе итераций (миллион пикапов, из которых создастся далеко не миллион и миллион проверок координат, которых действительно будет миллион). В твоём же случае ты получишь прирост в 0,0026 секунды для своего самого последнего пикапа.
Стоит ли оно всех тех проблем, которые за собой влечёт изменение пикапов с действия на кнопку (а у тебя сейчас именно оно, как я понимаю) на сами пикапы? Я просто хочу напомнить, что тебе придётся не только сами координаты пикапов подгонять, но и координаты для телепорта, ибо если ты телепортируешь игрока на пикап выхода, этот самый пикап сработает и игрока телепортирует обратно на пикап входа, который телепортирует... Рекурсия, в общем, получится для игрока :) Потому нужно будет либо делать костыль, который либо через таймер, либо через кол-во обращений к пикапу будет смотреть, нужно ли выполнять его действие или нет, либо телепортировать игрока чуть поодаль от пикапа, а для этого придётся снимать координаты вручную (хотя если у тебя есть открытие диалогов при взятии пикапа, то тогда тебе, опять же, придётся делать первый вариант костыля, ибо тогда этот самый диалог будет открываться каждый раз, пока игрок стоит на пикапе)
А чем тебя так пугает IsPlayerInRangeOfPoint? Разница между пикапом и IsPlayerInRangeOfPoint будет секунд в 20 при миллионе итераций (миллион пикапов, из которых создастся далеко не миллион и миллион проверок координат, которых действительно будет миллион). В твоём же случае ты получишь прирост в 0,0026 секунды для своего самого последнего пикапа.
Стоит ли оно всех тех проблем, которые за собой влечёт изменение пикапов с действия на кнопку (а у тебя сейчас именно оно, как я понимаю) на сами пикапы? Я просто хочу напомнить, что тебе придётся не только сами координаты пикапов подгонять, но и координаты для телепорта, ибо если ты телепортируешь игрока на пикап выхода, этот самый пикап сработает и игрока телепортирует обратно на пикап входа, который телепортирует... Рекурсия, в общем, получится для игрока :) Потому нужно будет либо делать костыль, который либо через таймер, либо через кол-во обращений к пикапу будет смотреть, нужно ли выполнять его действие или нет, либо телепортировать игрока чуть поодаль от пикапа, а для этого придётся снимать координаты вручную (хотя если у тебя есть открытие диалогов при взятии пикапа, то тогда тебе, опять же, придётся делать первый вариант костыля, ибо тогда этот самый диалог будет открываться каждый раз, пока игрок стоит на пикапе)
У меня есть анти флуд как на пикапы, так и на чекпоинты, ничего там переделывать не надо будет, всё работает отлично.
У меня нет практически действий на кнопки.
По поводу IsPlayerInRangeOfPoint ты ошибаешься, вот тебе 10 проверок координат vs 10 проверок ID пикапа (имитация), возьми протестируй:
stock Test1(playerid)
{
if(IsPlayerInRangeOfPoint(playerid, 2.0, 350.1096, 178.2794, 1014.1875)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 2.0, -2026.9523, -103.7664, 1035.172)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 3.0, 772.37, -5.51, 1000.73)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 3.0, 774.14, -50.28, 1000.59)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 2.0, 344.7585, 178.1348, 1019.9844)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 2.0, 367.41, 162.36, 1019.98)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 2.0, 1212.1314, -26.19085, 1000.9531)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 2.0, 344.6586, 178.1669, 1014.1875)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 2.0, 501.8800, -67.6500, 998.7578)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 2.0, 1467.3973, -1016.8040, 11.9159)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 2.0, 467.3973, -1016.8040, 111.9159)) return true;
return true;
}
stock Test2(id)
{
switch(id)
{
case 1000000001: return true;
case 1000000002: return true;
case 1000000003: return true;
case 1000000004: return true;
case 1000000005: return true;
case 1000000006: return true;
case 1000000007: return true;
case 1000000008: return true;
case 1000000009: return true;
case 10000000010: return true;
case 10000000011: return true;
}
return true;
}
Тестировал я на 10 млн итераций, с использованием JIT 2-ой вариант превосходит 1-ый в среднем в 30 раз.
P.S при проведении тестов на сервере был игрок. И да я знаю что ни одно из условий не выполняется, но нас ведь интересует время выполнения самих проверок, верно? Вот.
У меня есть анти флуд как на пикапы, так и на чекпоинты, ничего там переделывать не надо будет, всё работает отлично.
У меня нет практически действий на кнопки.
А как тогда у тебя устроены пикапы? В таймере что ли ищешь?
По поводу IsPlayerInRangeOfPoint ты ошибаешься, вот тебе 10 проверок координат vs 10 проверок ID пикапа (имитация), возьми протестируй:
stock Test1(playerid)
{
if(IsPlayerInRangeOfPoint(playerid, 2.0, 350.1096, 178.2794, 1014.1875)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 2.0, -2026.9523, -103.7664, 1035.172)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 3.0, 772.37, -5.51, 1000.73)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 3.0, 774.14, -50.28, 1000.59)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 2.0, 344.7585, 178.1348, 1019.9844)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 2.0, 367.41, 162.36, 1019.98)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 2.0, 1212.1314, -26.19085, 1000.9531)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 2.0, 344.6586, 178.1669, 1014.1875)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 2.0, 501.8800, -67.6500, 998.7578)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 2.0, 1467.3973, -1016.8040, 11.9159)) return true;
else if(IsPlayerInRangeOfPoint(playerid, 2.0, 467.3973, -1016.8040, 111.9159)) return true;
return true;
}
stock Test2(id)
{
switch(id)
{
case 1000000001: return true;
case 1000000002: return true;
case 1000000003: return true;
case 1000000004: return true;
case 1000000005: return true;
case 1000000006: return true;
case 1000000007: return true;
case 1000000008: return true;
case 1000000009: return true;
case 10000000010: return true;
case 10000000011: return true;
}
return true;
}
Тестировал я на 10 млн итераций, с использованием JIT 2-ой вариант превосходит 1-ый в среднем в 30 раз.
P.S при проведении тестов на сервере был игрок. И да я знаю что ни одно из условий не выполняется, но нас ведь интересует время выполнения самих проверок, верно? Вот.
А как тогда у тебя
Так ты сравниваешь работу IsPlayerInRangeOfPoint и switch, не? Причём тут пикапы? Тебя должен интересовать именно поиск нужного пикапа сервером, а не уже поиск полученного ID среди всех остальных. Нужно тестировать как-то так:
new pickup_array[1_000_000],
pickup_1;
public OnGameModeInit()
{
for(new i, Float:z=13.3828; i < 1_000_000; i++) pickup_array[i] = CreateDynamicPickup(1274, 23, 1893.1178,-2051.5422,z+=1.0, -1);
pickup_1 = CreateDynamicPickup(1274, 23, 1884.2887,-2042.4277,13.3906, -1);
CreateDynamicPickup(1274, 23, 1872.2954,-2049.6240,13.3828, -1);
return 1;
}
public OnPlayerPickUpDynamicPickup(playerid, pickupid)
{
new string[100],
time = GetTickCount();
for(new i; i < 1_000_000; i++)
{
if(pickup_array[i] == pickupid) return SendClientMessage(playerid, -1, "pickup_array");
}
if(pickupid == pickup_1)
{
printf("Pick: На поиск затрачено %d секунд", GetTickCount()-time);
format(string, sizeof(string), "Pick: На поиск затрачено %d секунд", GetTickCount()-time);
SendClientMessage(playerid, -1, string);
return 1;
}
return 1;
}
public OnPlayerKeyStateChange(playerid, newkeys, oldkeys)
{
if(newkeys & KEY_WALK)
{
new string[100],
time = GetTickCount();
for(new i; i < 1_000_000; i++)
{
if(IsPlayerInRangeOfPoint(playerid, 1.0, 1881.7056,-2055.4966,13.3828)) return SendClientMessage(playerid, -1, "IsPlayerInRangeOfPoint");
}
if(IsPlayerInRangeOfPoint(playerid, 1.0, 1872.2954,-2049.6240,13.3828))
{
printf("Key: На поиск затрачено %d секунд", GetTickCount()-time);
format(string, sizeof(string), "Key: На поиск затрачено %d секунд", GetTickCount()-time);
SendClientMessage(playerid, -1, string);
}
return 1;
}
return 1;
}
И, как я уже сказал ранее, разница есть, примерно, в 20 секунд при одном миллионе итераций в обоих случаях для самого последнего (1000001) пикапа. А чем пикап будет ближе стоять в условии, тем это время будет, соответственно, меньше.
Только вот прикол в том, что, как я уже сказал ранее, тебе всё равно придётся создавать различные костыли, которые будут срабатывать при взятии пикапа и которые так же будут отжирать своё время. Да и не всегда этот антифлуд удобен, ибо я могу, например, случайно закрыть диалоговое окно, которое открыл пикап и с твоим антифлудом мне придётся ждать определённое время.
В общем, как по мне, это бессмысленная попытка оптимизировать систему, которая и так работает, давая при этом больше удобства и создавая меньше проблем
Только вот прикол в том, что, как я уже сказал ранее, тебе всё равно придётся создавать различные костыли, которые будут срабатывать при взятии пикапа и которые так же будут отжирать своё время. Да и не всегда этот антифлуд удобен, ибо я могу, например, случайно закрыть диалоговое окно, которое открыл пикап и с твоим антифлудом мне придётся ждать определённое время.
Не поверишь, на том же ARP для тех же пикапов домов используется 2 тип и если игроку надо будет узнать информацию об доме второй раз, не заходя в него - ему придется потратить некоторое время и тем не менее никто не обсирает только из-за этого данный проект и никто еще не умер. Опять же еще один крупный проект тебе в пример - SRP, анти флуд стоит на расстояние, если поднял пикап и хочешь еще раз - будь добр отбежать и подобрать его заново, опять же никаких неудобств как таковых нет, это мелочи.
Так ты сравниваешь работу IsPlayerInRangeOfPoint и switch, не? Причём тут пикапы? Тебя должен интересовать именно поиск нужного пикапа сервером, а не уже поиск полученного ID среди всех остальных. Нужно тестировать как-то так:
Не. Возьми, пожалуйста, да протестируй тот код что я тебе дал, если ты будешь использовать вместо switch проверку такого типа как в твоём коде, к примеру:
if(id == 1000000001) return true;
Это тебе тебе практически никакого прироста не даст. Собственно сам попробуй. Ты проверяешь тоже самое что и я, разница только в построении кода, которая собственно на результат никак не отражается.
P.S я сравниваю скорость нахождения пикапа с помощью switch, имея ID пикапа так как собственно при вызове OnPlayerPickUpPickup уже несёт этот ID, ЗАЧЕМ мне его искать еще раз?! Мне кажется, ты просто не понял суть вопроса.
У нас есть пикап, когда игрок поднимет его вызовется соответственный паблик, в котором у нас уже имеется ID, нам нужно лишь чтобы система его пошустрее нашла и тут уже есть 2 варианта: проверка координат или же проверка по ID пикапу, собственно я тебе и пытаюсь доказать то что просто искать нужное условие по ID пикапу в 30 раз быстрее чем проверять кучу координат, естественно если проверка стоит там где-то в начале паблика, то разница мизерная, а если в самом-самом конце? Воооот, я очень надеюсь на то что ты понял меня в этот раз.
Не поверишь, на том же ARP для тех же пикапов домов используется 2 тип и если игроку надо будет узнать информацию об доме второй раз, не заходя в него - ему придется потратить некоторое время и тем не менее никто не обсирает только из-за этого данный проект и никто еще не умер. Опять же еще один крупный проект тебе в пример - SRP, анти флуд стоит на расстояние, если поднял пикап и хочешь еще раз - будь добр отбежать и подобрать его заново, опять же никаких неудобств как таковых нет, это мелочи.
Ну а в Европе однополые браки леализованы. Теперь нам в задницу начать всем долбиться, если где-то такое используется? Или тем, кто не любит долбиться в задницу, долбёжка от этого станет приятней?
Гораздо удобнее просто раз нажать на ALT и открыть диалог, если это требуется, нежели постоянно страдать от того, что ты случайно взял пикап и у тебя открылся диалог тогда, когда тебе это совсем не нужно.
А игроки просто не знают, что может быть иначе. Им просто не дали выбора. Это сравнимо с тем, когда у тебя в городе часто бывают пробки на дорогах, но нет метро и тебе приходится либо пользоваться маршруткой и испытывать неудобства, простаивая в пробках, либо ходить пешком.
Ну или если бы сейчас у тебя браузер открывал вкладки не тогда, когда ты на них нажал, а просто когда ты навёл на них курсор. Удобно тебе было бы маневрировать курсором между всех вкладок?
Не. Возьми, пожалуйста, да протестируй тот код что я тебе дал, если ты будешь использовать вместо switch проверку такого типа как в твоём коде, к примеру:
if(id == 1000000001) return true;
Это тебе тебе практически никакого прироста не даст. Собственно сам попробуй. Ты проверяешь тоже самое что и я, разница только в построении кода, которая собственно на результат никак не отражается.
P.S я сравниваю скорость нахождения пикапа с помощью switch, имея ID пикапа так как собственно при вызове OnPlayerPickUpPickup уже несёт этот ID, ЗАЧЕМ мне его искать еще раз?! Мне кажется, ты просто не понял суть вопроса.
У нас есть пикап, когда игрок поднимет его вызовется соответственный паблик, в котором у нас уже имеется ID, нам нужно лишь чтобы система его пошустрее нашла и тут уже есть 2 варианта: проверка координат или же проверка по ID пикапу, собственно я тебе и пытаюсь доказать то что просто искать нужное условие по ID пикапу в 30 раз быстрее чем проверять кучу координат, естественно если проверка стоит там где-то в начале паблика, то разница мизерная, а если в самом-самом конце? Воооот, я очень надеюсь на то что ты понял меня в этот раз.
Так а как система находит этот ID и передаёт его в OnPlayerPickUpDynamicPickup? Магия? Не поверишь, но сервер так же сверяет позицию игрока с позицией пикапа (точнее, там немного другие принципы, но суть одна: В реальности ID не появляется из воздуха, в отличии от того теста, что ты сделал)
Твой тест никак нельзя назвать нормальным, ибо в случае с IsPlayerInRangeOfPoint, ты сначала ищешь нужное место сверяя координаты игрока с координатами пикапа, хоть этот пикап там и не фигурирует, а потом только совершаешь действие.В случае с switch у тебя уже пикап найден => нет проверки на координаты, которая в реальной жизни не исчезнет, используй ты OnPlayerPickUpDynamicPickup.
Хочешь проверять быстродействие поиска нужного пикапа? Держи:
stock Test1(playerid)
{
switch(id)
{
case 1000000001: return true;
case 1000000002: return true;
case 1000000003: return true;
case 1000000004: return true;
case 1000000005: return true;
case 1000000006: return true;
case 1000000007: return true;
case 1000000008: return true;
case 1000000009: return true;
case 10000000010: return true;
case 10000000011: return true;
}
return true;
}
stock Test2(id)
{
switch(id)
{
case 1000000001: return true;
case 1000000002: return true;
case 1000000003: return true;
case 1000000004: return true;
case 1000000005: return true;
case 1000000006: return true;
case 1000000007: return true;
case 1000000008: return true;
case 1000000009: return true;
case 10000000010: return true;
case 10000000011: return true;
}
return true;
}
Вот так ты получишь именно то, что хочешь: поиск одного ID среди других. А твой первый тест сверяет скорость поиск пикапа относительно координат игрока и поиск одного числа среди других... -_-
И да, если ты используешь IsPlayerInRangeOfPoint в OnPlayerPickUpDynamicPickup, то это и правда выстрел себе в ногу. Просто перенеси этот код на действие через кнопку и возрадуйся.
Не надо слов, я лишь покажу результаты тестов твоего же кода.
Без JIT:
http://s09.radikal.ru/i182/1603/2b/4bf5b451d66f.png
С JIT:
http://s09.radikal.ru/i182/1603/f2/9ba9d7d118df.png
И, как я уже сказал ранее, разница есть, примерно, в 20 секунд при одном миллионе итераций в обоих случаях для самого последнего (1000001) пикапа.
И вправду, даже не вооружённым глазом видно разницу примерно в 20 мс *дикий сарказм*.
Не надо слов, я лишь покажу результаты тестов твоего же кода.
Без JIT:
http://s09.radikal.ru/i182/1603/2b/4bf5b451d66f.png
С JIT:
http://s09.radikal.ru/i182/1603/f2/9ba9d7d118df.png
И вправду, даже не вооружённым глазом видно разницу примерно в 20 мс *дикий сарказм*.
А теперь покажи код, который у тебя получился, ибо даже невооружённым взглядом видно, что код сам по себе кривой, судя по результатам Jit.
Вот только что зашёл и проверил:
Без Jit:
http://i.imgur.com/hPMWnrz.png
(В среднем разница в 200 секунд. Немного простой математики и можно выяснить, что на одну итерацию при поиске пикапа с ID 1000001 уйдёт 0,0002 секунды. Для ID 150 сам сможешь рассчитать время?)
С Jit:
http://i.imgur.com/avvPa5D.png
Значение прыгает от 25 до 35 секунд, о которых я тебе и говорил. И это с учётом миллиона пикапов
Вот вам, мисье, скрин, вашего же кода, чисто Ctrl+C Ctrl+V.
http://s020.radikal.ru/i712/1603/a9/ad239f5b2963.png
Так собственно кто или что у нас тут кривое?). Как не крути но стример тебе быстрее "найдёт" пикап чем IsPlayerInRangeOfPoint.
Вот вам, мисье, скрин, вашего же кода, чисто Ctrl+C Ctrl+V.
http://s020.radikal.ru/i712/1603/a9/ad239f5b2963.png
Так собственно кто или что у нас тут кривое?).
Твой мод? Ну никак объективно код в Jit-плагином не может иметь такие различи.
#include <a_samp>
#include <streamer>
main()
{
print("\n----------------------------------");
print(" Blank Gamemode by your name here");
print("----------------------------------\n");
}
new pickup_array[1_000_000],
pickup_1;
public OnGameModeInit()
{
for(new i, Float:z=13.3828; i < 1_000_000; i++) pickup_array[i] = CreateDynamicPickup(1274, 23, 1893.1178,-2051.5422,z+=1.0, -1);
pickup_1 = CreateDynamicPickup(1274, 23, 1884.2887,-2042.4277,13.3906, -1);
CreateDynamicPickup(1274, 23, 1872.2954,-2049.6240,13.3828, -1);
return 1;
}
public OnPlayerPickUpDynamicPickup(playerid, pickupid)
{
new string[100],
time = GetTickCount();
for(new i; i < 1_000_000; i++)
{
if(pickup_array[i] == pickupid) return SendClientMessage(playerid, -1, "pickup_array");
}
if(pickupid == pickup_1)
{
printf("Pick: На поиск затрачено %d секунд", GetTickCount()-time);
format(string, sizeof(string), "Pick: На поиск затрачено %d секунд", GetTickCount()-time);
SendClientMessage(playerid, -1, string);
return 1;
}
return 1;
}
public OnPlayerKeyStateChange(playerid, newkeys, oldkeys)
{
if(newkeys & KEY_WALK)
{
new string[100],
time = GetTickCount();
for(new i; i < 1_000_000; i++)
{
if(IsPlayerInRangeOfPoint(playerid, 1.0, 1881.7056,-2055.4966,13.3828)) return SendClientMessage(playerid, -1, "IsPlayerInRangeOfPoint");
}
if(IsPlayerInRangeOfPoint(playerid, 1.0, 1872.2954,-2049.6240,13.3828))
{
printf("Key: На поиск затрачено %d секунд", GetTickCount()-time);
format(string, sizeof(string), "Key: На поиск затрачено %d секунд", GetTickCount()-time);
SendClientMessage(playerid, -1, string);
}
return 1;
}
return 1;
}
public OnPlayerRequestClass(playerid, classid)
{
SetPlayerPos(playerid, 1958.3783, 1343.1572, 15.3746);
SetPlayerCameraPos(playerid, 1958.3783, 1343.1572, 15.3746);
SetPlayerCameraLookAt(playerid, 1958.3783, 1343.1572, 15.3746);
return 1;
}
И вот его результаты:
https://www.dropbox.com/s/5zip1it9huimg4p/gta_sa%202016-03-31%2019-03-26-284.avi?dl=0
Те же результаты и мой мод выдаёт. Можно было бы винить железо, но в таком случае разница с Jit Была бы гораздо адекватнее, нежели 100 и 500 (вполне возможно, что дооптимизировался, но не суть)
Как не крути но стример тебе быстрее "найдёт" пикап чем IsPlayerInRangeOfPoint.
Так а я отрицал это? Я лишь пытался тебе указать на то, что может не стоит овчинка выделки? Ради пары сотых наносекунды ты и игрокам жизнь подпортишь, и себя работой нагрузишь. Хочешь - пожалуйста. Я тебе уже все данные для раздумий выдал, а дальше уже решай сам
Ничья :good2:
Железо отличное и быть проблем с ним не могло быть.
Да и оптимизация тут тоже не при чем, абсолютно.
То есть ни мой код, ни моё железо не виноваты в результатах теста.
Результаты тестов "испоганил" плагин profiler, который был благополучно подключен у меня уже не первый месяц, собственно я за него уже и забыл. Тему можно закрывать. Вопрос решён.
Powered by vBulletin® Version 4.2.0 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot