RADION NAZMIEV, Потому что тогда этот using переносится во все h/cpp файлы, куда был подключен этот хедер и куда были подключены хэдеры, вкулючающие этот хэдер и т.д. фактически, это равносильно отсутствию пространства имён.
using namespace можно спокойно использовать внутри функций (даже если они внутри хэдера) и внутри cpp файлов, но уже с опаской. Внутри хэдеров в 99,999% случаев using namespace испоьзовать нельзя.
Ярослав Иванов,
логовед - кто разбирается в логах
логовод - кто ведёт логи
логоводовед - кто разбирается в тех, кто ведёт логи
И не надо путать терминологию.
В том то и дело, что это не в приложении дело, а в "особенностях" Windows10. Приложения же безрамочные внешне. Однопиксельная рамка(иногда) и тень вокруг окна. Причём тень гораздо больше 4-8 пикселов. В предыдущих Виндоусах вокруг клиентской области была рамка окна для изменения размера. Как я понял, теперь её визуально нет, но пустое пространство есть, наведя на которое можно менять размер. Ширина как раз где-то 8 пикселов визуально (когда мышку подводишь и курсор меняется). Но SM_CXSIZEFRAME возвращает 4 пиксела. Приложение MFC, но это не имеет значения, т.к. такое же поведение и у Firefox и у Thounderbird. Остальные приложения или в полноэкране запускаю или не выравнены по краю экрана, так что не видел таких же проблем, но они 100% есть.
Слева и снизу к экрану нельзя прилипнуть, а сверху прилипает без зазора. Я бы добавил этот "минус" в код, но непонятно, какое конкретно брать значение и от чего оно зависит, раз SM_CXSIZEFRAME не совпадает.
Евгений Шатунов, Не имеет значения, есть оно или нет. На результат работы этой функции наличие/отсутствие COW не повлияет, как и ненужный вызов clear. Просто необязательная работа, которую итак выполнит деструктор.
Про "плачевные результаты" вполне ожидаемо, если бы запретили преобразование к Си интерфейсу, то и проблем бы не было почти :)
mayton2019, Вставить браузер вообще не проблема в наше время. Например, ultralig.ht элементарно подключается. А вот именно встроить в игру уже сложнее, это надо с API игры разбираться или хак писать, но античит может по лбу дать за это.
Eric Packer, Сейчас у них плашка висит, что из-за ковида все сроки поменялись. Так что сейчас сложно что-то сказать. Раз уже одобрили, то ручной проверки быть не должно и нужно подождать, пок ана серверах данные обновятся. Вряд ли это займёт больше дня-двух. Проверь в настройках, что это публичная версия, а не какая-нибудь закрытая бета. И что никаких уведомлений не появилось о чём-то недозаполненном и недонастроенном.
Заполнение странички приложения это обязательное для всех требование, без этого просто не сможешь опубликовать публичную версию, даже для закрытых бета-версий нужно многое заполнять. Если красивые скриншоты, видосик и кратное, но завлекающее описание - может и получишь немного установок. Но я бы не расчитывал, что без рекламы будут установки. Нужен либо имидж, либо реклама.
Magneto903, тогда локальный путь каждый кадр пересчитывать (или 60 раз в секунду, например), а глобальный только когда выходит за границы укрупнённой ячейки.
Если кратчайший путь не обязателен, то вышеозвученный А* может более быстро давать глобальный путь. но у него нет никаких гарантий по времени и может довольно долго блуждать.
Magneto903, Зачем? В этом нет вобще никакого смысла.
В таких случаях реализуют сразу два механизма перемещения: глобальный и локальный. Глобально - пройти из одной части местности до другой, например, по большой ячейстой структуре с ячейками по 10 метров (условно). Это может быть граф или прямойгольная матрица - не имеет значения. Просто глобальное задание того, куда персонаж должен идти. Локальный вариант уточняет движение в пределах ячейки, чтобы обходить мелкие препятствия, не сталкиваться с другими персонажами и тому подобное, при этом он всё равно стремится идти в глобально заданном направлении. Т.е. он шёл, наткнулся на пенёк, сделал шаг в сторону и вернулся к "основному плану". При этом глобальный путь вычисляется или один раз или в случаи какого-то критического события (мост взрвали, дорогу перегородили т .п.), а локальный путь пересчитывается или каждый кадр или с каким-то тикрейтом. Напрмиер, если один шаг персонажа занимает 0,5 секунды, то пересчитывать путь чаще, чем 2 раза в секунду не имеет смысла. За эти 0,5 секунды может отрисоваться 120 кадров, при этом персонаж физически не может изменить траекторию движения.
Magneto903, На самом деле, ещё больше операций будет, потому что ещё накладные расходы на сохранение инексов ячеек текущего шага. Допустим, что реализация будет очень корявая и поиск будет занимать 1 секунду. Как часто боту будет нужно перепроверять маршрут? Замечали в играх, что условный танк ехал-ехал, доехал до взорванного моста, развернулся и другим путём поехал? Это от того, что маршрут перепроверяют не в каждом кадре и не раз в секунду даже.
Для оптимизаци можно карту побить на крупные ячейки и сперва для них путь строить, а потом уже внутри более точно.
P.S. не сразу заметил про JS. Может и пару секунд искать будет на полной карте (у меня недоверие к JS). Если сперва искать по укрупнённой матрице, то будет мгновенно искать. Например, сделать 500*500 размер и предрасчитать возможность перехода из ячейки в соседнии. Сперва искать по укрупнённой, а потом уже по полной, используя только выбранные ячейки.
Эдуард, "палитры" это где "селективная". "Потери" это правый нижний окошко с надписью "потери". Это чтобы сжатие с потерями было.
Самое главное, дизеринт со "случайное" попробуй переключить на "шаблонное" или вообще выключи. Для сжатия нет ничего хуже случайностей.
DeOxygen, Теоретически, можно ещё больше ускорить, если создать список из полигонов, описывающих положение кисти в каждом шаге и потом этот список нарисовать за один drawing call. Н отут уже потратится время на создание списка вершин и списа треугльников, так что я не буду утверждать, что это будет быстрее работать, чем один и тот же спрайт по разным координатам рисовать.
