GCC — 2022

Юрий "yurembo" Язев

независимый игродел

23-24 сентября в Перми в здании Morion Digital прошла конференция разработчиков видеоигр Game Construct Conference 2022. Никаких завлекающих вывесок перед входом не имелось. Опознать, что здесь проходит какое-то общественное событие, можно было только по кучке тусующихся у входа людей.

Внутри для проведения мероприятий конференции было выделено три зала. Промо девушек тоже не было.

Войдя в помещение, попадаешь в центральный — самый просторный зал, где разместились стенды и столы участников. 

Стенды — это оплаченные спонсорские месторазмещения с вывесками. Каждый из них был занят определенной компанией оба дня. Небольшие столики, на которых зиждется ноутбук разработчика, предназначены для участников Ярмарки проектов, желающих продемонстрировать свою игру. В каждый из дней их занимали разные участники.

Слева от входа за дверью находился зал для презентаций и докладов. Доклады проходили только в один поток по полчаса каждый.

Зал справа ничем особо не отделенный от центрального зала предназначался для общения и буфета. 

Рядом за дверью расположилась комната для проведения Круглых столов.

Походив по залам и пообщавшись с участниками, я узнал, что представителей из Перми и других участников из прикамья совсем мало. Исключение составила пермская Мортёшка. Она на Ярмарке проектов демонстрировала игру “Лихо”. А больше никого пермских и не было. Кстати, Мортёшка победила в двух номинациях.

Стенды занимали компании из Питера, Тольятти. В Ярмарке проектов были игры от разработчиков из Москвы, Питера, Екатеринбурга и Калининграда. Пообщались и сфотографировались с Романом Сакутиным. Он привез из Питера целую команду своей компании ЯЮниор.

Между тем, приятно, что в Перми проводятся конференции для разработчиков игр. До уровня международных конференций, проводимых в Москве, не дотягивает ни количеством,  ни массой, ни масштабом. Тем не менее, по качеству проведения конференция получилась довольно неплохая: удалось пообщаться со множеством единомышленников из разных городов. Сейчас, когда по политическим причинам большие конференции, наподобие DevGAMM’а в России не проводятся, такие локальные gamedev-мероприятия очень важны и нужны.

В конце второго дня в зале для докладов произошло награждение. Во всех номинациях определили победителей: лучшая игра, свежая идея, лучшая мобильная игра, лучшая PC-игра, MGVC Award, Teamplay Publishing Award.

Что касается докладов, я решил не тратить на них время, а посвятить его на общение и новые знакомства. Несколько презентаций я все же посетил. Самое главное, что я из них вынес — это:

1. Надо делать web-версии игр для соц. сети ВКонтакте. Тем самым получить дополнительный трафик + рекламу.
2. Мобильные и ПК-игры релизить в VK Play. Этот шаг хорошо использовать для обкатки игры перед релизом в Steam или других больших сторах.

 Переименовать локальный коммит в git

I'm imaging now that you tried to use git revert to undo the commit but it ends you up with additional commit, Here is a solution for you. use git log --oneline to show you your logs, You gonna find the commit with wrong message, Besides it you gonna find its hash (like 53fnd3w) copy it then type

git reset --hard <paste-the-hash>

This will lead you to go back to that commit, after that if you wanna just change the name of the commit use

git commit --amend -m "New commit message"

This gonna make you change the name of the latest commit which is the one you are standing on, But if you want to undo these changes because you want to divide them on two commits or something, Use

git reset HEAD^

This gonna return you back for the commit that is previous of the current one with changes un-committed, Once you make a new commit it will ignore the commits after HEAD^ and you gonna see only the new commit when you make

git log --oneline

Велозагон до деревни Казаево

Путешествия по Чусовскому району

Юрий «yurembo» Язев

Почему именно деревня Казаево, ведь вдоль Чусовой находится множество деревень и сел? Сначала я не собирался ехать ни в какую деревню, в мои планы даже не входило ехать вдоль Чусовой. Но азарт преодоления нового расстояния, любопытство увидеть новые населенные пункты. Пускай, они расположены относительно рядом с местом, где я живу. За всю жизнь не было нужды в них побывать.

Редко получается организовывать длительные велозагоны, слишком редко, последний раз поездка была до деревни Вереено в августе 2018-го года. Все времени драгоценного не хватает. Да, и в этот раз, как я уже говорил, не собирался ехать за пределы города.

Наконец-то, закончилось лето. Я рад ни тому, что закончился временной промежуток, а тому, что закончился летний сезон. Спала жара. На термометре было 12 градусов, переменная облачность. 

Я стартовал с Красного поселка, хотел сделать круг по Северному широтному коридору (объезд краснопоселковской дороги смерти) и на этом успокоиться. 

Велозагон от Красного поселка к Каспию-2

Путь от Красного поселка до развилки на пермскую дорогу представляет интересный маршрут продолжительностью примерно 13 км. Стоит от Красного поселка подняться в гору, как за поворотом растягивается длинная прямая дорога с небольшим контруклоном, который можно преодолеть со скоростью 11-15 км/ч. После кольца и 90-градусного поворота налево начинается постепенный спуск по объездной дороге, скорость местами достигает 50 км/ч. Когда спуск заканчивается, начинается прямой участок с двумя мостами через реки Вильву и Усьву, между ними находится путепровод над железной дорогой. Если во время спуска хорошо разогнаться, то этот участок проходится на высокой скорости без затруднения.

Мост через Усьву

Сразу после усьвинского моста начинается затяжной подъем. Он длится до отворота на пермскую дорогу. Преодолев его, я остановился у Каспия-2, передохнуть, водички попить и провести небольшое тех. обслуживание велосипеда. +13 км.

«Как-то это было совсем легко, надо еще куда-нибудь съездить» — подумал я, уже двигаясь в сторону Лисиков. Передо мной возник указатель на деревню Саламатово, свернем сюда. Рядом с указателем сидел маленький собачонок породы Пекинес, ухоженный и с ошейником. Однако хозяина рядом видно не было.

