Помощь новичку в программировании под дрим.

[Ivan Guber]

(08.01.2020 14:13)111 писал(а):  Ivan GR, с какой целью этим всем интересуешься? И да, даже если просто любопытство, то про KGL\GLdc можешь сразу забыть, ничего толкового с ними не сделаешь.

Кстати, если надо:
https://dcemulation.org/phpBB/viewtopic....2#p1057292

С целью портирования игр на дрим.

(08.01.2020 02:11)megavolt85 писал(а):  Ivan GR

Код:

File format is ELF, start address is 0x8c008300
Section IP, lma 0x8c008000, size 32768

твой пример собран под адрес 0x8c008300, это адрес IP.BIN отсюда и проблемы, там уже сидит dc-load

Как тогда elf запускать на дриме?

[megavolt85]

(08.01.2020 14:13)111 писал(а):  Да даже за бесплатно не все так однозначно, ведь до сих пор водятся сектанты, запрещающие выкладывать публично все, что "нелегально" (т.е. сделанное "краденым" софтом).

SEGA любит своих фанатов и палки в колёса им не ставит, чего только стоило офф разрешение выложить fish life amazon, редкая компания на такое пойдёт

(08.01.2020 14:13)111 писал(а):  скажем так, хуже, но не катастрофически. Один нюанс только: нормальную скорость без asm'а не получить никак.

ну новичку будет не реально освоить костыли на самом старте

(08.01.2020 14:13)111 писал(а):  а вот swat как рази-таки топил за кос именно из-за новых компиляторов

новые компиляторы это просто жесть, собираешь код и охреневаешь от кучи багов, откатываешься на старый и всё работает
при этом можешь открыть любую из свежих игр на KOS в дизасемблере и сразу увидишь кучу свободного места, все функции на кой то фиг выровнены под 32 байта, тоже самое на старых SDK KATANA
но и это не всё, смотришь на функцию и понимаешь что ты можешь её оптимизировать сэкономив при этом не мало места
открываешь что либо из последних KATANA игр в надежде приткнуть свой код для widescreen патча и молишься чтоб в бинарике не вырезали отладочный текст, потому что это единственное место куда можно приткнуть свой код

[111]

(08.01.2020 14:42)Ivan GR писал(а):  Как тогда elf запускать на дриме?

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

(08.01.2020 14:42)Ivan GR писал(а):  С целью портирования игр на дрим.

ну тут только остается пожелать удачи. Только учти, что кос недоделанный, и если какая-то проблема возникнет, то придется тебе самому все решать.
Один из моих случаев:
https://dcemulation.org/phpBB/viewtopic....9&t=104365
и это еще не самое худшее, что бывало. Иногда вообще без видимых причин может не работать
https://dcemulation.org/phpBB/viewtopic....1#p1054694
и т.д. и т.п.

(08.01.2020 15:25)megavolt85 писал(а):  SEGA любит своих фанатов и палки в колёса им не ставит, чего только стоило офф разрешение выложить fish life amazon, редкая компания на такое пойдёт

ну я-то в курсе про это все, но попробуй это объясни сектантам, для которых не то, что биос, а даже syscalls.bin (дамп памяти с 0x8c000000 по 0x8c008000) тоже "нелегальный" (мне пришлось дампить это с памяти эмулятора т.к. публично нигде не нашлось (вместо помощи за такие просьбы поливают говном и клеймят "пиратом")).

Да, есть немало адекватных людей, которым главное, чтобы просто хорошая игра была, но их не большинство, а упомянутые сектанты смешают тебя с нечистотами и сделают жесткий антипиар. Опять же, есть теоретический мизерный шанс получить C&D от сеги (как, например, в случае streets of rage remake), а работать за идею, как видишь, за последние 20 лет так никто и не захотел (не считая редких поделок на wince).

