SjASMPlus от z00m

[Demige]

In my project I have much text data (text dialogs). They not very big at once (may be 200b-3K for block), but their count big enough. And for each I need label to print text to screen. If I will use incbin, this would need for 500+ files to include.

I could wrote fulltext parser to get labels from text, but then I would have to solve problem where to store this labels and how to name them.

[Advertiser]

[Reobne]

Demige, а что если попробовать на LUA написать аналог INCBIN. Назвать его INCTEXT. Пусть он работает так же как INCBIN, но строки текста заканчивающиеся особым знаком превращал в метки.
Тогда подсунув ему такой текст в файле Messages.txt:

Label1>>
Supertext 
Message1>>
Game over!

Вызвав INCTEXT "Messages.txt",">>"
Он создаст две метки для двух текстов.

[Ped7g]

In my project I have much text data (text dialogs). They not very big at once (may be 200b-3K for block), but their count big enough. And for each I need label to print text to screen. If I will use incbin, this would need for 500+ files to include.

I could wrote fulltext parser to get labels from text, but then I would have to solve problem where to store this labels and how to name them.

I see, ok, this is the kind of stuff which makes big-text seem more important than I expected.

Some notes about possible workarounds with current sjasmplus version:

You can process data in device memory (reading them with { address } operator), but you can't easily build dynamic labels name from that, and values from memory can be read only in pass3, so the INCBIN+MACRO+DEFINE path would be very difficult to create some workaround, and it would probably not work well = unless I'm overlooking something, this is wrong approach.

Lua can add symbols (labels) (build dynamically, from file content for example) and can add bytes to the output (at least according to docs, I don't have these covered in tests, so you may find new bugs if you will try these, reporting them with example.asm will help me a lot). And there's probably a way in Lua to open text file and parse it, so you can implement your own INCTEXT as Reobne suggested, seems like good idea and should very likely work well (unless you run into some bug in sjasmplus). If you will go this route, and run into some problems, let me know, so we can fix it all.

Finally is the classic DB way *that* bad for these things?

Dialog1:
  db "Hi", 13, 13
  db "Some text.", 13
  db "Next line.",0
  ; to get zero terminated text with ZX enter=13 newlines

Depending on your workflow and where the devtime is mostly spent, having external .txt file processed by lua may even bring some productivity boost and may make it easier for non-programmer people to contribute to your project, so the Lua workaround sounds to me quite good, maybe even better than native support for big-text blocks from sjasmplus, but it's more initial work to get that setup working.

(would be also nice example of lua usage, if you want to share it afterwards , I can add it to the project tests/luaexamples)