| Разработка и ромхакинг > Ромхакинг и программирование |
| SGDK |
| << < (31/40) > >> |
| megavolt85:
Sharpnull, я к тому что мапер известно какой и его можно сделать самому и даже расширить до 128 мегабайт я знаю что поддержка добавлена из материалов Segaretro, но никто не запрещает чутка поправить код и использовать всё доступное адресное пространство схема на логике это лишь пример, при желании вся логика запихивается в FPGA и не занимает на плате много места P.S. да и я сомневаюсь что кто либо для выпуска своих кариков станет дербанить SSF2 карики, проще и дешевле сделать свои |
| worm:
Извиняюсь за возможно тупой вопрос, но куда в этом случае будет записываться дополнительная информация в роме? Ведь после 10мб сежка резервирует адреса для системы - vdp, ram и тд. Или это не важно, т.к. маппер сам адреса будет генерировать? (На вы с маппервми, увы) |
| ALKOSHA:
--- Цитата: worm от 24 Март 2020, 11:07:55 ---Извиняюсь за возможно тупой вопрос, но куда в этом случае будет записываться дополнительная информация в роме? Ведь после 10мб сежка резервирует адреса для системы - vdp, ram и тд. Или это не важно, т.к. маппер сам адреса будет генерировать? (На вы с маппервми, увы) --- Конец цитаты --- По-моему, там листание страниц осуществляется через младшие 3 бита и старшие 3 бита адреса (всего 6 бит - 64 банка по 512кб, итого 32 мегабайта можно адресовать). |
| megavolt85:
нет там никакого листания страниц, это полноценный MMU модуль адресное пространство карика (4 мегабайта) разбито на 8 областей по 512к каждая в первую область всегда отображаются первые 512к ПЗУ в остальные семь областей можно мапить любой 512к блок ПЗУ --- Цитата: ALKOSHA от 24 Март 2020, 13:29:21 ---всего 6 бит - 64 банка по 512кб, итого 32 мегабайта можно адресовать --- Конец цитаты --- в оригинале да, в кастомном можно использовать все 8 бит - 256 банков по 512кб, итого 128 мегабайт |
| ALKOSHA:
В демке Overdrive 2 были пару моментов с полупрозрачностью слоя. Оказывается это недокументированная фишка VDP. https://youtu.be/gWVmPtr9O0g?t=137 В курсе как её бахнуть на SGDK? Или нужно велосипедить асм-процедурки? |
| Sharpnull:
ALKOSHA, вряд ли там есть что-то для включения этой фичи, только если через вспомогательные функции, которые что-то куда-то пишут, что равносильно "асм-процедурке". Кстати, запустил Overdrive 2 в BlastEm 0.6.3-pre (RetroArch), остались ещё артефакт, в основном при переключении сцен. Не сразу понял, что чёрные полосы были по краям из-за этой сцены https://youtu.be/gWVmPtr9O0g?t=255, где робот снимает рамку, которую не увидеть, потому что эмуляторы обрезают до 320x240. |
| SPOT:
Кто подскажет как сделать что бы игра выдавала одинаковую скорость и на 50 и 60 герц? |
| ALKOSHA:
--- Цитата: SPOT от 25 Март 2020, 13:59:19 ---Кто подскажет как сделать что бы игра выдавала одинаковую скорость и на 50 и 60 герц? --- Конец цитаты --- Моторола чем хороша, у неё есть аппаратный таймер В кровавыше я делал разбивку на отдельные ф-ции - апдейт позиций, апдейт кадра. По вот этой статье. https://m.habr.com/ru/post/136878/ НО, порой на железе бывали глюки. Правда я там еще раритетную версию СДК юзал, может с обновлённой получше дела обстоят. Нынче я планирую умножать на дельта-тайм переменные приращений координат. Больше мороки, но зато и больше уверенности, что глючить будет не так сильно. Добавлено позже: Вообще на практике я не припомню случаев, чтоб хоть какая-то игра шла одинаково в 50/60Гц Музыка - да. Движок бэтмана и робина (суб терании/ред зоны) стабильно играется. Видимо, он как раз и тактируется от внутренних таймеров. Добавлено позже: --- Цитата ---где робот снимает рамку, которую не увидеть, потому что эмуляторы обрезают до 320x240. --- Конец цитаты --- Интыресна... Я знаю, что можно хайрез по вертикали сделать за счёт черезстрочной развёртки. Но как им удалось расширить по горизонтали ? |
| Sharpnull:
--- Цитата: ALKOSHA от 25 Март 2020, 14:05:04 ---Но как им удалось расширить по горизонтали ? --- Конец цитаты --- Внутренняя область там шире, в коде Gens, например, 336x240, а в отдельном приложении BlastEm можно убрать Overscan и получить такое (347x294): Про BlastEm поправка: проверил в blastem-win32-0.6.2 (не RetroArch) - всё работает правильно на глаз, артефактов нет как в BlastEm 0.6.3-pre (RetroArch), но иногда наверху есть горизонтальная полоска из других пикселей и за пределами основного экрана встречаются не только чёрные пиксели. Значит может быть: кривой порт libretro, регрессия в 0.6.3-pre, у меня что-то не так с RetroArch. Добавлено позже: --- Цитата: ALKOSHA от 25 Март 2020, 14:05:04 ---Нынче я планирую умножать на дельта-тайм переменные приращений координат. Больше мороки, но зато и больше уверенности, что глючить будет не так сильно. --- Конец цитаты --- Уже говорил здесь когда-то. Если игра не будет тормозить, то достаточно прибавлять всегда: x += vel_x * 1/50 и x += vel_x * 1/60, в зависимости от частоты, с учётом вещественных чисел с фиксированной точкой (делить и умножать на целые числа с FIX16 и FIX32 можно без макросов умножения и деления). В принципе, можно вместо "вещественных" в SGDK разделить пиксель на какое-то число, допустим 300 (оно делится на 5 и на 6). Тогда минимальная скорость для 50 FPS - 6 частей пикселя в кадр, а для 60 FPS - 5 частей в кадр. Когда хотим двигаться 1 пиксель в секунду: при 50FPS прибавляем 6, при 60FPS - 5. Через секунду будет 300, через 2 секунды - 600, делим на 300 чтобы узнать текущий пиксель для вывода: 300/300 == 1, 600/300 == 2. Скорость всегда должна быть кратна 5 и 6. Выбранное 300 для частей пикселя слишком большое для int16 (300 * 320 == 96000). В таком варианте будет выше точность для 50/60FPS, так как не будет погрешности при делении "вещественных" чисел при произвольной скорости vel_x * 1/50 (vel_x * 1/60). Но вряд ли такое кого-то устроит, может быть не заметно и это только моё предположение. UPD: Про BlastEm. Протестировал blastem-win32-0.6.3-pre-1ec6931d0a49 (27-Feb-2020 08:47), артефакты как в libretro (RetroArch), значит регрессия, но это всё-таки не стабильная версия. Странно что libretro впихнуло эту версию, настройки не смотрел, но было бы неплохо различать стабильные и нестабильные ядра. |
| SPOT:
Кто в курсе что лучше использовать по производительности (затраченное время на операцию) Деление или побитовое смещение? Пример 32 / 16 32 >> 4 ? |
| Sharpnull:
SPOT, если написать int16 = 32 / 16; int16 = 32 >> 4;, то результат (ром) будет одинаковый. Если написать int16 = a / 16; int16 = a >> 4;, нужно проверить, может быть одинаковым. Про производительность не знаю. Напомню, что если N отрицательное в N >> 4, то результат зависит от реализации, а для N << 4 вообще UB. ------- Вот такой код генерирует одинаковый ром: --- Код: ---// 1 s += 64 >> 4; // 2 s += 64 / 16; // 3 u16 n = 64; while (TRUE) { s += n >> 4; // 4 u16 n = 64; while (TRUE) { s += n / 16; --- Конец кода --- В 3-м и 4-м случаях n не менялся, поэтому тоже самое, что константа. В сложных случаях результат будет другой, а производительность можно проверить деля случайные числа много раз, по FPS. -------- Сделал тестовый пример, код одинаковый (для #if 0 и #if 1) получается: --- Код: ---#include <genesis.h> int main() { SYS_disableInts(); VDP_setScreenWidth256(); VDP_setScreenHeight224(); VDP_setPlanSize(32, 32); SYS_enableInts(); while (TRUE) { VDP_showFPS(TRUE); u16 s = 0; for (int i = 0; i < 32678; i++) { u16 rand = random(); #if 0 s += rand / 16; #else s += rand >> 4; #endif } char str[16] = { 0 }; intToStr(s, str, 6); VDP_drawTextBG(PLAN_B, str, 16, 16); VDP_waitVSync(); } return 0; } --- Конец кода --- В коде это записывается как lsr.w #4,D1. Если менять u16 s = 0 на s16, u32, s32, то также нет разницы между / 16 и >> 4. В общем, записывайте как удобней, а если сомневаетесь, просто сравните ромы. :) |
| ALKOSHA:
Не знаете, с чем может быть связано, что когда я задаю размеры плейнов 128х32 тайла, то на экране появляются гличащие тайлы, а при дефолтном размере плейнов глюков нет? |
| worm:
--- Цитата: megavolt85 от 24 Март 2020, 18:52:30 ---в кастомном можно использовать все 8 бит - 256 банков по 512кб, итого 128 мегабайт --- Конец цитаты --- Не перестаю восхищаться винтажными консольками :blush: --- Цитата: ALKOSHA от 25 Март 2020, 00:22:11 ---В демке Overdrive 2 были пару моментов с полупрозрачностью слоя. Оказывается это недокументированная фишка VDP. https://youtu.be/gWVmPtr9O0g?t=137 В курсе как её бахнуть на SGDK? Или нужно велосипедить асм-процедурки? --- Конец цитаты --- Очень похоже на режим shadow (может ошибаюсь). Там есть затемнение и высветление, есть и демка, использующая этот режим. --- Цитата: Sharpnull от 25 Март 2020, 18:20:51 ---всё работает правильно на глаз --- Конец цитаты --- Тоже сверял одновременно запустив видео и бластем)) что странно - они не сделали эту черную рамку прозрачной и если бы она не была черной на видео, я бы подумал, что это косяк эмулятора. --- Цитата: ALKOSHA от 31 Март 2020, 16:35:30 ---Не знаете, с чем может быть связано, что когда я задаю размеры плейнов 128х32 тайла, то на экране появляются гличащие тайлы, а при дефолтном размере плейнов глюков нет? --- Конец цитаты --- Сейчас, наверно, сморожу фигню, но возможно это конфликт размещения данных в ОЗУ. Одна программа записывает в ячейку памяти, допустим, координаты, другая в ту же ячейку индекс тайла. Данные перезаписываются одним процессом, считываются другим и получаются артефакты. Хотя, скорее всего, это плод моей больной фантазии :lol: |
| Sharpnull:
--- Цитата: ALKOSHA от 31 Март 2020, 16:35:30 ---Не знаете, с чем может быть связано, что когда я задаю размеры плейнов 128х32 тайла, то на экране появляются гличащие тайлы, а при дефолтном размере плейнов глюков нет? --- Конец цитаты --- Вроде обсуждали, нужно менять адреса для APlan, BPlan, Window, SpriteList, HScrollTable. Адреса по умолчанию менялись ранее, но сейчас такие (vdp.c): --- Код: ---#define WINDOW_DEFAULT 0xD000 // multiple of 0x1000 (0x0800 in H32) #define HSCRL_DEFAULT 0xF000 // multiple of 0x0400 #define SLIST_DEFAULT 0xF400 // multiple of 0x0400 (0x0200 in H32) #define APLAN_DEFAULT 0xE000 // multiple of 0x2000 #define BPLAN_DEFAULT 0xC000 // multiple of 0x2000 --- Конец кода --- Размеры BPLAN, APLAN, WINDOW - 0x1000 байт, что равно 2048 тайлам или 64x32, 32x64, 32x32. Для 128x32 и 32x128 нужно больше. Насколько знаю, если WINDOW не использовать, то пересечение не мешает с BPLAN, а вот на APLAN залезает HSCRL и SLIST. В примере xgmplayer такие: --- Код: ---VDP_setPlanSize(64, 64); VDP_setSpriteListAddress(0xA800); VDP_setHScrollTableAddress(0xAC00); VDP_setWindowAddress(0xB000); VDP_setBPlanAddress(0xC000); VDP_setAPlanAddress(0xE000); --- Конец кода --- То есть перенесли SLIST, HSCRL и WINDOW. VRAM стало меньше на 6144 байт. Можно попробовать совместить WINDOW, для экономии. -------- Странно, что сейчас 0xF000 и 0xF400, а не 0xF800 и 0xFС00, ведь им нужно по 0x400. Может для спрайтов может быть использовано больше памяти. Раньше было так в SGDK: --- Код: ---#define WINDOW_DEFAULT 0xD000 // multiple of 0x1000 (0x0800 in H32) #define HSCRL_DEFAULT 0xD800 // multiple of 0x0400 #define SLIST_DEFAULT 0xDC00 // multiple of 0x0400 (0x0200 in H32) --- Конец кода --- |
| ALKOSHA:
Ааа... точно.. Я и забыл. :blush: Просто в старой версии СДК дефолтные адреса были настроены так, что я с этим и не заморачивался как-то. Выставил 512х512 пикселей разрешение слоёв, и всё пахало. Лан. буду юзать 64х32 тайлов. Должно хватить для незримого обновления фона. Добавлено позже: --- Цитата ---Очень похоже на режим shadow (может ошибаюсь). Там есть затемнение и высветление, есть и демка, использующая этот режим. --- Конец цитаты --- Про уровни яркости знаю, в каждой третьей игре применяли такой подход. Но в овердрайве точно не оно, так как суммируются разные цвета, а не просто меняется яркость одного и того же цвета. Добавлено позже: В цытатке с Поуета есть упоминание про блендинг --- Цитата --- --- Конец цитаты --- |
| Sharpnull:
ALKOSHA, нашёл такое: https://www.reddit.com/r/emulation/comments/66emym/sega_mega_drive_notes_overdrive_2_demo/. SEGA Mega Drive / Genesis hardware notes Written by Kabuto of TiTAN during the development of Overdrive 2 https://docs.google.com/document/u/1/d/1ST9GbFfPnIjLT5loytFCm3pB0kWQ1Oe34DCBBV8saY8/pub -------- Занятно, мне ведь уже попадалось зеркало этого документа: https://plutiedev.com/mirror/kabuto-hardware-notes. Там нет кода, придётся сначала вкурить как работает железо, а потому уже это. -------- Последний сайт интересный: https://plutiedev.com/. Несколько коротких статьей, там сказано, что BlastEm может прочитать ром любого размера, значит пора сделать демку на 128МБ. |
| ALKOSHA:
--- Цитата: Sharpnull от 31 Март 2020, 20:17:21 ---значит пора сделать демку на 128МБ. --- Конец цитаты --- Но 0_0 При сеговском VRAM в 64кб и частоте проца в 7 мегагерц, такие объёмы пригодны разве что для кинца. Что в конечном счёте и произошло с насадкой MegaCD (хотя у той на борту были ещё свои графические фитчи). 4096 килобайт хватит всем! Даже в килобайты прекрасно влазят масштабные миры. А при процедурной генерации- так вообще целая вселенная (как в Elite) |
| SeregaZ:
это прям Sega-майнкрафт какой-то :) |
| Sharpnull:
--- Цитата: ALKOSHA от 31 Март 2020, 22:26:36 ---При сеговском VRAM в 64кб --- Конец цитаты --- У MD есть 128 KB mode, оказывается. Дело в количестве графики и уровнях вообще, а не одновременном использовании. Но я имел в виду просто тестовый файл, например галерею из аниме картинок. Кино бывало на картриджах официально... Game Boy Advance Video Shrek, Спанч-боб и другие. |
| SPOT:
--- Цитата: Sharpnull от 31 Март 2020, 22:44:48 ---У MD есть 128 KB mode, оказывается. Дело в количестве графики и уровнях вообще, а не одновременном использовании. Но я имел в виду просто тестовый файл, например галерею из аниме картинок. Кино бывало на картриджах официально... Game Boy Advance Video Shrek, Спанч-боб и другие. --- Конец цитаты --- "У MD есть 128 KB mode" Можно об этом поподробнее? |
| Навигация |
| Главная страница сообщений |
| Следующая страница |
| Предыдущая страница |