Сообщений в теме: 7

[BlackMan]

Здравствуйте!


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


В сети лежит отличный скрипт за авторством Sergey81 (за что большое спасибо , значительно увеличивающий дальность прорисовки педов и машин.

Путем декомпиляции получается такой вот код:


// This file was decompiled using sascm.ini published by Seemann (http://sannybuilder....files/SASCM.rar) on 13.10.2007

{$VERSION 3.1.0027}
{$CLEO .cs}

//-------------MAIN---------------
0000: NOP
0A8C: write_memory 0x732926 size 4 value 0x858FD8 virtual_protect 1 //[(float)300.0000] Vehicle LOD threshold, default: 70.0f
0A8C: write_memory 0x732978 size 4 value 0x858FD8 virtual_protect 1 //[(float)300.0000] Vehicle LOD threshold, default: 70.0f
0A8C: write_memory 0x4250F0 size 4 value 0x85AB00 virtual_protect 1 //[(float)1500.0000] onscreen spawn range for vehicles, default: 110.0f

0A8C: write_memory 0x4253E3 size 4 value 0x858EDC virtual_protect 1 //[(float)600.0000] DespawnOffscr?
0A8C: write_memory 0x431A24 size 4 value 0x858B40 virtual_protect 1 //unknown 50.0 3

0A8C: write_memory 0x73295E size 4 value 0x863994 virtual_protect 1 //[(float)220.0000] pedsDrawDistanceInstall
0A8C: write_memory 0x6120FF size 4 value 0x858EDC virtual_protect 1 //[(float)600.0000] ?absMaxDespawnOnscrInstall
0A8C: write_memory 0x612128 size 4 value 0x863994 virtual_protect 1 //[(float)220.0000] unknown absMaxDespawnOnscrInstall
0A8C: write_memory 0x612142 size 4 value 0xB6F11C virtual_protect 1 //[(float)0.9563] unknown

0A8C: write_memory 0x86D284 size 4 value 600.0 virtual_protect 1 // ped spawn distance
0A8C: write_memory 0x871008 size 4 value 500.0 virtual_protect 1 // spawnOffscrRingSizeInstall
0A93: end_custom_thread



Если перевести значения в 10-ный вид:


// This file was decompiled using sascm.ini published by Seemann (http://sannybuilder....files/SASCM.rar) on 13.10.2007

{$VERSION 3.1.0027}
{$CLEO .cs}

//-------------MAIN---------------
0000: NOP
0A8C: write_memory 0x732926 size 4 value 8753112 virtual_protect 1 //[(float)300.0000] Vehicle LOD threshold, default: 70.0f
0A8C: write_memory 0x732978 size 4 value 8753112 virtual_protect 1 //[(float)300.0000] Vehicle LOD threshold, default: 70.0f
0A8C: write_memory 0x4250F0 size 4 value 8760064 virtual_protect 1 //[(float)1500.0000] onscreen spawn range for vehicles, default: 110.0f

0A8C: write_memory 0x4253E3 size 4 value 8752860 virtual_protect 1 //[(float)600.0000] DespawnOffscr?
0A8C: write_memory 0x431A24 size 4 value 8751936 virtual_protect 1 //unknown 50.0 3

0A8C: write_memory 0x73295E size 4 value 8796564 virtual_protect 1 //[(float)220.0000] pedsDrawDistanceInstall
0A8C: write_memory 0x6120FF size 4 value 8752860 virtual_protect 1 //[(float)600.0000] ?absMaxDespawnOnscrInstall
0A8C: write_memory 0x612128 size 4 value 8796564 virtual_protect 1 //[(float)220.0000] unknown absMaxDespawnOnscrInstall
0A8C: write_memory 0x612142 size 4 value 11989276 virtual_protect 1 //[(float)0.9563] unknown

0A8C: write_memory 0x86D284 size 4 value 600.0 virtual_protect 1 // ped spawn distance
0A8C: write_memory 0x871008 size 4 value 500.0 virtual_protect 1 // spawnOffscrRingSizeInstall
0A93: end_custom_thread




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


Несмотря на то, что код хорошо закомментирован и в комментариях вроде бы написан смысл кода (адресов памяти и значений), но у меня все равно возникли трудности.


В первую очередь, никак не получается изменить значения и добиться увеличения/уменьшения дальности прорисовки.
То есть любые изменения в коде приводят к ошибкам (пробовал изменять значения многими способами)

В связи с этим возникли вопросы:

1) Почему в некоторые адреса памяти записываются значения размеров миллионы (!!!) 8753112, 8760064 (10-й вид) и т.д. , но при этом в последних двух строках в память пишется простые float значения 600.0, 500.0 ????
Хотя, казалось бы, запись опкода во всех строках одинакова, отличаются только значения и отличаются они очень сильно!
Почему в первой строке по адресу записывается аж число 8753112 (хотя в комментарии в строке написано [(float)300.0000] ), а в последних двух строках присваивается 600.0, 500.0 соответственно ?


