SGDK

[megavolt85]

Sharpnull, я к тому что мапер известно какой и его можно сделать самому и даже расширить до 128 мегабайт
я знаю что поддержка добавлена из материалов Segaretro, но никто не запрещает чутка поправить код и использовать всё доступное адресное пространство
схема на логике это лишь пример, при желании вся логика запихивается в FPGA и не занимает на плате много места

P.S. да и я сомневаюсь что кто либо для выпуска своих кариков станет дербанить SSF2 карики, проще и дешевле сделать свои

[Takamura-kun]

Извиняюсь за возможно тупой вопрос, но куда в этом случае будет записываться дополнительная информация в роме? Ведь после 10мб сежка резервирует адреса для системы - vdp, ram и тд. Или это не важно, т.к. маппер сам адреса будет генерировать? (На вы с маппервми, увы)

[ALKOSHA]

Извиняюсь за возможно тупой вопрос, но куда в этом случае будет записываться дополнительная информация в роме? Ведь после 10мб сежка резервирует адреса для системы - vdp, ram и тд. Или это не важно, т.к. маппер сам адреса будет генерировать? (На вы с маппервми, увы)

По-моему, там листание страниц осуществляется через младшие 3 бита и старшие 3 бита адреса (всего 6 бит - 64 банка по 512кб, итого 32 мегабайта можно адресовать).

[megavolt85]

нет там никакого листания страниц, это полноценный MMU модуль
адресное пространство карика (4 мегабайта) разбито на 8 областей по 512к каждая
в первую область всегда отображаются первые  512к ПЗУ
в остальные семь областей можно мапить любой 512к блок ПЗУ

всего 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]

Кто подскажет как сделать что бы игра выдавала одинаковую скорость и на 50 и 60 герц?

Моторола чем хороша, у неё есть аппаратный таймер

В кровавыше я делал разбивку на отдельные ф-ции - апдейт позиций, апдейт кадра.
По вот этой статье.
https://m.habr.com/ru/post/136878/

НО, порой на железе бывали глюки.
Правда я там еще раритетную версию СДК юзал, может с обновлённой получше дела обстоят.

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

Добавлено позже:
Вообще на практике я не припомню случаев, чтоб хоть какая-то игра шла одинаково в 50/60Гц

Музыка - да. Движок бэтмана и робина (суб терании/ред зоны) стабильно играется. Видимо, он как раз и тактируется от внутренних таймеров.

Добавлено позже:

где робот снимает рамку, которую не увидеть, потому что эмуляторы обрезают до 320x240.

Интыресна... Я знаю, что можно хайрез по вертикали сделать за счёт черезстрочной развёртки. Но как им удалось расширить по горизонтали ?

[Sharpnull]

Но как им удалось расширить по горизонтали ?

Внутренняя область там шире, в коде Gens, например, 336x240, а в отдельном приложении BlastEm можно убрать Overscan и получить такое (347x294):


Про BlastEm поправка: проверил в blastem-win32-0.6.2 (не RetroArch) - всё работает правильно на глаз, артефактов нет как в BlastEm 0.6.3-pre (RetroArch), но иногда наверху есть горизонтальная полоска из других пикселей и за пределами основного экрана встречаются не только чёрные пиксели. Значит может быть: кривой порт libretro, регрессия в 0.6.3-pre, у меня что-то не так с RetroArch.

Добавлено позже:

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

Уже говорил здесь когда-то. Если игра не будет тормозить, то достаточно прибавлять всегда: 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 тайла, то на экране появляются гличащие тайлы, а при дефолтном размере плейнов глюков нет?

[Takamura-kun]

в кастомном можно использовать все 8 бит - 256 банков по 512кб, итого 128 мегабайт

Не перестаю восхищаться винтажными консольками

В демке Overdrive 2 были пару моментов с полупрозрачностью слоя. Оказывается это недокументированная фишка VDP.
https://youtu.be/gWVmPtr9O0g?t=137
В курсе как её бахнуть  на SGDK? Или нужно велосипедить асм-процедурки?

Очень похоже на режим shadow (может ошибаюсь). Там есть затемнение и высветление, есть и демка, использующая этот режим.

всё работает правильно на глаз

Тоже сверял одновременно запустив видео и бластем)) что странно - они не сделали эту черную рамку прозрачной и если бы она не была черной на видео, я бы подумал, что это косяк эмулятора.

Не знаете, с чем может быть связано, что когда я задаю размеры плейнов 128х32 тайла, то на экране появляются гличащие тайлы, а при дефолтном размере плейнов глюков нет?