Как вариант только если методом китайцев это все продавать потом. Была еще идея каким-нибудь обфускатором обработать elf\bin (ну или, в крайнем случае, руками), чтобы затереть (текстовые) отсылки к lib'ам катаны.
Хз в общем. Если б был "честный" способ использовать сдк, то хрен бы я когда полез в этот кос. Если есть идеи на этот счет, то я внимательно слушаю.

(08.01.2020 15:25)megavolt85 писал(а):  ну новичку будет не реально освоить костыли на самом старте

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

(08.01.2020 15:25)megavolt85 писал(а):  новые компиляторы это просто жесть, собираешь код и охреневаешь от кучи багов, откатываешься на старый и всё работает
при этом можешь открыть любую из свежих игр на KOS в дизасемблере и сразу увидишь кучу свободного места, все функции на кой то фиг выровнены под 32 байта

ну тут да, без комментариев. Бесит вдвойне, когда причиной проблем оказывается gcc, ломающий код даже на -О1.
Про 32 байта - есть там атрибут такой:

Код:

__attribute__((aligned(32)))

который везде настоятельный рекомендуется использовать (без него, по утверждениям, либо не будет работать как надо, либо будет тормозить и т.д.). Правильно это или нет утверждать не берусь, ибо не разбираюсь.

[megavolt85]

(08.01.2020 20:04)111 писал(а):  вместо помощи за такие просьбы поливают говном и клеймят "пиратом"

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

(08.01.2020 20:04)111 писал(а):  Как вариант только если методом китайцев это все продавать потом. Была еще идея каким-нибудь обфускатором обработать elf\bin (ну или, в крайнем случае, руками), чтобы затереть (текстовые) отсылки к lib'ам катаны.

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

(08.01.2020 20:04)111 писал(а):  Про 32 байта - есть там атрибут такой:

Код:

__attribute__((aligned(32)))

который везде настоятельный рекомендуется использовать (без него, по утверждениям, либо не будет работать как надо, либо будет тормозить и т.д.). Правильно это или нет утверждать не берусь, ибо не разбираюсь.

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

P.S. по сисколам то всё нашёл что искал?

[111]

(09.01.2020 16:23)megavolt85 писал(а):  я как правило говорю что да, я пират и горжусь этим

ну было бы странно, наверное, поддерживать пиратство (мне пох), но при
этом самому что-то продавать.

(09.01.2020 16:23)megavolt85 писал(а):  вообще на dcemulation тот ещё контингент, все правильные до безобразия, постоянно твердят про отцов основателей KOS и при этом закрывают глаза на то каким образом была получена инфа для написания той же KOS

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

(09.01.2020 16:23)megavolt85 писал(а):  вон народ не гнушается продажей дисков со свежими переводами японских игр на инглишь, при том что сами ни для создания игры ни для перевода не сделали ровным счётом ничего, и продают же, ни кого не смущает что это пиратка

например какие и где? Не помню, чтобы где-то обсуждалось подобное.

(09.01.2020 16:23)megavolt85 писал(а):  ну а кучка идиотов поднявших вонь о лицензионности только подбавят пиара, так что ты зря волнуешься на этот счёт

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

(09.01.2020 16:23)megavolt85 писал(а):  выравнивание без условно нужно, но пихать его где попало это верх маразма
ну к примеру для чтения mov.w буфер из которого будет читаться должен быть выровнен до одного бита, для mov.l до двух бит, для считывания с пдаваюшей точкой до трёх бит
если буфер используется DMA контроллером, то выравнивать буфер надо до 32-х байт
но выравнивать все функции до 32-х байт это верх маразма

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

(09.01.2020 16:23)megavolt85 писал(а):  P.S. по сисколам то всё нашёл что искал?

так оно лежит в моей сборке nulldc. Пока не забанили, но это, скорее всего, потому, что СинийКраб и адепты в отпуске сейчас. Но я помню, что Metallic'у делали выговор за то, что выложил winpvr или что-то там еще из оф.сдк (естественно удалив все ссылки).