2) Возможно ли увеличить дальность прорисовки еще хотя бы на 100 метров (даже этого было бы достаточно). При этом поведениe, спавн, трафик, плотность и прочие характеристики не играют никакой роли. Только бы прорисовку увеличить на 100 метров еще....


Любые мои попытки изменить значения (в любой строке кода) ни к чему не приводят - результата нет, либо ошибки.

Приветствуются любые ответы, догадки, предложения, советы!


Заранее большое спасибо!

Сообщение отредактировал BlackMan: 04 December 2012 - 12:00

[listener]

http://en.wikipedia....i/IEEE_754-1985

[BlackMan]

http://en.wikipedia....i/IEEE_754-1985

Спасибо! Вы пастырь заблудших овец! ))) (шутка)

[BlackMan]

Шутка про заблудших овец оказалась пророческой - чувствую себя бараном


Опытными путем было обнаружено, что (независимо от другого кода) именно строка

0A8C: write_memory 0x73295E size 4 value 0x863994 virtual_protect 1 //[(float)220.0000] pedsDrawDistanceInstall

позволяет увеличить дальность прорисовки созданных вручную педов - именно тех, которых сам помещаешь на карту через скрипты. На дальность отрисовки других созданных самой игрой педов это никак не повлияло (оно нам и не важно).
Для проверки я параллельно с помощью другого скрипта создал на расстоянии 100 метров друг от друга 5 индифферентных к происходящему вокруг педов.
Дальность прорисовки, мягко говоря, гораздо лучше той, что по умолчанию. Хотя всех педов с одной точки увидеть и нельзя. По-моему, дальность отрисовки где-то 380-400 метров.

Вооружившись стандартом http://en.wikipedia....i/IEEE_754-1985 , двинулся дальше исследовать скрипт.

Как видно из кода выше, нас интересует адрес 0x73295E , другие мы даже трогать не будем.


1) Для начала закоментировал весь код (чтобы посмотреть какие значения пишутся по адресу по умолчанию).
Загрузил игру.
Запустил HEX-редактор.

Смотрю, какие значения выставлены по умолчанию:

HEX-вид


те же значения, только в двоичном виде




Вот оно, значение по нашему адресу, выставленное самой игрой (по умолчанию): 34 8b 85 00 (HEX), 00110100 10001011 10000101 00000000 (BIN)

2) Далее компилирую CLEO-скрипт с единственной рабоче строкой:

0A8C: write_memory 0x73295E size 4 value 0x863994 virtual_protect 1 //[(float)220.0000] pedsDrawDistanceInstall


Запускаю новую игру.
Смотрю в HEX-редактор:





те же яйца, только в двоичном виде



Все верно: по адресу 0x73295E записано значение 0x863994 (HEX), 00000000 10000110 00111001 10010100 (BIN ) , что и следовало ожидать от скрипта.


3) Дальше начинается самое интересное (и печальное

Предположительно, в память пишутся числа с плавающей запятой, но не в первозданном виде, а согласно стандарту http://en.wikipedia....i/IEEE_754-1985 .

Более того, в комментарии к строке кода написано :

0A8C: write_memory 0x73295E size 4 value 0x863994 virtual_protect 1 //[(float)220.0000] pedsDrawDistanceInstall

Что как бы намекает, что загадочное значение, которое записывается в память, это число (float)220.0000 , приведенное в божеский вид согласно стандарту.

Википедия дает ссылки на несколько онлайн конвертеров чисел в этот стандарт (первый, второй, третий, плюс я использовал отдельную программу).

Иду на первый конвертер http://www.binarycon...vert_float.html
Подставляю число 220.0000 - выдается число согласно стандарту:




Первое, что бросается в глаза, - представление числа согласно стандарту не сходится с тем, что уже есть в нашем коде.
Конвертер выдает нам 0x435C0000 = 01000011 01011100 00000000 00000000,
но в коде у нас 0x863994 (HEX), 00000000 10000110 00111001 10010100 (BIN )

Попытка подставить новое значение, которое выдал конвертер как представление числа 220.0000 в код ни к чему хорошему не привело - игра вылетела...


5) Далее я попробовал идти в каком то смысле от обратного: раз у нас уже есть рабочие значения памяти, значит надо просто конвертировать их обратно из стандарта IEEE-754 в человеко-понятный вид.

