Кодерский уголок

В опасении выделять из игр "игровую" составляющую. Копать можно только интерфейсные детали - графику и тексты. Но не логику и алгоритмы поведения. Гадкие старые игры

 

Я реально не догоняю... Ну закрыли тебе тему, потому что не поняли её смысл... Так бывает - не всем дано понять высокое

Спойлер: анекдотик

Октябрь 1974 г. Брежнев читает западные отзывы о "Бульдозерной выставке": ". чудовищное преступление против свободы творчества. красный сапог на горле культуры. варварская выходка. гневно осуждаем. передовая общественность не допустит. деятели культуры протестуют. "
Леонид Ильич отбрасывает бумаги, закрывает лицо руками, выдерживает МХАТовскую паузу, и гневно кричит:
— Ну что за дебилы!! Загнившее, зажравшееся, самодовольное стадо! Это же перформанс!! Как же они не понимают?! Бульдозер, сметающий картины — аллегорическое олицетворение хтонического ужаса, экзистенциальное воплощение протеста против агрессивных тенденций мироздания, дерзкий прорыв в навий мрак антимира. Современное искусство обязано шокировать и эпатировать!! Эпатировать и шокировать!! Да-с!! Боже, какие же они не тонкие, бесчувственные и бескультурные амёбы! Что эти дикари вообще смыслят в передовом акционизме?!

 

Видимо, дело в математике. Не любят ее здесь.

 

Ты сгущаешь краски...
Думаешь если я возьму игру(идеи, некую атмосферу - хотя это наверно сугубо личное) и сделаю из неё другую, то меня забанят?

 

Нет. Но тему обсуждения этой переделки, скорее всего, засрут и закроют.

 

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

--- добавлено 18 апр 2024, предыдущее сообщение размещено: 18 апр 2024 ---

Давай по теме тут писать,что-то про программирование что бы было, а то закроют тему то ))

 

Ну, на мой вопрос уже ответили. Лучший результат для игр 320*200 дает перевод экрана в "режим старого телевизора".

 

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

Это из Anno 1602, 64х31.
В Age of Empires, в первой версии 65х33, во второй 97х49 (по сути тоже самое, но под большие разрешение эрана).
В Lords of the Realm II, 58х30...

Если гуглить, то там будут советовать, что-то типа 64х32, соотношение 2 к 1.

Везде тайлы имеют "лесенку" по диагонали не рвану, что собственно и советуют. Но вот почему у одни высота чётная, у других не чётная? На чём основан их выбор?

 

Стандартно для чертежной изометрии.

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

 

У них не чётная высота, в базовом тайле. А так в высоту они могут быть и выше, в изометрии же, ширина постоянна...

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

 

Недавно попадалась статья как раз на эту тему: Как рисуется карта в Фараоне

 

Статья не ответила, на мой вопрос, но почитать было интересно и нашёл кучу интересных ссылок в комментариях, а а по тем ссылкам, еще ссылок... в общем два вечера было что почитать ))
Я недолюбливаю Хабр, за его политику. Мне не дают оставить комментарий, там где мне надо... И я теряю интерес нем. Потом пароль теряется, потом что-то надо - снова регаюсь, и снова не дают )) Я думаю не меньше 4-5 раз там регался за 15 лет активного использования интернета ))

 

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

На текущий момент обработана только треть одного видео (24 минуты, 60 кадров, AV1). Чем дальше от начала, тем больше времени уходит на один кадр (сейчас две-три минуты, сколько будет при чтении к концу пока не проверил).
Возможно, однако, что из-за кодека и процессора (i7-2600S, 2.8Ghz) проще перенести процесс на систему более мощную (таковая есть)?

 

Скорее из за Того, что видео закодировано без ключевых кадров, и В таком случае, его при любом чихе необходимо сначала до нужного момента читать.

--- добавлено 8 дек 2024, предыдущее сообщение размещено: 8 дек 2024 ---

Возможно, будет быстрее перекодировать заново с ключевыми кадрами, и уже после из него нужные дёргать

 

Тогда пока пострадаю и потом попробую на другой системе. Если и там будет также медленно читаться, то тогда попробую через перекодировку.

 

С использованием нейросетей начал понемногу пробовать реализовать один личный долгосрочный проект. Сделано пока немного, но возник вопрос который хотелось бы задать заранее.
На текущий момент сделал рисовалку на ассемблере, которая работает в нестандартном режиме 160x100x16 RGBI с возможностью сохранения результата в файл (IMG.PIC, 16000 байт, работа с файлом через FCB (File Control Block)).
Однако возникла новая проблема - после сохранения или загрузки файла (клавиши S и L соответственно) перестает работать прочий функционал (курсор не реагирует на стрелки, а при нажатии на другие клавиши он перемещается на несколько пикселей вправо в пределах строки, поведение повторяется и при выходе и повторном запуске). Попытки это исправить успехом не увенчались (Qwen, DeepSeek, Grok).
Возможно, что ошибку можно было бы отловить через дебаг, но моих способностей на это не хватает.
Исправление данной ошибки не является принципиально важным (можно компенсировать используя dosbox-x и DosBox Pure с сейв-стейтами), но есть некоторый интерес в выявлении проблемы и её устранении.
Буду благодарен, если кто-то сможет с этим помочь.
Во вложении - код на ассемблере, скомпилированный исполняемый файл и тестовый IMG.PIC.

 

@Gamerun, А с ассемблера конвертнуть во что нить типа python-а, и потом уже "прозондировать" в чем-нить из вышеназванного (или например с gemini) на предмет бага(-ов)?..

 