[megavolt85]

(09.01.2020 19:49)111 писал(а):  про контингент очевидно, но другого-то и нет (или есть другие места, где можно поговорить на эти темы?).

на assemblergames обсуждали что угодно и код свободно выкладывали

(09.01.2020 19:49)111 писал(а):  В случае кос утверждается, что все сделано реверс-инженирингом. Или есть что-то, чего я не знаю?

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

(09.01.2020 19:49)111 писал(а):  например какие и где? Не помню, чтобы где-то обсуждалось подобное.

вот например

(09.01.2020 19:49)111 писал(а):  хз, про тот же 4x4 jam долго ходило поверие, что оно сделано официальным сдк ("графон подозрительно хорош"), и немало тех было, кто поддерживал воняющих идиотов (пока не выяснилось, что это был просто слух).

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

(09.01.2020 19:49)111 писал(а):  тогда, скорее всего, это компилятор что-то мутит. Про выравнивание функций (если такое возможно указать препроцессором) слышу впервые.

вот и я о том, эти современные компиляторы приносят больше проблем чем пользы и код который они генерят далёк от идеала
я бы и дальше этого не знал, но весь прошлый год я очень много дизасмил как офф игры, так и homebrew от старых до новых, самый оптимальный код в играх на последнем KATANA SDK

(09.01.2020 19:49)111 писал(а):  Пока не забанили, но это, скорее всего, потому, что СинийКраб и адепты в отпуске сейчас.

после объявления о закрытии assemblergames, |darc| обещал послабление правил на dcemulation, вот и посмотрим

[111]

(09.01.2020 21:41)megavolt85 писал(а):  на assemblergames обсуждали что угодно и код свободно выкладывали

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

(09.01.2020 21:41)megavolt85 писал(а):  ага, и биос реверсили и офф sdk, не гнушались ни какими способами

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

(09.01.2020 21:41)megavolt85 писал(а):  зато сейчас если говоришь что надо исправить функцию потому что я видел что в биосе всё иначе, то краб либо кричит идите в жопу у меня всё прекрасно работает или кричит ню ню, так делать нельзя, отцы основатели были бы против.
я сначала был в афиге от такого подхода, а потом смирился, меняю всё что хочу у себя локально, а на офф ветку мне плевать, я уверен что развиваться она уже не будет,

вроде как последние (минимум) лет 10 только Краб и тащит все это, так что формально кос 2.x можно считать его творением, потому под основателями он, наверное, имеет ввиду себя. С другой стороны, если бы не он, то и валялось бы это все мертвым грузом.

(09.01.2020 21:41)megavolt85 писал(а):  более того в последнем релизе SDL сломан, там большие проблемы со звуком

порт sdl всегда был говном, инфа 100%.

(09.01.2020 21:41)megavolt85 писал(а):  вот например

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

И что насчет маркетинговой составляющей? Где-то же это рекламилось? Или просто молча подобное вбрасывать и ждать, пока кто-то найдет (так себе затея)?

(09.01.2020 21:41)megavolt85 писал(а):  так этот слух не мешал продажам, игру всё равно покупали даже не смотря на то что ей больше подходит название технологическое демо

но информации по продажам вроде как нет публично? Видимо дела шли не очень, раз авторы той игры потом делали кикстартер (внезапно взлетевший).

(09.01.2020 19:49)111 писал(а):  самый оптимальный код в играх на последнем KATANA SDK

понятно. А последний - это R10.1? И как ты определяешь, на какой версии сдк делалось? Это прямым текстом в 1st_read.bin написано, или как-то по частям кода?

(09.01.2020 19:49)111 писал(а):  после объявления о закрытии assemblergames, |darc| обещал послабление правил на dcemulation, вот и посмотрим

https://dcemulation.org/phpBB/viewtopic....51#p946651
ладно, если не будет реакции на то, что я выложил, то будем считать, что получено молчаливое согласие.

