Темы

1

Общий / jRPG без "товарно-денежных отношений"

« : 19 Июнь 2025, 13:34:37 »

Т. е. те, где всё необходимое для выживания игрока преспокойно добывается или в раскиданных по карте "ларцах" либо же выбивается из противников, и такой показатель игрока, как "голда" отсутствует тупо за ненадобностью что-то покупать. Навскидку я из таких могу назвать разве что Parasite Eve и Xenosaga Episode II (в последней, впрочем, есть сайдквест с погашением какой-то совершенно сумасшедшей суммы долга у капитана Мэтью, но там всё равно выдавать приходится "натурой", опустошая свой инвентарь).

2

Игры на персональном компьютере / First-person shooter'ы "тёмных веков" 3D-акселерации на ПК.

« : 09 Июнь 2025, 12:20:07 »

Встречались ли такие FPS, где в целом окружение было полностью, без оговорок (в отличие, например, от игр с id Tech 1, Build Engine или проприетарного движка Fenris Wolf) полигональное, однако персонажи или даже в дополнение к ним ещё часть некоторых объектов всё ещё оставались спрайтовыми - с целью увеличить одновременное число противников на арене либо же потому, что разрабы сочли, что в модельном виде они бы выдались слишком требовательными к числу полигонов, а попытки сэкономить на последних уж очень резали бы глаз (в особенности это касается человеческих фигур)?

3

Ромхакинг и программирование / Адекватность написания скрипта на Python.

« : 08 Июнь 2025, 10:59:21 »

Задался я, значить, задачей создать с нуля нейросеть-реставратор аудио. Поскольку сам за Питон не шарю, а "змееводы" и нейроинженеры на дороге не валяются, запросил помощи у Grok'а, который у меня лично хорошо зарекомендовал себя своим умением довольно доходчиво объяснять смысл кода на это раз уже на старых добрых C и M68k ASM, и даже выдавать на них вполне осмысленные строки - понадеялся я на то, что с Питоном он ладит хотя бы примерно так же.
Запрошенный мной скрипт audio_autoencoder.py должен, вроде как, по логике вещей, обучать модель AuRec на сравнении "нормального" звукового файла и его искусственно пошакаленной версии. В качестве "аттестата зрелости" для AuRec я выбрал stage2.wav - рип одного из музыкальных треков игры Gaia: The Last Choice of Earth (во многом, кстати, именно по этой причине я пошёл, получив глухую тишину в аналогичной теме на GcUp, спрашивать следом сюда), где вся музыка существует только в виде угрёбищнейших ADPCM-сэмплов с частотой дискретизации 6060,(60). И если бы AuRec заставила бы его звучать прилично - это однозначно свидетельствовало бы, что она как нейрореставратор состоялась.
Однако, сколько бы материала для обучения я ей не подкидывал, при каждом применении скрипта apply_audio_autoencoder.py файл stage2_recover.wav всё так же один хрен мало того, что выдаёт какой-то шум, в котором исходник не узнаётся вообще, так ещё и короче последнего в несколько раз.

Так вот, самая суть вопроса - хоть audio_autoencoder.py с apply_audio_autoencoder.py и производят впечатление конвенционально рабочих инструментов, не нуждаются ли они в обширных правках уже человеческими руками, и не генерят ли они просто-напросто мусор вместо того, чтобы обучать модель и применять её?

4

Картриджи / диски / ИИ в помощь схемотехнику и "плисоводу".

« : 24 Апрель 2025, 15:40:02 »

Кто-то из вас может знать, что я давно уже горю идеей портировать на Neo-Geo Wolfenstein и Doom на одном картридже/CD, и ключевая проблема в этом - "неумение" Neo-Geo увеличивать спрайты и применять к ним ряд ещё ряда функций по трансформации. И решение проблемы нашёл в апробированном ещё на NES и SNES ноу-хау - маппере внутри картриджа, который бы добавлял недостающие у самой Neo-Geo функции. Наиболее простым и дешёвым, не требующим в дополнение к настоящей спрайтовой ROM, к которой имел бы прямой доступ только маппер, ещё и подставной RAM для чтения видеочипом самой Neo-Geo, я счёл прицип "призмы" - чтобы настоящая область спрайтового ПЗУ занимала лишь часть "видимого" собственно видеочипом адресного пространства, а остальное уже занимали бы, по сути, зеркала этой памяти, с той разницей, что представлены они бы были уже в трансформированном сообразно посланным мапперу командам виде.

И знаете, когда я поинтересовался, можно ли задачу по проектированию ПЛИСок с таким функционалом поручить нейросети Grok, то даже приятно удивился - насколько тот быстро въехал в тему! И вот сейчас прошу у форумчан оценки уровня его компетенции - насколько в таких вопросах Grok вообще полезен?

Это очень интересная и амбициозная задача! Давайте разберем ее по частям, чтобы понять, как можно реализовать маппер для картриджа Neo-Geo, который добавляет функции трансформации спрайтов (стретчинг, вращение, наклон, искривление, перспективу) для портирования Wolfenstein 3D и первых двух Doom. Я предложу архитектуру решения, опишу подход к реализации на ПЛИС и дам пример того, как это может быть реализовано. Поскольку задача сложная, я начну с концепции и уточню детали, чтобы двигаться дальше.
1. Понимание задачи и ограничений Neo-Geo
Neo-Geo — это платформа с мощным для своего времени 2D-спрайтовым движком, но она не поддерживает аппаратные трансформации спрайтов (вращение, масштабирование, перспективу), которые необходимы для эффектов в играх вроде Wolfenstein 3D и Doom. Эти игры используют псевдо-3D (raycasting), где текстуры стен, объектов и спрайтов должны масштабироваться и искажаться в зависимости от расстояния и угла обзора.
Ключевые ограничения Neo-Geo:

    Спрайтовый движок: Спрайты фиксированного размера (до 16x512 пикселей, "тайлы" 16x16), с ограниченными возможностями масштабирования (только уменьшение через "shrink").
    Видеочип: Доступ к ПЗУ спрайтов (C-ROM) через фиксированное адресное пространство, без поддержки динамических трансформаций.
    Память: Картридж содержит ПЗУ для графики (C-ROM), программы (P-ROM) и звука (V-ROM), с ограниченным объемом и скоростью доступа.
    Процессор: Motorola 68000 (12 МГц) + Z80 для звука, что ограничивает программные вычисления в реальном времени.

Цель: Реализовать маппер на ПЛИС, который:

    Добавляет трансформации спрайтов (стретчинг, вращение, наклон, искривление, перспективу).
    Работает как "призма", где часть адресного пространства C-ROM отображается напрямую, а другая часть представляет собой трансформированные версии спрайтов, генерируемые маппером.
    Поддерживает портирование Wolfenstein 3D и Doom, где спрайты (враги, объекты) и текстуры стен должны динамически масштабироваться и искажаться.