За поворотом начался крутой подъем по брусчатой дороге, выложенной кирпичами. Кое-где с заплатами из асфальта. Подъем оказался долгим и изнурительным. После него пролегает дорога с незначительным уклоном, ехать стало легко. В этом месте густо вплотную к дороге растут хвойные деревья, придавая воздуху характерный запах. Далее градус уклона  стал возрастать. По левую руку расположены обширные луга с выкошенной травой, которая собрана в аккуратные цилиндры, пока лежащие на полях.

Цилиндры скошенной травы

Спуск стал совсем крутой. Внизу него на указателе было написано, что от этого отворота расстояние до д. Саламатово 0,5 км. Взглянув в том направлении, я увидел пять домиков. Решил туда не ездить, а продолжить следование по брусчатке. При медленном движении по ней со скоростью ниже 15 км/ч передние амортизаторы успевают сгладить перепады между камнями. При быстром движении, например, под горку, когда скорость превышает 30 км/ч, ощущаются резкие удары в руки. Со спиной при езде по брусчатке — беда. У меня велик типа, hard tail, то есть без заднего амортизатора. Поэтому каждый камень отдается в пояснице. 

За поворотом больше не было подъемов и спусков, ровная дорога пролегала до конца моего маршрута. Похоже, за ним так же. Однако брусчатка осталась. По обе стороны дороги раскинулись поля с ухоженными растениями, подозреваю, культурными. Но вместе с ними на полях, как исполины, стоят столбы высоковольтной электропередачи. 

За следующим поворотом надпись на табличке извещала о въезде в село Верхнее Калино. 

Въезд в Верхнее Калино

Внутрь села я заезжать не стал, проехав с его краю по улице Набережной. Между тем, Верхнее Калино — довольно большой обособленный населенный пункт по сравнению с последующими. В центре села находятся объекты социальной инфраструктуры: школа, детский сад, дом досуга. В последнем помимо дома досуга располагаются: дом культуры, сельская библиотека и администрация села. К зданию прилегает широкая территория, огражденная забором. 

Пару раз меня обгоняла или попадалась на встречу газель с надписью «Дети». Очевидно, из близлежащих деревень, где нет школ, в Верхнее Калино привозят детей на учебу. А потом развозят обратно. До чего дошел прогресс.

Верхнее Калино постепенно перетекло в деревню Мичурино, где я продолжил следовать по улице Набережной по его краю. На самом деле там явная граница в виде реки Брусун, но эту реку не сразу признаешь рекой, ручеек какой-то.

После Мичурино брусчатка закончилась, ехать стало приятнее. Через небольшое расстояние встретилась деревня Нижнее Калино, где я поехал по улице Береговой, пролегающей аккурат возле реки Чусовой. Мичурино и Верхнее Калино расположены на внушительном расстоянии от реки, ее видно лишь вдалеке. С улицы Береговой в Нижнем Калино до реки рукой подать.

Нижнее Калино

На последнем отрезке от Нижнего Калино до деревни Казаево у меня свело ногу, и я задумался над тем, что пора поворачивать назад. 

Техасские прерии в чусовском районе

Пока я думал над этим, по мостику пересек реку — ручеек Брусун. Что он делает между Верхним Калино и Мичурино для меня остается загадкой, поскольку, судя по карте, он протекает здесь. Между делом въехал в Казаево, где за мной погналась собака, но так и не догнала. Доехав до конца деревни, я сделал конечную остановку, отдохнул.

Здесь ощущается «глубокая» деревня. Пасутся козы, мычат коровы, удивленно на меня смотрят гуси, беспричинно ходят курицы. На реке умиротворенно рыбак ловит рыбу. В остальном, тишина. 

Тут меня догнал автобус №322 и, гордо обогнав, последовал в Кучино. Я же развернулся и уже на пониженной скорости, особо не обращая внимания на окружение, покрутил педали в сторону базы. +15 км.

Путь до Саламатово протекал без проблем — по прямой. Сделав у поворота последнюю фотографию, понравились мне цилиндры из сена, я устремился в длинный и поначалу довольно крутой подъем.

Во время спуска по брусчатке к главному шоссе на большой скорости ручки руля выскальзывали из рук от усталости. Пришлось снизить скорость. +15 км.

От отворота на Саламатово до Красного поселка предстояло проехать еще 5 км. На въезде в Чусовой, уже в Старом городе, после моста через Усьву установлена табличка-указатель, где белым по синему написаны названия населенных пунктов: Соликамск, Порнозаводск. Половина буквы "П" закрашена синим штрихом.

+5 км. 

В итоге, 48 км.

Про ассемблер – 2 (GameDev)

Юрий "yurembo" Язев

Рассмотрим, как кроме языков высокого уровня применялся и до сих пор применяется ассемблер в разработке видеоигр. Это покажет общую тенденцию в направлении к универсальности и упрощению в области разработки ПО.

Вернемся в начало 80-х. Хэви метал, секс, наркотики, множество аппаратных несовместимых между собой платформ, компьютеров: Apple 2, Atari, Amiga, Commodore, IBM PC, Macintosh, еще больше разнообразных игровых консолей — неразбериха в духе времени. Не было защищенного режима и это не про секс. Программы выполнялись в реальном режиме процессора. Программисты имели неограниченный доступ к аппаратным средствам компьютера, и никто не стоял у них на пути: ни процессор, ни операционная система. Чтобы управлять всем этим богатством, необходимо было знать ассемблер, иначе всю мощь из компьютера не выжмешь, а он и так слабенький!

Игры в то время практически целиком писались на ассемблере, — не было ни графических, ни физических библиотек и фреймворков, ни тем более игровых движков. Время шло, появился процессор x386. В нем был реализован защищенный режим, поддержка виртуальной памяти и некоторые другие привычные нам фичи. Использование этих возможностей программистами и их реализация в операционных системах случилась далеко не сразу. Тем не менее, со скрипом и тормозами к выходу Windows 95 все более или менее освоились с защищенным режимом. Каждый процесс теперь располагал виртуальными 4ГБ памяти, все устройства обеспечивались драйверами, управляемыми операционной системой, поэтому лезть на уровень ядра прикладному программисту уже не надо и не имело смысла. Тем временем язык ассемблера перешел из разряда обязательных инструментов к специфическим.