[megavolt85]

(10.01.2020 00:06)111 писал(а):  ну тогда если на обскурегамерс правила те же, то может быть свалю туда. Просто особой активности по дримкасту что там, что уже на дохлом ассемблере мною как-то не замечено.

правила те же
а активности по разработке под дрим сейчас нигде нет

(10.01.2020 00:06)111 писал(а):  С другой стороны, если бы не он, то и валялось бы это все мертвым грузом.

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

(10.01.2020 00:06)111 писал(а):  порт sdl всегда был говном, инфа 100%.

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

(10.01.2020 00:06)111 писал(а):  занятно, но пример не самый удачный. Оно же вроде как бесплатно публично выложено?

это коммерческая игра, только за то что человек продаёт самописный диск можно прикрыть и на долго

(10.01.2020 00:06)111 писал(а):  И что насчет маркетинговой составляющей? Где-то же это рекламилось? Или просто молча подобное вбрасывать и ждать, пока кто-то найдет (так себе затея)?

ну я об этом сайте понятия не имел, нашёл рекламу на каком то игровом сайте

(10.01.2020 00:06)111 писал(а):  но информации по продажам вроде как нет публично? Видимо дела шли не очень, раз авторы той игры потом делали кикстартер (внезапно взлетевший).

публично нет, но не с проста они стали дорабатывать свою демку до полноценной игры

(10.01.2020 00:06)111 писал(а):  А последний - это R10.1?

да

(10.01.2020 00:06)111 писал(а):  И как ты определяешь, на какой версии сдк делалось? Это прямым текстом в 1st_read.bin написано, или как-то по частям кода?

да, в бинарике остаются стринги с версиями линкованых библиотек

[SWAT]

Ух, наконец интересный холивар ))
Вставлю и я свое слово по поводу компиляторов.

Да, последние версии на SH4 к сожалению корявые, особенно те что пошли после 5.2. Но я думаю это лишь потому, что на эти процессоры уже все забили по большому счету.
А вот по поводу производительности и оптимизации я не согласен с megavolt85.
Мне кажется что судить по читабельности ассемблера после компилятора неверно, просто потому, что современные компиляторы так хитро расставляют инструкции, чтобы полноценно использовать суперскалярность и кэш. Да, читать такой асм код вообще невозможно порой, но это и не нужно разработчику в большинстве случаев. Этот код читает процессор, а ему хорошо когда инструкции расположены особым образом и этот особый образ совсем не подходит для чтения человеком, для него это абракадарба.
Старые компиляторы вообще ничего не оптимизировали, они практически прямолинейно транслировали Си код в ассемблер и только поэтому читать такой асм легко человеку, потому что он выглядит почти как Си код, который и писал человек.
Я лично пробовал писать асм от руки с учетом суперскалярности и прочих хитростей процессора и поверьте мне, код этот абсолютно не читаем становится с логической точки зрения, его и писать сложно и уж тем более читать тому, кто его первый раз увидел.

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

Выравнивание же под 32 байта в коде нужно для кэша, так как одна линия кэша (обоих типов) равна 32 байтам. И заполнять ее меньше нет никакого смысла, даже если записать туда 8 байт, использоваться будет 32 и в кэше поиск будет осуществляться по адресу начала этих 32 байт.
Да это немного откусывает оперативки, но если тебе важнее она, то собирай с другими оптимизациями, благо их 4 уровня + есть возможность включать и выключать что не нужно доп. флагами.
Если код не сильно громоздкий и не требует уместиться в микроразмер, то такой подход с выравниванием себя оправдывает, потому как оптимальная работа с кэшем значительно повышает производительность всего кода в целом, потому что оперативка очень медленная по сравнению с кэшем процессора. И чем меньше процессор в нее ходит, тем больше есть у него свободного времени на выполнение инструкций, вместо ожидания памяти. Тут главное нужно понимать - процессор значительно быстрее памяти, чем меньше обращений к памяти, тем быстрее работает код. Поэтому читать и писать в память нужно максимальными блоками, которые позволяет шина. А прежде чем работать с блоком данных и/или инструкций, его нужно предварительно поместить в кэш.