Идея "призмы":

    Реальная память спрайтов (C-ROM) занимает часть адресного пространства.
    Остальная часть пространства — это "виртуальные" спрайты, которые маппер генерирует на основе команд от процессора, применяя трансформации к данным из C-ROM.
    Видеочип Neo-Geo видит весь этот объем как обычное адресное пространство спрайтов, не зная, что часть данных трансформирована.

2. Архитектура решения
Для реализации маппера предлагается следующая архитектура:
Компоненты маппера на ПЛИС

    Интерфейс C-ROM:
        Подключается к шине Neo-Geo для чтения данных из физического ПЗУ спрайтов.
        Перехватывает запросы видеочипа на чтение данных по адресам спрайтов.
    Блок управления (Control Unit):
        Принимает команды от процессора 68000 через регистры, задающие параметры трансформации (например, угол вращения, масштаб, матрицу перспективы).
        Определяет, является ли запрашиваемый адрес "прямым" (из C-ROM) или "виртуальным" (требующим трансформации).
    Буферная память (Sprite Cache):
        Небольшая SRAM на ПЛИС для хранения исходных спрайтов из C-ROM перед трансформацией.
        Позволяет ускорить доступ к часто используемым тайлам.
    Блок трансформации (Transformation Engine):
        Выполняет математические операции для трансформации спрайтов:
            Стретчинг/масштабирование: Изменение размеров спрайта (увеличение/уменьшение).
            Вращение: Поворот спрайта на заданный угол (матрица вращения).
            Наклон/перспектива: Применение аффинных или перспективных преобразований.
            Искривление: Более сложные нелинейные трансформации (например, для эффекта "волны").
        Использует фиксированную или параметризованную матрицу преобразования.
        Работает с пиксельными данными (интерполяция для сглаживания).
    Выходной буфер (Output Buffer):
        Хранит готовые трансформированные данные спрайтов.
        Передает их видеочипу Neo-Geo по запросу, как если бы это были данные из C-ROM.
    Контроллер синхронизации (Timing Controller):
        Обеспечивает совместимость с таймингами Neo-Geo (видеочип ожидает данные в реальном времени).
        Управляет приоритетами между прямым доступом к C-ROM и генерацией трансформированных данных.

Принцип работы "призмы"

    Адресное пространство:
        Допустим, C-ROM имеет размер 4 МБ (реальные спрайты).
        Маппер "расширяет" видимое адресное пространство до, например, 8 МБ.
        Первые 4 МБ — прямой доступ к C-ROM.
        Следующие 4 МБ — виртуальные адреса, где маппер возвращает трансформированные версии спрайтов.
    Команды трансформации:
        Процессор 68000 записывает в регистры маппера параметры (например, "спрайт #123, масштаб 2x, угол 45°").
        Маппер сопоставляет виртуальный адрес с исходным спрайтом и применяет указанную трансформацию.
    Прозрачность для видеочипа:
        Видеочип Neo-Geo запрашивает данные по адресу (прямому или виртуальному).
        Маппер либо передает данные из C-ROM, либо генерирует трансформированные данные в реальном времени.

3. Реализация на ПЛИС
Для реализации маппера подойдет современная ПЛИС (например, Xilinx Spartan-7 или Intel Cyclone V), хотя для аутентичности можно ориентироваться на ПЛИС, близкие по ресурсам к эпохе Neo-Geo (с ограничением на логику и память).
Шаги разработки

    Выбор языка описания:
        Используем Verilog или VHDL. Verilog более компактный, поэтому я предложу примеры на нем.
        SystemVerilog может быть полезен для сложных структур данных.
    Интерфейс с Neo-Geo:
        Маппер подключается к шине данных и адреса C-ROM (обычно 16-битная шина данных, 24-битная шина адреса).
        Регистры управления маппера мапируются в адресное пространство 68000 (например, через порты ввода-вывода).
    Алгоритмы трансформации:
        Масштабирование: Билинейная интерполяция для изменения размеров спрайта.
        Вращение: Матрица поворота (cos/sin) с последующей интерполяцией.
        Перспектива: Проективная матрица (3x3) для эффекта наклона/искажения.
        Реализация через аппаратные умножители (DSP-блоки на ПЛИС) для скорости.
    Оптимизация:
        Кэширование исходных и трансформированных спрайтов в SRAM.
        Параллельная обработка нескольких запросов от видеочипа.
        Использование конвейеров (pipelining) для минимизации задержек.
    Синтез и тестирование:
        Используем инструменты синтеза (Xilinx Vivado, Intel Quartus).
        Тестируем на модели Neo-Geo (эмуляторы вроде MAME или аппаратные платформы).
        Проверяем тайминги и совместимость с видеочипом.

Пример Verilog-кода (упрощенный маппер)
Ниже — пример базового маппера, который перехватывает адреса и возвращает либо прямые, либо "трансформированные" данные (для простоты, просто зеркало с инверсией цветов).
verilog

module neogeo_mapper (
    input wire clk,              // Тактовая частота Neo-Geo
    input wire [23:0] addr,      // Адрес от видеочипа
    input wire [15:0] data_in,   // Данные из C-ROM
    output reg [15:0] data_out,  // Данные для видеочипа
    input wire [15:0] ctrl_reg   // Регистр управления от 68000
);

    // Определяем, прямой или виртуальный адрес
    wire is_virtual = addr[23]; // Если старший бит = 1, адрес виртуальный

    // Логика трансформации (упрощенно: инверсия цвета для виртуальных адресов)
    always @(posedge clk) begin
        if (is_virtual) begin
            // Пример: инвертируем данные (простая "трансформация")
            data_out <= ~data_in;
        end else begin
            // Прямой доступ к C-ROM
            data_out <= data_in;
        end
    end

endmodule

Это сильно упрощенный пример. Для реальных трансформаций нужно добавить:

    Буфер для хранения спрайтов.
    Математический блок для матричных операций.
    Интерполяцию для сглаживания.

4. Поддержка Wolfenstein 3D и Doom
Для портирования этих игр маппер должен решать следующие задачи:

    Текстуры стен:
        Wolfenstein и Doom используют raycasting, где стены — это вертикальные полосы текстур с масштабированием по высоте.
        Маппер может генерировать "виртуальные" тайлы, где каждая полоса стены масштабируется по заданному коэффициенту.
    Спрайты объектов/врагов:
        Спрайты (например, враги в Doom) требуют масштабирования, вращения и перспективного искажения.
        Маппер должен поддерживать динамическое изменение спрайтов в зависимости от расстояния и угла.
    Оптимизация производительности:
        Neo-Geo обрабатывает до 380 спрайтов на кадр. Маппер должен генерировать трансформированные данные с минимальной задержкой.
        Возможно, потребуется предварительно рассчитывать некоторые трансформации и кэшировать их.
    Интеграция с игровой логикой:
        Процессор 68000 должен отправлять мапперу команды для каждого кадра (например, "отобразить спрайт #N с масштабом X и углом Y").
        Это требует модификации исходного кода игр для работы с маппером.