Игроделам такой расклад не понравился, так как защищенный режим не позволял им напрямую обращаться к аппаратуре и выжимать из нее всю мощь. Поэтому они продолжили разрабатывать игры под MS-DOS. Благо Windows располагала полной совместимостью с последней. Уже это не понравилось Microsoft. Они быстренько купили разработчиков Game SDK, переименовали пакет в DirectX SDK и стали его развивать. DirectX SDK позволил разработчикам игр из защищенного режима приблизиться к устройствам — работать с ними на более низком уровне с помощью языков высокого уровня. Игроделы обрадовались, забросили ассемблер и стали его применять только в самых критичных ко времени исполнения вычислениях. Microsoft тоже осталась довольна, так как разрастающаяся библиотека игр способствовала популяризации их новой операционной системы. 

Программисты игровой индустрии обратили внимание, что все игры включают общие элементы и механизмы: визуализатор, контроллер памяти, управление файловыми потоками ввода/вывода, сетевая подсистема, обработчик пользовательского ввода, обработчик физики, искусственный интеллект и прочее. Эти механизмы немногим отличаются от игры к игре. Тогда игроделы смекнули, что эти игровые механизмы можно стандартизировать в виде модулей и не переписывать каждый раз, а только менять параметры для тонкой настройки. Сказано, сделано: набор этих слаженных механизмов стал представлять собой игровой движок. Настройку параметров и более широкое описание игрового процесса возложили на скриптовый язык. Его изучение оказалось еще более простым, чем языка высокого уровня, так как в нем уже не надо было управлять памятью и беспокоиться о других возможных проблемах. Понятно, что с таким положением дел, ассемблер стал еще менее используемым инструментом среди разработчиков игр. Причем тут ассемблер, C/C++ для разработки игр, применяя движок, можно не использовать!

Последним нововведением в процесс программирования игр стали графические языки: блоки свойств соединяются стрелочками, определяющими последовательность выполнения блоков. Это переосмысление скриптовых языков, и оно стало возможным благодаря возросшим мощностям вычислительных машин. Скриптовый язык определяет объекты, набор доступных свойств которых известен в каждый момент времени, поэтому эти наборы можно объединить в блоки и модифицировать. Настройка свойств объектов осуществляется в визуальном редакторе свойств. Тем самым программирование игр еще более упростилось.

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

Про ассемблер

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

По большому счету, есть две сферы применения ассемблера: это системное программирование и инфосек. К первому относятся: разработка операционных систем, разработка драйверов устройств, систем управления БД, графических/игровых движков и другого фундаментального ПО. Просто, сейчас настало такое время, когда определенные игроки заняли самые заметные места на рынке. Но появляются новые устройства, для них нужно новое системное ПО, рынок разрастается не только вертикально, но и горизонтально. Ведется проектирование новых процессоров, для которых нужно фундаментальное ПО.

Инфосек развивается заметнее и, кажется, быстрее. Здесь много работы ведется по анализу и дизассемблированию. Но даже в современных антивирусных лабораториях применяется автоматика, разрабатываются и используются автоматические вирусные анализаторы. Но, чтобы их создать, чтобы научить автоматическому определению малвари, их разработчики должны в совершенстве знать архитектуру компьютера и язык ассемблера.

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

Как питчить игры игрожуру

(из рассылки InGameDev за 01.07.22)

GamesIndustry.biz поговорил с журналистами из IGN, Rock Paper Shotgun, Polygon, Gayming Magazine и других изданий, чтобы выяснить как сделать так, чтобы они написали о вашей игре.

Анна Диас (Ana Diaz), автор Polygon: «Я не пишу для разработчиков, я пишу для своего 20-летнего кузена, который наиграл тысячу часов в Fortnite и может позволить себе до двух игр в год; для людей из TikTok, одержимых обустраиванием своих островков в Animal Crossing. Это не значит, что я не хочу освещать инди релизы, но нашу аудиторию очень сложно заставить их читать. Но не все потеряно!»

• Начните с элементарных вещей •

Прежде чем приступать к активной фазе пиара, убедитесь, что информация о вашей игре уже представлена в Интернете и находится в свободном доступе. Начать можно с контактной информации на сайте. «У инди часто нет вебсайтов!», – возмущается замглавред Гализ-Роу из Gayming Magazine, «И обновляйте его! <…> По возможности уделяя место и прочим работам студии», – вторит Элис Белл из Rock Paper Shotgun.

Нет игрожуру больше радости, чем сформированный пресс-пакет из аннотации, выпускных данных, отобранных скриншотов и логотипа на прозрачном фоне. Репортер из IGN просит, чтобы изображения не были гигантскими и были представлены без маркировок / надписей, лучше даже и без UI.

Если ваша игра играется вертикально, все равно подготовьте горизонтальные иллюстрации.

Все больше изданий просят анимированные гифки или вирусные мемчики с Twitter.

Блоги – это хорошо, когда хочется получить дополнительной информации, но они не должны заменять собой сайт.

• Смотрите, с кем разговариваете •

У изданий существует специализации, прежде чем обращаться к редактору издания КишкиХардкорПК4лайф.jp, ознакомьтесь с политикой издания в отношении выбранного вами жанра и платформы, а также то, что вы обращаетесь к правильному человеку.

«Я – репортер, а мне присылают письма с просьбой написать превью или рецензию», – жалуется Ребекка Валентайн из IGN.

Анна Диас советует использовать персонализированный адрес почты, чтобы повысить свой шанс на ответ. Она также добавляет, что не стоит ждать мгновенных результатов, «В девяти случаях из десяти они обращаются в неподходящее время – писать об их игре пока нет смысла, но мы берем ее на заметку».

• Налаживайте контакт правильно •

Для одних получать сообщения в социальных сетях – это предпочтительный способ, для других – бестактность в крайней своей степени. В общем, чтобы не испортить все с самого начала, нужно обратить внимание на предпочтительную форму связи.

В любом случае, нужно быть кратким и говорить по делу, предоставляя ссылки на соответствующие ресурсы – социальные медиа, официальный сайт, трейлеры, демо и т.п.

Тема письма – крайне важна. Тут уже вам придется поиграть в журналиста и придумать хороший заголовок, или, как говорят профессионалы, – «крючок». Ubisoft и Xboxмогут по этому поводу не запариваться, их имя уже обращает на себя внимание, но маленьким инди придется поднапрячься. Некоторые советуют использовать понятные аналогии, чтобы быстрее сформировать представление об игре, к примеру, «Doom + Animal Crossing».

