SGDK

[Dragon]

Скажите, пожалуйста, кому-нибудь уже удалось написать что-то стоящее с помощью SGDK? Всё-таки это С++, не лучше ли писать сразу на ассемблере? Я понимаю, что С++ гораздо доступнее, но все же

[Sharpnull]

кому-нибудь уже удалось написать что-то стоящее с помощью SGDK?

Да.

Всё-таки это С++

Это C (Си).

Я понимаю, что С++ гораздо доступнее, но все же

А вот и ответ.

[Takamura-kun]

А вот и ответ.

да и + оптимизация в наше время у компиляторов — будь здоров, не то что раньше) программируя на асме в этом плане сейчас не сильно выиграешь, а вот времени и сил потратишь прилично)
Поэтому асм хорош для хацкинга, а C/C++ для геймдева.

На NES вон вообще на питоне хреначить можно...

[Dragon]

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

[Takamura-kun]

Dragon, ну вот игра намечается)

[MaxWay]

Привет. Прошу помощи. Программа CodeBlocks20.03 и SGDK1.51, нажимаю Build и выходи такая ошибка src\boot\rom_head.c  fatal error: genesis.h: No such file or directory. И когда новый проект создаешь или загружаешь готовый все равно та же ошибка.

[Sharpnull]

MaxWay, переменных среды не хватает, чтобы находить, про установку для Windows здесь: https://github.com/Stephane-D/SGDK/wiki/SGDK-Installation

[Segaman]

Dragon,
мой порт Switchblade на Sega Mega Drive

Официальный геймплей

Полное прохождение во время разработки на стриме

Популярная нынче Xeno Crisis

Порт интересной индюшатины Cave Story

[Lunar Laser]

Ещё ламерский вопрос. Си какого стандарта используют при разработке на Mega Drive?

Поддерживается новый стандарт языка, или скачать для начала какую-нибудь книжку начала 90-ых про какой-нибудь Turbo C и стандарт в духе C89 - и по ней учиться?

[Segaman]

Lunar Laser, читать книжки про язык программирования на котором пишешь?


Вообще забавно: Я целую игру написал на SGDK, а каким стандартом языка С пользовался при написании - понятия не имею. В какой век живём. Век самоучек и трайхардеров 



Судя по версии, компиль должен понимать все существующие стандарты.
По памяти это: C89, C90, C95, C99, C11

[Takamura-kun]

Ну что, вот и 1.6 вышла) прям как CS теперь
Главная особенность - багофикс хэндлера вертикальных прерываний, который переехал в SYS_doVBlankProcess() во избежание потенциальных багов из-за забытых включений/отключений.

[ALKOSHA]

Как средствами СДК выжать резолюцию 320х448 ?

[SPOT]

Как средствами СДК выжать резолюцию 320х448 ?

Присоединяюсь к вопросу.

[Segaman]

я бы не стал:
1) это разрешение понимают только телевизоры. захватить его с консоли будет нельзя
2) графен переключается в какой-то хитрый режим. кажется тайлы становятся вдвое выше. т.е. 8*16 вместо 8*8
3) в доке по сеге об этом режиме написано ничтожно мало
4) никогда не видел этот режим где-то кроме второго соника. в СГДК этот режим скорее всего обойдён стороной
5) время потраченное на изучение этого режима можно более эффективно потратить на разработку в обычном разрешении

[ALKOSHA]

никогда не видел этот режим где-то кроме второго соника.

Ещë в combat cars при игре на двоих, если мне память не изменяет.

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

Наверное, и режим этот на самом деле никакой не режим, а всë те же программные трюки с HBlank + Scroll по прерыванию H_Int. Но это лишь догадки.

[Werton]

зарелизена версия 1.62
вот что автор отмечает

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

-Easier SGDK usage (not anymore requiring PATH patching nor using GDK env var)
-A nice optimization on sprite resource.
Before associated metadata (sprite size, frame info..) could take quite a bit of space (~15% of the total resource size) which has been reduced to about a quarter of that (less than 5% of total size).
-Even easier bank switching mechanism (do not require anymore data alignment and spending time with the symbol file for that).
-Several new samples (h-int effects for instance).
еще из заметного, максимальный размер спрайта вырос до 248 пикселей, максимальный  размер рома до 12 MB, из-за оптимизации спрайта, также частично изменилась его структура.