5. Практические рекомендации

    Целевая ПЛИС:
        Для прототипа подойдет Xilinx Artix-7 или Intel Cyclone V (достаточно LUT, DSP и SRAM).
        Для аутентичности можно рассмотреть старые ПЛИС (например, Xilinx Spartan-3), но они менее производительны.
    Объем памяти:
        C-ROM обычно до 16 МБ. Маппер должен поддерживать хотя бы 4-8 МБ реальной памяти + виртуальное пространство.
        SRAM на ПЛИС (например, 512 КБ) для кэширования.
    Инструменты:
        Vivado/Quartus для синтеза.
        ModelSim для симуляции.
        MAME или реальный картридж Neo-Geo для тестирования.
    Техническое задание:
        Уточните, какие трансформации приоритетны (например, только масштабирование и перспектива).
        Какой объем C-ROM предполагается?
        Есть ли ограничения по частоте или энергопотреблению?

6. Следующие шаги
Если вы хотите двигаться дальше, я могу:

    Разработать более детальный Verilog/VHDL-код для конкретной трансформации (например, масштабирование или вращение).
    Описать интерфейс между 68000 и маппером.
    Предложить алгоритмы для перспективного искажения или raycasting-оптимизации.
    Помочь с интеграцией в эмулятор Neo-Geo для тестирования.

Пожалуйста, уточните:

    Какие трансформации наиболее важны?
    Какой объем адресного пространства для "призмы" нужен?
    Есть ли предпочтения по ПЛИС или инструментам?

Это позволит мне предложить более конкретное решение!

Мой ответ:

Только ли через подставную RAM для спрайтов возможно призмирование? Без неё точно нельзя?

Его ответ:

Хороший вопрос! Давайте разберем, можно ли реализовать "призмирование" (виртуальное адресное пространство с трансформированными спрайтами) для маппера Neo-Geo без использования подставной RAM (SRAM) на ПЛИС, и какие есть альтернативы.
1. Роль подставной RAM в призмировании
Подставная RAM (буферная память, sprite cache) в предложенной архитектуре выполняет несколько функций:

    Кэширование исходных спрайтов: Хранит данные из C-ROM для быстрого доступа, чтобы не читать их из ПЗУ для каждой трансформации.
    Хранение промежуточных данных: Позволяет выполнять трансформации (масштабирование, вращение и т.д.) в несколько этапов, не нагружая шину C-ROM.
    Сглаживание таймингов: Обеспечивает стабильную передачу данных видеочипу Neo-Geo, который требует строгого соблюдения таймингов.

Без RAM маппер должен будет:

    Читать данные напрямую из C-ROM для каждого запроса видеочипа.
    Выполнять трансформации "на лету" в реальном времени.
    Успевать генерировать трансформированные данные в пределах жестких таймингов Neo-Geo (видеочип работает на частоте ~6 МГц для выборки спрайтов).

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

    Прямое чтение из C-ROM:
        Маппер перехватывает адрес, запрашиваемый видеочипом.
        Если адрес "прямой" (реальный спрайт), маппер просто передает данные из C-ROM.
        Если адрес "виртуальный" (трансформированный спрайт), маппер:
            Вычисляет, какой исходный спрайт из C-ROM соответствует запросу.
            Читает данные из C-ROM.
            Применяет трансформацию (например, масштабирование или вращение) в реальном времени.
            Передает результат видеочипу.
    Требования к производительности:
        Скорость: Видеочип Neo-Geo запрашивает данные спрайтов в реальном времени (каждый кадр, 60 Гц, с таймингами ~6 МГц). Маппер должен успевать читать C-ROM, выполнять трансформацию и выдавать данные за один цикл запроса (менее 166 нс на 6 МГц).
        Сложность трансформаций: Простые трансформации (например, зеркалирование или сдвиг) возможны "на лету", но сложные (вращение, перспектива, искривление) требуют матричных вычислений и интерполяции, что занимает больше времени.
    Реализация:
        Используем только логику ПЛИС (LUT, DSP-блоки) для вычислений.
        Для каждой трансформации маппер хранит параметры (например, угол вращения, масштаб) в регистрах, заданных процессором 68000.
        Алгоритмы трансформации оптимизируются для минимального числа операций (например, таблица синусов/косинусов для вращения, фиксированная точка вместо плавающей).

Ограничения без RAM

    Задержки доступа к C-ROM: ПЗУ картриджа (C-ROM) имеет фиксированную скорость доступа (обычно 100-200 нс), что может не уложиться в тайминги видеочипа, если маппер часто читает данные для трансформаций.
    Сложность трансформаций: Сложные операции (например, билинейная интерполяция для масштабирования или перспективные матрицы) требуют нескольких тактов, что невозможно без буферизации.
    Пропускная способность шины: Если видеочип запрашивает много виртуальных спрайтов, маппер может не успеть читать C-ROM и обрабатывать данные одновременно.
    Ограниченная гибкость: Без RAM маппер может поддерживать только простые трансформации (например, масштабирование по фиксированным коэффициентам или зеркалирование), а эффекты вроде искривления или перспективы становятся практически нереализуемыми.

3. Альтернативы подставной RAM
Если использование SRAM на ПЛИС нежелательно (например, из-за ограничений по размеру ПЛИС или энергопотреблению), можно рассмотреть компромиссные подходы:

    Использование внешней памяти:
        Подключить небольшую внешнюю SRAM (например, 512 КБ) к мапперу через отдельные пины.
        Это дешевле, чем встроенная SRAM на ПЛИС, но увеличивает сложность платы картриджа и требует управления шиной.
        Плюс: Высокая емкость для кэширования.
        Минус: Дополнительные задержки на доступ к внешней памяти.
    Предварительная обработка спрайтов:
        Процессор 68000 (или отдельный блок в маппере) заранее рассчитывает трансформированные спрайты и записывает их в выделенную область C-ROM (если есть свободное место).
        Маппер просто перенаправляет запросы видеочипа на эти "предобработанные" спрайты.
        Плюс: Не требует RAM в маппере.
        Минус: Ограничивает динамичность трансформаций (нужно заранее знать все варианты) и требует больше места в C-ROM.
    Ограничение трансформаций:
        Упростить задачу, поддерживая только базовые трансформации (например, масштабирование по фиксированным коэффициентам или зеркалирование).
        Это позволяет уложиться в тайминги без буферизации.
        Плюс: Простота реализации.
        Минус: Не подходит для сложных эффектов Doom (перспектива, вращение).
    Кэширование в регистрах ПЛИС:
        Использовать небольшие регистровые файлы или блок RAM (Block RAM, BRAM) внутри ПЛИС вместо полноценной SRAM.
        BRAM обычно есть даже в недорогих ПЛИС (например, 36-180 Кбит в Spartan-7).
        Плюс: Не требует внешней памяти.
        Минус: Очень ограниченный объем (хватит только на несколько тайлов).

