В любом месте Паскаль-программы можешь вызывать оператор asm(имя_процедуры), который вызовет процедуру на ассемблере. Процедура пишется после последнего END программы на Паскале. После выполнения asm-овской процедуры управление переходит к следующему оператору Паскаля.
В процедуре на асме можешь творить всё, что угодно, оно без изменения перенесется в файл asm.
Иногда ассемблерный код нужен не в конце программы, которая перевалит за #C000 а например вначале.Сообщение от Andrew771
И как насчет подгрузки текстов для самого паскаля, аля библиотеки процедур, а то всё в одном файле, как-то ...
Андрев771 ведь с самого начала дал понять, что модернизацией СДК заниматься не намерен, если хочется доработок - есть исходник на Делфях.И как насчет подгрузки текстов для самого паскаля, аля библиотеки процедур, а то всё в одном файле, как-то ...
Почему это? Паскаль я периодически дорабатываю, все предложения принимаются и рассматриваются. Это ты с законченными нашими играми перепутал
Для асмовских процедур в файле PRG можешь расставлять любое количество ORG-ов с любыми адресами, в том числе меньше, чем у Паскаль-программы (только тогда рассчитай, чтобы они не заехали на Паскаль). Они все без изменения перенесутся в файл ASM.
Или тебе надо саму Паскаль-программу дробить по разным адресам?
- - - Добавлено - - -
В одном файле PRG удобнее и экономичнее держать Паскаль+Асм, лишнего не подцепишь, а также искать легко
Dart Alver (25.08.2020)
А, ну да, точно про такой костыль не подумал. Но всё же возможность встраивать asm непосредственно в тело паскаля думаю было бы полезно. Даже подозреваю что это не особо сложно сделать, достаточно обработки пары тегов - для начала ассемблерного кода и для окончания. А чтобы не спутать тег окончания с командами для ассемблера лучше заточить его под asm-комент типа ;endasm или похожее.
Об этом не думал, но в принципе достаточно интересная идея. Вообще идеально было бы выделять области памяти которые будут обходить мимо процедуры и данные паскаля, но сомневаюсь что на данный момент это реально.
Не согласен. Дело конечно предпочтений, но когда программа насчитывает хренову кучу процедур, чтобы дотянуться до которых надо перелистать туда-сюда кучу десятков (а то и сотни) строк это уже не легко )) Я бы предпочёл создавать некое количество небольших файлов подключаемых в основную программу в которых легче ориентироваться.
Разбивка на модули нужна. А то на ctrl+F уже мозоли натëр.
Ещë бы добавить флаг выбора рендеринга в виртуальный / реальный экран. Именно не перед компиляцией, а чтоб была такая возможность во время исполнения программы.
+ наличие spr_lib процедур было бы весьма кстати.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Ну это всё ж не костыль. Ты же в файле исходника PRG всё-равно пишешь асмовские процедуры и коды спрайтов, заодно и ORG-и вставляешь.
Команду asm с кодом внутри Паскаля вставлю, я тоже о ней думал, удобно. Можно заодно читать сразу паскалевские переменные (это и сейчас можно), вставляешь знак подчеркивания и заглавными буквами имя переменной или константы (например, если в Паскале задана переменная zx123, то ее можно вызвать в своей процедуре по имени _ZX123).
Это реально, достаточно придумать оператор Паскаля ORG address, который можно вставлять в любом месте Паскаля. Впрочем, можно его вставлять и внутри asm/endasm.
возьму на карандаш
Нет это немного другое, но то о чём я говорил это действительно малореально и чезчур геморно )) Смысл в выделении областей запрещенных для компиляции кодов/переменных паскаля. Т.е. транслятор при достижении адреса начала области ставит переход на адрес за её пределами. Проблема реализации такой фичи в том, что паскаль всего-лишь транслирует коды в ассемблер и если для трансляции паскалевских процедур ещё с грехом пополам можно использовать счетчик использованной памяти, хотя тоже повозится надо, то при ассемблерных вставках (тем более если ассемблер со своими изворотами) всё летит нафиг.
Но ORG-шки для паскаля это тоже очень даже неплохая вещь.
Ну если уж наглеть, то пока Andrew771 карандаш не положил )) Мысль насчёт того чтоб создать возможность обьявляя переменную/массив при необходимости задавать её/его физический адрес. Хотя может оно уже есть, только я не вкурил ?
Ещё одна рекомендация по дальнейшему апгрейду касаемо спрайтов - зеркальные спрайты указывать не отдельной ф-цией, а передавать в качестве флага одного из аргументов ф-ции.
Почему так? Вот на данный момент мне на каждую фазу анимации надо выполнять проверку if dir = 1 then SpritePutClear () else SpritePutMirrorClear ()
Код получается громоздким. Тогда как при передаче через аргумент достаточно SpritePutClear (...,1/0). Ну и такой подход обычно во всех адекватных SDK.
Меня это тоже бесит на реальных проектах. Это первое, что я сделаю, как будет время - одна команда sprite для всех видов и типов спрайтов. А также думаю над единой адресацией всех спрайтов, чтобы не делать под каждый спрайт свою команду.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