Некоторые собеседники изъявили желание получать письма с картинками. Ну или хотя бы со стишками.

Важно обратить внимание на каком этапе находится ваша пиар-кампания:

• Анонс

• Превью

• Ревью

• Лонч

• Пост-лонч (апдейты и DLC)

• План идеального питча •

И Белл, и Валентайн представили схожий план успешного питча:

• Хороший крючок в теме;

• Краткое представление: кто вы (уж не создатель ли чего-то примечательно?), откуда, когда релиз и для каких платформ;

• Одно предложение о том, что вы питчите;

• Изображение или гифка, чтобы было понятно, как это выглядит;

• Более подробное описание. Абзац о том, как это играется, что в этом интересного. Если ваша студия чемм-то отличается от прочих, об этом стоит сказать.

• Прощания со ссылками на ассеты, в том числе демку, если такая имеется.

• Красные флаги •

«Письма, составленные под копирку, сразу отправляются в корзину, – угрожает Калиф Адамс из подкаста Spawn On Me, – Вы должны дать понять, почему вы решили обратиться именно к нам. Мы – достаточно нишевое издание и нам важно понимать, что мы можем вам предоставить».

Белл предупреждает, что краткий сухой текст с кучей ссылок имеет все шансы не пройти спам-фильтр.

Валентайн просит избегать излишней дружелюбности и не составлять письма в три часа ночи в состоянии алкогольного опьянения: «Пусть это звучит грубо, но ваши мольбы о том, как вам нужна поддержка и прочее, вам не помогут, мы не благотворительная организация и не ведемся на подобные манипуляции».

«И нам не нужны ключи, если мы их не запрашивали», – расшатывает основы основ игрожура Гализ-Роу.

Об игровой индустрии в РФ

В России и раньше, по большому счету, не было геймдева, его зародыши были сконцентрированы лишь в Москве и Питере. Игроделы со всей остальной части страны либо сотрудничали со столичными студиями, либо что-то пытались предпринять сами на местах. Как правило, неудачно или недолго. Потому что в России не было индустрии, не было какой-то движухи, о чем мы можем читать в зарубежных СМИ: сделки между компаниями, слияния, продажи, поглощения, новые образования. Каждая небольшая группа единомышленников или разработчики-одиночки выживали как могли, каждый за себя даже внутри одной студии. Грош цена такой индустрии. Это индустрией-то называться не может!

Многие "ушедшие российские студии" открыли юридические образования в Казахстане и других странах ближнего зарубежья. Найдут ли они там нужное количество специалистов? Навряд ли. Релоцируют команды? Не все захотят менять шило на мыло. Поэтому разработчики так и будут сидеть в России, но будет считаться, что они работают в Казахстане или другой стране. Самое важное, что "официальная" игровая индустрия настолько мала и дезорганизована, что ее преобразования не будут ощутимы даже ее участниками. На месте ушедших образуются новые. Чтобы заниматься разработкой игр останется только быть инди, впрочем, ничего не изменится.

Весь вопрос в том, что сейчас стало еще более проблематично выйти на рынок и заработать на своей игре.

Сайт DTF

Самое сложное в написании научно-технической книги — это стать мастером в теме излагаемого материала. Иначе после десятой страницы попросту будет не о чем писать.

Причины перехода на новую версию Windows

Какие раньше были причины перейти на новую версию Windows или остаться на старой?

Я, на самом деле, долго полностью не переходил на Windows XP с Windows 98. На моем компьютере одновременно были установлены обе системы. Они настолько сильно различались, что создаваемые мной игры работали на них кардинально по разному.

После выхода Windows Vista у меня еще не было подходящего для ее работы компьютера. Потом начался тяжелый переход с 32-х бит на 64. Все же мне кажется, он не был настолько тяжелым, как переход с 16 бит на 32, который я не застал в силу того, что он имел место быть гораздо раньше описываемых событий. После всего этого выяснилось, что никто Вистой не пользуется, и я решил не переходить.

Вскоре вышла Семерка. Перешел на нее практически сразу, благодаря программе Microsoft в помощь студентам. В рамках которой студентам предоставляется свободный доступ ко всему ПО от Microsoft.

Восьмерку купил с большой скидкой, благодаря наличию лицензионной Семерки, сразу после ее выхода, но она мне не понравилась из-за обновленного интерфейса, в частности, отсутствия привычного меню «Пуск». Для Windows 7 продолжали выходить обновления безопасности, поэтому я остался на ней. Как только вышла Windows 10, я сразу перешел на нее. В ней были отменены, произведенные в Восьмерке изменения пользовательского интерфейса. На нее можно было бесплатно обновится с лицензионных Семерки и Восьмерки.

С выходом Windows 11 нас ждал неприятный сюрприз с завышенными требованиями к аппаратной начинке компьютера, которые удовлетворил только мой пурпурный ноутбук на новеньком, но слабеньком Pentium Silver. Имеются возможности установки Windows 11 на не соответствующие требованиям компьютеры, но на них система не будет получать обновления.

Как можно сделать вывод, своевременно обновленная операционная система лучше присутствия в ней антивируса.

О безопасности операционных систем

Недавно была обнаружена брешь в Microsoft Office, названная Follina. При ее успешной эксплуатации возможно выполнение произвольного код, подкинутого хакером. Сначала Microsoft глазом не моргнула, посчитав эксплуатацию бреши трудновыполнимой задачей. Но вскоре стали появляться опасные документы Microsoft Office, реализующие атаку не только в результате открытия документа, но и после простого наведения курсора в Проводнике Windows на файл с начинкой. И, только спустя уже критический отрезок времени, Microsoft признала угрозу и выпустила патч.

Произвольный код, подкинутый хакером, может выполнять любые действия от того он и произвольный. Но во всех ситуациях на него накладываются дополнительные ограничения: какая программа его выполняет, с какими правами запущена эта программа и какими возможностями она обладает.

В последние годы (уже очень многие годы) в сообществе «крутых хацкеров» принято ругать операционную систему Windows. Однако последняя с солидным отрывом от конкурентов остается основным средством взаимодействия с компьютером.