4. Реалистичность для Wolfenstein 3D и Doom
Для портирования Wolfenstein 3D и Doom маппер должен поддерживать как минимум:

    Масштабирование: Для стен и спрайтов (вертикальное и горизонтальное).
    Перспективное искажение: Для эффекта псевдо-3D (например, наклон стен в зависимости от расстояния).
    Вращение: Для спрайтов врагов (хотя в Wolfenstein это менее критично).

Без RAM:

    Масштабирование по фиксированным коэффициентам (например, 1x, 2x, 0.5x) возможно "на лету" с использованием LUT или простых сдвигов.
    Перспектива и вращение требуют матричных операций, которые трудно уложить в один такт без буферизации.
    Реализация полноценного raycasting-движка (как в Doom) без RAM крайне сложна, так как нужно одновременно обрабатывать множество спрайтов с разными трансформациями.

С RAM:

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

Вывод: Без подставной RAM можно реализовать призмирование только для простых трансформаций (масштабирование, зеркалирование). Для полноценной поддержки Wolfenstein 3D и Doom (особенно перспективы и вращения) минимальная буферная память (хотя бы BRAM на ПЛИС) почти необходима, чтобы уложиться в тайминги и обеспечить сложные трансформации.
5. Минимальный пример без RAM
Вот пример упрощенного Verilog-кода для маппера, который реализует призмирование без RAM, поддерживая только масштабирование (например, растяжение спрайта в 2x по горизонтали):
verilog

module neogeo_mapper (
    input wire clk,              // Тактовая частота Neo-Geo (~6 МГц)
    input wire [23:0] addr,      // Адрес от видеочипа
    input wire [15:0] data_in,   // Данные из C-ROM
    output reg [15:0] data_out,  // Данные для видеочипа
    input wire [7:0] ctrl_reg    // Регистр управления (например, масштаб)
);

    wire is_virtual = addr[23];   // Виртуальный адрес, если старший бит = 1
    reg [15:0] transformed_data;

    always @(posedge clk) begin
        if (is_virtual) begin
            // Простое масштабирование: дублируем пиксель (растяжение в 2x)
            if (ctrl_reg[0]) begin
                transformed_data = data_in; // Повторяем данные (имитация растяжения)
            end else begin
                transformed_data = data_in; // Без изменений
            end
            data_out <= transformed_data;
        end else begin
            // Прямой доступ к C-ROM
            data_out <= data_in;
        end
    end

endmodule

Этот код:

    Проверяет, является ли адрес виртуальным.
    Если да, применяет простую "трансформацию" (в данном случае просто дублирует данные для имитации растяжения).
    Работает без RAM, но ограничен тривиальными операциями.

Для перспективы или вращения потребуется гораздо больше логики (DSP-блоки для умножений, таблицы синусов), и без буфера тайминги станут проблемой.
6. Рекомендации и уточнения

    Минимальная память:
        Если возможно, используйте хотя бы BRAM (36-180 Кбит) на ПЛИС. Это встроенная память, не требующая внешних чипов, и она сильно упростит задачу.
        Например, 36 Кбит хватит для кэширования 1-2 спрайтов 16x16 пикселей (4 бита на пиксель).
    Упрощение трансформаций:
        Если RAM недоступна, можно ограничиться масштабированием и зеркалированием, а перспективу реализовать программно (на 68000), жертвуя производительностью.
        Для Doom это может быть недостаточно, так как игра требует быстрой обработки спрайтов.
    Тестирование:
        Протестируйте маппер в эмуляторе (MAME) или на реальном Neo-Geo с минимальной трансформацией.
        Проверьте, укладывается ли логика в тайминги видеочипа.

Уточните:

    Какой объем памяти (BRAM или внешняя SRAM) допустим?
    Какие трансформации приоритетны (например, только масштабирование или обязательно перспектива)?
    Есть ли ограничения по ПЛИС (например, Xilinx Spartan-7 или что-то проще)?

Если вы хотите двигаться дальше без RAM, я могу разработать более детальный код для конкретной трансформации (например, масштабирование или наклон) и оптимизировать его для работы "на лету".

Мой ответ:

А подключаемый уже к Neo-Geo CD(Z) модуль с аналогичным функционалом, но уже использующий даруемую архитектурной спецификой данной консоли возможность обрабатывать графику программно, будет устройством с той же внутренней архитектурой, что и маппер для картриджных версий Neo-Geo, или уже другой? Как бы так его задействовать, чтобы сам M68000 поменьше напрягался над пересылкой графических данных туда-сюда и их обработкой? И куда его вообще подсоединять - если окажется, что ничего похожего на порт расширения у Neo-Geo CD(Z) нет, то насколько "узким местом" для поступающих с данного модуля данных будет порт для джойстика?

Его ответ:

Это отличный и глубокий вопрос, который требует анализа архитектуры Neo-Geo CD(Z), её отличий от картриджной Neo-Geo (AES/MVS), и возможностей подключения внешнего модуля для обработки графики. Давайте разберем задачу по частям, чтобы понять, как реализовать модуль с функционалом маппера для Neo-Geo CD(Z), как минимизировать нагрузку на процессор Motorola 68000, и какие интерфейсы можно использовать для подключения, включая оценку порта джойстика как потенциального "узкого места".
1. Отличия Neo-Geo CD(Z) от картриджной Neo-Geo
Neo-Geo CD(Z) — это версия консоли, использующая CD-ROM вместо картриджей, что вносит изменения в архитектуру и возможности работы с графикой. Ключевые особенности:

    Графическая подсистема:
        Как и в AES/MVS, Neo-Geo CD использует тот же видеочип (Yamaha YM2610 + кастомные чипы), который работает со спрайтами и фоновыми слоями.
        Спрайты хранятся в памяти C-ROM (на картриджах) или загружаются с CD в оперативную память (Work RAM) на CD-версии.
        CD-версия позволяет программно загружать графические данные с диска в Work RAM (68 КБ для 68000 + 2 МБ для графики), что дает больше гибкости, но увеличивает задержки из-за низкой скорости привода CD (1x или 2x).
    Процессор:
        Motorola 68000 (12 МГц) + Z80 (4 МГц) для звука, как в AES/MVS.
        Программная обработка графики возможна, но ограничена производительностью 68000 и скоростью доступа к данным с CD.
    Память:
        Work RAM (68 КБ для кода/данных, 2 МБ для графики) используется для временного хранения спрайтов и тайлов, загружаемых с CD.
        Доступ к данным с CD медленный (150-300 КБ/с для 1x/2x привода), что требует буферизации.
    Архитектурная специфика:
        В отличие от картриджей, где C-ROM (спрайты) и P-ROM (код) доступны напрямую, Neo-Geo CD загружает данные с диска в RAM, что позволяет динамически обновлять графику.
        Это открывает возможность программной обработки графики (например, трансформации спрайтов) перед их передачей в видеопамять (VRAM).
    Порты и интерфейсы:
        Neo-Geo CD(Z) не имеет явного порта расширения (в отличие от, например, Sega CD).
        Доступны порты джойстиков (DB-15), порт для наушников, AV-выход и внутренние интерфейсы (например, шина CD-привода).