Снова иду на первый конвертер - http://www.binarycon...vert_float.html
Беру наше значение из работающего кода 0x863994 (HEX) и подставляю его в нужное поле.

Результат:



К сожалению, получается слишком большое число....

P.S. Далее....



Далее была попытка "инвертировать" порядок байтов, то есть из
0x863994 (HEX), 00000000 10000110 00111001 10010100 (BIN )
сделать
0x943986 (HEX), 10010100 00111001 10000110 00000000 (BIN )
но это дало еще худший результат (как следовало ожидать, ведь теперь бит, определяющий по стандарту знак числа, дает отрицательное значение)....


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

Заранее большое спасибо!

[listener]

Там нет однозначного представления: 220.0f может быть представлено как 2.2e2, 22.0e1, 220.0, 2200.0e-1 и так, насколько хватит точности.

Я, обычно, иду по пути наименьшего сопротивления

#include <stdio.h>
void main () {
   union { float f; unsigned int d; } num;
  num.f = 220.f;
  printf ("Decimal representation: 0x%08x\n", num.d);
}

Чтобы не перекомпилироваться каждый раз, можно приделать fscanf

[Sergey81]

Ого, жесть какая. 0x863994 это не число, это такой же адрес, по которому записано 300.0. Ответил подробнее на твои сообщения в ЛС. Последние два значения меняются напрямую, потому что другие функции их не используют и ничего страшного от их перезаписи не произойдет. (Написал бы в приват где-нить на gtaforums, я сюда иногда нечасто захожу, сам видишь)

Сообщение отредактировал Sergey81: 06 December 2012 - 11:22

[BlackMan]

Ого, жесть какая. 0x863994 это не число, это такой же адрес, по которому записано 300.0. Ответил подробнее на твои сообщения в ЛС.
Последние два значения меняются напрямую, потому что другие функции их не используют и ничего страшного от их перезаписи не произойдет.
(Написал бы в приват где-нить на gtaforums, я сюда иногда нечасто захожу, сам видишь)

Спасибо огромное за ответ!

Много интересного познал, пока изучал этот вопрос, поэтому это даже здорово

Да, обязательно буду посещать побольше форумов по модингу ГТА, хорошо что они все есть!

Еще раз спасибо всем за ответ и участие

[BlackMan]

Продолжение хождений


Опять таки опытным путем было выявлено, что изменять значение дальности прорисовки по адресу 0x73295E (сам содержит адрес памяти со значением, но об этом было написано выше) больше чем на цифру 140 не имеет смысла.

Значение 140 дает весьма хорошую дальность прорисовки. (Имею ввиду только педов, и только созданных через скрипт вручную, все остальные объекты это не затрагивает.)
Любые попытки увеличить это число ни к чему не привели - видимо достигнут предел. Печаль.


Как жить дальше?
Как добиться большей дальности прорисовки? Куда копать, куда смотреть?


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

а) Это либо функция отрисовки, которая проверяет расстояние до модели и решает, показывать её или нет.
Но это сомнительно, ведь логичнее было делать эту проверку в другом месте, а в функцию отрисовки давать уже только нужные модели.

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

в) ?


Однако, как бы там ни было, если они используют это значение из памяти, почему увеличение дальности отрисовки не происходит после значения 140?

Достигнут лимит игрового движка? Но ведь другие игровые объекты (деревья, краны, дома) рисуются и дальше.... Или для педов есть такой вот жесткий лимит внутри движка?

Возможно, в коде записано как тот так limit = Min(pedDrawDistance_0x73295E, 140) ???
Как это найти и обойти?


Подскажите, помогите куда дальше смотреть? какие возможные варианты?

Приветствуются любые ответы, догадки, предложения, советы!

Заранее большое спасибо!

Сообщение отредактировал BlackMan: 06 December 2012 - 20:16