Ну и немного о легальности.
Конечно глупо сейчас заявлять что KOS была написана только реверсинжинирингом. Это не правда. Реверс там безусловно есть, но не все на нем основано.
Базовая информация для ядра (а точнее зачаток этого ядра) была взята с сайта Marcus Comstedt, который в свою очередь эту инфу явно где-то раздобыл, мне кажется у него был доступ к материалам о создании консоли, по крайне мере о железе. Скорее всего у него есть друг который к этому был причастен. Явно не он сам причастен, иначе он бы молчал в тряпочку из за подписанных соглашений. Да и Marcus не дурак, открыто не выкладывал всю инфу, оформил кое-что как свое исследование и не выложил ничего критически важного. Так же этот-же друг дал полную инфу и для Rand Linden (или Marcus ему дал), который создал эмулятор Bleem!, без этой инфы создание эмулятора такого уровня в те года было просто невозможным, потому как в отрытом доступе ничего кроме корявый поделок и обрывков инфы небыло. Даже SDK не помогли бы, потому как там нет исходников, а на реверс нужно огромное количество времени. Я не хочу уменьшить тем самым гениальность автора, ни в коем случае, он при любом раскладе крутой.
Плюс ко всему, я могу сходу тыкнуть носом того-же Lawrence Sebald (aka BlueCrab) в то, что он сам подглядывал инфу в официальных источниках (как пример драйвер G1-ATA), а так же он сам ковырял всякие PSO и делал для них патчеры/загрузчики... Айайай пират.
В общем конечно странно наблюдать весь этот легальный буллщит. Консоль и ее технологии уже на столько устарели, что это по сути никому не нужно уже кроме этих же фанатов, которые еще зачем-то кривятся лицом. Тут в пору уже всю эту инфу на памятнике гравировать, а они все пыхтят и боятся что их Sega прижмет.

[111]

@SWAT
тут вопрос еще был немного в другом. В кос абсолютно НЕвозможно сделать нормальное (по быстроте) 3д без (правильного) асма, а оф.сдк это все грамотно скрыто и (в основном) не нужно отвлекаться на всякую ерунду, не связанную с игровой логикой (конечно нужно время на изучение API, но оно хотя бы гарантированно рабочее, в отличии от).

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

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


И да, пока ты здесь: так как, все-таки, собрать CDI с LBA 45000 (для программ из катаны)? Мегавольт говорил, что никак.

[SWAT]

Ну хорошего уровня да, не получится, только мелкие поделки. И дело там не в асме мне кажется, тот асм волшебный уже давно выдернули.
Проблема скорее в корявом и очень обрубленном драйвере для GPU. В KOS много чего нет.

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

Помоему можно CDI собрать под 45000, так не делали лишь для экономии места мне кажется. Хотя я на 100% утверждать не могу, я точно не помню.

[111]

(14.01.2020 11:13)SWAT писал(а):  Ну хорошего уровня да, не получится, только мелкие поделки. И дело там не в асме мне кажется, тот асм волшебный уже давно выдернули.
Проблема скорее в корявом и очень обрубленном драйвере для GPU. В KOS много чего нет.

для отрисовки в кос вполне достаточно сделано. Две главных проблемы:
1) софтварные трансформы (я не знал, что дримкаст в этом плане днище т.е. что нет нормального TnL-юнита (даже в PS1 был GTE, например). Это, на мой взгляд, самый главный "bottleneck").
2) отправление вертексов на gpu

В первом пункте все понятно, т.е. учитывая, что каждый кадр делаются десятки тысяч перемножений, сложений и пр. логично такое писать вручную, а не надеятся на компилятор, например так:
https://dcemulation.org/phpBB/viewtopic....4#p1054104