Сейчас, наверно, сморожу фигню, но возможно это конфликт размещения данных в ОЗУ. Одна программа записывает в ячейку памяти, допустим, координаты, другая в ту же ячейку индекс тайла. Данные перезаписываются одним процессом, считываются другим и получаются артефакты. Хотя, скорее всего, это плод моей больной фантазии

[Sharpnull]

Не знаете, с чем может быть связано, что когда я задаю размеры плейнов 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]

Ааа... точно.. Я и забыл. 

Просто в старой версии СДК дефолтные адреса были настроены так, что я с этим и не заморачивался как-то. Выставил 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]

значит пора сделать демку на 128МБ.

Но 
При сеговском VRAM в 64кб и частоте проца в 7 мегагерц, такие объёмы пригодны разве что для кинца. Что в конечном счёте и произошло с насадкой MegaCD (хотя у той на борту были ещё свои графические фитчи).

4096 килобайт хватит всем!

Даже в килобайты прекрасно влазят масштабные миры.

А при процедурной генерации-  так вообще целая вселенная (как в Elite)

[SeregaZ]

это прям Sega-майнкрафт какой-то

[Sharpnull]

При сеговском VRAM в 64кб

У MD есть 128 KB mode, оказывается. Дело в количестве графики и уровнях вообще, а не одновременном использовании. Но я имел в виду просто тестовый файл, например галерею из аниме картинок. Кино бывало на картриджах официально... Game Boy Advance Video Shrek, Спанч-боб и другие.

[SPOT]

У MD есть 128 KB mode, оказывается. Дело в количестве графики и уровнях вообще, а не одновременном использовании. Но я имел в виду просто тестовый файл, например галерею из аниме картинок. Кино бывало на картриджах официально... Game Boy Advance Video Shrek, Спанч-боб и другие.

"У MD есть 128 KB mode"
Можно об этом поподробнее?

[ALKOSHA]

например галерею из аниме картинок

Маняме прекрасно поддаётся RLE компрессии.
Как и комиксы. Поэтому в той же Panorama Cotton валом анимированных катсцен при двух мегабайтном роме, не считая самой игры.
В Yuu Yuu Hakusho Gaiden оного в разы больше, так как это вообще новелла + файтинг. И он тоже не превышает двух мегабайт, вроде как.

[Takamura-kun]

А вот и горяченькое подвезли))

COMPILER

RESCOMP
added ALIGN directive (read rescomp.txt for more information about it)
added UNGROUP directive (read rescomp.txt for more information about it)
added 'compression' and 'far' field to BIN resource
replaced Map structure export by TileMap
minor optimization in building IMAGE tilemap
plain tiles are now ignored (taken from system tiles) when using a base tile index offset for tilemap (mapbase parameter in IMAGE resource)
more flexible resource compilation
ignore palette and priority for transparent pixel
sprite can have their palette not starting at index 0
reorganized resource data export order for better LZ4W compression and bank switch support
added support for 1bpp and 2bpp indexed color images
faster LZ4W tool call (embeded in rescomp now)
preserve resource order for better BIN data compression with LZ4W
more constrained sprite cutting process depending chosen optimization strategy
minor fix to allow using bit 7 (color index >= 128) in IMAGE resource as priority bit in tilemap
simplified / fixed binary compression block with alignment
fixed a bug on possible duplicated resource export
fixed Circle collision type export
now return -1 as exit code on error
replaced FileWriter by StringBuffer (faster and safer)
minor changes and improvements to rescomp.txt file
XGMTOOL
fixed a small bug during sample conversion processing
XGMROMBUILDER
updated to last XGMTool and XGM driver version
LZ4W
fixed LZ4W compression which could failed in very are case
BINTOS
fixed data section (it was .text instead of .rodata)
MAKEFILE
updated 'release' target to generate symbol.txt file (always interesting to have)
show more warnings
forced no inlining of memset / memcpy methods to fix LTO agressive optimization issue


LIBRARY

