Как прицепить integer к типу юнита? И потом считать его?

Принятый ответ

Через хеш, структура + поиск по всем структурам медленнее будет.
globals
    key AttachIntParentKey
endglobals

function AttackInt takes integer rawcode, integer i returns nothing
    call SaveInteger(Hash, AttachIntParentKey, rawcode, i)
endfunction

function GetAttachedInt takes integer rawcode returns integer
    return LoadInteger(Hash, AttachIntParentKey, rawcode)
endfunction
`
ОЖИДАНИЕ РЕКЛАМЫ...

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
1
11
4 года назад
1
Медленнее? Для глаза хотя бы заметно это?:) Постоянно удивляет этот байтодрочинг :) Который по факту в самой игре вообще никто не заметит - пример тому Дотка от Фрога :) Играется уже больше десятка лет, код супер-топорный, но не видел еще ни одной жалобы на то, что че то медленно работает, типа - "Ребят, у вас тут код надо исправить, медленно работает, сделайте через ХТ, а то эти 0.02 секунды слишком сильно влияют на мое АПМ в игре".
2
17
4 года назад
Отредактирован Vlod
2
При большом количестве элементов поиск перебором оборвет поток исполнения, или код PT153 настолько сложный?
0
7
4 года назад
0
Vlod, ну можно тогда использовать бинарный поиск, намного быстрее будет
0
11
4 года назад
0
Хз через структуры делал целые БД для всех юнитов на карте и для всех айтемов, по 2.5 часа игры длились - и ничего не обрывалось и не начинало лагать. А тут вдруг начнет... Ну ок
0
7
4 года назад
0
Мне помнится наоборот писали, что структуры быстрее будут, не уверен, что это так
Но в случае, если прикрепить нужно не одну цифру, а большее количество различных данных, хранить их в структуре будет эффективнее
0
20
4 года назад
0
PT153:
Через хеш, структура тут медленнее будет.
globals
    key AttachIntParentKey
endglobals

function AttackInt takes integer rawcode, integer i returns nothing
    call SaveInteger(Hash, AttachIntParentKey, rawcode, i)
endfunction

function GetAttachedInt takes integer rawcode returns integer
    return LoadInteger(Hash, AttachIntParentKey, rawcode)
endfunction
спасибо, про хэшки совсем запамятовал

respect_gg:
Постоянно удивляет этот байтодрочинг :)
в этом вся суть XGM
1
11
4 года назад
1
Haikyo:
Мне помнится наоборот писали, что структуры быстрее будут, не уверен, что это так
Но в случае, если прикрепить нужно не одну цифру, а большее количество различных данных, хранить их в структуре будет эффективнее
В этом и суть, я через структуры привязывал к юнитам (абсолютно к любым, которые были задействованы в карте) в районе 20-25 характеристик, так же у каждого айтема бонусы были сделаны через БД структуры - и как итог никаких лагов, никто не жаловался что че то медленно работает. Все летало и работало как часы. А весь этот байтодрочинг оставьте комьюнити, пусть хоть чем то займутся :)
5
17
4 года назад
Отредактирован Vlod
5
Прежде ознакомьтесь пожалуйста с понятиями линейный поиск и хеш-таблица.
1
32
4 года назад
1
Постоянно удивляет этот байтодрочинг :)
включаем минусаторы
Nazar проводил тесты, и доказал (случайно доказал), что нет никакой разницы в скорости, что 0,0001 это не быстрее, а люди пишущие про скорость двинуты на голову (Прости PT153, я не про тебя, ты нормальный)
2
28
4 года назад
Отредактирован PT153
2
respect_gg, действительно, что быстрее, цикл через все возможные равкоды, у которого сложность O(N), или хеш, у которого сложность O(1) в среднем. При 1000 равкодах разница будет ощутима.

Ну и да, верное прикручивание структуры к юниту позволяет делать конвертацию туда и обратно за O(1). Ты же не делаешь линейный поиск, чтобы найти юнита. Мой комментарий относился к решению, что предложил Haikyo.
Так что наезд ни о чём, так-то структуры быстрее хеша, но разница невелика, ибо и там, и там O(1).

Haikyo:
Мне помнится наоборот писали, что структуры быстрее будут, не уверен, что это так
Но в случае, если прикрепить нужно не одну цифру, а большее количество различных данных, хранить их в структуре будет эффективнее
Верно, но при создании структуры нужно будет её сохранить в хеш по равкоду, чтобы избежать поиска.
0
32
4 года назад
0
Насчет байтодрочерства - драколич уже доигрался, массовые жалобы на просадки фпс, ниже плинтуса. Вот когда оно приспичит, тогда будите заниматся оптимизацией.
Есть еще 1 костыльный метод, ро код самого юнита. Помню была даже статья на эту тему.
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.