В обществе айтишников, глубоко не разбирающихся в безопасности, принято, что новый программный продукт уязвимее, чем старый. Но это не относится к операционным системам. К ним лучше всего подходит высказывание: «мы стоим на плечах предков». Каждая новая версия ОС строится отнюдь не с нуля, а на фундаменте предыдущих версий. Поэтому самая последняя версия ОС — самая защищенная. Самая последняя ОС Windows – Windows 11 была разработана не полгода назад, когда состоялся ее выпуск. Она носит в себе все механизмы, наработки, баги, ошибки и потрясающие идеи, начиная с 1993-го года, с момента выхода первой версии Windows NT 3.1. Безусловно, найденные в унаследованном коде ошибки исправляются, выходят патчи, корректирующий двоичный код в целях латания дыр. Но о каких дырах речь?

Дыры — представляют условия, воспользовавшись которыми, можно подсунуть операционной системе или другой программе выполнить произвольный код, подготовленный хакером.

Дыры в операционных системах могут представлять наибольшую угрозу, так как выполнение подброшенного кода происходит от ее имени.

Обновления безопасности выходят в целом одинаковые для всех поддерживаемых версий Windows.

Несомненно в новых версиях ОС содержатся новые подсистемы, программы и приложения — одним словом код, иначе бы, зачем ее называть новой версией? Этот новый код безусловно тоже может содержать бреши, но хакерам еще предстоит их найти. Велика вероятность, что ее найдут «добрые» хакеры (специалисты по безопасности), сообщат (продадут) Майкрософту, и те подготовят исправление раньше, чем произойдет неблагоприятный исход со взломами и убытками.

«Специалисты», говорящие о небезопасности Windows 11 в сравнении с более старшими версиями Windows полные профаны, следующие на общественном бараньем поводу. А большинство – недалекие люди. В угоду им создается большая часть массовой информации.

Точными данными обладает тот, кто знает мат. часть.

 Архитектура ЭВМ – II

Поговорим об интегрированных видеокартах. В современных компьютерах никакой интегрированной видеокарты нет, ее роль играет дополнительное ядро центрального процессора. Если его разобрать, никаких ядер мы тоже не обнаружим, все это лишь условности – объединенные с одной целью миллиарды транзисторов.

Еще в начале 21 века, интегрированная видеокарта была размещена в северном мосту чипсета, названного так, благодаря своему расположению – вверху платы. Мой первый ноутбук iRu на процессоре Pentium 4 - как раз был построен по такому принципу.

На закате жизненного цикла процессоров Pentium 4 (эта марка имела завидно длинную жизнь), Intel стала внедрять видеоадаптер в процессор. Более того, она внедрила в процессор всю функциональность северного моста. Бывшие там микросхемы предназначались для обмена данными между центральным процессором и высокоскоростными устройствами: оперативной памятью, графическим адаптером. Теперь на материнской плате фактически нет северного моста.

Соответственно, южный мост предназначен для взаимодействия с медленными (с точки зрения процессора) устройствами: жестким диском, разными накопителями, дисководами, интерфейсами: IDE, SATA, USB и прочими.

 Архитектура ЭВМ

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

Реальная реальность

Epic Games упорно заставляет нас использовать Unreal Engine 5 под предлогом реалистичной реальности. Нужна ли нам она, эта их достоверная реальность? Сомнительно. Разве нам не хватает реальности в обыденной жизни?

Отсутствие настоящей реальности привлекает нас в видеоиграх. Здесь, точно так же, как с роботами, пока они не похожи на человека – они милые изобретения, как только они становятся похожими на людей, человеческое сознание отторгает их.

Пиксельные приключения, путешествия по воксельным мирам, решение схематических головоломок, обладание невероятными способностями, управление фантастическими механизмами, встреча с инопланетными созданиями – именно в таком виде игры приносят радость от процесса играния, лишь отдаленно намекая на реальность: серую, мерзкую, пропитанную фальшью.

Про графические api

Современные графические api создаются не для того, чтобы их использовали люди, потому что, чем дальше, тем они многословнее, они создаются для использования автоматами - графическими движками: Unity, Unreal, Godot, т.д.

Первый графически api современной истории – OpenGL был создан в 1992 году, долгое время был неизменным и всех устраивал, потом для него начали изготавливать расширения, в итоге, он дожил до 4-й версии.

Следующая веха OpenGL ES для встраиваемых и мобильных систем, затем их всех заменил Vulkan, разрабатываемый на основе OpenGL.

OpenGL представляет собой крайне удобную для использования api, которую можно спокойно применять, программируя в ручном режиме, впрочем, так и должно было быть, ибо, когда она появилась, ни о каких автоматах речи и не было; Vulkan же представляет очень запутанную систему, чтобы сделать с помощью него простейшую операцию, надо написать кучу кода, пусть этим занимаются движки.

Одновременно с OpenGL Майкрософт развивала DirectX исключительно для своей платформы, в нем так же: на ранних версиях можно было писать самому, но в DirectX 12 – утонешь в широком разнообразии и многословности.

Metal - продукт Apple, созданный на основе OpenGL/Vulkan для своих девайсов, потому что все крупные компании (Apple, Microsoft, NVidia, AMD) входят в консорциум Khronos, где разрабатываются открытые api OpenGL/Vulkan.

Поэтому, чтобы не мучить прикладных программистов и игроделов написанием своих визуализаторов, в игровых/графических движках их создатели реализуют визуализаторы, использующие все графические подсистемы.

Apple WWDC'22

Самый интересный момент прошедшей вчера презентации Apple WWDC'22 – бесспорно представление ноутбуков MacBook Air и MacBook Pro на чипе M2 – новом поколение Apple Silicon. Однако, по сравнительным характеристикам M2, в целом, обходит M1 только на 25%.

Еще момент, меня заинтересовавший, это желание Apple продвижения игр для маков. Наибольшая часть выручки AppStore приходится на игры. Но это почти на 100% касается мобильных игр. Поэтому Apple стремится привлечь игроделов к разработке игр для macOS. Тенденция к этому была замечена в момент представления чипа M1, когда Apple активно демонстрировала красоты Shadow of the Tomb Raider на своем чипе, говоря иначе, демонстрировалась уже морально устаревшая игра, на тот момент ей было уже два года. 

