sirmax

Да, я его еще каким-то чудом догнал. :)

Если кто-то на ней не играл, попробуйте и прозрейте от мизерных УГН и крайне долгой перезарядки и сведения. Собственно, на любом другом танке я бы так не радовался, но этот - вообще уникальный. Вот, к примеру, показательный отзыв с официального гайда: http://forum.worldoftanks.ru/index.php?/topic/894103-gpz-mk-vi-e/page__pid__22015619#entry22015619

Собственно, сабж. Не могу не поделиться реплеем. Я уже эту арту почти похоронил, а она, оказывается еще вполне ничего. http://wotreplays.ru/site/1403172

Вроде я закончил с разделением на модули.

Да, пока не сделал. Сейчас в достижениях много меняют, подождем пока устаканится. Вроде если поставить startPage:1, то должно быть нормально.

А у них все нормально - они же не могут двигать элементы через конфиг. :) Поэтому у них маркер типа танка всегда попадает в нужные координаты. В общем, залил фикс с пустым полем, не хочу глубоко копать. Быстрей бы они уже полностью на AS3 перешли, старый код уже хочется переписать побыстрей.

В общем, причину я нашел. Это очередной оптимизец от картошки. Они почему-то посчитали, что то, что рисуется с отрицательными координатами - не существует, поэтому если ни один элемент маркера не попадает в область с положительными координатами, вообще ничего не рисуют. Стоит добавить пустое текстовое поле с координатами 0x0, как все начинает работать. Можете проверить: "textFields": [ { "visible": true, "format": "" }, ... Эх, оптимизируют не то и не там. Если не найду другого способа, буду добавлять пустое текстовое поле принудительно. Вместо оптимизации получится наоборот лишняя нагрузка.

еще бы кто-то вспомнил, было ли в тест1.

да, есть такое. что-то поменялось, надо смотреть что именно. VMM.swf тот же, так что что-то в питоне, по-видимому. появилось в 0.8.9.CT3, или так же было на 0.8.9.CT2? Я поставил y=-35, при этом маркеров сначала нет, потом они появляются, и если покрутить камерой, то они то появляются, то исчезают. Если в снайперском режиме приблизить-удалить, тоже - то появляются, то исчезают. Вот, пытаюсь найти после какого момента это стало появляться.

Наверно их движок все-таки на C++. И про многопоточность не вижу ничего.

Без понятия, не смотрел.

https://code.google.com/p/wot-xvm/source/browse/trunk/addons/clanicons/scripts-topclans/update-topclans-eu.sh#4

Да все они нормально и правильно делают. Нормальные там программеры (встречаются). Если что-то в движке не используется, то зачем его вкомпиливать? Архитектура тоже была выбрана стратегически правильно (хотя это больше заслуга не WG, а BigWorld, но WG все-таки выбирали платформу для своей игры, хочется верить, что они руководствовались соображениями, описанными ниже, а не просто ткнули пальцем в небо.). В качестве движка для HUD был выбран Scaleform. Альтернатив ему, к сожалению, практически нет. В оригинале Scaleform в качестве бэка использует C++, который достаточно затратен в плане ресурсов как по деньгам на зарплату разработчикам, так и по времени разработки. Поэтому, для упрощения разработки, между С++ и флешем была сделана прослойка на скриптовом языке (в данном случае - Питон). Питон великолепен в плане синтаксиса, но весьма скуден на системном уровне. У него не самая выдающаяся производительность, и нет поддержки многопоточности (GIL в питоне все портит). Даже miltiprocessing, который в WoT вырезан - это не многопоточность, а многозадачность - разница довольно приличная в плане использования ресурсов. Есть реализации питона и с нормальной многопоточностью, но BigWorld их не выбрал, по причинам, известным только им. С другой стороны, альтернативы питону практически нет. Все остальные "честные" скриптовые языки еще медленней. Реально быстрее только C/C++, фреймворки C#, Java и JS/V8. Про C++ я уже писал - он затратен по ресурсам. C#/Java требуют фреймворков (я не вдавался в подробности, но их почему-то не любят в gamedev'е). V8 был бы интересным вариантом, но он появился в 2008 году, до этого никто JavaScript серьезно не рассматривал. Собственно, поэтому мы имеем то, что имеем. И я не могу сказать что все сделано плохо. В основном все сделано достаточно хорошо, да и с каждым патчем видно, что WG занимаются оптимизацией. Если бы все было сделано на C++, может быть работало бы оно и быстрее, но новые патчи были бы намного реже. Скажем, не каждые 2 месяца, а раз в полгода. И интерес к игре при этом был бы значительно меньше чем сейчас, что было бы хуже как для WG, так и для игроков.

Ну это еще не картошка, это BW вырезали.

Ты это WG скажи, которые начисто весь мультипроцессинг из питона вырезали. В 0.8.9 должно быть лучше, я нашел способ обойти это ограничение.

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

Не удалось, пока забил.

Можно и поменять, как по мне, совершенно не принципиально.

Осталось IP выяснить, и можно делать что хочешь. :) У меня все обновления стоят, возможно в этом причина. Так, проверил на домашнем компе, все нормально. Стоит почти все то же самое, разница только в том, что ноут в домене. Ну и дрова другие, естественно.

Везет вам. У меня даже в safe mode остаются.

У меня так же на x86 в виртуалке. Значит это что-то с системой, уже лучше.

Запусти RamMap, перейди на процессы, там должно быть много cmd.exe. Если у тебя их нет, то это что-то у нас с системой (антивир, например).

Сверху есть ссылка на RamMap, в нем видно. Проверил на W7x86, все ок, процессы не остаются. Собственно, вот все что нашел по этому вопросу: http://stackoverflow.com/questions/11302232/simple-loop-on-windows7-creates-memory-leak

Может WG что-то в движке сменили.

Может быть. Вообще, проблема, похоже, глобальная в Win7x64. На x32 вроде народ пишет что этой проблемы нет. Делаем батник: @echo off :label cmd.exe /c cls echo hello goto label запускаем, смотрим как течет память Скорей всего связано с WOW64 Да, проверил, зависают все 32-битные процессы, не важно - консольные или нет. 64-битные процессы тоже остаются. В общем, винда как всегда...