А вот со вторым пунктом хз что и как делать. Не знаю, возможно ли такое, но нужно как-то не по одному в цикле отправлять каждый вертекс, а пачками за меньшее число раз.
Т.н. "direct render" т.е. макросы для использования "store queue"ов (я хз, че это такое, но не суть), вроде как и отсылают по 32 байта за раз т.е. вертекс целиком (pvr_prim(), предположительно, отправляет по одной переменной т.е. по 4 байта, поэтому и медленней). Может быть для этого и нужно использование DMA, но нигде нет примеров использования и сравнений.

Еще один из примеров:
https://dcemulation.org/phpBB/viewtopic....7#p1034137
но я не вникал, как оно работает.

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

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

(14.01.2020 11:13)SWAT писал(а):  В лоб продавать конечно нельзя такое.
Но мне кажется если скрыть все копирайты в коде, которые слишком красноречиво говорят о том что это KATANA SDK и не говорить об этом на каждом углу, то не думаю что кто-то будет проверять это

выше уже упоминал подобное. Проблема тут в другом - сектанты наверняка спалят т.е. 100% найдется "герой", который решит поковыряться в 1st_read.bin'е и громко разоблачить мерзкого пирата.
Хотя для одноразового срубания бабла (без выкладывания демо-версии) это может и сойти, наверное.

(14.01.2020 11:13)SWAT писал(а):  Помоему можно CDI собрать под 45000, так не делали лишь для экономии места мне кажется. Хотя я на 100% утверждать не могу, я точно не помню.

ну ты говорил, что это зависит от размера трека (т.е. "заполнителя" первой сессии?). Но если не помнишь, то ладно, не сильно это уже и нужно.

[megavolt85]

(14.01.2020 11:13)SWAT писал(а):  Помоему можно CDI собрать под 45000

единственный софт для сборки CDI это cdi4dc, audio/data он собирает под 11702, data/data под 0, так что для сборки с lba 45000 придётся переписать код cdi4dc, готовых решений нет

[SWAT]

(14.01.2020 16:25)megavolt85 писал(а):  

(14.01.2020 11:13)SWAT писал(а):  Помоему можно CDI собрать под 45000

единственный софт для сборки CDI это cdi4dc, audio/data он собирает под 11702, data/data под 0, так что для сборки с lba 45000 придётся переписать код cdi4dc, готовых решений нет

Я имел ввиду возможность самого формата. А то что из коробки это не сделать это да. Но не думаю что сложно поправить cdi4dc, благо есть исходники.

(14.01.2020 15:21)111 писал(а):  

(14.01.2020 11:13)SWAT писал(а):  Ну хорошего уровня да, не получится, только мелкие поделки. И дело там не в асме мне кажется, тот асм волшебный уже давно выдернули.
Проблема скорее в корявом и очень обрубленном драйвере для GPU. В KOS много чего нет.

для отрисовки в кос вполне достаточно сделано. Две главных проблемы:
1) софтварные трансформы (я не знал, что дримкаст в этом плане днище т.е. что нет нормального TnL-юнита (даже в PS1 был GTE, например). Это, на мой взгляд, самый главный "bottleneck").
2) отправление вертексов на gpu

В первом пункте все понятно, т.е. учитывая, что каждый кадр делаются десятки тысяч перемножений, сложений и пр. логично такое писать вручную, а не надеятся на компилятор, например так:
https://dcemulation.org/phpBB/viewtopic....4#p1054104

А вот со вторым пунктом хз что и как делать. Не знаю, возможно ли такое, но нужно как-то не по одному в цикле отправлять каждый вертекс, а пачками за меньшее число раз.
Т.н. "direct render" т.е. макросы для использования "store queue"ов (я хз, че это такое, но не суть), вроде как и отсылают по 32 байта за раз т.е. вертекс целиком (pvr_prim(), предположительно, отправляет по одной переменной т.е. по 4 байта, поэтому и медленней). Может быть для этого и нужно использование DMA, но нигде нет примеров использования и сравнений.