[Takamura-kun]

зарелизена версия 1.62

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

Товарищи модеры, может переименуем таки тему в просто "SGDK" наконец?) Тема настройки давно себя исчерпала и общение перешло на глобальную тему)

[mr287cc]

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

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

[bolon667]

Здравствуйте. Скажите пожалуйста, как реализовать в SGDK, коллизию между спрайтом и тайлами? 

[Sharpnull]

bolon667, также как и везде. У спрайта не может быть коллизий, это графика (если не учитывать VDP sprite collision flag). Для движущегося объекта задать структуру описывающую размеры (несколько прямоугольников, например), хранить уровень в сетке (двумерный массив). Перед движением получить будущие координаты объекта, разделить на 8 (или 16 в зависимости от размера блоков уровня), чтобы получить индекс в сетки уровня и проверить можно ли двигаться. Придётся считать для нескольких точек. В зависимости от ситуации и оптимизацией есть варианты.
В самом SGDK нет возможностей для расчёта коллизий, кроме структур BoxCollision, CircleCollision, Collision в sprite_eng.h.
Можете поискать примеры кода на SGDK, спокойно найдёте реализацию.

[rep-stosw]

Попробовал этот SGDK в действии. В целом неплох, но есть несколько замечаний с практической точки зрения:

1) Нельзя задавать разную задержку между кадрами в разных анимационных циклах: к примеру тот же Соник - в WAIT у него 2 кадра, в RUN - 6 кадров.  В итоге либо RUN медленный, либо WAIT слишком быстрый:



А хочется каждый анимационный цикл со своей задержкой...

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

К примеру нужна анимация: 0,1,2,3,4,3,2,1...  Это требует вставки дублей фреймов - 1,2,3. В то время как "двунаправленная" анимация  потребует на 3 фрейма меньше

3) Нельзя сделать переходные анимации по двум направлениям. К примеру: одновременно приседание + вскидывание руки с оружием.  Здесь уже задействованы разные фреймы по двум направлениям.

4) Проблемы с потерей цветов.

Исходный файл 4 бита на точку - 16 цветов.  Палитра 8 бит на компоненту.  Из-за ограничений сеги, палитра должна приводиться  в 3 бита на компоненту.

SGDK неправильно  это делает.  Он просто делит каждую компоненту на 32( сдвиг вправо на 5) , а затем  сдвиг влево на 5 (умножает на 32).  В итоге часть цветов приводятся к одному и происxодит потеря цвета.

Например - два оттенка зелёного цвета:

17,68,1  и  26,92,4  - SGDK сконвертит в одинаковые: 0,64,0

А должно быть:

32,64,0  и  32,96,0

тоесть - не откидывать дробную часть, а арифметически округлять.

Придётся допиливать самостоятельно и очень многое...

[Sharpnull]

Придётся допиливать самостоятельно и очень многое...

Это не игровой движок, пункты 1), 2), 3) не обязаны быть, возможности анимации сделаны "чтобы было", нет смысла улучшать, потому что разные требования у разных игр. Можно было бы много всего добавить для удобства.

4) Проблемы с потерей цветов.

Исходную картинку нужно добавлять уже с кратными значениями, которые вам нужны, и не будет проблем, заодно будете видеть результат сразу. Проблема решается элементарным скриптом.
В любом случае, когда делается игра хорошо и нужно использовать цвета по максимуму, то используется одна палитра сразу для нескольких объектов, значит объекты рисуются исходя из общей конечной палитры. Это уже исключает бездумное добавление картинки без подготовленной палитры.

А должно быть:

32,64,0  и  32,96,0

тоесть - не откидывать дробную часть, а арифметически округлять.

Нет, не должно. Не знаю что такое "арифметически округлять", а "откидывать дробную часть" - это округление к меньшему. Кому как нравится.

[rep-stosw]

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

А как быть, если нужно сделать порт с игры ПК на сегу?

Допустим, есть спрайтовый атлас, но там RGB 8:8:8  .   Стоит задача эффективно конвертнуть в 16 цветов с минимальной потерей качества.  Я пока делаю так:  в IrfanView уменьшаю число цветов до 16 и сохраняю в 16-цветный PNG или BMP.   Качество меня не радует.

