У нас был опыт разработки под Эльбрус ПО для системы рентгеновской инспекции. Чтобы этот хоть как-то работало в режиме реального времени (там как раз обработка больших изображений и пр.) пришлось вынести все, что возможно, на видеокарту. Чтобы процессор вообще не участвовал в процессе. Вот тогда все заработало прилично по скорости. Но от Эльбруса в плане использования осталось одно формальное название. Других вариантов не было 😂
Как-то делали свою систему реактивности на c++. И подробная задача встала в чуть более обобщённом варианте. Нужна была возможность отдать из объекта callback, который имеет доступ к полям объекта. Не только для рассылок, в объем случае. Сам объект мог начать уничтожаться в произвольный момент из произвольного места. Завернуть весь объект в шаред и удерживать его не всегда было возможно. В итоге сделали под такие callback отдельный класс с блокирующим деструктором. И помещали их в конец определения класса. Пока шла обработка вызова callback, его деструктор просто не давал родительскому объекту уничтожитьия. Бонусом убрали необходимость обязательной рассылки. По типу weak_ptt. Если такой callback умер, тот вызова и не будет. Само потом почиститься. В итоге и ручных отписок в очень большом production приложении практически нет. За исключением какой-то сложной логики
Не работал с orient_2d. Быстрый поиск сказал, что это это при ориентацию треугольника. Если в ней больше ничего нет, то это самая наименьшая проблема в задаче булевых операций между двуми треугольниками. Так другие проблемы с точностями и округлениям возникают в части согласованности трактовок разных кейсов. У меня была продакшн задача, где требовалось гарантированное робастное решение. Ух, сколько проблем вылезло. CGAL, libIGL многие другие известные библиотеки не справлялись пр разному. CGAL просто крашился на сложныз случаях. libIGL не справлялся нормально, когда из одного треугольника нужно было вычесть десять и т.д. Задача кажется простой, но...
SDF как приближенное решение - да. А все описанное в статье - логично. Но не решает задачу на практике. Для начала нужно написать алгоритм, который сможет корректно отработать просто два треугольника. Решение для 95% случаев пишется за день. Для остальных 5% случаев за время, которое сложно оценить 😂 Может занят годы. Из-за неточностей и округлений. Когда надоест, можно посмотреть на библиотеку Manifold. Единственную из тех, что мне попадались, где все это корректно продумано. Да, она 3D, но это не меняет сути вопроса. И обязательно почитать диссертацию, на которую они ссылаются. Если в итоге получится рабочее собственное решение, нужно сделать много-много текстов на всякие пограничные случаи.
Как Вы так прочитали мой коментарий? Я писал о мнении других людей. Для меня оно понятно, что удобнее всего остального, т.к. писалось как для себя. Я говорил конкретно о коммерческих пользователях, коих уже под сотню. Почти все заказчики имеет многолетний опыт в сфере отработки томографических объемов, в основном в ПО известных производителей томографов (типа GE, Yxlon, Nikon, пр.), и независимых монстро-пакетах типа VG (VolumeGraphics). Я привел их отзывы. После них наш продукт воспринимается (дословная цитата) как "хорошо оптимизированная игра" как в плане удобства, так и скорости. Блендером они так же почти все пользуются факультатовно для подготовки разных вспомогательных мешей.
Не очень понимаю причину такой яростной защиты блендера. Мой личный опыт сильно негативный. Всегда привожу его на собраниях по UX/UI как антипример. Никто ни разу не возразил. Есть знакомые дизайнеры, работающие проффесионально на киноиндустрию. Рисуют картинки для моделированитя атмосферны полнометражны фильмов (не знаю как это правильно называется). Из того, что я видел, уровень Марвелла (я не профи в графике такого уровне, но очень круто). Все сидят на винде, видел 3D Max, Photoshop, много других инструментов. Никаких блендеров. Но там реальная постоянная работа, им некогда играться.
У вас праздный интерес или реальный? Вопрос том, что профессионалу нужен инструмент, который позволяет ему эффективно работать, а не решать какие-то проблемы, не связанные с задачей. Для бытовых целей перечисленные открытые инструменты вполне себе. Да и еще и бесплатные. Это хорошо. Что-то можно сделать.
А в профессиональной сфере выбор инструмента осуществляется именно по наличию нужных возможностей, удобству, скорости и качеству достижения целей. Религиозность выбора ОС здесь вообще не присутствует. Например, если я сейчас (реальный кейс) разрабатыаю внутреннее ПО рентгеновского детектора (это такая камера для детектирования рентгена с размером активной области сенсора 43х43 см), то у меня стоит Линукс, вопроса выбора ОС не было. Т.к. внутри у него тоже Линукс. Это логично и во многом удобно.
Если Вам заказчик по долгу службьы высылает огромные xlsx (не имеет смысл обсужлдать, насколько это правильно, заказчик есть заказчик), то вы должны иметь возможноть его открыть и изменить без того, что бы испорить. А это возможно только в оригинальном MS Office. У меня много таких файлов, даже при условии, что я не занимаюсь такиеми документами, ни идут как сопроводительные. Аналогично с другими офисными документами со сложным форматированием. Если ваша рабоат связана с ними, то нужен оригинальный офис. Ставить его не на винду, ну это на вкус и цвет. Я бы так не делал.
Аналогично с Gimp. Я профессионально работал в дизайне еще до 2000 года. Сейчас регулярно открываю Gimp для мелких задач, ничего сложного мне не требуется. Так вот текущший Gimp для проф. использования не сравним Corel Photopaint 5-6 версии и фотошопом тех лет. Это сугубо мое мнение, может кому нравится.
Про блендер мне сложно объяснить, если у Вас не было опыта работы с ним в плане редактирования сложных моделей. Если интперес реальный - попробуйте. Но даже на базовом уровне наш собственный инстумент для анализа томографических 3D объемов, которому всего один год отроду, имеет на порядок более удобную навигацию по 3D пространству. Это подтверждается всеми, кто пробовал. Вам, извините, предложить попробовать не могу, идет в комплекте с оборудованием.
Статья очень похожа на пропихивание Линукс тем, кому он не подходит. Да свободная система, да, хорошая во многом, но работа она не про ОС. Мотивация выборы Линукс для решения этих задач мне абсолютна непонятна. А для непосвященных просто вредна.
Да ровно тоже, что и с OpenOffice, Gimp и еще с ними. В блендере плюс к этому еще просто феерический UI/UX, на уровне злого гения. Для поделок и простых работ, либо если вы в них профи и вообще никак не завязаны не внешние требования, может и подойдет. С натягом. Возможно. Но это не точно. А для профессиональных работ, когда вам нужно просто эффективно и качественно работать, лучше даже не заикаться про все эти варианты. Это если касаться только возможностей/удобства. Но есть еще огромный пласт требований по 100% совместимости с заказчиком. Тут вообще говорить не о чем.
Полностью согласен. Если обновить комп раз в 5 лет заставляет напречься, то лучше поискать другой вид деятельности. А выбор ОС... В мире разработки/дизайна и других работ (не пользования соц. сеточками) - если нормального софта под ОС для данной задачи нет, то нет и смысла обсуждать достоинства этой ОС. Это просто запускалка нужного софта. Ее просто не должно быть видно. Я - программер под всякие томографии, в основном быстрые реализации GPU, визуализация воксельных объемов, большие объемы данных. Мне Linux вполне себе, удобнее винды. Но под винду совместимость поддерживаем. А вот если нужен, хотя бы нормальный офис и совместимость со сложными таблицами, то Linux в пролете. У меня у зказчика есть сложная таблица, из которой наш импортер забирает всякие связи для внутренностей софта. Наш импортер работает, а вот открыть этот xlxs в Линуке уже никак. Ни то, что бы подредактировать. Благо это не есть наша задача. В сфере дизайна (тоже занимался ни один год) вообще обсуждать нечего. Gimp и Blender - даже не смешно. Тут альтернатив винде просто нет (для 2D Mac норм еще, 3D уже нет).
Андрей. У Вас очень хорошие статьи, читаю с удовольствием. Но вот лично меня терзают сомнения, стоит ли публиковать такое. В том смысле, что если человек этого не понимает, то так писать просто не следует. А стоит пользоваться функциями выделения из (своей или чужой) библиотеки, которая, во-первых, сделаем проверку. Но важнее, что вернет shared. Еще раз - если с умом и этого не требуется, то можно и руками, но редко. Итого имеем выделение и освобождение без проблем. Может у меня параноя, но я все Cuda'вское так же выделяю с кастомными делитерами через shared. Включая даже stream. Просто что бы забыть об их управлении. И это в мега нагруженном Cuda коде. Коментарий для начинающих, естественно.
Нда. Обленились люди. Если хоть раз видел отладчик в жизни, понимаешь, что можно просто поставить бряки. Не только на код, но и на доступ к памяти по определьным адресам. И не нужно полагаться на стандартные обфуксакторы и пр. Первым делом делается явная проверка, для частных людей. Она работает, но легко выпиливатся. Ее цель формальная. Далее хотя бы делается развязка кода общения с ключом и кода запрашивающего. Минимальная крипта. В случае маленьких обменов и тривиальной хватит. Т.е. факт запроса есть, а кто запросил и что сделал с результатом не ловится. Ну и по результатам немного что-то делаем, без явного последствия. Это уже болезненно. А если сверху статистику от ключа с неизвестным распределением и обычный обфускатор, то, скорее всего, ваше ПО не насколько нужно. Все перечисленное "свое" пишется за день. Пробовал. Работает отлично
Вот прямо в точку. Я неплохой такой спец по разного рода обработке изображений, начиная от оптической и электронной микроскопии, и особенно заканчивая рентгеном и томографией.
Германия. Врач делает снимок, смотрит, говорит - нужно все вскрывать, у вас каналы пустые (не запломбированные), все пропало. Я офигеваю немного, беру в руки снимок. Еще раз офигеваю и сообщаю, что это не мой зуб. Его лицо нужно было видеть...
А историй про то, как и от чего пытались лечить детей даже пересказывать не буду. Когда после их вредительских диагнозов приходил к врачам на пару уровней выше, не единожды слышал: "Ну мы же, блин, их этому учили. Эх...".
Все, что описано выше правда. Но не имеет никакого смысла пока не начать думать как описано выше ? Поскольку для таких задач CPU уже странно использовать, то мы упираемся примерно в те же вопросы, нет уже на уровне GPU. И то, что описано как "хитрое" есть как должное. Любой алгоритм на GPU начинается с выбора паттерна доступа к памяти. Очень часто там и заканчивается ?
Стекло аморфно. Из этого вытекает две проблемы. Первой вытекает именно текучесть ? В достаточно старых храмах, которым далеко не сотни тысяч лет, остекление утолщено к низу вследствие течения. Да, там есть нагрузка. Но даже в тонких пластинах, думаю, эффект может сыграть из-за очень малого размера областей интереса (битов). Эффект номер два - кристаллизация, которая, конечно, идёт медленно из-за низкой текучести, но идет. Из-за этого в тех же храмах остекление мутнеет. Так что со временем хранения, мне кажется, они погорячились. Но это, скорее всего, и не нужно в таких масштабах.
И да. Есть собственная система реактивная, для Qt и Qml, ибо плакать хочется от дефолтной реализации. И все на shared. Без этой всякой ерунды с parent. И без всяких signal/slot , поскольку бесит писать десятки строк в никуда.
Проблема вообще мало понятная. Когда пишешь, нужно думать. Хоть малечко. Большие проекты. Все на C++. Один раз в жизни посмотрел на память. Ничего интересного не увидел. Обычные sbared, вкупе с UI weak , иногда. Чего сложного?
Абсолютно согласен. Почти 30 лет назад звали туда учиться, после результатов олимпиад. Не поехал, чему несказанно рад. В этом году имел удовольствие собеседовать 3 человека из данного вуза по IT профилю. Результаты такие же, как у выпускников ИТМО. Такие же, как после любого ВУЗа. Если человек умен, ВУЗ ему поможет (немного). Не более того. Сын сейчас учится в другом, тоже не безызвестном заведении. Я даже не берусь оценивать - сам плюется.
Позволю себе не согласится. Не знаю конкретно насчет танков, но писал достаточно много игр на ассемблере для ZX Spectrum. Намного больше этой. И знаете, там был далеко не говнокод. Да, глобальные переменные, но все четко структурировано, вполне предсказуемо и даже отлаживаемо. При крайне ограниченных ресурсах. Многим современным писателям и не снилось такое. Если что, сейчас занимаюсь разработкой сложного спец. софта для аналитического оборудования, могу оценить умения современных разработчиков. Часто просто страшно смотреть.
Микровокусные рентнгеновские трубки для рентгеновской томографии вещь серийная. К дифрактографии они, правда, отношения совсем не имеют. Там другие трубки и задачи.
У нас был опыт разработки под Эльбрус ПО для системы рентгеновской инспекции. Чтобы этот хоть как-то работало в режиме реального времени (там как раз обработка больших изображений и пр.) пришлось вынести все, что возможно, на видеокарту. Чтобы процессор вообще не участвовал в процессе. Вот тогда все заработало прилично по скорости. Но от Эльбруса в плане использования осталось одно формальное название. Других вариантов не было 😂
Как-то делали свою систему реактивности на c++. И подробная задача встала в чуть более обобщённом варианте. Нужна была возможность отдать из объекта callback, который имеет доступ к полям объекта. Не только для рассылок, в объем случае. Сам объект мог начать уничтожаться в произвольный момент из произвольного места. Завернуть весь объект в шаред и удерживать его не всегда было возможно. В итоге сделали под такие callback отдельный класс с блокирующим деструктором. И помещали их в конец определения класса. Пока шла обработка вызова callback, его деструктор просто не давал родительскому объекту уничтожитьия. Бонусом убрали необходимость обязательной рассылки. По типу weak_ptt. Если такой callback умер, тот вызова и не будет. Само потом почиститься. В итоге и ручных отписок в очень большом production приложении практически нет. За исключением какой-то сложной логики
Не работал с orient_2d. Быстрый поиск сказал, что это это при ориентацию треугольника. Если в ней больше ничего нет, то это самая наименьшая проблема в задаче булевых операций между двуми треугольниками. Так другие проблемы с точностями и округлениям возникают в части согласованности трактовок разных кейсов. У меня была продакшн задача, где требовалось гарантированное робастное решение. Ух, сколько проблем вылезло. CGAL, libIGL многие другие известные библиотеки не справлялись пр разному. CGAL просто крашился на сложныз случаях. libIGL не справлялся нормально, когда из одного треугольника нужно было вычесть десять и т.д. Задача кажется простой, но...
SDF как приближенное решение - да. А все описанное в статье - логично. Но не решает задачу на практике. Для начала нужно написать алгоритм, который сможет корректно отработать просто два треугольника. Решение для 95% случаев пишется за день. Для остальных 5% случаев за время, которое сложно оценить 😂 Может занят годы. Из-за неточностей и округлений. Когда надоест, можно посмотреть на библиотеку Manifold. Единственную из тех, что мне попадались, где все это корректно продумано. Да, она 3D, но это не меняет сути вопроса. И обязательно почитать диссертацию, на которую они ссылаются. Если в итоге получится рабочее собственное решение, нужно сделать много-много текстов на всякие пограничные случаи.
Как Вы так прочитали мой коментарий? Я писал о мнении других людей. Для меня оно понятно, что удобнее всего остального, т.к. писалось как для себя. Я говорил конкретно о коммерческих пользователях, коих уже под сотню. Почти все заказчики имеет многолетний опыт в сфере отработки томографических объемов, в основном в ПО известных производителей томографов (типа GE, Yxlon, Nikon, пр.), и независимых монстро-пакетах типа VG (VolumeGraphics). Я привел их отзывы. После них наш продукт воспринимается (дословная цитата) как "хорошо оптимизированная игра" как в плане удобства, так и скорости. Блендером они так же почти все пользуются факультатовно для подготовки разных вспомогательных мешей.
Не очень понимаю причину такой яростной защиты блендера. Мой личный опыт сильно негативный. Всегда привожу его на собраниях по UX/UI как антипример. Никто ни разу не возразил. Есть знакомые дизайнеры, работающие проффесионально на киноиндустрию. Рисуют картинки для моделированитя атмосферны полнометражны фильмов (не знаю как это правильно называется). Из того, что я видел, уровень Марвелла (я не профи в графике такого уровне, но очень круто). Все сидят на винде, видел 3D Max, Photoshop, много других инструментов. Никаких блендеров. Но там реальная постоянная работа, им некогда играться.
У вас праздный интерес или реальный? Вопрос том, что профессионалу нужен инструмент, который позволяет ему эффективно работать, а не решать какие-то проблемы, не связанные с задачей. Для бытовых целей перечисленные открытые инструменты вполне себе. Да и еще и бесплатные. Это хорошо. Что-то можно сделать.
А в профессиональной сфере выбор инструмента осуществляется именно по наличию нужных возможностей, удобству, скорости и качеству достижения целей. Религиозность выбора ОС здесь вообще не присутствует. Например, если я сейчас (реальный кейс) разрабатыаю внутреннее ПО рентгеновского детектора (это такая камера для детектирования рентгена с размером активной области сенсора 43х43 см), то у меня стоит Линукс, вопроса выбора ОС не было. Т.к. внутри у него тоже Линукс. Это логично и во многом удобно.
Если Вам заказчик по долгу службьы высылает огромные xlsx (не имеет смысл обсужлдать, насколько это правильно, заказчик есть заказчик), то вы должны иметь возможноть его открыть и изменить без того, что бы испорить. А это возможно только в оригинальном MS Office. У меня много таких файлов, даже при условии, что я не занимаюсь такиеми документами, ни идут как сопроводительные. Аналогично с другими офисными документами со сложным форматированием. Если ваша рабоат связана с ними, то нужен оригинальный офис. Ставить его не на винду, ну это на вкус и цвет. Я бы так не делал.
Аналогично с Gimp. Я профессионально работал в дизайне еще до 2000 года. Сейчас регулярно открываю Gimp для мелких задач, ничего сложного мне не требуется. Так вот текущший Gimp для проф. использования не сравним Corel Photopaint 5-6 версии и фотошопом тех лет. Это сугубо мое мнение, может кому нравится.
Про блендер мне сложно объяснить, если у Вас не было опыта работы с ним в плане редактирования сложных моделей. Если интперес реальный - попробуйте. Но даже на базовом уровне наш собственный инстумент для анализа томографических 3D объемов, которому всего один год отроду, имеет на порядок более удобную навигацию по 3D пространству. Это подтверждается всеми, кто пробовал. Вам, извините, предложить попробовать не могу, идет в комплекте с оборудованием.
Статья очень похожа на пропихивание Линукс тем, кому он не подходит. Да свободная система, да, хорошая во многом, но работа она не про ОС. Мотивация выборы Линукс для решения этих задач мне абсолютна непонятна. А для непосвященных просто вредна.
Да ровно тоже, что и с OpenOffice, Gimp и еще с ними. В блендере плюс к этому еще просто феерический UI/UX, на уровне злого гения. Для поделок и простых работ, либо если вы в них профи и вообще никак не завязаны не внешние требования, может и подойдет. С натягом. Возможно. Но это не точно. А для профессиональных работ, когда вам нужно просто эффективно и качественно работать, лучше даже не заикаться про все эти варианты. Это если касаться только возможностей/удобства. Но есть еще огромный пласт требований по 100% совместимости с заказчиком. Тут вообще говорить не о чем.
Полностью согласен. Если обновить комп раз в 5 лет заставляет напречься, то лучше поискать другой вид деятельности. А выбор ОС... В мире разработки/дизайна и других работ (не пользования соц. сеточками) - если нормального софта под ОС для данной задачи нет, то нет и смысла обсуждать достоинства этой ОС. Это просто запускалка нужного софта. Ее просто не должно быть видно. Я - программер под всякие томографии, в основном быстрые реализации GPU, визуализация воксельных объемов, большие объемы данных. Мне Linux вполне себе, удобнее винды. Но под винду совместимость поддерживаем. А вот если нужен, хотя бы нормальный офис и совместимость со сложными таблицами, то Linux в пролете. У меня у зказчика есть сложная таблица, из которой наш импортер забирает всякие связи для внутренностей софта. Наш импортер работает, а вот открыть этот xlxs в Линуке уже никак. Ни то, что бы подредактировать. Благо это не есть наша задача. В сфере дизайна (тоже занимался ни один год) вообще обсуждать нечего. Gimp и Blender - даже не смешно. Тут альтернатив винде просто нет (для 2D Mac норм еще, 3D уже нет).
Прискорбно. Если все хреново в принципе, тема статьи не в кассу.
throw... Мы же в C++. Отлов на внешнем уровне вроде как является обязательным с точки зрения здравого смысла.
Андрей. У Вас очень хорошие статьи, читаю с удовольствием. Но вот лично меня терзают сомнения, стоит ли публиковать такое. В том смысле, что если человек этого не понимает, то так писать просто не следует. А стоит пользоваться функциями выделения из (своей или чужой) библиотеки, которая, во-первых, сделаем проверку. Но важнее, что вернет shared. Еще раз - если с умом и этого не требуется, то можно и руками, но редко. Итого имеем выделение и освобождение без проблем. Может у меня параноя, но я все Cuda'вское так же выделяю с кастомными делитерами через shared. Включая даже stream. Просто что бы забыть об их управлении. И это в мега нагруженном Cuda коде. Коментарий для начинающих, естественно.
Нда. Обленились люди. Если хоть раз видел отладчик в жизни, понимаешь, что можно просто поставить бряки. Не только на код, но и на доступ к памяти по определьным адресам. И не нужно полагаться на стандартные обфуксакторы и пр. Первым делом делается явная проверка, для частных людей. Она работает, но легко выпиливатся. Ее цель формальная. Далее хотя бы делается развязка кода общения с ключом и кода запрашивающего. Минимальная крипта. В случае маленьких обменов и тривиальной хватит. Т.е. факт запроса есть, а кто запросил и что сделал с результатом не ловится. Ну и по результатам немного что-то делаем, без явного последствия. Это уже болезненно. А если сверху статистику от ключа с неизвестным распределением и обычный обфускатор, то, скорее всего, ваше ПО не насколько нужно. Все перечисленное "свое" пишется за день. Пробовал. Работает отлично
Вот прямо в точку. Я неплохой такой спец по разного рода обработке изображений, начиная от оптической и электронной микроскопии, и особенно заканчивая рентгеном и томографией.
Германия. Врач делает снимок, смотрит, говорит - нужно все вскрывать, у вас каналы пустые (не запломбированные), все пропало. Я офигеваю немного, беру в руки снимок. Еще раз офигеваю и сообщаю, что это не мой зуб. Его лицо нужно было видеть...
А историй про то, как и от чего пытались лечить детей даже пересказывать не буду. Когда после их вредительских диагнозов приходил к врачам на пару уровней выше, не единожды слышал: "Ну мы же, блин, их этому учили. Эх...".
Все, что описано выше правда. Но не имеет никакого смысла пока не начать думать как описано выше ? Поскольку для таких задач CPU уже странно использовать, то мы упираемся примерно в те же вопросы, нет уже на уровне GPU. И то, что описано как "хитрое" есть как должное. Любой алгоритм на GPU начинается с выбора паттерна доступа к памяти. Очень часто там и заканчивается ?
Стекло аморфно. Из этого вытекает две проблемы. Первой вытекает именно текучесть ? В достаточно старых храмах, которым далеко не сотни тысяч лет, остекление утолщено к низу вследствие течения. Да, там есть нагрузка. Но даже в тонких пластинах, думаю, эффект может сыграть из-за очень малого размера областей интереса (битов). Эффект номер два - кристаллизация, которая, конечно, идёт медленно из-за низкой текучести, но идет. Из-за этого в тех же храмах остекление мутнеет. Так что со временем хранения, мне кажется, они погорячились. Но это, скорее всего, и не нужно в таких масштабах.
И да. Есть собственная система реактивная, для Qt и Qml, ибо плакать хочется от дефолтной реализации. И все на shared. Без этой всякой ерунды с parent. И без всяких signal/slot , поскольку бесит писать десятки строк в никуда.
Проблема вообще мало понятная. Когда пишешь, нужно думать. Хоть малечко. Большие проекты. Все на C++. Один раз в жизни посмотрел на память. Ничего интересного не увидел. Обычные sbared, вкупе с UI weak , иногда. Чего сложного?
Абсолютно согласен. Почти 30 лет назад звали туда учиться, после результатов олимпиад. Не поехал, чему несказанно рад. В этом году имел удовольствие собеседовать 3 человека из данного вуза по IT профилю. Результаты такие же, как у выпускников ИТМО. Такие же, как после любого ВУЗа. Если человек умен, ВУЗ ему поможет (немного). Не более того. Сын сейчас учится в другом, тоже не безызвестном заведении. Я даже не берусь оценивать - сам плюется.
Позволю себе не согласится. Не знаю конкретно насчет танков, но писал достаточно много игр на ассемблере для ZX Spectrum. Намного больше этой. И знаете, там был далеко не говнокод. Да, глобальные переменные, но все четко структурировано, вполне предсказуемо и даже отлаживаемо. При крайне ограниченных ресурсах. Многим современным писателям и не снилось такое. Если что, сейчас занимаюсь разработкой сложного спец. софта для аналитического оборудования, могу оценить умения современных разработчиков. Часто просто страшно смотреть.
P.S. Пример одной из игр. https://www.youtube.com/watch?v=EWBqVuqhPGc
Микровокусные рентнгеновские трубки для рентгеновской томографии вещь серийная. К дифрактографии они, правда, отношения совсем не имеют. Там другие трубки и задачи.