Еще один из примеров:
https://dcemulation.org/phpBB/viewtopic....7#p1034137
но я не вникал, как оно работает.

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

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

Я об этом и говорю, о вертексах и клиппинге в первую очередь, а так же там есть еще всякие sort list для вертексов и прочие штуки завязанные на DMA. Это как раз и не позволяет сделать все по взрослому.
Частично это вроде как реализовано в новом GL драйвере, который писал Фантом, но там есть еще куда расти да и не все там опять же есть и вообще хоршо оптимизировано.
Тот же DMA, на который все завязано, используется в KOS через одно место, отголоски реверс-инжиниринга так сказать. В ASIC есть готовые регистры для всех этих функций, где DMA обоих чипов подружены, но типа знание о них равняется тому что ты пользовался официальными доками. Вот кто мне объяснит чем отличается в этом случае G1 ATA драйвер )) Вот он написан с использованием этих самых регистров в ASIC. Я в свою очередь их использовал еще в эмуляции CDDA для отсылки данных в звук память по DMA, там все очень удобно и просто, в отличии от того, что понаписано в KOS.
Store queue это процессорная штука, что-то между DMA и memcpy так сказать, для копирования во внешнюю память в общем без DMA, но при этом и не грузить проц лишними ожиданиями. Но их нужно грамотно использовать, чтобы получить их приемущество полноценно мне кажется.

(14.01.2020 15:21)111 писал(а):  

(14.01.2020 11:13)SWAT писал(а):  В лоб продавать конечно нельзя такое.
Но мне кажется если скрыть все копирайты в коде, которые слишком красноречиво говорят о том что это KATANA SDK и не говорить об этом на каждом углу, то не думаю что кто-то будет проверять это

выше уже упоминал подобное. Проблема тут в другом - сектанты наверняка спалят т.е. 100% найдется "герой", который решит поковыряться в 1st_read.bin'е и громко разоблачить мерзкого пирата.
Хотя для одноразового срубания бабла (без выкладывания демо-версии) это может и сойти, наверное.

Но будет уже поздно, а правообладатели я сомневаюсь что будут наезжать

(14.01.2020 15:21)111 писал(а):  

(14.01.2020 11:13)SWAT писал(а):  Помоему можно CDI собрать под 45000, так не делали лишь для экономии места мне кажется. Хотя я на 100% утверждать не могу, я точно не помню.

ну ты говорил, что это зависит от размера трека (т.е. "заполнителя" первой сессии?). Но если не помнишь, то ладно, не сильно это уже и нужно.

Ага. Только в случае с GDI там 2 трека.

[111]

(15.01.2020 08:46)SWAT писал(а):  Частично это вроде как реализовано в новом GL драйвере, который писал Фантом, но там есть еще куда расти да и не все там опять же есть и вообще хоршо оптимизировано.

не, там только store queue'ы (я помню, что он где-то когда-то спрашивал про dma, но в итоге пришли в выводу, что толку от него не будет). И куча глюков. И жрет оно 5мб рам. И давно мертво. Свой проект я делал на нем, потому и облом вышел.
Актуальным щас считается GLdc, но оно не намного лучше (по скорости).

(15.01.2020 08:46)SWAT писал(а):  ...DMA...ASIC...
там все очень удобно и просто, в отличии от того, что понаписано в KOS.

вопрос только один: можно ли как-то этим всем пользоваться, не разбираясь, как оно работает?
В случае с store queue'ами все относительно просто (подставляешь что надо в макросы и пользуешься) и мною проверялось,
https://dcemulation.org/phpBB/viewtopic....9&t=105407

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

(14.01.2020 11:13)SWAT писал(а):  Ага. Только в случае с GDI там 2 трека.