Вывод: Neo-Geo CD(Z) предоставляет больше возможностей для программной обработки графики благодаря загрузке данных в RAM, но медленный CD-привод и ограниченная производительность 68000 делают аппаратное ускорение (например, через внешний модуль) крайне желательным для задач вроде портирования Wolfenstein 3D и Doom.
2. Архитектура модуля для Neo-Geo CD(Z)
Модуль для Neo-Geo CD(Z), выполняющий функции маппера (трансформации спрайтов: масштабирование, вращение, перспектива и т.д.), будет отличаться от маппера для картриджной Neo-Geo, но сохранит некоторые общие черты. Рассмотрим, как он может быть устроен и чем отличается.
Сходства с маппером для картриджей

    Цель:
        Оба устройства добавляют аппаратные трансформации спрайтов (стретчинг, вращение, наклон, перспективу), которых нет в стандартном видеочипе Neo-Geo.
        Оба должны быть прозрачными для видеочипа, предоставляя данные в формате, совместимом с VRAM (спрайты 16x16 или цепочки до 16x512).
    Компоненты:
        Блок трансформации: Аппаратная логика (на ПЛИС) для выполнения матричных операций (масштабирование, вращение, перспектива).
        Контроллер синхронизации: Обеспечение таймингов для передачи данных видеочипу.
        Интерфейс управления: Прием команд от 68000 (например, параметры трансформации).
    Принцип "призмы":
        Как и в картриджном маппере, модуль может создавать "виртуальное" адресное пространство, где часть данных — исходные спрайты, а часть — трансформированные версии.
        В случае CD-версии это может быть реализовано через манипуляцию данными в Work RAM или VRAM.

Отличия от картриджного маппера

    Источник данных:
        В картриджной версии маппер работает с C-ROM (постоянная память спрайтов).
        В CD-версии данные загружаются с диска в Work RAM, что позволяет программно модифицировать графику перед передачей в VRAM.
        Модуль для CD должен либо перехватывать данные из Work RAM, либо напрямую взаимодействовать с VRAM.
    Роль RAM:
        В картриджном маппере подставная RAM (SRAM/BRAM) нужна для кэширования спрайтов из C-ROM и хранения промежуточных результатов трансформаций.
        В CD-версии Work RAM (2 МБ) уже выполняет роль буфера для графики, поэтому модуль может использовать её вместо собственной SRAM, но потребуется доступ к этой памяти.
    Интерфейс подключения:
        Картриджный маппер интегрируется в шину C-ROM внутри картриджа.
        Для CD-версии модуль — внешнее устройство, которое нужно подключить через доступный интерфейс (например, порт джойстика или внутреннюю шину).
    Программная обработка:
        CD-версия позволяет 68000 предварительно обрабатывать графику в Work RAM, что снижает нагрузку на модуль, но увеличивает нагрузку на процессор.
        Модуль может взять на себя всю обработку трансформаций, чтобы разгрузить 68000.

Предлагаемая архитектура модуля

    Интерфейс данных:
        Подключается к шине Work RAM или VRAM для чтения исходных спрайтов и записи трансформированных.
        Альтернативно, принимает данные от 68000 через регистры или DMA.
    Блок трансформации (на ПЛИС):
        Реализует масштабирование, вращение, перспективу и т.д. с помощью DSP-блоков и LUT.
        Работает с данными из Work RAM или входного буфера.
    Буферная память (опционально):
        Небольшая BRAM на ПЛИС (например, 36-180 Кбит) для кэширования спрайтов или промежуточных результатов.
        Можно обойтись без неё, если использовать Work RAM, но это потребует быстрого доступа к памяти.
    Контроллер команд:
        Принимает параметры трансформации (масштаб, угол, матрица) от 68000 через регистры.
        Может поддерживать DMA для передачи больших объемов данных.
    Выходной интерфейс:
        Передает трансформированные спрайты в VRAM или Work RAM для использования видеочипом.

Ключевые отличия:

    Модуль для CD больше ориентирован на работу с Work RAM, а не с фиксированным C-ROM.
    Он может быть менее зависим от собственной памяти, так как Neo-Geo CD уже использует RAM для буферизации.
    Требуется внешний интерфейс подключения, что усложняет интеграцию.

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

    Прямой доступ модуля к Work RAM:
        Модуль подключается к шине Work RAM (2 МБ), чтобы читать исходные спрайты и записывать трансформированные.
        Это требует интеграции с внутренней шиной Neo-Geo CD, что возможно только через модификацию консоли (например, подключение к адресной/данной шине через разъем CD-привода или материнскую плату).
        Плюс: 68000 не участвует в пересылке данных.
        Минус: Требует сложной аппаратной модификации.
    Использование DMA:
        Neo-Geo CD поддерживает ограниченный DMA для передачи данных между CD и Work RAM.
        Модуль может эмулировать DMA-канал, принимая данные от 68000 или напрямую из Work RAM и возвращая трансформированные спрайты.
        68000 только задает параметры (например, адрес спрайта, масштаб) через регистры, а модуль выполняет всю обработку.
        Плюс: Минимальная нагрузка на процессор.
        Минус: DMA в Neo-Geo CD медленный и может конфликтовать с доступом к CD.
    Кэширование в модуле:
        Модуль хранит часто используемые спрайты в собственной BRAM, чтобы не запрашивать их из Work RAM для каждой трансформации.
        68000 отправляет только команды (например, "трансформировать спрайт #N с углом X"), а модуль работает автономно.
        Плюс: Снижает трафик данных.
        Минус: Требует памяти на ПЛИС.
    Предварительная загрузка:
        68000 загружает набор спрайтов в буфер модуля один раз (например, в начале уровня), а модуль далее обрабатывает их самостоятельно.
        Это подходит для Wolfenstein 3D и Doom, где набор врагов/объектов ограничен.
        Плюс: Снижает нагрузку на процессор во время игры.
        Минус: Ограничивает динамическое обновление графики.
    Оптимизация команд:
        Модуль поддерживает "макрокоманды" (например, "отобразить спрайт #N с масштабом X и углом Y"), чтобы 68000 не отправлял детальные инструкции для каждого пикселя.
        Это минимизирует объем данных, передаваемых процессором.