SYS
added bank switch support using SSF2 mapper (allow ROM > 4MB)
use ENABLE_BANK_SWITCH flag in config.h file to enable bank siwtch support in SGDK
added FAR(..) directive to access a resource through bank switch if required
added SYS_getBank(..) / SYS_setBank(..) methods
moved RAM initialization to sys.c unit and added support for bank crossing (more control on it)
minors changes to reset methods (simpler)
added ROM and RAM constants (yeah, why not ^^)
SPRITE
added sprite frame change event callback (using SPR_setFrameChangeCallback(..) method)
added SPR_loadAllFrames(..) to (pre)load all frames data of a SpriteDefinition to VRAM
removed unpack buffer (replaced by DMA buffer and new DMA_QUEUE_COPY method)
fixed a small issue with delayed update
fixed a bug on SPR_setDefinition(..) (can display glitches as some sprites weren't always properly hidden)
fixed internal sprite link (could occasionaly let some phantom and glitched sprites visible)
added out of range index detection for animation and frame (debug build only)
DMA
added new DMA buffer for easier and better DMA queue management
added 'bufferSize' parameter to DMA_initEx(..) function
added DMA_setBufferSize(..) and DMA_setBufferSizeToDefault() functions to set the temporary DMA buffer size
added new DMA_QUEUE_COPY transfer method (TransferMethod enum) to copy data to a temporary buffer before transfer actually occurs
added DMA_allocateAndQueueDma(..) function which return a temporary buffer and queue a DMA transfer from it
added DMA_allocateTemp(..) and DMA_releaseTemp(..) methods to allocate memory from DMA temporary buffer (use that safely)
added DMA_copyAndQueueDma(..) function which copy data to transfer to a temporary buffer and queue the DMA transfer
added a new generic DMA_transfer(..) function
added DMA_doCPUCopy(..) function to do a CPU copy to VRAM/CRAM/VSRAM
added DMA_getMaxQueueSize() and DMA_setMaxQueueSize() to get and set the queue size.
passed the DMA queue flush loop in assembly for better control (and also faster operation as GCC was dumb about it)
safer DMA operation on DMA_doDMA(..)
added DMA_initEx(..) and simplified DMA_init()
added new DMA_DISABLED flag in config.h to completely disable DMA support in SGDK (for debug purpose)
fix for HALT_Z80_ON_DMA (stupid typo)
VDP
many refactoring (see refactoring section at bottom)
TILE_USERMAXINDEX now take allocated VRAM for sprite engine in account !
added TILE_SPRITEINDEX constant to get base tile index for the Sprite Engine
added tilemap row update methods
VDP_setTileMapDataRow(..) / VDP_setTileMapDataRowEx(..)
VDP_setTileMapRow(..) / VDP_setTileMapRowEx(..)
added tilemap column update methods
VDP_setTileMapDataColumnFast(..) / VDP_setTileMapDataColumn(..) / VDP_setTileMapDataColumnEx(..)
VDP_setTileMapColumn(..) / VDP_setTileMapColumnEx(..)
added TransferMethod parameter to many tilemap set methods
added tilemap wrapping support to VDP_setTileMap(..) and VDP_setTileMapEx(..) methods.
added setupVram parameter to VDP_setPlaneSize(..) function
removed vdpSpriteCacheQueue table (replaced by new DMA_QUEUE_COPY)
re-introduced VDP_loadTileData(..) method in vdp_tile.c unit (no more assembly code for this one)
moved font loading in VDP_resetScreen() method (fix)
PALETTE
fixed palette fading so it correctly trigger during vblank (avoid CRAM dot)
fixed minor issue in palette fading (sometime not properly doing last fade step)
MEMORY
fixed MEM_getLargestFreeBlock(..) method
added MEM_pack() method to help reducing memory fragmentation
removed MEM_init() access as it's not safe to call it externally
increased stack size to 0xA00
MATHS
fixed getLog2Int(..) method
replaced sin tabs to use FIX32/FIX16 (thanks to FireRat for the generator)
TYPES
added new rorxx(..) / rolxx(..) functions which are correctly turned into ROR / ROL instruction when optimization are enabled
Z80
fixed Z80 enable restoration on DMA
general cleanup and refactoring

SAMPLE

Updated for SGDK 1.5 changes
BENCHMARK
added memory information at startup
some changes to adapt to last SGDK
SPRITE
updated resources to use large backgrounds
updated to support long scrolling > 512 px (vertical and horizontal) !
as collision is not implemented, added physic settings using START button so we can play with vertical scrolling too
enemies sprites frames preloaded and animated using new Sprite engine features
Showcase of SPR_loadAllFrames(..) and SPR_setFrameChangeCallback(..) methods
XGMPlayer
updated for easier integration in XGM ROM Builder tool
added notes and tutorial references to README.txt

REFACTORING

TILE_USERMAXINDEX now take allocated VRAM for sprite engine in account !
_voidCallback --> VoidCallback
_joyEventCallback --> JoyEventCallback
PLAN_A --> BG_A
PLAN_B --> BG_B
PLAN_WINDOW --> WINDOW
VDP_PLAN_A --> VDP_BG_A
VDP_PLAN_B --> VDP_BG_B
VDP_PLAN_WINDOW --> VDP_WINDOW
all references to 'Plan' keyword --> 'Plane'
VDPPlan --> VDPPlane
VDP_clearPlan --> VDP_clearPlane
VDP_getTextPlan --> VDP_getTextPlane
VDP_setTextPlan --> VDP_setTextPlane
VDP_setAPlanAddress --> VDP_setBGAAddress
VDP_setBPlanAddress --> VDP_setBGBAddress
VDP_setPlanSize --> VDP_setPlaneSize
all references to 'Map' --> 'TileMap'
Map --> TileMap
unpackMap --> unpackTileMap
allocateMap --> allocateTileMap
VDP_setMap --> VDP_setTileMap
VDP_setMapEx --> VDP_setTileMapEx

Качаем, тестим 

[Sharpnull]

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

"У MD есть 128 KB mode"
Можно об этом поподробнее?

Ничего не знаю об этом, просто увидел в упомянутом SEGA Mega Drive / Genesis hardware notes by Kabuto (зеркало), что у некоторых моделей есть дополнительная VRAM. Вот обсуждали. Использовать всё равно нет смысла.

[Werton]

Пару недель назад видел в коммитах что он вытворяет с названиями методов

ага, немного напрягает постоянное изменение названий, с константами тоже никак не может определиться, был aplan, потом plan_a, теперь bg_a

[Takamura-kun]

Теперь можно и SSF2 маппер проверить.

Я как-то давно проверял возможность собирать жирные ромы - запихнул туда целую песню в максимальном по возможности качестве - работало) ну и специально асм вставки делал после 4мб - тоже пахало но с моими познаниями о мапперах - наверно, я чего-то недопонял)