вот только и для сборки GDI тоже ничего нет.
лол

[megavolt85]

буквально на днях видел на github какой то инструментарий для сборки GDI

кстати касательно KOS, вот пример ошибки в реверсе на основании которого писалась KOS
http://mc.pp.se/dc/syscalls.html#vecB8

Код:

FLASHROM_READ (r7=1)
Read data from the system flashrom.

Args:

r4 = read start position, in bytes from the start of the flashrom
r5 = pointer to destination buffer
r6 = number of bytes to read
Returns: number of read bytes if successful, -1 if read failed

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

[SWAT]

(15.01.2020 18:19)111 писал(а):  

(15.01.2020 08:46)SWAT писал(а):  Частично это вроде как реализовано в новом GL драйвере, который писал Фантом, но там есть еще куда расти да и не все там опять же есть и вообще хоршо оптимизировано.

не, там только store queue'ы (я помню, что он где-то когда-то спрашивал про dma, но в итоге пришли в выводу, что толку от него не будет). И куча глюков. И жрет оно 5мб рам. И давно мертво. Свой проект я делал на нем, потому и облом вышел.
Актуальным щас считается GLdc, но оно не намного лучше (по скорости).

(15.01.2020 08:46)SWAT писал(а):  ...DMA...ASIC...
там все очень удобно и просто, в отличии от того, что понаписано в KOS.

вопрос только один: можно ли как-то этим всем пользоваться, не разбираясь, как оно работает?
В случае с store queue'ами все относительно просто (подставляешь что надо в макросы и пользуешься) и мною проверялось,
https://dcemulation.org/phpBB/viewtopic....9&t=105407

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

Да SQ в том виде в котором его используют маловато толку дает. Ну да чуть быстрее копирование в память происходит нежели чем туда напрямую процем ходить, но главный недостаток по сути это PIO, который никуда не девается. Проц хоть и простаивает по сути, но этот простой никак не используется. Это создает дополнительный лаг.
В KATANA же, на сколько я знаю, все это работает асинхронно, простои минимизированны. Причем там нет тредов как таковых, там один ивент луп синхронизированный по частоте развертки + прерывания. Хотя в поздних версиях SDK начали треды прикручивать.
Ну а пользоваться этим не разбираясь не получится, только хардкор

(15.01.2020 18:19)111 писал(а):  

(14.01.2020 11:13)SWAT писал(а):  Ага. Только в случае с GDI там 2 трека.

вот только и для сборки GDI тоже ничего нет.
лол

Что-то есть, погугли.

(15.01.2020 22:07)megavolt85 писал(а):  кстати касательно KOS, вот пример ошибки в реверсе на основании которого писалась KOS
http://mc.pp.se/dc/syscalls.html#vecB8

Код:

FLASHROM_READ (r7=1)
Read data from the system flashrom.

Args:

r4 = read start position, in bytes from the start of the flashrom
r5 = pointer to destination buffer
r6 = number of bytes to read
Returns: number of read bytes if successful, -1 if read failed

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

Может в его биосе было именно так ))

[megavolt85]

(16.01.2020 08:35)SWAT писал(а):  Может в его биосе было именно так ))

я разве что только v0.74 не проверил, но что то мне подсказывает что и в нём будет всё тоже самое

[111]

(16.01.2020 08:35)SWAT писал(а):  Ну а пользоваться этим не разбираясь не получится, только хардкор

это печально.

(16.01.2020 08:35)SWAT писал(а):  Что-то есть, погугли.

таки да, внезапно появился GDIBuilder (раньше был только gdrom explorer).

[SWAT]

(16.01.2020 17:10)megavolt85 писал(а):  

(16.01.2020 08:35)SWAT писал(а):  Может в его биосе было именно так ))

я разве что только v0.74 не проверил, но что то мне подсказывает что и в нём будет всё тоже самое

А те что в KATANA SDK лежат смотрел?