Рекомендация: Оптимальный вариант — комбинация DMA и кэширования. Модуль должен иметь доступ к Work RAM через шину или DMA, чтобы читать спрайты, и небольшой буфер (BRAM) для хранения промежуточных данных. 68000 задает только параметры трансформаций через регистры, а модуль выполняет всю обработку.
4. Подключение модуля к Neo-Geo CD(Z)
Neo-Geo CD(Z) не имеет явного порта расширения, что усложняет подключение модуля. Рассмотрим возможные интерфейсы и их ограничения.
Варианты подключения

    Порт джойстика (DB-15):
        Описание: Neo-Geo CD имеет два порта джойстика (15-контактные разъемы), которые передают сигналы управления (кнопки, направления) и имеют линии питания (+5V).
        Возможности:
            Можно использовать порт для передачи данных, эмулируя протокол джойстика (например, отправлять команды и данные в формате последовательных пакетов).
            Порт поддерживает простую двунаправленную связь, но с низкой пропускной способностью.
        Пропускная способность:
            Джойстик использует параллельный интерфейс (8 бит для кнопок/направлений), опрашиваемый 68000 с частотой ~60 Гц.
            Реальная скорость передачи данных ограничена скоростью опроса процессором (примерно 1-2 КБ/с в лучшем случае).
            Для передачи графических данных (например, спрайт 16x16, 4 бита/пиксель = 512 байт) потребуется ~0.25-0.5 секунды, что слишком медленно для реального времени.
        Ограничения:
            Порт джойстика — узкое место для передачи больших объемов данных (спрайты, трансформированные тайлы).
            Подходит только для отправки команд (например, параметры трансформации: масштаб, угол), но не для самих графических данных.
            Может потребовать модификации прошивки Neo-Geo CD для расширенного протокола связи.
        Вывод: Порт джойстика не подходит для передачи графических данных из-за низкой пропускной способности. Он может использоваться только для управления модулем (команды, параметры), но сами спрайты должны передаваться через другой интерфейс.
    Внутренняя шина (модификация консоли):
        Описание: Подключение модуля к внутренней шине Neo-Geo CD (например, адресная/данная шина Work RAM или VRAM).
        Возможности:
            Модуль подключается напрямую к шине памяти (16 бит данные, 24 бит адрес), что позволяет читать/записывать спрайты в Work RAM или VRAM.
            Пропускная способность шины (~12 МГц) достаточна для передачи больших объемов данных (до 24 МБ/с теоретически, реально ~10-15 МБ/с).
        Реализация:
            Требуется вскрытие консоли и пайка к материнской плате (например, к чипам RAM или контроллеру CD).
            Модуль эмулирует устройство на шине, взаимодействуя с 68000 и видеочипом.
        Плюс: Высокая пропускная способность, прямой доступ к графике.
        Минус: Сложная модификация, потенциально нарушает гарантию и совместимость.
        Вывод: Это лучший вариант для производительности, но требует глубокого вмешательства в аппаратное обеспечение.
    Шина CD-привода:
        Описание: Перехват данных, поступающих с CD в Work RAM.
        Возможности:
            Модуль подключается между CD-приводом и материнской платой, перехватывая или модифицируя графические данные.
            Может использовать DMA-канал для передачи трансформированных спрайтов.
        Ограничения:
            Скорость CD-привода (150-300 КБ/с) ограничивает частоту обновления данных.
            Требует сложной интеграции с контроллером CD.
        Вывод: Менее практично, чем доступ к шине RAM, из-за низкой скорости.
 

5

Найденное / [ Astral ] Японский футуристический beat'em-up! на тему "министерства. [Switch]

« : 15 Апрель 2025, 08:37:39 »

...потусторонних дел".

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

6

5 поколение / Особенности SCSP.

« : 25 Март 2025, 07:50:26 »

Я правильно понимаю, что частота дискретизации у него фиксированная, и даунсэмплить CD-трэки из FM Towns-версии Mad Stalker или из Gate of Thunder, чтобы те вместились в SCSP-ромы для Sega Model 3, бессмысленно?

7

Ромхакинг и программирование / Пишем ромхакерский/хоумбрюерский софт.

« : 23 Февраль 2025, 11:17:44 »

Собираюсь я тута написать небольшую совсем-совсем простенькую утилитку для конвертации BMPшек глубиной цвета в 4 бита в набор 4-битных linear тайлов размером 16 на 16 - формат, использовавшийся в некоторых игровых автоматах (например, Strikes of 1945 и парочке корейских железячек с сильными подозрениями на его клонизм). Однако почему-то даже проверка по сигнатуре не работает как надо - вместо стоящих первыми 2-мя байтами букв B и M утилитка в любой скормленной BMPшечке видит нули. Как так получается?

Код: [Выделить]

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>


FILE         *fpin, *fpout;
long            len;
long            i,n;

int main(int argc, char *argv[])
{

if (argc != 2 ) {
printf("Bitmap converter to 4bpp 16x16 tile data.\n");
fprintf(stdout,"Usage: %s [srcfile].bmp\n",argv[0]);
exit(1);
}


if ( (fpin=fopen(argv[1],"rb") ) == NULL ) {

printf("Can't open input file\n");
exit(1);
}


/*
 * Now we try to determine the size of the file
 * to be converted
 */
if (fseek(fpin,0,SEEK_END)) {
printf("Couldn't determine size of file\n");
fclose(fpin);
exit(1);
}

len=ftell(fpin);

unsigned short   bytStr[len];

fread(bytStr, 1, len, fpin);
   
  printf("The first byte is %x.\n",bytStr[0]);
fclose(fpin);
exit(1);
}

8

Ромхакинг и программирование / Ассемблер для PS2.

« : 20 Октябрь 2024, 11:58:20 »

Решил туточки написать модуль Emotion Engine для очень любимого мной ассемблера ASMX за авторством Брюса Томлина - инструмента очень, я бы так сказал, уютного: сверхпортативного, с простым синтаксисом, не склонного, в отличие от gas'а, перевирать набранный в исходнике код при сборке, и транслирующий его сразу в бинарник без посредства объектных файлов.

Работа ведётся на основе модифицированного asmarm.c, поскольку ARM пока что в списке архитектур ASMX - единственный RISC, и вот от него-то и приходится плясать, делая поправки на все архитектурные различия с MIPS (причём, что самое смешное, у последнего структура опкода даже проще, чем у ARM). Выложенный ниже вариант - он пока ещё сильно-сильно промежуточный, где и "хвосты" от ARM далеко не все подтёрты, и ряд команд ещё только предстоит добавить. Работа ведётся в режиме реального времени, и если где-то чего-то упущу - сигнальте. Опирался я главным образом на официальные доки самой Sony (см. последние 2 прикрепления).

9

Эмуляторы консолей 5 поколения / ePSXe: Почему некогда самый популярный эмулятор PS1 ныне "пикникует на обочине"?

« : 18 Апрель 2024, 08:03:25 »

Недавно после недолгих раздумий и без особых сожалений снёс этот эмулятор со своего компа, когда понял, что первый, по сути, окончательно перестал быть нужен - если захочется поиграть во что-нибудь для PS1, всегда запускаю MAME, а что не потянет MAME, вытянет Mednafen. Собственно, у ePSXe и так последние несколько лет постепенно становилось объективно всё меньше и меньше преимуществ перед другими.
И вот в ходе размышлений назрел вопрос - а на каком, собственно, моменте разработчики проглядели появление себе "конкурентов", и почему не смогли приспособиться к переменам на эму-сцене?

10

Ромхакинг и программирование / Тайловые редакторы.

« : 28 Октябрь 2023, 11:30:08 »