На этот раз Apple активно показывала Resident Evil: Village, тоже не самую новую игру, вышедшую год назад. Сейчас происходит ее адаптация для железа Apple, рассказать об этом на презентации был приглашен один из ее разработчиков из Capcom. Он упомянул, какие прекрасные эффекты они могут реализовать с помощью Metal 3.0 – проприетарного графического API от Apple, созданный специально для своих девайсов. По моему, лучше бы они совсем его не разрабатывали, был же OpenGL, и всем его хватало.

На рубеже веков Стив Джобс реально хотел сделать мак игровой платформой. Apple сотрудничала с игровыми издателями и разработчиками, даже Bungie была у них под крылом. Но потом что-то не срослось, и Bungie досталась Майкрософту, для которого она сделала главный эксклюзив Xbox — Halo.

Мао Цзэдун: «Революция – это не званый обед, не литературное творчество, не рисование или вышивание; она не может совершаться так изящно, так спокойно и деликатно, так чинно и учтиво. Революция — это восстание, это насильственный акт одного класса, свергающего власть другого класса».

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

Несмотря на то, что GameDev – тесная тусовка, к своему огорчению я увидел: в GameDev-сообществе в большинстве своем такие же показушные дураки, как везде, они не обладают ни умением, ни желанием разбираться в том, с чем и над чем работают, о чем говорят, только подсирают друг друга на местах, выдавая чужие заслуги за свои.

О рейтрейсинге и видеокартах его поддерживающих

Понятие трассировки лучей появилось в кибернетике задолго до зарождения информатики, 3D-игр и ее использования в качестве метода визуализации. Но мы не будем погружаться в длинную историю, а сразу перейдем к зарождению трехмерных игр, тогда еще 2.5D. Юный Джон Кармак использовал метод рейтрейсинга для обнаружении столкновения выпущенного снаряда со спрайтом персонажа. Именно спрайтом, а не мешем или моделью, потому что псевдо-3D. Без 3D ускорителей игроделы выживали, как могли. 

В самом общем понимании, рейтрейсинг — это математическая операция для вычисления столкновения луча, что в математическом понимании бесконечная прямая, ограниченная с одного конца, другими словами, имеющая точку – определенное начало, с треугольном — базовым примитивом, из множества которого строятся все остальные объекты.

Когда рейтрейсинг стал применяться в качестве способа визуализации еще не существовало подходящих 3D-акселлераторов, поэтому вычисления проводились на центральном процессоре. Трассировка лучей может быть любой по сложности. Если взять упомянутый выше пример со снарядом, это наипростейший случай, так как используется только один вектор. Тогда, как при освещении методом трассировки лучей для создания реального изображения луч, имеющий свойства источника, соприкасаясь с поверхность (определенным пикселем), отдает ей свои свойства, принимает ее и, в соответствии с реальным поведением фотонов, отскакивает в направление к другой поверхности виртуальной сцены. И так продолжается определенное количество раз, зависимое от мощности источника света и многих других условий: затемненности игрового пространства, свойств материалов, с которыми луч соприкасается. В результате, из простого математического выражения образуется сложнейшее уравнение с десятками и сотнями переменных! Необходимо учесть, что освещение — это огромное количество лучей, влияющих на цвет каждого пикселя! 

Такое колоссальное количество вычислительных операций было не по плечу ни одному центральному процессору, которому вдобавок к трассировке лучей надо выполнять свою основную работу: управлением операционной системой и отлавливанием прерываний от устройств. Поэтому рейтрейсинг, как основной метод растеризации в реальном времени пришлось отложить. Между тем, кое-где с небольшим количеством лучей его использовали.

С появлением многоядерных процессоров интерес игроделов к рейтрейсингу вновь проснулся. Теперь можно было поручить выполнение вычислений нескольким полностью равноценным ядрам. Но недолго длилось счастье, вскоре стало очевидно, что даже восьми ядер мало!

Существуют эффекты, достижение правдоподобной визуализации которых без рейтрейсинга невозможна или требует настолько сложных алгоритмов и вычислений, что их обработка является более тяжеловесной, чем сама трассировка лучей. К ним относятся: отражение, полупрозрачность, затенение. И, хотя существуют способы отображения этих эффектов без использования трассировки лучей, они уступают по качеству получаемого изображения. Поэтому схемотехники и проектировщики вычислительных устройств стали размышлять о том, что, вероятно, для вычисления пути луча вовсе необязателен полноценный процессор со всеми его возможностями, достаточно урезанной по своим возможностям и, соответственно, имеющей меньший размер вычислительной интегральной схемы, способной выполнять ограниченный набор математических операций, но делающей это максимально быстро.

Плодом этих рассуждений и разработок стала микроархитектура Turing, реализованная в видеокартах Nvidia GeForce RTX 20XX. В ней используются десятки RT-ядер, в задачи которых входит исключительно просчет трассировки лучей. Благодаря их большому количеству, они одновременно просчитывают трассы для многих лучей, из-за чего скорость визуализации с применением рейтрейсинга возросла во много раз!

В итоге, получается, что рейтрейсинг представляет собой алгоритм смешения цветов.

Определение вомглы

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

GameDev-апокалипсис

Игроделы пожаловались президенту на то, что у них могут отобрать Unity и Unreal Engine, в результате чего они не смогут разрабатывать игры, и наступит gamedev-апокалипсис. Как-будто на этих двух движках средства разработки игр исчерпаны. Для исправления ситуации конкретно этим игроделам нужно много бабосиков и 2-3 года. Во-первых, сколько бы не было у них бабосиков, движок уровня Unity/Unreal они за 2-3 года не разработают. Во-вторых, лишение россиян этих движков равносильно отключению ГитХаба, ибо Unreal частично Open Source, и Windows. А так же удаленной активации инструкций судного дня, что приведет к самоуничтожению процессоров.

Берешь средства операционной системы, плюс, по желанию, DirectX/OpenGL/Vulkan и пилишь свой движок, делов-то.

Не зря я в детстве до появления всех этих фреймворков и движков кодил игры под DirectX и OpenGL. Я знал, это необходимо. Этот день наступит!

