Jump to content
Korean Random

SoprachevAK

User
  • Posts

    278
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by SoprachevAK

  1. Ну как то так. Будем считать что отображение виджетов доделано. Поддерживается: Добавление виджетов по URL и из локальных файлов DevTools для открытых виджетов (нужно прописывать в конфиге и перезапускать игру) Изменение размера в двух режимах, зависит от мета тега страницы Произвольное изменение высоты/ширины Изменение ширины, а высота подстраивается под высоту страницы Блокировка виджета – не даёт его случайно сдвинуть, делает прозрачным для кликов Перезагрузка страницы с отключенным кешем страницы Минимизация виджета – виджет всё ещё выполняется, но не отправляется на клиент (почти не тратит ресурсов компа) Возможно накликать разные размеры/позиции для боя и ангара Виджеты сохраняются при перезапуске игры LocalStorage сохраняется между сессиями https://github.com/WOT-STAT/cef-widget Следующий шаг – Data Provider, который будет через WebSocket расшаривать для виджетов какие нибудь данные по типу результатов боя. Будет отдельным модом и встроенным в этот
  2. Здравствуйте Подскажите, есть ли возможность по DAAPI передать ByteArray из питона во флеш? Пробовал много: Напрямую у меня не получилось. Пишет ошибку приведения типов, видимо не предусмотрели. Поправьте если я ошибаюсь Через кодирование в String, передачу строкой и декодирование writeMultiByte(value:String, charSet:String):void тоже не вышло. Из танкового флеша вырезаны все charSet'ы кроме UTF8 и Unicode, а ими не закодировать произвольный набор байт. Через String + Base64 декодинг получается очень медленно, Base64Decoder тоже медленный. Через Socket получается хорошо, но в танковом флеше он забагован, и спустя рандомное время работы крашит игру без сообщения об ошибке. Судя по дампу – выход за приделы виртуальной памяти. Пока что остановился на кодирование в массив int'ов, передаю его DAAPI во флешевый Array<uint>, потом нативно конвертирую в Vector<uint>, нативно сериализую в AMF3 ByteArray, обрезаю первые несколько байт заголовков AMF3, и получаю желаемый ByteArray. Очень костыль, но это лучшее что я смог. Сейчас подумал, что можно попробовать сохранять в файл и читать его с диска, в теории с Page Cache должно быть быстро.
  3. Оказалось что Python тоже медленный язык, и просто так пройтись по всем пикселям картинки, и каждый цвет RGB поделить на прозрачность и умножить на 255 тоже очень медленная операция, а numpy весит 100мб На этом я пошел попробовал скомпилить c++ на винду из под не винды, ничего не вышло, вернулся к питону. Заменил функцию на сишную, которую вызываю через ctypes, вроде бы быстро, а работает или нет узнаем когда сервера включат после обновы.
  4. Но ведь в играх ping'ом называют не то что icmp ping, а время отправки и получения стандартного пакета. Буквально время между выстрелом и инфой когда вылетит пулька, а значит он как раз должен учитывать все особенности тактирования. Интересно как это соотносится с 10 тикрейтом танков. Как будто бы, пинг < 100 вообще не может существовать, но при этом разница 10 и 100 очень ощущается. Может там как в кс2 сабтики
  5. Я не знаю, я просто украл кажется даже из какого то другого мода, ну либо из самой игры) Как минимум, оно совпадает с тем, что игра отображает в углу экрана ping = BigWorld.LatencyInfo().value[3] - 0.5 * SERVER_TICK_LENGTH
  6. Про влияние ФПС на точность пока не изучал, времени не было, там нужно засесть и тыкаться в базу Мне кажется что вылеты за пределы круга и неровный фпс могут быть следствием движения танка/мыши Человек едет на скорости и шевелит мышкой => вылеты за круг сведения Человек едет на скорости и шевелит => подгружаются и отгружаются модельки, меняется количество полигонов в кадре => фпс прыгает вверх вниз на пару кадров
  7. Ну вообще есть такое ощущение. Но возможно это нюансы расчета пинга. Возможно пинг рассчитывается в момент кадра. У Unity я точно знаю что есть такая особенность, что даже если запустить сервер и клиент на одном компе, то пинг всё равно будет 16мс = 1 целый кадр. Но корреляция есть бесспорно, в том числе и для каждого игрока в отдельности (при условно неизменном ПК и интернете)
  8. Знаете какого цвета эта цифра 5? – Абсолютно белая с 50% прозрачности А знаете почему она выглядит серой? – А потому что CEF отдаёт картинку в PRGBA, а OBS её юзают как RGBA У меня в моде будет корректно)
  9. А есть где нибудь актуальные примеры по добавлению флешки в боевой интерфейс? Вроде бы он уже тоже на AS3 и как будто бы должно быть как с ангаром app.loadView(SFViewLoadParams(...)), а потом во флеше extends AbstractView и addChild. Но как то не работает. Посмотрел Полироидовский флеш, там всякие его common либы с абстрактными BattleDisplayable и инжекторами, которые динамически регистрируют компоненты уже из флеша. Оно только так и работает, или можно попроще? ______ UPD: Всё сильно проще, ровно как и с ангаром. Просто я импортировал ангарные зависимости)
  10. Да по хорошему да, но как то совсем не просто Там тоже будут некоторые проблемы, в плане что оно будет поверх всего интерфейса, и скорее всего даже курсора. Скорее всего пока оставлю как есть, в крайнем случае можно с потерями сжимать. Упираюсь то именно в трансфер во флеш
  11. Woker'ов в танках судя по всему нет, либо нужно как то с бОльшими правами запускать, может через ViewSettings какие нибудь хитрые ERROR: [Scaleform] ReferenceError: Error #1065: Variable Worker is not defined.
  12. К чему я пришел: 1. Из питона во флеш через DAAPI передаю Array (из uint, но во флеше они нетипизированные) 2. Через глобальную нативную функцию Vector превращаю массив в типизированный вектор 3. Записываю Vector в ByteArray через нативный сериализатор AMF3 4. Обрезаю заголовки формата и получаю точные байтики которые хотел передать. Этот костыль в 5 раз быстрее чем пустой цикл на длину массива. И в 10 раз быстрее чем декодинг из Base64. Моего процессора всё равно хватает только на 250-300 кбайт png файла. Дальше основное ядро забивается и игра начинает лагать. В идеале можно вынести в Worker, которые во флеше есть, но хз как в танковом. Быстрее не станет, но лагать будет только виджет, а танки не будут. (конечно правильно было бы через d3d, но я не готов)
  13. Действительно) Читал там только про DAAPI. Спасибо Но к сожалению оно тоже не поддерживает передачу байтиков(
  14. Эх, в танках поддерживаются charSet'ы только unicode и utf-8, которые не позволяют закодировать произвольные массив байт А кто нибудь знает, как до DAAPI реализовывалась связь Python->Flash ?
  15. Выглядит супер интересно, респект) Если ты этим занимаешь, можешь ещё попробовать подобную картинку где будут пользователи, а не выстрелы Можно в каждой группе брать uniq(playerName), это приближенный расчёт, но он очень быстрый. Как мы уже раньше выясняли, вылеты кроме фпс и пинга сильно зависят от стиля игры, а вот стиль игры уже определяется компом и пингом. С высоким пингом на реакцию не постреляешь. Но а по этому графику, нужно реально что то сделать, чтоб на 60 и 144гц не было пиков. То есть по идеи ты должен брать BbIJIET/count() в каждой клеточке (скорее всего ты так и делаешь, но тогда я не понимаю откуда пики в процентах, от того что там больше выстрелов, % меняться не должен, тк и промахов должно быть пропорционально больше) Я бы всё таки фильтровал по рандому. Там всякие космические режимы и натиски могут сильно влиять на результат. Ещё, фпс может сильно влиять на клиентский прицел, если он дискретно пересчитывается каждый кадр, то чем меньше интервал пересчёта, тем меньше будет его погрешность. И к моменту выстрела он чаще находится там где надо. Интересно посмотреть такое же по серверному. Будет ли там фпс хоть как то влиять
  16. Картинка танкового сайта весит 250к интов Превращаю байты в инты в питоне, передаю во флеш, декодирую обратно Вот кодирование и передача мгновенные, но ПУСТОЙ ЦИКЛ во флеше до 250к выжирает весь мой процессор (одно ядро, на котором основной поток танков) Вот буквально пустой цикл. Как будто бы надо мучать всякие нативные декодеры, пусть и менее оптимальные по памяти. Есть надежда на writeMultiByte(value:String, charSet:String):void, но надо будет подобрать charSet который фиксированной ширины и полностью её покрывает PS. С моими wotstat виджетами работает супер хорошо (скорее всего они очень хорошо сжимаются), а вот какой нибудь видос открыть с высоким битрейтом уже проблема
  17. Сделал передачу картинки из питона во флеш по DAAPI, кодирую в base64, потому в utf8 и передаю как стрингу, потом во флеше крайне неоптимально декодирую обратно в байты. Оно работает, не крашится, и даже 60фпс тянет без особых проблем. Нужно конечно сильно порефакторить, но способ рабочий. Скорее всего, будет оптимальнее передавать через массив uint’ов, как будто бы оно по байтам оптимальнее будет, да и декодирование быстрее получится. Но это уже вопрос кодека.
  18. А есть какой нибудь питоновский коллбек на каждый кадр (который fps)?
  19. Попробовал минимальный пример, реально крашится из-за сокета. Когда данные по нему ходят, со временем случается рандомная ошибка. Пока данные не ходят, всё норм. Если сокетов одновременно несколько, ошибки случаются чаще чем линейно. Могу предположить, что сборщик мусора собирает что то лишнее. Потыкал DAAPI, не нашел в нём способа передать ByteArray, зато можно передать String любой длины и как будто бы даже быстро (без лагов), так что завтра повтыкаю в кодировки, и попробую сокеты слушать в танковом питоне, а во флеш отправлять уже картинку (png байты) ps. Самому страшно от количества костылей, через которые картинка проходит между процессором и монитором)
  20. Ну вообще конечно такой вариант есть, а флеш оставить чисто для кнопочек с настройками, но я там полистал, выглядит страшно Хотел было я сказать, что танковый браузер скорее всего так и сделан, но чёт нашел https://github.com/IzeBerg/wot-src/blob/RU/sources-as3/gui_lobby/scripts/net/wg/gui/lobby/browser/Browser.as вот это, где они просто картинку по url грузят. Но я сомневаюсь, что это они в 60фпс грузят скриншоты. Учитывая, что там даже ютуб неплохо работает, то скорее всего оно на аппаратном ускорители, а значит выводится сразу на экран.
  21. Да там проблема в том, что судя по всему, это имплементация socket’a внутри Scaleform внутри BigWorld внутри игры, и там конечно тяжело что то понять(
  22. Ну вообще не только, это скорее для разных игровых виджетов например для всяких турниров. Я хочу ещё провайдер данных сделать, чтоб в виджет поступала какая нибудь информация об игре: результаты боя, урон, хп но это если оно мне перестанет игру крашить, иначе затея впустую
  23. И сюда же в догонку, кто нибудь отправлял большие ByteArray (до 1Мб) по DAAPI, насколько оно вообще медленно? Вероятнее всего это баг в Scaleform’овских сокетах, и придётся переносить их в питон Может есть ещё удобные способы стримить данные из внешнего процесса в танковый флеш
  24. Есть значит у меня мод, который из флеша подключается к 127.0.0.1 сокету открытому другим процессом. Каждый раз когда что то приходит, я читаю всё из сокета в массив байт. Если таких подключений несколько (на разных портах), игра очень стабильно крашится без логов, зато с багрепортом. Если одно, вроде бы работает более или менее стабильно. Если несколько, то крашится секунд через 10-20 корректной работы. Если одно, то и по 20 минут работало, но иногда бывают рандомные краши Собственно говоря вопрос в том, вот есть у меня багрепорт, есть windbg, ну вот открываю я его и вижу там что то, оно мне как то может помочь или без танковых дебаг символов нафиг не нужно? А если не поможет, то что делать? Ну кроме как максимлаьно изолировать проблему в отдельном минимальном моде
  25. Йоу. Работает) output.webm
×
×
  • Create New...