Werton, потом будет layer_b/a))

[Segaman]

вот смотрю на такие строчки кода и понимаю, почему в SGDK так все плохо.


вот список моих выводов после выяснения причин, почему моя игра вылетала на старом железе без веской причины:

• по дефолту выключена приостановка z80 во время операций DMA, что тут же открывает двери вылетам на первых моделях мегадрайва в рандомных местах
• стэфан (автор сгдк) на полном серьёзе преподносит эту "фичу", как костыль для ваших там Tectoy-eв, и по дефолту выключает ее заненадобностью, обрекая всех разрабов на проблемы с работой их игр на первых моделях мегадрайва

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

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

вот еще масла в огонь.

установка фрейма анимации не обнуляла таймер в версии сгдк 2018го года.
а вот что я вижу в последней версии. совпадение?

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

еще обмолвлюсь, что порт Switchblade начал делать не я, а какой то вафел Z Team и вот в каком виде этот монстр предстал передо мной:

а вот для сравнения то что сделал с этим я с моим другом VLD (тестер и музыкант):

так вот я был вынужден работать на SGDK и на тот момент я и так не был его фанатом.
теперь же когда игра доделана, а все пуканы сожжены, я написал свое двигло, которое использует C++17. вот демка того, что уже есть:

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

[Sharpnull]

стэфан (автор сгдк) на полном серьёзе преподносит эту "фичу", как костыль для ваших там Tectoy-eв, и по дефолту выключает ее заненадобностью, обрекая всех разрабов на проблемы с работой их игр на первых моделях мегадрайва

Обычно о таком нужно автору писать, нельзя всего знать, но судя по:

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

/**
 *  \brief
 *      Set it to 1 if you want to force Z80 halt during IO port (controller) accesses.<br>
 *      Some Megadrive models (as some MD2) need it to prevent some possible Z80 corruption bugs
 *      (may happen when Z80 access the main BUS during IO port access from 68K).
 */
#define HALT_Z80_ON_IO      0Он знал о проблемах (на официальной MD2, как я понял) и всё равно оставил выключенным. Странно.
Конечно для серьёзного SDK нужна тщательная проверка на разных устройствах. Совместимость должна быть макс. по умолчанию, как мне тоже кажется.
Плюс в SGDK и вообще известных продуктов, что там лучше поддержка и т. п.

я написал свое двигло, которое использует C++17

Будет закрытым? Какой оверхед?

[Werton]

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

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

теперь же когда игра доделана, а все пуканы сожжены, я написал свое двигло, которое использует C++17. вот демка того, что уже есть:

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

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

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

[Segaman]

Ну и справедливости ради, до этого, не слышал, про подобные проблемы у других релизов на sgdk.

недавно приобрел Md JAP NTSC Model 1.
игры работают отлично, а Xeno Crisis артефачит и вылетает.

[Takamura-kun]

я написал свое двигло, которое использует C++17

Главное - поддерживать актуальность стандартов и версий А то стеф долго сидел на одной и той же GCC 3.4.6, пока не понял, что чем новее версия, тем лучше генерация кода (отрицал это до последнего ) однауко gcc уже далеко ушел с момента обновления компилятора в sgdk, версия 9.3 с Марта доступна...