Потому что в свежих версиях Unity вынесли большую часть ранее "базовой" функциональности в отдельные пакеты. Если я правильно помню, нужно поставить через пакетный менеджер пакет "AI Navigation" (из списка Unity Registry).
Поскольку речь тут про Windows, для выполняемого кода лучше выделять память через VirtualAlloc с флагом PAGE_EXECUTE (ну или поменять для уже выделенной области права доступа с помощью VirtualProtect). В POSIX для этой же цели можно использовать mmap и mprotect.
В комментарии, на который я отвечал, есть фраза "Ведь на любом современном компьютере/ОС нельзя запустить на исполнение произвольный адрес в памяти". На что я парировал, что можно, и перечислил API, которое для этого нужно.
В Windows можно пометить кусок памяти как исполнимый через VirtualProtect с флагом PAGE_EXECUTE_READ, в Linux и MacOS - через mprotect с флагом PROT_EXEC. Грузить динамическую библиотеку для этого не нужно.
Если речь про баллы, то да. Но тут жюри должно делать поправку на заявленную целевую платформу.
Переключение экранов не все используют на 128, многие как и на 48 просто "бегут" за лучом. Тот же NIRVANA с мультиколором на обоих платформах одинаково работает.
Но я понял вашу мысль. Согласен, в плане судейства сложно сравнивать игры. Но, мне кажется, все равно проще, чем между Спеком и БК.
128й — это 48й с дополнительной периферией. Процессор тот же, разрешение экрана такое же, с точки зрения программирования они очень похожи (у 128го добавили дополнительных портов для переключения банков памяти и звуковой сопроцессор). Одно и то же внешнее железо можно подключать, практически весь софт с 48го на 128м работает.
Может быть, вы путаете с Советскими клонами, на которых и 512К памяти ставили, и видеорежимов добавляли и чего только еще не делали? На них как раз далеко не все игры с оригинального Спека работали.
Игры для 48 и 128 вполне можно сравнивать. Так же, как можно сравнивать игры под DOS со звуком через спикер и со звуком через Sound Blaster. Некоторые игры на Спеке, например, на 48м требовали периодической подгрузки данных с кассеты, а на 128м просто грузились в память. Ну и со звуком, как я уже упомянул — пищалка или без звука против музыки на чипе Yamaha.
А БК — абсолютно другое железо: другой процессор и система команд, другие видеорежимы, даже формат модуляции при записи на кассету другой.
Я не автор публикации, но я из тех людей, кто "кинутся кодить на ассемблере", поэтому попробую ответить.
Эмулятора БК-0010, фортрана и паскаля тут нет, потому что эта публикация — анонс конкурса (это даже в заголовке статьи написано), конкретно по разработке под ZX Spectrum. БК — это совершенно другой компьютер и конкурса по разработке под него не анонсировали пока что.
Смысловая нагрузка статьи — анонс конкурса и полезная информация для желающих участвовать.
Кто кинется писать на ассемблере? Ну вот я, например, а еще, наверняка, те люди, кто участвовал в конкурсе в 2019 году. "В два клика" я пишу на основной работе, на Unity. И это, знаете, иногда надоедает. Хочется сложностей для ума, попытаться уложиться в ограниченное количество регистров и памяти, а не клепать очередной матч 3. Если вы решали когда-нибудь головоломки или играли в шахматы, то идея та же самая: получить удовольствие от решения сложной и необычной задачи, выйти за рамки обыденности. Заодно посоревноваться с другими, других посмотреть да себя показать.
А при чем тут шифрация? Score шифровать? Кто мешает хакеру зашифровать преувеличенный score самому? Если игровой клиент имеет ключи для зашифровки своих данных и расшифровки данных от сервера, значит и взломщик рано или поздно получит доступ к этим ключам. Вопрос только в сложности взлома. А если клиент не имеет доступа к ключам, то и зашифровать/расшифровать общение с сервером не сможет.
Тут же налицо классическая проблема любой онлайн игры — они зачем-то стали доверять клиентскому коду, что он пошлет корректный score обратно. А ему доверять нельзя, потому что он полностью находится в руках взломщика и уязвим для анализа и манипуляций.
И простого решения тут нет. Можно слать в конце еще и реплей (какие кнопки нажимались и в какой момент) и проверять на сервере, но его также можно подделать. Да даже если, например, во время игры постоянно отправлять на сервер информацию о нажатых кнопках и валидировать на сервере таймстамп и ввод на предмет того, что игрок не ходит сквозь стены и не телепортируется, то что мешает игроку написать бота, который пробежит это расстояние за максимально короткое время?
Самый простой и быстрый способ — в методе Update игрока определять расстояние между центрами объектов зомби и игрока ((transform.position — player.transform.position).magnitude), и если оно стало меньше некоторого значения, значит зомби около игрока. В качестве контрольного расстояния можно взять число чуть больше суммы двух радиусов NavMesh агента (они есть в настройках запекания навмеша).
Еще можно использовать коллайдер в режиме IsTrigger для проверки попадания зомби в область около игрока. Но в такой простой игре это, скорее всего, не даст никаких преимуществ.
С сетью в Юнити ситуация интересная. Они задепрекейтили текущую сетевую функциональность, а новая все еще находится в состоянии альфы/превью. Писать про старую версию я смысла не вижу: она рано или поздно окончательно исчезнет. А новая еще не устаканилась.
Есть отличные сторонние продукты, как, например, Photon Unity Networking. Можно статью про него написать.
С другой стороны, статью написать — не в стор выложить, можно и с альфой нового сетевого стека разобраться.
Если на английском, то я советую начать с официального обучающего сайта Unity: learn.unity.com. На Youtube есть отличные видео от Brackeys. На Reddit могу посоветовать /r/gamedev и /r/Unity3d.
На русском языке есть форум unity3d.ru. По разработке игр в целом: gamedev.ru, хотя аудитория на этом форуме бывает довольно резкой и прямолинейной. На Хабре есть хабы Unity и Разработка Игр.
Если хотите набраться практического опыта, можно участвовать в game jam'ах. На itch.io их проводится колоссальное количество, расписание есть тут: https://itch.io/jams. Я лично очень люблю участвовать в Ludum Dare, он проходит полностью онлайн и у многих проектов (в том числе и за прошлые годы) можно скачать исходный код, чтобы посмотреть как они работают. В "физическом" мире в конце января будет проходить Global Game Jam, у них есть площадки по всему миру.
А если вы хотите сделать разработку игр своей профессией, вам нужны расписание и дедлайны для домашней работы, или просто хотите заниматься с живым преподавателем, то можете записаться на наш курс по Unity.
.pro.user — да вроде добавлял, но все равно его пушит, видимо я что-то не так делаю
Если вы файл закоммитили до того, как прописали в .gitignore, то git будет его отслеживать. Попробуйте удалить файл из репозитория и пересоздать, после этого git должен перестать пытаться его коммитить.
Кроме того, глядя на маски, которые у вас в .gitignore: файлы вида QtAutoTools.pro.user.d3e52c4 (с хешем после user) под них не попадают, только QtAutoTools.pro.user. Надо что-то вроде *.user.*, либо QtAutoTools.pro.user.*
В официальном пейпере по Спектру есть код proof-of-concept на JavaScript и достаточно подробно описано, как он работает. Для обхода ограничения по таймеру пускают Web Worker, атомарно уменьшающий счетчик. Для очистки кеша вместо процессорной инструкции читают мусор из большого массива. В общем, было бы желание.
Насколько я понял, добраться до адресного пространства другого процесса нельзя, но можно читать адресное пространство браузера, что уже неплохо.
Как мне средствами JavaScript указать какой именно адрес я хочу читать?
Ну, я думаю, тем же способом, как и в нативном коде. Проходитесь циклом по всему адресному пространству и ищете какие-то маркеры. Чтобы знать, что конкретно искать, можно почитать исходники браузера или поработать отладчиком и дизассемблером с бинарником.
Вообще, в CMake все стандартные тулчейны настраиваются обычными cmake-скриптами, которые лежат в "<путь-установки>/share/cmake/Modules" (большинство из них — в директориях Compiler и Platform) и там можно почерпнуть много информации. Но скрипты там не очень очевидные и да, я согласен, что это очень плохо документировано.
На самом деле, cmake все-таки позволяет собрать проект двумя командами на любой платформе. Сначала вы генерируете проект обычным способом, а затем используете команду cmake --build. для сборки. Для каждого генератора будет выполнен соответствующий ему сборщик, например для Visual Studio это будет MSBuild, а на Unix это будет, например, Make.
Для многих задач это более, чем приемлемо. Тот же JavaScript исполняется еще медленнее, что, впрочем, не помешало портировать на него Unreal Engine.
Собственно я пытался донести мысль, что dynamic_cast — это относительно затратная операция, и у авторов приведенных в статье библиотек есть основания, чтобы реализовывать свой велосипед. И что этот велосипед в некоторых случаях будет работать быстрее, чем стандартная реализация.
А вот переходить на стороннюю реализацию имеет смысл только когда dynamic_cast уверенно сидит в топах профилировщика по затратам процессорного времени. Но в таком случае вообще надо хорошо задуматься — возможно dynamic_cast используется там, где можно было бы использовать виртуальные методы.
Вынужден вас разочаровать, но на некоторых платформах и компиляторах используется именно сравнение строк. Основная причина — необходимость корректной работы dynamic_cast между динамическими библиотеками.
У Visual С++ цифры особо красноречивы. У GCC и Clang все гораздо лучше, но тоже имеются случаи, когда производительность падает примерно в 7-8 раз относительно вызова виртуального метода.
Стандартный dynamic_cast жутко медленный. Во многих реализациях он использует сравнение строк, чтобы найти нужный объект. Поэтому нет ничего удивительного в том, чтобы RTTI-библиотека предлагала собственный, более быстрый вариант.
Потому что в свежих версиях Unity вынесли большую часть ранее "базовой" функциональности в отдельные пакеты. Если я правильно помню, нужно поставить через пакетный менеджер пакет "AI Navigation" (из списка Unity Registry).
Поскольку речь тут про Windows, для выполняемого кода лучше выделять память через VirtualAlloc с флагом PAGE_EXECUTE (ну или поменять для уже выделенной области права доступа с помощью VirtualProtect). В POSIX для этой же цели можно использовать mmap и mprotect.
В комментарии, на который я отвечал, есть фраза "Ведь на любом современном компьютере/ОС нельзя запустить на исполнение произвольный адрес в памяти". На что я парировал, что можно, и перечислил API, которое для этого нужно.
В Windows можно пометить кусок памяти как исполнимый через VirtualProtect с флагом PAGE_EXECUTE_READ, в Linux и MacOS - через mprotect с флагом PROT_EXEC. Грузить динамическую библиотеку для этого не нужно.
Если речь про баллы, то да. Но тут жюри должно делать поправку на заявленную целевую платформу.
Переключение экранов не все используют на 128, многие как и на 48 просто "бегут" за лучом. Тот же NIRVANA с мультиколором на обоих платформах одинаково работает.
Но я понял вашу мысль. Согласен, в плане судейства сложно сравнивать игры. Но, мне кажется, все равно проще, чем между Спеком и БК.
Зря вы так, 48 и 128 очень похожи.
128й — это 48й с дополнительной периферией. Процессор тот же, разрешение экрана такое же, с точки зрения программирования они очень похожи (у 128го добавили дополнительных портов для переключения банков памяти и звуковой сопроцессор). Одно и то же внешнее железо можно подключать, практически весь софт с 48го на 128м работает.
Может быть, вы путаете с Советскими клонами, на которых и 512К памяти ставили, и видеорежимов добавляли и чего только еще не делали? На них как раз далеко не все игры с оригинального Спека работали.
Игры для 48 и 128 вполне можно сравнивать. Так же, как можно сравнивать игры под DOS со звуком через спикер и со звуком через Sound Blaster. Некоторые игры на Спеке, например, на 48м требовали периодической подгрузки данных с кассеты, а на 128м просто грузились в память. Ну и со звуком, как я уже упомянул — пищалка или без звука против музыки на чипе Yamaha.
А БК — абсолютно другое железо: другой процессор и система команд, другие видеорежимы, даже формат модуляции при записи на кассету другой.
Я не автор публикации, но я из тех людей, кто "кинутся кодить на ассемблере", поэтому попробую ответить.
Эмулятора БК-0010, фортрана и паскаля тут нет, потому что эта публикация — анонс конкурса (это даже в заголовке статьи написано), конкретно по разработке под ZX Spectrum. БК — это совершенно другой компьютер и конкурса по разработке под него не анонсировали пока что.
Смысловая нагрузка статьи — анонс конкурса и полезная информация для желающих участвовать.
Кто кинется писать на ассемблере? Ну вот я, например, а еще, наверняка, те люди, кто участвовал в конкурсе в 2019 году. "В два клика" я пишу на основной работе, на Unity. И это, знаете, иногда надоедает. Хочется сложностей для ума, попытаться уложиться в ограниченное количество регистров и памяти, а не клепать очередной матч 3. Если вы решали когда-нибудь головоломки или играли в шахматы, то идея та же самая: получить удовольствие от решения сложной и необычной задачи, выйти за рамки обыденности. Заодно посоревноваться с другими, других посмотреть да себя показать.
Чего-то его вообще в составе жюри не видно.
А при чем тут шифрация? Score шифровать? Кто мешает хакеру зашифровать преувеличенный score самому? Если игровой клиент имеет ключи для зашифровки своих данных и расшифровки данных от сервера, значит и взломщик рано или поздно получит доступ к этим ключам. Вопрос только в сложности взлома. А если клиент не имеет доступа к ключам, то и зашифровать/расшифровать общение с сервером не сможет.
Тут же налицо классическая проблема любой онлайн игры — они зачем-то стали доверять клиентскому коду, что он пошлет корректный score обратно. А ему доверять нельзя, потому что он полностью находится в руках взломщика и уязвим для анализа и манипуляций.
И простого решения тут нет. Можно слать в конце еще и реплей (какие кнопки нажимались и в какой момент) и проверять на сервере, но его также можно подделать. Да даже если, например, во время игры постоянно отправлять на сервер информацию о нажатых кнопках и валидировать на сервере таймстамп и ввод на предмет того, что игрок не ходит сквозь стены и не телепортируется, то что мешает игроку написать бота, который пробежит это расстояние за максимально короткое время?
Самый простой и быстрый способ — в методе Update игрока определять расстояние между центрами объектов зомби и игрока ((transform.position — player.transform.position).magnitude), и если оно стало меньше некоторого значения, значит зомби около игрока. В качестве контрольного расстояния можно взять число чуть больше суммы двух радиусов NavMesh агента (они есть в настройках запекания навмеша).
Еще можно использовать коллайдер в режиме IsTrigger для проверки попадания зомби в область около игрока. Но в такой простой игре это, скорее всего, не даст никаких преимуществ.
С сетью в Юнити ситуация интересная. Они задепрекейтили текущую сетевую функциональность, а новая все еще находится в состоянии альфы/превью. Писать про старую версию я смысла не вижу: она рано или поздно окончательно исчезнет. А новая еще не устаканилась.
Есть отличные сторонние продукты, как, например, Photon Unity Networking. Можно статью про него написать.
С другой стороны, статью написать — не в стор выложить, можно и с альфой нового сетевого стека разобраться.
Идея хорошая. Если найду время — напишу.
Если на английском, то я советую начать с официального обучающего сайта Unity: learn.unity.com. На Youtube есть отличные видео от Brackeys. На Reddit могу посоветовать /r/gamedev и /r/Unity3d.
В целом по разработке игр: gamedev.net, gamasutra.com.
На русском языке есть форум unity3d.ru. По разработке игр в целом: gamedev.ru, хотя аудитория на этом форуме бывает довольно резкой и прямолинейной. На Хабре есть хабы Unity и Разработка Игр.
В Телеграме можно посмотреть на каналы Разработка игр, Game Dev Fiber, GameDev, Backtracking, Заметки Игродела, Game Dev. Канал ECS Comrade полностью посвящен разработке в Unity с использованием технологии DOTS.
Если хотите набраться практического опыта, можно участвовать в game jam'ах. На itch.io их проводится колоссальное количество, расписание есть тут: https://itch.io/jams. Я лично очень люблю участвовать в Ludum Dare, он проходит полностью онлайн и у многих проектов (в том числе и за прошлые годы) можно скачать исходный код, чтобы посмотреть как они работают. В "физическом" мире в конце января будет проходить Global Game Jam, у них есть площадки по всему миру.
Я свое знакомство с Unity начинал со специализации на Coursera: https://www.coursera.org/specializations/game-development.
А если вы хотите сделать разработку игр своей профессией, вам нужны расписание и дедлайны для домашней работы, или просто хотите заниматься с живым преподавателем, то можете записаться на наш курс по Unity.
Если вы файл закоммитили до того, как прописали в .gitignore, то git будет его отслеживать. Попробуйте удалить файл из репозитория и пересоздать, после этого git должен перестать пытаться его коммитить.
Кроме того, глядя на маски, которые у вас в .gitignore: файлы вида
QtAutoTools.pro.user.d3e52c4(с хешем после user) под них не попадают, толькоQtAutoTools.pro.user. Надо что-то вроде*.user.*, либоQtAutoTools.pro.user.*В официальном пейпере по Спектру есть код proof-of-concept на JavaScript и достаточно подробно описано, как он работает. Для обхода ограничения по таймеру пускают Web Worker, атомарно уменьшающий счетчик. Для очистки кеша вместо процессорной инструкции читают мусор из большого массива. В общем, было бы желание.
Насколько я понял, добраться до адресного пространства другого процесса нельзя, но можно читать адресное пространство браузера, что уже неплохо.
Ну, я думаю, тем же способом, как и в нативном коде. Проходитесь циклом по всему адресному пространству и ищете какие-то маркеры. Чтобы знать, что конкретно искать, можно почитать исходники браузера или поработать отладчиком и дизассемблером с бинарником.
set(CMAKE_C_COMPILE_OBJECT "<CMAKE_C_COMPILER> <DEFINES> <INCLUDES> <FLAGS> -o <OBJECT> -c <SOURCE>") set(CMAKE_C_LINK_EXECUTABLE "<CMAKE_C_COMPILER> <FLAGS> <CMAKE_C_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>")Вообще, в CMake все стандартные тулчейны настраиваются обычными cmake-скриптами, которые лежат в "<путь-установки>/share/cmake/Modules" (большинство из них — в директориях Compiler и Platform) и там можно почерпнуть много информации. Но скрипты там не очень очевидные и да, я согласен, что это очень плохо документировано.
Собственно я пытался донести мысль, что dynamic_cast — это относительно затратная операция, и у авторов приведенных в статье библиотек есть основания, чтобы реализовывать свой велосипед. И что этот велосипед в некоторых случаях будет работать быстрее, чем стандартная реализация.
А вот переходить на стороннюю реализацию имеет смысл только когда dynamic_cast уверенно сидит в топах профилировщика по затратам процессорного времени. Но в таком случае вообще надо хорошо задуматься — возможно dynamic_cast используется там, где можно было бы использовать виртуальные методы.
Конкретные цифры легко гуглятся, например вот: tinodidriksen.com/2010/04/14/cpp-dynamic-cast-performance
Там же есть и ссылка на исходник тестовой программы.
У Visual С++ цифры особо красноречивы. У GCC и Clang все гораздо лучше, но тоже имеются случаи, когда производительность падает примерно в 7-8 раз относительно вызова виртуального метода.
Если не верите, что используется именно сравнение строк, посмотрите например вот этот пост (в конце есть фрагмент кода из libc++): www.nullptr.me/2014/07/01/libcxxabi-__dynamic_cast-random-strings