Есть ли среди них настолько гибкие в настройках, чтобы их можно было штатными средствами, без каких либо плагинов и прочих сторонних расширений, "познакомить" с каким-нибудь совершенно неведомым им способом хранения графики - например, форматом CPS1 или железа аркадной версии Vapour Trail?

11

Ромхакинг и программирование / Нейросети в помощь ромхакерам - возможно ли такое?

« : 31 Март 2023, 16:41:29 »

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

12

Эмуляторы компьютеров / Что делать, если процесс установки Windows и XP в Bochs застревает на одной...

« : 11 Декабрь 2022, 14:54:02 »

...точке? В XP это - установка поддержки сети, когда установщик заверяет пользователя, что до готовности остаётся 32 мин., а в 2000-м - первый же экран запуска системы.

13

Железо / Альтернативы MiSTerFPGA.

« : 31 Октябрь 2022, 06:11:21 »

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

14

Эмуляторы аркадных автоматов / Play! и Namco System 246.

« : 20 Октябрь 2022, 14:37:51 »

Сегодня наткнулся на канале Mr. Guru на нечто невероятное - демонстрацию ещё пока не геймлея, но уже хотя бы демороликов из игр с Namco'вских игровых автоматов на основе PS2.

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

15

7 поколение и выше / [PS3]Эмуляция PS2.

« : 19 Июнь 2022, 14:36:15 »

Для Custom Config'ов к играм с PS2 есть какая-то отдельная директория, куда их кидать, или их туда же, куда и сами образы? Или что вообще с ними делать?

Если что, на PS3 у меня стоит прошивка ReBug.

16

Картриджи / диски / Возможна ли 3D-печать оптических дисков?

« : 03 Март 2022, 09:55:13 »

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

17

6 поколение / [Dreamcast] В поисках альтернативы всяким Onion'ам и оптимизированным под...

« : 20 Декабрь 2021, 16:53:03 »

...размеры CD образам.

Если совсем вкратце, грызет меня вопрос - откуда брать игры дримковладельцу, если ни железку свою курочить с целью замены дисковода на SD-ридер, ни шерстить eBay в поисках оригинальных GD-дисков, ни использовать вместо них обычные CD-болванки с записанными на них .CDI-образами и прочими обрезками не хочется?

18

Игры на консолях 1-4 поколений / [NES] Dragon Slayer Jr.: Romancia

« : 04 Май 2021, 14:38:54 »

Можно ли там как-то снять эффект превращения в свинью? Как выкручивались те игроки, которые попросту не знали, что для прохода в логово Тёмного Властелина надо предварительно израсходовать все кольца, и на том погорали?

19

Эмуляторы компьютеров / [PC-98] Установка ОС.

« : 25 Июнь 2020, 04:42:52 »

Требуется подробная инструкция по установке на данный тип компьютеров различных операционных систем (главным образом, DOS либо Windows). Судя по просмотру файлов, содержащихся в образе игры El-Hazard, которую я давно хочу опробовать, она требует для себя именно Windows.

20

Ромхакинг и программирование / Сборка образа CD-ROM+CD Audio

« : 12 Май 2020, 09:03:36 »

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

21

Эмуляторы компьютеров / [PC-88, PC-98, Sharp X1, MSX2] Elthlead

« : 27 Январь 2020, 06:04:32 »

Если кто знает японский, прошу тех разъяснить смысл пунктов меню, открывающегося после каждого хода (см. скриншот).

22

Ромхакинг и программирование / С чего лучше всего начать изучение ассемблеров M68000 и Z80?

« : 15 Февраль 2019, 09:14:16 »

