| Разработка и ромхакинг > Ромхакинг и программирование |
| SGDK |
| << < (24/40) > >> |
| MetalliC:
--- Цитата: Sharpnull от 26 Март 2019, 13:46:56 ---С++ медленнее чем C по определению, даже с отключением всяких фишек. --- Конец цитаты --- --- Цитата: worm от 26 Март 2019, 14:53:52 ---выполняться медленнее, а сам код будет генериться максимально убогим образом. --- Конец цитаты --- кто вам таких глупостей понарассказывал ? лет 20 с лишним назад - да, было дело, но уже много лет как это не так. более того, при использовании C++ного или C++11 STL частенько генерится более эффективный код чем при использовании C-шного подхода. а если есть сомнения всегда можно сходить на https://godbolt.org/ и посмотреть что получается на выхлопе тех или иных компиляторов. |
| worm:
MetalliC, это я не различных форумах поначитался :blush: спасибо за сайт - такому любителю покопаться в коде как я это просто находка) Жаль, что поддержки MC68000 нет |
| m4x1k:
Ответ самого разработчика такой был: --- Цитата ---SGDK does not support C++ as it requires more binaries and libraries to get it work (actually a lot more). I always wanted to maintain SGDK size to the strict minimum requirement, also C++ add some overhead which might hurt for megadrive development... Still i agree it would be nice to have C++ (and so OO programming) support, that may be something to thing about... I believe Chilly Willy already got C++ support on with 68k targeted gcc and he reported overhead was not that heavy. Problem is that i really want to stay on gcc 3.4.6 for SGDK as newers version are really awful in term of code generation for 68k target. --- Конец цитаты --- Я сам всю жизнь C++ изучал, никаких проблем с SGDK пока не встретил. Скажите, а каким инструментом сейчас удобнее пользоваться для создания карты, который понимает тайлы и карту в Сеговском формате? |
| Sharpnull:
MetalliC, я скорее имел в виду не генерацию, а подходы структурного процедурного программирования и ООП. Хотя да, это утверждение было неверно в любом случае. --- Цитата: m4x1k от 27 Март 2019, 18:49:25 ---Скажите, а каким инструментом сейчас удобнее пользоваться для создания карты, который понимает тайлы и карту в Сеговском формате? --- Конец цитаты --- Можно просто скормить PNG rescomp, он найдёт дубликаты и отражения, я грузил как IMAGE и там уже есть палитра, map data и сами тайлы. Карту нужно в коде грузить в нужный момент, а тайлы обычно грузят сразу все, если памяти хватает. Сам Stef так делает, экспортируя из известного редактора Tiled. Там упоминается ещё специальный редактор Beehive от создателя Tanglewood. -------- У способа с IMAGE есть одна проблема, там уровень компрессии задаётся для карты и для тайлов одновременно, а если динамически подгружать карту, то на распаковку уходит память и время, хотя тайлы можно сжать сильно, если грузятся только в начале уровня. В rescomp.txt написано, что MAP не поддерживается, но я не пробовал. Кстати, rescomp теперь зависит от java. |
| m4x1k:
Sharpnull, имелось ввиду именно редактор. Попробую Tiled, спасибо. :) Объясните ещё нубу: вот имеется спрайт на экране, у него фиксированное поле 512х512. Есть ещё 20 спрайтов/npc. Если я скроллю экран и хочу, чтобы двигался только основной персонаж, то мне нужно каждому спрайту npc выравнивать координаты, чтобы он остался на фиксированной точке, всё верно? Или есть иной способ? |
| Sharpnull:
m4x1k, слой спрайтов не скроллится, так что, насколько я знаю, по-другому нельзя. |
| ALKOSHA:
Уговаривал стеффа давно ещё замутить ф-цию зеркалирования изображения. А он такой типа "зачем?, оно же всё равно компилятором ресов распознаёт зеркальные участки". Но рассмотрим случай, если мне пикчу фона в анимации надо забадяжить, или в каких-то сценах в одном виде, в каких-то - в зеркальном виде. То это прогонять через компилятор оба варианта пикчи, это будут две уникальные пикчи. Конечно можно прогонять через тайловый массив, с заданным атрибутом зеркалирования и расположением XY в обратном порядке, но это сложна + куча лишнего велосипедного кода. Кстати, о велосипедах. Дермосценеры щеголяют всякими эффектами. Почему бы не сделать набор ф-ций, и сделать из низкоуровневого СДК высокоуровневый движок. Я вот когда делал эффект palette shifting, заготовил на каждый шифт палитры тайлик, из которого через данные извлекал индексы и присваивал заданной пикче. Но ведь можно было бы процедурно это сделать, но для меня, ламера, сложновато. Почему бы на такие ситуации не собрать набор ф-ций, и не выложить в общий доступ, чтоб любой желающий, не имеющий скилла в прогинге, мог осилить сделать игору ? |
| Sharpnull:
ALKOSHA, про "зеркалирование", имеется в виду полное (или региона) отражение изображения и проблема в доп. памяти из-за дублирования тайлов? Я бы не сказал, что прям много кода. Перетасовать map data и вызвать ту же VDP_setTileMapData*(). Вам кажется что это всем нужно, а ему это поддерживать. Можно ещё просто отразить изображение рядом в той же картинке, только наверно это будет неудобно и какие-нибудь ограничения вылезут. --- Цитата: ALKOSHA от 28 Март 2019, 14:09:13 ---Почему бы на такие ситуации не собрать набор ф-ций, и не выложить в общий доступ, чтоб любой желающий, не имеющий скилла в прогинге, мог осилить сделать игору ? --- Конец цитаты --- Наверно просто нет желающих. Высокоуровневый движок для NES на кикстартере же был. Инструмент для создания текстовых квестов для MD есть, потому что это просто реализовать. |
| m4x1k:
Sharpnull, понял, спасибо. А как можно реализовать динамическую подгрузку карты? Есть, к примеру, карта 128/128. План выставлен как 64/32. Карта грузится сразу целой (128/128) и постепенно смещается, или нужно разбивать карту на несколько отрезков (по 32/32) и загружать целиком каждый раз? Как это происходит в SGDK? Есть ли пример со скроллингом и подгрузкой у кого-нибудь? |
| Sharpnull:
m4x1k, ручками нужно делать, как в оригинальном Sonic, например. Никакой поддержки от SGDK. Видел объяснения несколько раз с картинками (это не специфично только для SGDK), суть в перезаписи столбцов/строк перед камерой. В Sonic записываются толщиной 2 тайла (16 пикселей), наверно для эффективности. На картинке зелёная область - экран, по центру - то, что было позади. Я смотрел когда-то этот пример: Scrolling Map Demo (github), но что-то там было криво сделано, наверно обращение за пределы памяти, что видно в Plane Explorer/Viewer эмулятора. Кроме того, там тайлы/карта/палитры заданы в коде. Я делал загрузку прямо из Image (png), но для эффективности приходилось убирать сжатие, что увеличивало размеры рома. Как уже выше писал, к сожалению не знаю как просто сжимать только тайлы, без карты. |
| m4x1k:
--- Цитата: Sharpnull от 29 Март 2019, 12:41:03 ---m4x1k, ручками нужно делать, как в оригинальном Sonic, например. Никакой поддержки от SGDK. Видел объяснения несколько раз с картинками (это не специфично только для SGDK), суть в перезаписи столбцов/строк перед камерой. В Sonic записываются толщиной 2 тайла (16 пикселей), наверно для эффективности. На картинке зелёная область - экран, по центру - то, что было позади. (Ссылка на вложение) Я смотрел когда-то этот пример: Scrolling Map Demo (github), но что-то там было криво сделано, наверно обращение за пределы памяти, что видно в Plane Explorer/Viewer эмулятора. Кроме того, там тайлы/карта/палитры заданы в коде. Я делал загрузку прямо из Image (png), но для эффективности приходилось убирать сжатие, что увеличивало размеры рома. Как уже выше писал, к сожалению не знаю как просто сжимать только тайлы, без карты. --- Конец цитаты --- Спасибо большое. С сжатием, да, не ясно, почему карты RESCOMP до сих пор не поддерживает. Ни отдельно не загрузить, ни сжатие произвольно не выставить. |
| ALKOSHA:
Сжатие SGDK больше годится для скроллов, а-ля, зельда. Выставил 256*224 экран, плэйны 512*512. Загрузил на него одну пикчу: как только герой выходит за пределы, с оффсетом 256 выплёскивать другую пикчу, а после - скроллить. И то, получается, что каждая пикча уникальна для кода, тогда как обе они могут содержать одинаковый набор тайлов. В общем, шляпнеко. Экономнее процедурно в цикле грузить отдельные пикчи, нарезанные на тайлы. |
| Segaman:
короче чо вы думаете компиль сделал первым делом увидев мой код? оптимизация просто сумасшедшая, компиль буквально меня за идиота считает и трёт больше половины моего кода, так как результат его выполнения един :cool: а SGDK-шный компиль чот так не могёт и неделает :lol: надеюсь время будет доработать ето всё до рабочей версии, ибо такого уровня оптимизация просто необходима я считаю. кстати это подтвердило мнение о том, что современная оптимизация С++ вполне может утереть нос старенькому Си |
| worm:
--- Цитата: Segaman от 14 Апрель 2019, 01:01:16 ---это подтвердило мнение о том, что современная оптимизация С++ вполне может утереть нос старенькому Си --- Конец цитаты --- Ты это Стефу покажи, вступи в команду разрабов sgdk, такие люди там нужны, судя по тому, какие у них тулзы. |
| ALKOSHA:
Вот бы кто подружил его с TMX-картами размером более 512*512 (1024*256)... да коллизией по ним, хотя бы на уровне супер Марево броуз... |
| Segaman:
worm, тулзы у них и правда боль, но я буду думать над вступлением. я вообще недумаю в публику выкладывать наработки :) |
| worm:
--- Цитата: Segaman от 15 Апрель 2019, 10:19:15 ---я вообще недумаю в публику выкладывать наработки --- Конец цитаты --- это дело сугубо твое личное и ты имеешь на это полное право, но если ты что-то делаешь для себя, почему бы не пустить это на благо общества? Торвальдс тоже не сразу ядро открыл, однако только благодаря этому решению ты сейчас используешь Linux (как и этот самый компилятор, как и раньше использовал крякнутую винду с крякнутыми прогами), а если бы каждый делал только для себя, каким бы был мир?) Сам же говорил - будущее за открытым ПО, но это будущее может и не настать из-за дефицита адекватного открытого ПО, а дефицит из-за чего? Из-за тех, кто жлобит свои наработки. Не будь одним из них - ты ведь не такой. |
| MetalliC:
чо за скулеж ? во всех этих хоумбрюшных SDK, для мегадрайвов, гейкубов и прочих дримкастов, используется обычный GCC. не устраивает оптимизация более старых версий компилятора ? -> возьмите более новую. вот только не факт что они будут генерить более лучший код для антикварных моторол, или старых поверписей, говорят не редко бывает и наоборот, потому что на них все давно забили. |
| MetalliC:
--- Цитата: worm от 15 Апрель 2019, 12:19:25 ---будущее за открытым ПО, но это будущее может и не настать из-за дефицита адекватного открытого ПО --- Конец цитаты --- Free and Open Source Software (FOSS) это бизнес, который целиком и полностью существует за счет платной поддержки продуктов. ну то есть, разработчики $материально$ заинтересованы чтоб этот весь софт был глючным, или в нём не хватало каких-то фич, и пользователи вынуждены были искать девелоперов которые бы исправили или доделали интересующие их программы. я надеюсь всем понятно какой вот это всё ^^^ оказывает эффект на качество и юзабельность ПО, и почему имеет место быть напряг с нормальным открытым ПО ? |
| worm:
--- Цитата: MetalliC от 15 Апрель 2019, 14:20:00 ---разработчики $материально$ заинтересованы чтоб этот весь софт был глючным --- Конец цитаты --- но ведь это ложь) многое среди открытого ПО если не превосходит платные аналоги, то уж точно не хуже - тот же qbittorrent vs utorrent, blender vs 3ds max, notepad++ vs edit pad pro и тд. Кроме того, если foss - это сплошные глюки, где тогда скачать исходники глючных релизов десятого шындовса? --- Цитата: MetalliC от 15 Апрель 2019, 14:20:00 ---я надеюсь всем понятно какой вот это всё ^^^ оказывает эффект на качество и юзабельность ПО, и почему имеет место быть напряг с нормальным открытым ПО ? --- Конец цитаты --- напряг заключается в дефиците качественного открытого ПО, а не в его глючности. Разумеется, поделки школьников не в счет - это всего лишь побочный эффект доступности инструментария для всех желающих. --- Цитата: MetalliC от 15 Апрель 2019, 14:13:53 ---чо за скулеж ? --- Конец цитаты --- Ну зачем грубить и оффтопить? Я, конечно, понимаю, что здесь выстроена иерархия по степени дартаньянности, но давайте общаться культурно и по теме) |
| Навигация |
| Главная страница сообщений |
| Следующая страница |
| Предыдущая страница |