SjASMPlus от z00m

[Ped7g]

Ограничение на длину строки в 128 байт для BYTE/DB/DC является очень важным, или лимит можно увеличить?

All internal buffers are fixed size. read-line is 2048, define-substitution two buffers 2048, emit-bytes-values inside BYTE/DB/DC/DZ directive is 128+2, etc...

You can raise limits of all those buffers (and hope that you did find all relevant ones) and build version which will accept more, but there will be always some hard limit unless you rewrite the code to use dynamic memory allocation per line.

But even to reach 128 items in DB it must be super long source-code line which is difficult to read+edit in text editor, so I don't see 128 limit as an issue (in my own source I'm often limiting number values to 16 or 32 per line and quoted text to 64 chars).

For binary data like gfx consider `INCBIN` instead of converting it to source code, or patch the convertor to split it into multiple lines.

[Advertiser]

[transman]

Ped7g, Нет. Скомпилировать SJASM+ я не могу.
128+2 байт хватает, когда DB используется для стандартных сценариев. Но не хватает, когда пишутся или адаптируются под sjasm+ игровые скрипты, особенно содержащие в себе много текста. Тогда приходится проделывать множество ручной работы, компилируя скрипты, выявляя строки, не укладывающиеся в ограничения по длине и в ручную ограничивая их длину.
Почему нельзя задать буфер под DB с некоторым запасом например 512+2 или 1024+2 ? Это снимет все вопросы к данной директиве раз и на всегда.
У современных конфигураций компьютеров память может исчисляться десятками гигабайт и лишняя пара килобайт ничего не значит.

[Bedazzle]

Почему нельзя задать буфер под DB с некоторым запасом например 512+2 или 1024+2 ? Это снимет все вопросы к данной директиве раз и на всегда.

Уже проходили. 640кб хватит всем.

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

Это если алгоритм не завязан на структуру. К примеру, в байт больше 256 значений не засунешь.

P.S.
Я просто поболтать, исходники ассемблера не смотрел.

- - - Добавлено - - -

Лично я полностью согласен, что DD-MM-YYYY is wrong

Хуже этого только месяц-день-год и АМ/РМ время.