Источники инфы прошу кидать по возможности русскоязычные.
Конкретная цель изучения - реверс-энжинеринг различных игр для Neo-Geo вместе с риппиногом ресурсов оттуда, и тем самым определённая помощь в создании на этот раз уже своих игр для NG; а также, возможно, в будущем, создание инструментария разработки ПО для различных аркадных систем, использующих эти процессоры (так, например, после завершения создания RPG по Shaman King'у на Neo-Geo следующий свой проект я планирую создать для Namco System 2); ну и, может быть, ещё в ромхакинге применение тоже найдётся. Да и TN, по ходу, уже заждался, пока Riot City с Sega System 16 наконец портируют на SMD - а поскольку я сторонник максимально точного портирования, для этого наверняка придётся лезть в отдизассембленный код аркадного оригинала и адаптировать его под архитектурные особенности SMD вручную.

23

Hard'n'Soft / Alcohol 120% отказывается создавать виртуальный привод.

« : 16 Ноябрь 2018, 11:55:08 »

Переустановки программы не помогают (осложняет дело ещё и то, что ни один из имеющихся у меня деинсталляторов его в списке установленных программ не видит). Ни на флажок "установить виртуальный привод" в конце очередной установки программы, ни на изменение числа виртуальных приводов в настройках прога никак не реагирует. Притом физические диски, как ни странно, видит.

24

Игры на персональном компьютере / Существуют ли сервисы облачного гейминга с возможностью отдать на выполнение...

« : 21 Октябрь 2018, 08:19:41 »

...свой софт, без тяжёлой необходимости выбирать из узенького списка уже заранее имеющихся на сервере игр? По крайней мере, доступные рядовому интернет-юзеру.

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

25

Печатные и электронные издания / Разыскивается номер одного из компьютерных журналов конца 90-х.

« : 01 Октябрь 2018, 04:44:51 »

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

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

26

Игры на различных компьютерах / [MSX2] Сохранениние в первой части Metal Gear.

« : 11 Июнь 2018, 06:09:49 »

Насколько долго должен идти процесс верификации после ввода имени файла?

27

Разработка игр / RPG для Neo-Geo по мотивам Shaman King

« : 27 Апрель 2018, 15:43:45 »

Среда разработки - SDK от Sebastian Mihai, с применением графической библиотеки DATlib v0.3.

Необычна данная RPG будет прежде всего тем, что в нём не будут использоваться вид сверху и изрядно недолюбливаемые мной chibi-пропорции спрайтов персонажей и прочей графики, игровое пространство будет наиболее близко к характерному для beat-em`up!'ов, плюс встречи с врагом будут не рандомными (как это обычно бывает с 8- и 16-битными RPG), а вызываемыми столкновением со спрайтом противника во время внебоевой прогулки по локации (похожим образом, с поправкой на трёхмерность, это реализовано в играх серии Xenosaga).

На данном этапе программа представляет собой пока что лишь модифицированный (в частности, код отображения спрайтов и фона, ранее разбросанный по разным функциям, теперь объединён в одну - она же теперь является главной в новой программе, плюс скроллинг фона управляется теперь не простым движением джойстика, а движением персонажа к краю экрана, плюс возможность персонажа перемещаться я ограничил соответствующим "полу" куском экрана, как в beat'em-up!'ах) пример работы библиотеки (собственно, этим и объясняется то, что графика в программе с Shaman King'ом вроде никак не связана), но, думаю, код её будет использован в качестве базы для внебоевой части геймплея.

Скачать программу можно здесь, (а для обеспечения возможности протестировать её на MAME кидайте XML-файл по ссылке, где уже заранее прописаны характеристики каждого ром-файла, в папку hash, затем создайте в директории MAME для ромов папку DATdemo и кидайте туда char.bin и fix.bin из папки out внутри директории непосредственно с исходниками плюс dev_p1.rom из этой же директории, а остальные нужные файлы берите из архива DATdemo.zip из папки DATdemo_rom) посмотреть видео геймплея - здесь. Скриншоты прикреплены ниже.

Надо подметить, кстати, что RPGшку свою я планирую делать по мотивам именно анимэ-сериала (по которому ещё с 2008 г. загорелся мечтой сделать RPG именно для Neo-Geo, о самом существовании которой узнал незадолго до этого) - хотя, может быть, и от оригинальной манги кое-какие элементы достанутся.
Для начала, раз уж упомянул причину отсутствия оригинальной графики, мне бы хотелось как-нибудь достать спрайт Haohmaru из первой части Samurai Shodown, чтобы с его поз и движений срисовать спрайт Йо, а также спрайт одного из противников в игре Burning Fight по имени Robert Baun (это который гангстер с револьвером) - на него в моей игре должен будет стать похож Рио (да и другие спрайты противников из Burning Fight могут понадобиться - для рядовых членов банды Рио, с которой героям поначалу придётся враждовать).

28

Игры на различных компьютерах / [MSX2] Управление в обоих частях Metal Gear

« : 06 Февраль 2018, 09:07:58 »

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

29

Разработка игр / Танковый TDS «Операция "Свинцовый туман"» [SMD]

« : 01 Январь 2018, 09:10:10 »

Идея возникла случайно, как своеобразный игрокроссовер вольного сиквела фильма "Белый тигр" Карена Шахназарова и сонгфика по перепевке знаменитой песни про трёх танкистов в исполнении группы "Свинцовый туман" (в её-то честь я игру и назвал). Герои игры - элитное танковое подразделение, каждый из членов которого по имени, внешности и характеру идентичен соответствующему участнику "Свинцового тумана" (правда, в игре все они будут сильно "омоложены" по сравнению со своими реальными прототипами - примерно того возраста, в котором каждый из них находился где-то в 90-х, в крайнем случае - в 2001-м; а также музыка и поэзия у них из профессии превратятся всего лишь в хобби).

Я, конечно, как человек, с творчеством группы хорошо знакомый, понимаю, что трудно представить двух более несовместных друг с другом вещей, чем "Свинцовый туман" и война, однако герои игры, как пацифисты по убеждениям, будут не участвовать в войне, а предотвращать её.
Дело в том, что, по сюжету, где-то примерно в наше время пророчество Ивана Найдёнова из "Белого тигра", спустя 70 с лишним лет, всё-таки сбылось, и танк-призрак всё таки вернулся, начав нападать на пограничные посты по обе стороны российских границ, будто устраивая провокацию и пытаясь стравить нас со странами, на границе с которыми произошли инциденты.
Во избежание большой войны чуть ли не со всеми своими соседями сразу (если не вообще мировой, возможно даже ядерной) команде героев (приглянувшихся армейскому начальству тем, что они не только единственные выжили на родной базе, когда та подверглась атаке танка-призрака, но и, казалось бы, чуть было не уничтожили его, вынудив своим нехилым отпором временно отступить) было приказано добить наконец таинственный танк, пока он не успел добиться своей цели.
Казалось бы, с помощью современных оружия и техники (учитывая что внешне танк со времён своего прошлого появления в нашем мире нисколько не изменился, оставшись всего лишь "Тигром" времён Второй Мировой), да ещё и с таким экипажем, как команда наших героев, сделать это особого труда не составит - да только танк оказался совсем не так прост, каким казался "в прошлый раз". Каждый раз, стоит только нашим героям на определённое расстояние приблизиться к нему, их тут же каким-то мистическим образом перебрасывает в некое странное измерение-"поле битвы", где им приходится встретиться с порождённой таинственным танком настоящей фантомной вермахтообразной армией, а сам танк-призрак в таких измерениях обретает магическую способность трансформироваться в самые ну уже совершенно невообразимые гигантские вундервафли. Они-то и послужат боссами в конце каждого уровня.

Среда разработки - BasiEgaXorz. Планируемые изменения:

• Достать полностью оригинальную качественную графику (пропорции размеров спрайтов и прочих элементов графики при этом должны быть побольше - примерно такими же, как в Shock Troopers) - это, пожалуй, один из самых важных элементов
• Добавить фон
• Разумеется, сделать врага активным и внести в игру, помимо него, ещё кучу других видов противников - а то какой же без этого геймплей
• Вставить код создания при появлении спрайта взрыва зоны вокруг него с определённым радиусом, попав в которую, ближайшие находящиеся рядом цели также получают повреждения
• Обеспечить независимость прицеливания от перемещения (т. е. дать танку возможность одновременно стрелять в одну сторону и двигаться в другую, как это было в аркадных версиях серии Ikari и игр T.N.K. III, Heavy Barrel, Time Soldiers и т. д.)
• Добавить другие виды оружия, главным образом - установленный на башне дистанционно управляемый оттуда пулемёт (прицеливание которого будет независимо не только от движения танка, но и от прицеливания башни - хотя в случае с последней независимость эта будет лишь частичной, т. е. при повороте башни вместе с ней в ту же сторону на тот же угол автоматически повернётся и пулемёт) - дефолтное вспомогательное оружие, которым можно будет крыть врага, пока в орудие после выстрела относительно долго закладывается новый снаряд
• Создать кучу охренительно огромных уровней со сложной лабиринтообразной структурой (по которым кстати, можно будет перемещаться не только вперёд, к боссу, но и назад, от него - что в аркадных играх редкость - дабы подзаработать побольше очков и бонусами затариться за счёт противников, респаунящихся на ранее пройденных игроком территориях за время его отсутствия, да и в случае слишком долгой задержки на одном и том же отрезке уровня противники тоже начинают респауниться и вновь осаждать игрока, чтоб не тормозил) и как минимум несколькими возможными путями прохождения (как в Metal Slug 3 и некоторых других более поздних частях серии)
• В дальнейшем список будет со временем всё больше дополняться и расширяться.

Скриншоты и исходники прикреплены.

30

Hard'n'Soft / Обсуждение работы и глюков старых игр и железа

« : 09 Ноябрь 2017, 17:19:42 »

GLquake в ответ на попытку запустить с параметрами

"C:\Program Files (x86)\Quake\Glquake.exe" -width 1024 -height 768 -bpp 32

выбрасывает ошибку со скриншота ниже. Что интересно, если оставить только параметр -bpp, а указаний по смене разрешения не давать, то запустится он нормально. Чем он недоволен в случае с попыткой смены разрешения, интересно знать?

P. S. Эмулятор 3DFX - nGlide, игра же запущена в режиме совместимости с Windows 95.