Острее стоит проблема недоступности площадок цифровой дистрибуции и невозможность выхода на китайский рынок по причине того, что нам нечего им предложить!

О работе процессоров и выполнении программного кода

По словам Джима Келлера, известного проектировщика процессоров, приложившего руку к чипам в Intel и AMD: независимо от микропроцессорной архитектуры 80% всего рабочего времени процессор выполняет только 8 команд из своего набора инструкций. Эти команды должны быть максимально оптимизированы.

Мои изыскания в области работы процессоров и выполнения программного кода подтверждают его слова: загрузка, пересылка значений, математические операции (сложение, вычитание, умножение, деление), команда сравнения и пара переходов в зависимости от установки битов в регистре флага. Остальное применяется значительно реже.

Индустрия вомгле...

Я тут пишу рассуждения про GameDev. Но если задуматься, мои советы подходят для разработки любого малого или среднего по размеру программного проекта. В большом – вещи приобретают иной оборот.

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

Я предпочитаю работать в одиночестве, считаю, чтобы сконцентрироваться на решение задач нужно погружение в раздумья, собственные мысли, необходима временная изоляция от внешних раздражителей. Поэтому я предпочитаю работать дома/из дома всегда, независимо от мейнстрима.

Невозможно полноценно использовать свой мозг, когда в комнате находится несколько человек. Каждый из них издает свои звуки, пускай, клацание мышью, печать на клавиатуре, да, хоть дыхание. Ситуация становится еще хуже, когда начинаются перемещения по офису и/или разговоры. Если бы был правильно выполнен этап планирования, никакие разговоры были бы не нужны. За что я люблю удаленную работу, так это отсутствие ненужных разговоров. Я могу временно отключить мессенджер, чтобы никто меня не отвлекал, а вдоволь пообщаться с коллегами во время следующего этапа планирования.

Раздражают моменты, когда сотрудники не только беспричинно ходят по комнате, в которой развертывается разработка видеоигры или какого-то другого проекта, но и без всякой просьбы (или даже разрешения) заглядывают в твой экран, высматривая, что на нем происходит. Совсем выводят из себя последующие комментарии: «А я тоже так смогу». После таких слов охота на этом же месте разбить его голову клавиатурой или чем-нибудь потяжелее. Запустить Unity может и моя бабушка! Кстати, в крупных организациях сотрудники редко позволяют себе такую свободу, в небольших же компаниях подобное случается довольно часто.

Еще одна крайне мерзкая штука, имеющая место быть, когда приходишь в уже длящуюся какое-то время разработку, это сокрытие деталей «ветеранами». Обо всем приходится догадываться самостоятельно, а спрашивать только о том, чего недопонял. Это съедает катастрофическое количество времени! Ведь можно же поступить по хорошему, для вновь прибывшего сотрудника всецело рассказать о проекте, и уже на этом этапе позволить ему задать вопросы про специфические детали. Но у нас все делается через жопу! Создается впечатление, что никто из «ветеранов» не обладает знаниями о проекте, который они разрабатывают! И, чтобы не показывать из себя дураков, разработчики стараются по минимуму обсуждать связанные с проектом вещи. Во время этапов планирования необходимы «тесные» беседы о разных частях проекта, обмен информацией, опытом не только текущим, но и, возможно, полученным во время предыдущих разработок и собственных исследований.

Планирование и отчетность

Сами по себе планирование и создание отчетов игру не разработают, скажу больше, они не помогут ее разработать и к этому даже не стремятся. Планирование стоит рассматривать, как организацию последовательности стадий или задач (тасков) в разработке. Это последовательная запись предстоящих задач с упорядочиванием по срочности и важности. Процесс разработки видеоигры — длинная вереница сложных задач, преследующих одну цель. Поэтому планирование должно стать неотъемлемой его частью. Необходимо документировать каждую стоящую реализации мысль. Без этого не получится создать сколько-нибудь сложную интерактивную историю — видеоигру.

Создание, написание отчетов, как мне кажется, менее важное занятие. При правильном планировании, отчет почти полностью вытекает из плана, не требуя переделывания или переписывания. И во многих случаях сводится к перетаскиванию таска из столбца To-do в столбец Completed системы управления проектами. Я приветствую подробные отчеты о выполненных заданиях, особенно, когда последние имеют специфическую природу, а их решения потребовали значительные промежутки времени. В то же время, написание отчета не должно выполняться из-под палки и демотивировать разработчика. Также не должно быть написание отчета ради написания отчета, другими словами, должна быть реальная оценка труда разработчика, а не размера написанного им отчета. Приятно оформленный, хорошо написанный отчет может помочь самому разработчику, его написавшему, через несколько недель/месяцев вернувшегося к этому блоку кода/задаче для изменения/модификации или в решении подобной задачи в будущем.

GameDev в одиночку

Не лучший вариант. Только если ориентироваться на мобильную игру можно уложиться в приемлемые сроки. Чем масштабнее игра, тем больше для нее нужно элементов различного характера, это, безусловно, даже ежу понятно. Если говорить о премиальных играх, чем являются однопользовательские сюжетные игры, тот идеал, к разработке которого я всю жизнь стремлюсь, то по количеству необходимого контента их можно очень грубо поставить между мобильными и MMO-играми. Но последние не могут быть интересными по ряду озвученных мною ранее причин, ключ их популярности ни в том, что несет видеоигра, а в социальном взаимодействии, что видеоигрой не является, тусовка, собрание, общение, мероприятие, но не видеоигра.

Многообразие контента — есть сложность создание премиальных игр. Время, ресурсы, группа людей. Но проблема здесь в том, что хотя команда объединена одной целью, цели у ее участников могут быть различны и лежать далеко от создания превосходной видеоигры. Мерзкая ситуация случается, когда процессом разработки руководит человек, не понимающий ни в играх, ни в управлении. Или в чем-то одном из этого. Что, тем не менее, картину не исправляет. Разработка становится неуправляемой и уже процессом созидания называться не может. Бесполезные споры, повторяющиеся раз за разом, и, продолжающиеся не для того, чтобы сделать игру лучше. Разработка больших игр — командная работа.

Разработка игр в одиночку? Уже не кажется такой безумной идеей.

 Over the Rainbow - 2009

Юрий "yurembo" Язев