Если очень древние и нестандартные приёмы кода, может не понять. Или своё добавить. А тем более конверт, остаётся только логика алгоритма, а ошибки платформы будут выкинуты или преумножены. Удобно если результат понятен, функция выполняется нужная или документ в формате понимает. я демку полёт на Марсе пробовал из АСМ вывести, в целом работает, летает, но насажало собственных артефактов, причём попытка исправления их уродовало движок окончательно.
Чем сложнее код тем больше к ошибкам, ошибки ИИ ещё добавляются.

В данном случае я бы режим сделал - сохранить и выйти.

И, может быть стоит не на АСМ писать? Работает ли на железе это вообще (а то может быть с железом всё ок, падает под досбоксами), хотя бы в полноценных эмуляторах попробовать запускать, а не в досбокс. Может он тупо не поддерживает прерывания или вектора какие. Ну и явно мусор после запуска и краша утилиты остаётся, который мешает, возможно выгружатопы какие резидентные могут без остатка снимать задачу.
И совсем глупый вопрос, если это АСМ, зачем в формате EXE скомпилированно, а не в COM? смотрю с телефона.

 

LINK.EXE компилит EXE, для COM нужен EXE2BIN, который появился только в PC-DOS 1.10 (в PC-DOS 1.00 только LINK.EXE).

Это часть идеи проекта - использовать сохранившийся до ныне софт по годам (конкретно в этом случае - 1982 год).

В PCBox работает (конфиг

), в MartyPC тоже.

 

@Gamerun, понял :-) а статья хорошая получилась, мне понравилось.

ответ дипсика

Основная причина зависания программы при нажатии клавиш S (Save) и L (Load) – отсутствие обработки критических ошибок DOS (Int 24h).
При попытке обращения к диску (чтение/запись через FC DOS может вызвать обработчик критической ошибки, если диск не готов, отсутствует или повреждён. По умолчанию DOS выводит сообщение «Abort, Retry, Fail?» и ожидает ввода с клавиатуры. Программа при этом останавливается, экран переключается в текстовый режим (или искажается), создавая иллюзию зависания. Пользователь не видит сообщения DOS из-за графического режима и не может ответить, поэтому программа «висит».

Дополнительные потенциальные проблемы в коде:

1. Неправильная адресация данных CRTC в процедуре SET_MODE_160X100
   В строке MOV AL, CS:[SI] происходит обращение к сегменту кода (CS), хотя массив crtcvals находится в сегменте данных (DATA_SEG). Из-за этого могут загружаться неверные значения регистров CRTC, что приведёт к некорректной установке видеорежима.
   Исправление: заменить CS:[SI] на DS:[SI] (или просто [SI], т.к. DS используется по умолчанию).
   
   
2. Избыточное сохранение/восстановление регистров в обработчиках ошибок
   Хотя формально баланс стека соблюдён, код в SAVE_ERROR_POP и LOAD_ERROR_POP избыточен и может запутать при сопровождении. Рекомендуется упростить логику, убрав лишние POP или используя единую точку выхода.
   
   
3. Отсутствие восстановления видеопамяти после FLASH_GREEN / FLASH_RED
   Процедуры визуальной обратной связи затирают верхнюю строку экрана, но не восстанавливают её. После возврата в основной цикл эта область остаётся испорченной. Хотя это не приводит к зависанию, ухудшает пользовательский опыт.

Рекомендации по исправлению:

• Добавить обработчик критической ошибки (INT 24h), который будет возвращать код «Fail» без ожидания ввода, либо установить собственный обработчик, чтобы избежать блокировки.
  
  
• Использовать функции DOS с расширенной обработкой ошибок (например, через handles с проверкой кода возврата в AX), что менее подвержено критическим ошибкам.
  
  
• Исправить обращение к crtcvals в SET_MODE_160X100, убрав префикс CS:.
  
  
• В процедурах FLASH_GREEN и FLASH_RED перед выходом восстанавливать предыдущее содержимое экрана (сохранять буфер или перерисовывать). Либо использовать более щадящие способы индикации (например, изменение цвета рамки).

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

исправления

"Исправленная версия программы DRAW160.ASM
Что именно было исправлено:
(Основные изменения: добавлен обработчик критической ошибки INT 24h, исправлена адресация CRTC, упорядочено сохранение регистров в процедурах ввода‑вывода, восстановление верхней строки экрана после визуальной индикации.)"

"

1. 
   
   
   • Добавлен обработчик INT 24h (MY_INT24), который просто возвращает код Fail (03h) без вмешательства пользователя. Это предотвращает зависание при ошибках дискеты/диска.
   • В процедуре SET_MODE_160X100 убрано ошибочное обращение к CS:[SI] — теперь данные читаются из DS:[SI].
   • Переписаны процедуры SAVE_IMAGE и LOAD_IMAGE – восстановлен правильный порядок сохранения регистров (PUSH/POP), убраны лишние POP AX, добавлены комментарии.
   • Визуальная индикация (FLASH_GREEN / FLASH_RED) теперь сохраняет и восстанавливает верхнюю строку экрана, чтобы не портить рисунок.
   • Добавлены переменные для хранения старого вектора INT 24h и установка/восстановление этого вектора при входе/выходе.

После этих изменений программа перестанет зависать при нажатии S или L, а также корректно отработает при отсутствии диска или других ошибках ввода‑вывода."

Не знаю, получилось у него что или нет, и соответствует ли предложенный вариант историчности поддержки.