Последнюю консоль у меня есть возможность собрать - ещё одну целиком, но с памятью 32 МБ вместо 64 (большие РОМы от NEOGEO и Capcom будут недоступны, остальное работает). Или выслать в виде конструктора. Цену называть не буду, чтобы никого не обидеть. Основная проблема в решении организационных вопросов по набору комплектации - это походы в магазины, поиск в своих элементных базах, выпаивание части комплектации из плат ноутбуков/телефонов (этим добром завален весь балкон). На это уходит почти целый день. Всё-же идеален вариант с полу-конструктором: высылаю платы, основные комплектующие (микросхемы, кварцы, разъёмы, немного мелочи). Остальное сами.
Есть собранная полностью рабочая плата от предыдущей консоли EMU-Pocket, могу отдать, цену предлагайте сами:
А вот в СТим тыбы выпустил ? Ну не ГРАДИУС конечно. А аналогичный ШМАП,но свой. Этакий клон. Со своим названием, артом, и всем контентом. Там вроде есть какие то ретро игры)))
На Стим выпустить не проблема. На контент прийдётся раскошелиться: найти pixelart artist и олдскульного трекерщика. Но без грамотной PR-кампании прибыли это занятие не принесёт. Это же не ААА-игры
Делаю консоли и пишем игры небольшим коллективом ради своего удовольствия. И финансово в минусе, но это не важно! Нам нравится делать то, что мы делаем.
Это хобби. Чтобы это стало работой нужно: 1) работать в USA. Там это восстребовано 2) наложить табу на ввоз паршивых дешёвых китайских консолей 3) поменять образ мысли большинству обывателей
Проект делается Just For Fun. Печатные платы и часть комплектующих у меня есть. Интересующимся высылаю почтой. Документация для сборки-наладки, прошивки - купившим плату+комплектующие. По любым вопросам консолестроительства писать на ящик: repstosw2018 [собака] gmail [точка] com
Псих) В смысле... Ну псих, же) В хорошем смысле, само-собой! Одобряю сие, потому псих - комплимент.
Скорее - одержимый идеей создания собственной игровой консоли/приставки! ну и как орг-игродел немного ещё ))
Добавлено (16 Октября 2019, 16:14) ---------------------------------------------
ЦитатаDimaLink ()
Это круто,что ты самостоятельно такой проект замутил. Он как бы ремейк, как ты пишешь) ,Я не играл в Третью часть. Вот хотел спросить ты именно в основном перенес именно третью часть или все-таки свое что-то сделал? В частности что ты пишешь,что каждый урвоень уникалный. Я простон е играл в 3 часть,незнаю как там сделано. Там тоже так)) Или это вот твое решение). Ты еще написал что свои фишки типа внес. Так это твоя версия,твое видение или именно порт типа?
Конечно, смотрится очень мощно)))
Слишком сложный вопрос, боюсь, исчерпывающе не смогу ответить.
Игра, которую мы написали и SNES-овский Gradius 3 - совершенно разные игры. Да, некоторые противники, музыка, боковики - позаимствованы с SNES, некоторые изменены, а часть - новая, чего нет в SNES.
Можно сказать, что игра Gradius 3 Total Terror - создана по мотивам Gradius 3 SNES, но не является ремейком в строгом смысле этого слова. Скорее всего - пародия с улучшенной графикой. В нашей игре враги и объекты действительно уникальны в пределах уровня, в то время как в SNES версии - очень много повторов обычных противников на уровнях.
Наша игра не порт, а полностью написанное приложение со своими концепциями, движком.
От себя добавлю: обязательно скачайте SNES версию Градиуса чтобы расставить все точки над "i"
Добавлено (06 Декабря 2019, 10:47) --------------------------------------------- Финальный релиз игровой консоли BlackPrism Portable, на которой идёт Gradius III Total Terror:
Добавлено (02 Февраля 2020, 05:20) --------------------------------------------- В этом году исполняется 12 лет с момента рождения первой игровой консоли на ARM-микроконтроллере: Advanced MicroMachine. В связи с этим было принято решение отдать дань внимания своему первому детищу - портировал туда игру Gradius 3 Total Terror.
На этой консоли идут также эмуляторы GameBoy Color и NES.
Так как это первая консоль на ARM, то в силу малого опыта, конструкция содержит недочёты, в частности:
1) VS1003 и SD-карта висят на одном SPI, что создаёт некоторые неудобства, если нужны они сразу одновременно (AT91RM9200 имел один SPI)
2) Малый объём памяти - 2 МБ (используется микросхема SRAM 1Mx16, использовать SDRAM в то время побоялся)
3) Отсутствие Memory-To-Memory DMA, что делает невозможным передачу данных в дисплей или копирование памяти без участия процессора невозможным (AT91RM9200 вместо DMA имеет PDC в направлениях: "память-устройство", "устройство-память")
4) Маленькая площадь дисплея (OLED дисплей 128x128 пикселей, 262 тыс цветов, контроллер SSD1339 - в то время мобильных Java-игр считался настоящим чудом!)
5) Схемотехническая избыточность (два звуковых чипа - VS1003 и YMF721, наличие RS232 с согласователем уровней и многое другое, что упрощает отладку)
6) Отсутствие аппаратной поддержки вычислений с плавающей точкой (AT91RM9200)
7) LCD и внешняя память 2 МБ висят на одной шине (16 бит EBI)
8) Запись в порт LCD не может идти бурстами, так как адресная линия подключена к младшему биту шины.
Тем не менее, вышеуказанные недочёты не сильно мешают писать игры и использовать игровую консоль по назначению.
Игра Gradius 3 Total Terror на AT91RM9200. Полное прохождение.
Музыка в игре - результат проигрывания MIDI-файлов аппаратным таблично-волновым синтезатором от Yamaha (микросхема YMF721: поддерживает оба синтеза - частотный и табличный + разбор MIDI-секвенций: стандарт MPU401).
Парсер секвенций MIDI писал самостоятельно, ноты улетают в звуковой чип, а отсчёт дельт ведётся по прерыванию таймера AT91RM9200.
Вот он - железный дух J2ME игр, на голом Cи с Ассемблером!
Короче, консоль типичной архитектуры мини-ПК, просто на самопальной плате для штекеров дисплея. Посему порт не на неё, а на ОС, которая задействована в ПК.
Нет. Сходство консоли с ПК заканчивается на 32-битности. Железо очень разное.
При написании игр, используется три уровня. Иллюстрация ниже. Нижний уровень на всех платформах свой - нативный, который обеспечивает работу с железом консоли или ОС ПК.
Добавлено (15 Сентября 2019, 09:06) --------------------------------------------- Благодаря такому замечательному видеоконтроллеру как S1D13746, стало возможным запускать игру Gradius III Total Terror на экране телевизора!
1) Поддержка видеокартой VESA VBE версии 1.2 как минимум.
2) Поддержка звуковой карты на уровне Sound Blaster 16 или его эмуляция.
3) Наличие переменной окружения BLASTER (к примеру: BLASTER=A220 I5 H5, где A - порт, I - аппаратное прерывание, H - номер канала 16-битного DMA)
Порт для DOS вначале был получен с помощью DJGPP, затем окончательно перенесён в Open Watcom C/C++ и поддерживается расширителем ДОС(DOS-extender) DOS/4G.
Используется самая навороченная версия DOS4GW - DOS4G, так как она обеспечивает бОльшее выделение памяти и поддерживает функцию коллбэка DPMI: 0x303
Звуковая карта, на которой тестировали: PCI Creative Sound Blaster Live - от саунд-бластера которой осталось только название, вся работа в режиме SB16 через драйвер-эмулятор (эмуляция в DOS'е софтовая через VCPI EMM386 + HIMEM).
К сожалению, труЪ-шной ISA карты SoundBlaster у меня нет, также как и PCI Cmedia CMI8738, способной работать в режиме Legacy Audio и выдавать "железный" SoundBlaster для DOS'а.
Результаты:
1) MS DOS 7.1 - идёт превосходно 2) Free DOS - идёт превосходно (выбирать вариант загрузки с EMM386) 3) Win98 - идёт превосходно 4) WinXP - идёт с небольшими рывками, но без тиринга (для эмуляции SoundBlaster, надо скачать драйвер VDMSound: https://www.old-games.ru/wiki/VDMSound) 5) DOSBox - скорость приемлема только в режиме без фильтра, задержки считаются неверно(в межуровневых сценариях звук проигрывается раньше, чем отработает задержка)
В DOSBox есть ошибка эмуляции - в 16-битных графических режимах неверно работают регистры VGA: 0x01 и 0x13 (порты 0x3D4/0x3D5), которые устанавливают логическую ширину строки. Она должна быть в 2 раза больше, а на эмуляторе кадр был короче в 2 раза. Проблема совместимости решилась вызовом функции 0x4F06 VESA VBE и отказом от программирования VGA-регистров.
Формат вызова: Gradius3 m s
m - режим: x1 - 128x128 без фильтра (оригинальный кадр) - 320x200 x2 - 256x240 с фильтром - 640x400 или 640x480 x2f - 256x256 с фильтром - 640x400 или 640x480
s - слот: 0 - Level 1 1 - Level 1 Boss 2 - Level 2 3 - Level 2 Boss 4 - Level 3 5 - Level 3 Boss 6 - Level 4 7 - Level 4 Boss
Без параметров игра идёт в 256x256.
Игра создаёт файл LastSave.bat с последней точкой сохранения.
Игра на 100% повторяет порты для Win, Linux. Иными словами, DOS-порт является полноценным.
Для этого пришлось самостоятельно писать микширование звуковых каналов и заниматься декодированием аудио OGG Vorbis и ADPCM (в SDL это можно делать по умолчанию).
Добавлено (15 Июля 2019, 05:31) ---------------------------------------------
Цитатаk0fe ()
Не совсем понял, что за бонусные шары с цифрами и буквами.
L - жизнь I - временное бессмертие E - убивает врагов в кадре
Добавлено (18 Июля 2019, 17:15) --------------------------------------------- Новый билд игры Gradius III Total Terror под DOS: http://gradius3.space/download8.php
Что нового:
1) Исправлено потребление стека на оптимальное (теперь ДОС-экстендеры не требуют EMM386, HIMEM)
2) Перешли на PMODE/W вместо DOS4/GW
Добавлено (20 Июля 2019, 13:45) --------------------------------------------- Портировал Gradius III Total Terror на самодельную игровую консоль BlackPrism (пока макет).
Консоль в процессе:
Видео с полным прохождением на игровой консоли Black Prism:
Добавлено (24 Июля 2019, 12:33) --------------------------------------------- Портировал Gradius на другую свою игровую консоль: EMU Pocket. (она появилась раньше, чем BlackPrism). У неё очень скромные ресурсы : Flash память 2 МБ, оперативная память 1 МБ (фрагментированная на куски). Тем не менее, мне удалось вместить игру в такие объёмы!
Правда, музыка играет с SD карты. Без SD карты будут только звуки )))
Для сравнения:
1) Железо BlackPrism: 32-битный DSP TMS320C6745, частота ядра 456 МГц, два встроенных RISC-сопроцессора по 228 МГц каждый, кеш L1 по 32 кБ на код и данные, кеш L2 на 256 кБ. Внешняя память : 32 МБ. Планируется переход на 64 МБ. Статус: макет. Планируется релиз.
2) Железо EMU Pocket: 32-битный ARM STM32H743, частота ядра 400 МГц, только кеш L1 по 16 кБ для кода и данных. Память Flash (ROM) 2 МБ, RAM - суммарный объем 1 МБ (нарезана кусками - 512, 256,... кБ в разных адресах). Статус: завершён
Там же схема, описание, исходники портированных эмуляторов для отладочной платы STM32H743 Nucleo. (на ней проводили макетирование EMU Pocket)
Добавлено (10 Августа 2019, 07:11) --------------------------------------------- Консоль поддерживает практически все эмуляторы популярных (по ретро-меркам) игровых приставок-консолей:
1) GameBoy (цветной, черно-белый) 2) GameBoy Advance 3) NES 4) Atari Lynx 5) SEGA Master System 6) SEGA Game Gear 7) SEGA Mega Drive 8) Turbo Grafx 16 9) SNES 10) NEO-GEO 11) Capcom Play System 1,2
Занимаюсь программированием на ПК(и не только) на низком уровне. Довольно часто приходится писать программы или кидать порты под DOS + DPMI.
Многие сейчас усмехнутся, сказав, что ДОС умер... Может быть это и так, но DOS по крайней мере живёт на моём компьютере и в голове
Ближе к делу...
Дано:
1) Звуковая карта PCI Sound Blaster Live (насколько я понял, от саундбластера там осталось лишь одно название). Чип EMU10K. 2) Для ДОС были найдены драйверы, которые эмулируют режим SB16 через эту карту (с помощью VCPI EMM386). Тоесть - это софтовая эмуляция SB16, а не Legacy, как это сделано, к примеру, на картах Cmedia CM8738. 3) С помощью этих драйверов можно конфигурировать SB16: назначить порт, прерывание и номер DMA-канала. 4) DOS-Extender DOS4G (коммерческая версия самого популярного расширителя ДОС: DOS4GW. Почему используется именно он - см. ниже).
Надо:
Реализовать непрерывное воспроизведение аудио-потока с помощью кольцевого буфера с подгрузкой новых данных по прерыванию, вызывающегося после проигрывания очередной половины буфера.
Проблема:
Когда эмуляция SB16 настроена на одно из прерываний ведомого контроллера прерываний (IRQ8 - IRQ15), к примеру - IRQ10, то обработчик прерывания НЕ вызывается!
Если же настроить карту на одно из прерываний ведущего контроллера (IRQ0 - IRQ7), к примеру - IRQ5, то прерывание происходит и всё работает как надо.
Данное поведение, честно говоря, ввело меня в ступор... Попробовал тоже самое сделать в реальном режиме на Turbo Pascal 7.0 - алгоритм работает на IRQ5 и на IRQ10 !!!
Использую компилятор Open Watcom ASM/C/C++ последней официальной версии. Платформа - DOS32(sys dos4g).
Поиск в интернете:
... привел меня к товарищам по несчастью (несколько лет назад):
DOS/4(W) has auto passup range for interrupts 08h-2Eh, i.e. if any of that interrupt occured in real mode, extender reflects it to protected mode. For interrupts occured in protected mode externder searches interrupt handler in protected and if none found pass interrupt down to real mode.
Если же вспомнить, что Master-контроллер прерываний по умолчанию настроен на INT 0x8..INT 0xF (IRQ0..IRQ7), а Slave-контроллер на INT 0x70..INT 0x77 (IRQ8..IRQ15), то становится очевидным, что DOS4GW не может работать с IRQ8..IRQ15, если просто установить обработчик прерывания стандартной C-функцией:
Код
_dos_setvect(0x72,SB16_New); // INT 0x72 - IRQ10
или с помощью DPMI функции 0x205 (установка обработчика прерывания защищённого режима).
Решение номер 1:
Не совсем красивое с точки зрения технической эстетики.
Решение возникло на основе знаний о том, что прерывание IRQ10 от звуковой карты всё-же обрабатывалось, если оно было установлено программой РЕАЛЬНОГО режима.
На Turbo Pascal, а позже на Flat Assembler, был написан небольшой резидентик, устанавливающий обработчик прерывания в реальном режиме, сигнализирующий о том, что карта завершила чтение буфера:
Код
ORG 0x100
jmp int0x72
IRQSlave: push ax push dx mov al,1 ;флаг SB_RM_FLAG mov BYTE [cs:SBFlag],al ;узнаём порт (заполняется 32-битной программой, см. ниже) mov dx,WORD [cs:SBPort] add dx,0x00F in al,dx mov al,0x20 out 0x20,al out 0xA0,al pop dx pop ax iret
SBPort dw 0x220 SBFlag db 0
int0x72: mov ah,0x25 mov al,0x72 mov dx,IRQSlave int 21h ;установка вектора прерывания в реальном режиме mov dx,int0x72 ;завершить работу программы, оставив её часть резидентной (от IRQSlave до int0x72) int 27h
Как видно из программы, ничего особенного - обработчик просто подтверждает прерывание чтением из порта и записывает 1 в ячейку памяти со смещением SBFlag от начала кода обработчика (это байт со смещением 0x1C).
Далее собственно, мы проверяем этот флаг из нашей программы защищённого режима в другом обработчике прерываний, с которым проблем не возникает. Это прерывания таймера IRQ0:
Код
volatile u8 *SB_RM_FLAG; //флаг завершения чтения данных от обработчика прерывания реального режима
SB_RM_FLAG=(u8*)(((*(u16*)((0x72UL*4)+2))<<4)+(*(u16*)(0x72UL*4))); //указатель указывает на физический адрес вектора прерывания INT 0x72 реального режима
void interrupt far TimerNew(void) { if(SB_RM_FLAG) //если флаг установлен { SB_RM_FLAG=0; //то сбрасываем его MIXER(); //подгружаем новые данные в свобродную половину буфера }
out8(0x20,0x20); //шлём EOI ведущему и ведомому контроллеру прерываний out8(0xA0,0x20); }
Решение блестяще работает как на ведущих, так и на ведомых прерываниях.
Недостатки решения:
1) Требуется постоянно запускать программу-резидент перед запуском основной программы
2) Постоянный опрос флага по прерыванию таймера
Решение номер 2:
Избавляемся от программы-резидента.
В стандарте DPMI (dpmispec1.0.pdf) есть интересная функция: 0x201 - Set Real Mode Interrupt Vector. Она требует на входе указания номера вектора прерывания, а также адрес обработчика реального режима в формате сегмент:смещение.
Попутно понадобилась ещё одна функция - выделить блок памяти ниже 1 МБ (для размещения кода обработчика прерывания РЕАЛЬНОГО режима). Это DPMI функция 0x100 - Allocate DOS Memory Block.
Обработчик прерывания был взят с программы-резидента и закодирован в C-массив констант:
Но так как данный массив скорее всего будет размещён линковщиком по адресу выше первого мегабайта, то его необходимо скопировать в заранее выделенную область памяти с помощью вышеназванной функции 0x100.
Целиком набор функций инжектора кода обработчика прерывания реального режима выглядит так:
Код
s8 DOS_Allocate(u16 paragraph,u16 *segment,u16 *selector) //выделяет память в адресном пространстве ниже 1 МБ { s8 r=0; u16 _seg; u16 _sel; _asm { mov ax,0x100 mov bx,paragraph int 0x31 jnc OK mov r,-1 OK: mov _seg,ax mov _sel,dx } *segment=_seg; *selector=_sel; return r; }
s8 Set_RM_Handler(u8 i,u16 s,u16 o) //установка обработчика прерывания реального режима (по номеру прерывания и по адресу сегмент:смещение) { s8 r=0; _asm { mov ax,0x201 mov bl,i mov cx,s mov dx,o int 0x31 jnc OK mov r,-1 OK: } return r; }
u16 SB_RM_SELECTOR; //селектор на участок памяти ниже 1 МБ (нужен для освобождения памяти по завершению работы программы)
s8 SB_Set_RM_Handler(u8 i,u8 *handler,u16 size) { u16 segment; //сегмент участка памяти ниже 1 МБ, полученный функцияе 0x100
if(DOS_Allocate((size+15)>>4,&segment,&SB_RM_SELECTOR))return -1; //просим необходимое число параграфов
u32 physical=((u32)segment)<<4; //вычисляем физический адрес (необходим для считывания флага, установленного обработчиком прерывания)
SB_RM_FLAG=(u8*)(physical+0x1C); //находим физический адрес нашего флага
*(u16*)&handler[0x1A]=SB_IO; //set SB I/O Port - записываем номер порта подтверждения прерывания (помогаем обработчику)
memcpy((void*)physical,handler,size); //копируем код обработчика в выделенную память ниже 1 МБ
Труды увенчались успехом!!! Программа работает с любым IRQ от любого контроллера - ведущего или ведомого. Проверял: в MS DOS 7.1, Free DOS, Win98, WinXP - всё работает.
Следует участь одну важную деталь: в DOS4GW база всегда =0, поэтому 32-битное смещение(ближний указатель) равен физическому адресу. Поэтому мы просто можем обращатся к ячейкам памяти, умножив сегмент на 16 и сложив со смещением (для реального режима). В других расширителях ДОС база может быть ненулевой, поэтому код прийдётся скорректировать!
Важное замечание:
Здесь и далее опущены моменты освобождения памяти и восстановления прежних обработчиков, адреса/селекторы которых были заранее получены специальными функциями DPMI. Сделано это с целью упростить объём и изложение материала, сфокусировавшись на главном.
И наконец -
Решение 3.
Обрабатываем всё в прерывании от звуковой карты! Освобождаем обработчик таймера от постоянного опроса флага.
Полезная функция DPMI: 0x303 - Allocate Real Mode Callback Address. Функция даёт адрес реального режима сегмент:смещение - точка входа в РЕАЛЬНОМ режиме, в которой будет вызов функции ЗАЩИЩЁННОГО режима. Коллбэк позволяет вызвать процедуру ЗАЩИЩЁННОГО режима, если процессор находится РЕАЛЬНОМ (или V86) режиме!
Объединив это с предыдущим решением, мы получим обработку прерывания в реальном режиме с заходом в функцию защищённого режима.
Следует отметить, что в процедуре колбэка нам нужно будет восстановить виртуальные регистры (V86 mode) Flags, CS:IP обработчика реального режима.
Обработчик коллбэка написан на Watcom Assembler:
Код
.CODE
EXTRN __GETDS:PROC ;это ваткомовский прикол, без него вызов функций внутри обработчика приводит к аварийному вылету программы EXTRN UserCallBack_:PROC ;это пользовательская функция коллбэка
PUBLIC SystemCallBack_
SystemCallBack_: pushad push ds push es push fs push gs cld lodsw mov es:[edi+0x2A],ax ;IP lodsw mov es:[edi+0x2C],ax ;CS lodsw mov es:[edi+0x20],ax ;FLAGS call __GETDS push ds pop es call UserCallBack_ pop gs pop fs pop es pop ds popad iretd
END
Отказ от написания обработчика на C/C++ вызван здесь тем, что компилятор C/C++ затирает регистры ds,es,esi,edi, используя их для своих нужд. А они нам нужны для получения виртуального контекста. Подробнее см. в спецификации DPMI (функция 0x303; передача и приём виртуального контекста регистров V86).
Пользовательская функция коллбэка:
Код
void UserCallBack(void) { MIXER(); //загружаем новые данные
s8 Set_RM_HandlerCallBack(u8 i,void far *handler) { if(CallBack_Allocate(handler,&SB_RM_New))return -1; //выделяем адрес коллбэка RM, при вызове которого будет происходить вызов PM функции handler if(Set_RM_Handler(i,SB_RM_New))return -1; //устанавливаем этот коллбэк в качестве вектора для обработчика RM прерывания! return 0; }
#pragma pack(1) //запрещаем выравнивание членов структуры, чтобы не было дырок struct RMI //виртуальные регистры для RM V86 (контекст для реального обработчика прерывания) { u32 EDI,ESI,EBP,ReservedByRMI,EBX,EDX,ECX,EAX; u16 flags,ES,DS,FS,GS,IP,CS,SP,SS; };
s8 CallBack_Allocate(void far *c,RMA *a) //32-битный указатель на SystemCallBack, получаем сегмент:смещения для вызова PM коллбэка в RM { union REGS r; struct SREGS sr; static RMI rmi;
memset(&sr,0,sizeof(sr)); memset(&rmi,0,sizeof(rmi)); //здесь контекст виртуальных регистров (в обработчике коллбэка восстанавливаем Flags, CS, IP - см. выше)
Решение успешно работает на ведущих и ведомых IRQ, проверял на: MS DOS 7.1, Free DOS, Win98, WinXP, эмуляторе DOSBox.
Необходима КОММЕРЧЕСКАЯ версия ДОС-экстендера - DOS/4G. Так как некоммерческая версия НЕ поддерживает DPMI-функцию установки RM коллбэка(0x303) и имеет ограничение на максимально используемую память!
Следует отметить, что данный приём оказался совместимым и с другими DOS-extender'ами:
1) causeway 2) pmodew (для обработки прерываний он не использует V86, а переходит в настоящий RM) 3) dos32
И что самое интересное, они в СВЕЖИХ версиях - поддерживают обработку всех аппаратных прерываний (IRQ: ведущие и ведомые).
И можно просто сделать:
Код
_dos_setvect(0x72,SB16_New); // INT 0x72 - IRQ10
или с помощью DPMI функции 0x205 (установка обработчика прерывания PM).
И оно будет работать, в отличие от DOS4G, DOS4GW.
Так же следует отметить, что версии расширителей ДОС, входящие в состав Open Watcom - СТАРОЙ версии, поэтому описаный здесь трюк будет как нельзя кстати!
Надеюсь, выложенная здесь информация будет кому-то полезной/интересной.
Всем, кто дочитал - СПАСИБО! - за проявленный интерес!
Для горизонтального сролл-шутера лучше взять более широкоэкранное соотношение сторон, чтобы было больше видимости и места для манёвров.
Игра задумывалась в 2008 году для мобильных телефонов. Но по ряду причин разработка игры была заморожена. Движок со скроллом и релизными картами уровней были уже сдеаны и нарисованы. Поэтому не стали переделывать размер кадра, оставив его 128х128 для возможности переделки под мобильные платформы (кнопочные телефоны) и ощущения "ламповости" как от J2ME MIDP игр на телефонах).
Новый релиз от 03.06.2019
Что нового? :
1) Сделал обводку надписей на игровом табло (число очков, Bullet, Bomb, Score, Life) и на сообщениях Pause, Game Over. 2) Добавлена поддержка полноэкранного режима 3) Добавлены фильтры HQ3x и HQ4x для режимов соотвественно: 384x384 и 512x512
Фильтр HQ3x:
Фильтр HQ4x:
Добавлено (06 Июня 2019, 10:17) --------------------------------------------- http://gradius3.space/download3.php (Новый релиз от 06.06.2019)
4) Оптимизация по загрузке CPU - теперь игра занимает столько процессороного времени, сколько необходимо 5) Устранены причины, приводившие FireFox выводить предупреждение о скачивании архива игры
Добавлено (13 Июня 2019, 09:43) --------------------------------------------- Итак, после долгих и упорных исследований, нам [коллективу разработчиков игры "Gradius III Total Terror"] удалось улучшить плавность анимации в игре!
Удалось избавиться от:
- Тиринга (Tearing) - разрезания изображения - Периодического подёргивания изображения
В этом месте особенно хорошо тестируются:
Допилили SDL 1.2 - написали свой рендерер через OpenGL, поддерживающий VSync. Кроме того, для VSync задействовали DWM там, где это возможно (см. ниже).
Алгоритм VSync теперь следующий:
1) проверяется наличие поддержки Desktop Window Manager (DWM). 2) если DWM поддерживается, то VSync в оконных режимах будет через DWM_Flush() (подробнее - курим MSDN). 3) если DWM не поддерживается, то VSync будет через флажок OpenGL (выставляется принудительно).
DWM присутствует в ОС Win, начиная с Vista. В Windows 7 DWM начинает работать, если включена AERO в настройках Персонализации. В Windows 10 DWM работает всегда (?)
Почему мы делаем VSync, используя оба метода OpenGL и DWM ? Потому что использование VSync без DWM с помощью OpenGL повышает % использования CPU.
В ходе экспериментов мы установили следующее:
1) Включение AERO снижает % использования CPU в полноэкранных режимах, когда VSync с помощью OpenGL
2) Включение AERO сильно снижает % использования CPU в оконных режимах, когда VSync с помощью DWM
3) С выключенной AERO VSync с помощью DWM не работает, а OpenGL VSync грузит двух-ядерный CPU на 50%
4) VSync DWM работает только с включенной AERO и только в оконном режиме
5) AERO в Win10 включена всегда, а в Win7 включается через "Персонализацию"
6) При переключении в полноэкранный режим возможны задержки, если AERO включена (Win7)
7) VSync в OpenGL лучше переключать, используя прямой вызов функций расширений OpenGL, а не через SDL (проблемы на встроенных картах Intel в Win10)
Попутно проверили рендерер Direct 3D: VSync там оказался некачественным - присутствовали резкие подёргивания при анимации изображения. Проверяли в эмуляторе SNES9x (рендерер Direct3D, галочка VSync, ROM biometal.sfc) и на программе-заготовке в SDL 2.0
А также пробовали адаптировать игру на SDL 2.0. Никаких улучшений по сравнению с SDL 1.2 мы не заметили, напротив - одни ухудшения:
- дёрганная анимация на D3D рендерере (см. выше) - некорректно происходит работа со звуком (SDL_Mixer 2.0) - присутствовали резкие щелчки после окончания звука и некорректное декодирование форматов
1) Реализована плавность анимации (ликвидированы Tearing и рывки при анимации) 2) Улучшена синхронизация звука (в критических местах), не зависящая от фреймрейта
Желательна поддержка "железного" Open GL не ниже 1.2
Добавлено (24 Июня 2019, 11:24) --------------------------------------------- Новый релиз игры Gradius III Total Terror от 24.06.2019:
1) Подправлены мелкие баги в API (для игрока прозрачно) 2) Полноэкранные режимы теперь на всю высоту дисплея (сам кадр оставили квадратным, чтоб не нарушать Aspect Ratio) 3) Внедрили титульник созданный, пользователем Sharpnull (за это ему БОЛЬШОЕ спасибо! 4) Исправили название космического корабля (замечание от пользователя OmKol, спасибо!)
Добавлено (30 Июня 2019, 12:20) --------------------------------------------- Сделали порт под Linux.
1) Обводка надписей на игровом табло (число очков, Bullet, Bomb, Score, Life) и сообщений Pause, Game Over. 2) Добавлена поддержка полноэкранного режима 3) Добавлены фильтры HQ3x и HQ4x для режимов соотвественно: 384x384 и 512x512 4) Оптимизация по загрузке CPU - теперь игра занимает столько процессороного времени, сколько необходимо 5) Устранены причины, приводившие FireFox выводить предупреждение о скачивании архива игры 6) Реализована плавность анимации (ликвидированы Tearing и рывки при анимации) 7) Улучшена синхронизация звука (в критических местах), не зависящая от фреймрейта 8) Подправлены мелкие баги в API (для игрока прозрачно) 9) Полноэкранные режимы теперь на всю высоту дисплея (сам кадр оставили квадратным, чтоб не нарушать Aspect Ratio) 10) Внедрили титульник созданный, пользователем Sharpnull (emu-land) (за это ему БОЛЬШОЕ спасибо! 11) Исправили название космического корабля (замечание от пользователя OmKol (emu-land), спасибо!) 12) Порт для Linux 13) Порт для DOS 14) Оптимизировано потребление стека в DOS-версии 15) Сделан порт на игровую консоль Black Prism (см. ниже) 16) Сделан порт на игровую консоль EMUPocket (см. ниже)
Девелоперы: Коллектив разработчиков: 2 человека. В основном программисты, с небольшими навыками художников.
Мы являемя фанатами серии игр "Gradius", выпущенными на игровые приставки NES, SNES и аркадные автоматы.
Описание: Игра представляет собой космический 2D-шутер с видом от 3-го лица сбоку. Направление полёта - вправо.
Игра сделана как ремейк (хотя может слово не совсем точное) - сильно напоминает Gradius3 под SNES, но со своими оригинальными элементами!
Локации, противники, боссы - здесь есть всё: от похожести на Gradius3, до оригинальных решений!
Ваша задача - облететь 4 планеты и победить противников, которые захватили эти планеты и ведут деятельность по их загрязнению.
Локации, поведение врагов и боссов - детерминировано, мозг по мере игры, постепенно запоминает локации и повадки противника, в конечном итоге - движемся всё дальше и дальше и проходим игру до конца!
Игра создавалась с важным правилом: "Каждый уровень - уникальный!" Местность, противники: на каждой планете - разные! Повторов нет!
Управляющие клавиши: Enter - старт/пауза Стрелки - управление кораблём Левый Ctrl - стрельба патронами (количество выстрелов - бесконечность) Левый Alt - сброс бомбы (максимальное количество - три) Esc - немедленный выход из игры
Скриншоты - режимы 2x, 3x, 4x:
титульник:
карта:
1-й уровень:
2-й уровень:
3-й уровень:
4-й уровень:
лаунчер:
режим 128x128:
режим 384x384:
Фильтр HQ3x:
Фильтр HQ4x:
Игра задумывалась в 2008 году для мобильных телефонов. Но по ряду причин разработка игры была заморожена. Движок со скроллом и релизными картами уровней были уже сдеаны и нарисованы. Поэтому не стали переделывать размер кадра, оставив его 128х128 для возможности переделки под мобильные платформы (кнопочные телефоны) и ощущения "ламповости" как от J2ME MIDP игр на телефонах).
Сообщение отредактировал Gradius - Среда, 24 Июля 2019, 12:32