21 сентября 2009-го года, в понедельник в ДК им. Солдатова, что в г. Перми, состоялся потрясающий концерт группы Over the Rainbow. Следовательно, как, уважающий себя и свою любимую музыку металлист, я не мог пропустить это грандиозное событие, поэтому участвовал в этом мероприятии!

Вообще, группа Over the Rainbow была организована 21 июня 2008 года бывшими участниками группы Rainbow, игравшими когда-либо. Однако место соло-гитариста занимает новый участник – сын Ричи Блэкмора – Югдан Блэкмор. Напомню, Ричи организовал группу Rainbow в 1975-ом.

По поводу переименования группы я имею следующие размышления. Во-первых, без Ричи уже не Rainbow, поэтому участники не захотели идти против него, и возможно, против закона – авторских прав Блэкмора старшего, о которых он бы обязательно вспомнил. И вторая мысль имеет противоречие самой себе и заключается в следующем. Младший Блэкмор не хотел повторять лейбл группы своего отца. Это утверждение имеет такое противоречие: как же так, если новая группа играет хиты Rainbow. Отсюда следует, что первое утверждение, скорее всего, правильно.

У микрофонной стойки на месте вокалистом во вновь образованной группе в  настоящее время находится Джо Линн Тёрнер. И о концерте.

Как обычно бывает на подобных концертах, зал был полон. У меня было место в первом ряду амфитеатра, то есть, это получается приблизительно 11-ый ряд в общем числе. При этом билет далеко не самый дешевый. Ну, да ладно, всё равно под конец концерта все вылезли на сцену! И, как обычно на концертах таких групп, зрительский контингент состоял в основном из взрослых людей, то и лучше!

Я точно не помню на сколько задержалось начало концерта, было не до этого! Кроме того, перед началом концерта я купил две мега-футболки с символикой группы. Концерт начался с песни Tarot Woman, которая была на альбоме Rainbow Rising, вышедшем в 1976-ом. После этого было исполнено много великолепных вещей Rainbow, в числе которых: Death Alley Driver, Power, Stone Cold, Can’t Happen Here, Since You’ve Been Gone и даже чудесная Stargazer! Первую половину концерта люди - зрители спокойно сидели на своих местах, и похоже я один прыгал рядом со своим местом, всё это очень не нравилось людям, сидящим сзади меня, на что я ответил: «Да, чёрт возьми, это же рок – концерт!» После чего, ко мне уже никто не приставал! Вторую половину концерта, точнее, последнюю четверть, как я уже говорил, все вылезли на сцену! Ну, это образно говоря, так как охрана никого на сцену не пускала, к тому же около сцены всё было отгорожено, и попасть на нее можно было только по двум подмосткам, находящимся возле нее. И самые отчаянные фанаты, в числе которых был автор этой статьи, обступили их. Собственно, народ окончательно сошёл с ума во время исполнения «Long Live Rock’n’Roll», и все, подпевая «long live rock’n’roll» бросились на сцену! В этом безумстве мне удалось пожать руку Джо Тёрнеру (вокалисту) и получить медиатор от самого Блэкмора, пускай и младшего, но великолепно играющего на гитаре! Теперь, когда у меня есть медиатор, чтобы научиться играть на гитаре осталось то совсем ничего – купить саму гитару! Чтобы получить медиатор, надо было вынести страшную давку, массу народа, толпу людей, и после его получения, остаться в живых под человеческой массой! И мне повезло! Вот, я живой вернулся домой и печатаю этот текст!  В очередной раз, когда Джо подошёл к озверевшей публике, он опустил в нее микрофон, и, парень, стоящий возле меня поймал его и начал орать в микрофон: «Long Live Rock’n’Roll!».  Мне микрофон не достался, Джо поспешил забрать его обратно :) !

После Long Live Rock’n’Roll было исполнено ещё пара песен, но я уже не помню, что это были за песни, все вокруг что-то орали…! Опомнился я тогда, когда вместе со всеми орал: «I wanna touch you all night long, I wanna feel you all night long» - слова из песни «All Night Long».

Всё замечательное когда-нибудь заканчивается, и это была последняя песня этого великолепного концерта! Правильно сказал Ронни Дио в 1978 (когда был вокалистом Rainbow) в своей песне: “Long Live Rock’n’Roll!”

 Ассемблерная заметка №3

О разрядности процессоров

Процессор считается «N-битным», главным образом, по размеру его шины данных и значительной части его сущностей (внутренней архитектуры): регистров, аккумуляторов, арифметико-логических единиц (ALU), набора инструкций и т. д.

Например: Старый добрый процессор Motorola 6800 (или Intel 8050) - это 8-битный процессор. Он имеет 8-битную шину данных, 8-битную внутреннюю архитектуру и 16-разрядную адресную шину.

Ассемблерная заметка №2

Об инструкции CMP

Furthermore, with the CMP instruction, the destination operand doesn't change. Just the flags.

Let me illustrate. Let's say EAX = 00000005 and EBX = 00000005. If we do this arithmetic operation:

CMP EAX, EBX

What's happening, is in effect this:

EAX - EBX ----> 00000005 - 00000005

Since the result would be 0, but we don't change the destination operand in a CMP instruction, the zero flag is set to 1 (since it's true).

So, as we saw, depending on the result of the previous arithmetic operation, flags can be set accordingly:

Ассемблерная заметка №1

Об инструкции TEST

Some x86 instructions are designed to leave the content of the operands (registers) as they are and just set/unset specific internal CPU flags like the zero-flag (ZF). You can think at the ZF as a true/false boolean flag that resides inside the CPU.

in this particular case, TEST instruction performs a bitwise logical AND, discards the actual result and sets/unsets the ZF according to the result of the logical and: if the result is zero it sets ZF = 1, otherwise it sets ZF = 0.

Conditional jump instructions like JE are designed to look at the ZF for jumping/notjumping so using TEST and JE together is equivalent to perform a conditional jump based on the value of a specific register:

example:

TEST EAX,EAX

JE some_address

the CPU will jump to "some_address" if and only if ZF = 1, in other words if and only if AND(EAX,EAX) = 0 which in turn it can occur if and only if EAX == 0

the equivalent C code is:

if(eax == 0)

{

    goto some_address

}