Есть ли скипт- или способ сделать круче?   Например - как дизеринг  на этой картинке :



Это атлас из Alien Soldier -  на спрайтах виден дизеринг в "шахматную клеточку", который увеличивает качество изображения.   Есть ли программы, превращающие RGB 8:8:8 в такой дизеринг?

В Irfan View дизеринг НЕ подходит, он слишком шумный и без шага настройки.

[Sharpnull]

Стоит задача эффективно конвертнуть в 16 цветов с минимальной потерей качества.

Для Mega Drive нужно 15 цветов, не считая фонового или прозрачности.
Photoshop хорошо уменьшает цвета (вкладка Save fo Web), но это неудобно делать, если много однотипно обрабатывать. Ещё на основе существующей палитры можно подогнать картинку, похожее можно сделать в Python через Pillow (PIL).
Color quantizer (http://x128.ho.ua/color-quantizer.html) - хороший, рядом с кнопкой OK опции, там много вариантов дизеринга. И я не нашёл лучше этой программы для PNG с альфа-прозрачностью, когда у каждого цвета в палитре ещё значение прозрачности (от 0 до 255). Консольный вариант - TruePNG (http://x128.ho.ua/pngutils.html) имеет меньше возможностей и немного другой алгоритм, но тоже хороший для альфа-прозрачности, а через Python это получалось не очень. Картинки с индексированным цветом и альфа-прозрачностью нужны для PS2/PSP, например.
Нужно пробовать другие варианты, где могло улучшиться. Я пробовал когда-то ImageMagick, но что-то не нравилось.
На счёт округления цветов, если делать как вы хотели, то будет неравномерное округление: 0-15 -> 0 (16 значений), 16-47 -> 32 (32 значения), ..., 208-255 -> 224 (48 значений).

[Ti_]

А должно быть:
32,64,0  и  32,96,0

Уже неправильно. Цвета должны быть: 0,36,72, .. с шагом в 36. Такие выдаёт большая часть эмуляторов.
А если под железо делать там тем более другие цвета, из эмулей их выдаёт например blastem.

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

Есть ли скипт- или способ сделать круче? 

Можешь попробовать RetroGraphicsToolkit, там есть на выбор несколько алгоритмов дизеринга и уменьшения цветов. Только сама программа крайне неудобная, сложно разобраться.

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

Есть ли скипт- или способ сделать круче?   Например - как дизеринг  на этой картинке :

Что сделать? Ты выложи для начала исходную картинку и что у тебя получилось.

[Ogr]

Допустим, есть спрайтовый атлас, но там RGB 8:8:8  .   Стоит задача эффективно конвертнуть в 16 цветов с минимальной потерей качества.  Я пока делаю так:  в IrfanView уменьшаю число цветов до 16 и сохраняю в 16-цветный PNG или BMP.   Качество меня не радует.

А нужно еще при сохранении использовать сеговскую палитру, Которая состоит всего из 512 цветов:

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

[Werton]

Нельзя задавать разную задержку между кадрами в разных анимационных циклах...А хочется каждый анимационный цикл со своей задержкой...

Нет же, хочется отдельную задержку на каждый кадр, но не очень, т.к. делается это просто

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

К примеру нужна анимация: 0,1,2,3,4,3,2,1...  Это требует вставки дублей фреймов - 1,2,3. В то время как "двунаправленная" анимация  потребует на 3 фрейма меньше

rescomp выкидывает дублирующие кадры из конечных ресурсов, так что от дублей ром жирнее не станет.

[ALKOSHA]

Есть же тулза, через которую можно регулировать исходную палитру.
Genesis Optimizer : Pals
http://gendev.spritesmind.net/page-tools.html

Радует, что наконец-то добавили нативную поддержку фонов более физических размеров плейна.
Но карту коллизий всё равно надо велосипедить.

а у VDP нет ли часом аппаратной проверки оверлапа спрайта с конкретным тайлом?
Даже у Атари2600 было подобное (консоль затачивалась чисто под понг).

[rep-stosw]

Color quantizer (http://x128.ho.ua/color-quantizer.html) - хороший, рядом с кнопкой OK опции, там много вариантов дизеринга.

Спасибо, программа действительно конвертит в 16 цветов лучше, чем IrfanView.

А нужно еще при сохранении использовать сеговскую палитру, Которая состоит всего из 512 цветов

Использую палитру Sega Genesis.pal : https://gendev.spritesmind.net/forum/viewtopic.php?t=3192

rescomp выкидывает дублирующие кадры из конечных ресурсов, так что от дублей ром жирнее не станет.

Это очень хорошо! 

Нет же, хочется отдельную задержку на каждый кадр, но не очень, т.к. делается это просто

Как это сделать средствами SGDK ?

Пока приходят в голову 2 идеи:

1) Распилить атлас на отдельныве анимации и задать им разное время.
2) Сделать самостоятельно процедуры анимации - с нужными задержками и переходами между фреймами в одном большом атласе.

Что сделать? Ты выложи для начала исходную картинку и что у тебя получилось.

На ТВ изображение теряет деталицацию:  не видно лица девушки, костюм сливается в один цвет.

Исходный фрагмент атласа (RGB 8:8:8):



Сконверченный в 16 цветов:



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





Есть ли какие-нибудь правила, которыми руководствуются художники при рисовании спрайтов для экрана ТВ (ЭЛТ) ?

Вот, набросал небольшой полигон для испытаний:



Ещё на счёт коллизий не совсем понятно.   Можно ли сделать коллизию с точностью до пиксела?  Или только на сетку, которая кратна 8 ?  Сейчас получается - нога слева может висеть в воздухе (расстояние менее 8), нога справа - нормально.

[ALKOSHA]

Есть ли какие-нибудь правила, которыми руководствуются художники при рисовании спрайтов для экрана ТВ (ЭЛТ) ?

В древности пиксель-артисты сразу видели результат прямо на своём ЭЛТ экране.
Щас лучше рисовать с учётом того, как видно на ЖК. ЭЛТхи вымирают.
А тобло у твоей бабы плохо видно просто из-за того, что оно 4х4 пикселя.
Тут не то что на ЭЛТ, на ЖК особо не разберёшь, если не вглядываться. Не нравится такой расклад - делай гидроцефала чиби-онимэ, либо делай с естественными пропорциями, но крупный спрайт.
Вообще редко у кого в 2д платформерах с ОТНОСИТЕЛЬНО естественными пропорциями были различимы физиономии. Вспомни контру хард корпс, или же кастлу симфонию ночи  (шо то, шо это одинаково красиво на ЖК и ЭЛТ, но при этом рож не разглядеть) .
Под суб-пиксели ты всё равно не подстроишься, так как у тебя спрайт подвижен. Да и это было более актуально для CGA composite.

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

  - у лисы видны глаза, уши

Потому что оно более онимушное (лупоглазое), чем твоя бабца.
 Ваш кэп.


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

Сейчас получается - нога слева может висеть в воздухе (расстояние менее 8), нога справа - нормально.

Разве нельзя сделать проверку с оффсетом, и в зависимости от этого поменать кадр позы , будто стоит на краю обрыва?
Ладно. Ну допустим, есть у тебя per-pixel колижн, дальше что?)
Бабца всё равно на раскорячку стоит. То есть энивей нужен кадр другой стойки. Или придумать что-то с левел-дизайном, как в том же варлоке: чтоб особо не париться со стойкой на наклонных поверхностях,сделали foreground, закрывающий ноги.

Добавлено позже:
 проверка коллизий откуда-то из примеров взята, или же свой велосипед?

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

костюм сливается в один цвет

Ещё бы он не сливался. Синий и зелёный находятся по соседству друг с другом  в спектре.


Читни теорию  цвета,пагугли  цветовые круги
Вообще, твоей тйолке не хватает объёму. Пропорции ещё более-менее сносные. Но вот шейдинг хромает. И светотень, это не просто изменение яркости одного и того же цвета. Тут меняются все три компоненты HSL
Сега своими цветовыми ограничениями наставляет тебя на путь истинный (это на снес криворукие никогда не исправлялись, и делали мыльно-пластиновое убожество), а сежка - самое то для закалки художественного скилла.