SavagePencil wrote

You will want a table that maps dialogue ID to the location of the corresponding string. Or if you are embedding more detail than just the text, the table maps a dialogue ID to the struct that has all of the relevant info for the string. I can't remember if you're using C or WLA DX but each has its own peculiarities for defining structs. Your function should be something analogous to get_dialogue_struct_by_ID().

I'm honestly not sure you want to go through the hoops of pre-cooked VRAM locs, but if you do, I'd suggest a macro that takes ROW, COL and calculates it for you.

Maxim wrote

That'd do it. Using dialogue IDs is a bit cumbersome, though; why not use labels like "DialogueString_Well" at the point you need them, instead of looking them up in a table? As you're likely to have more than 256 string in total, 16-bit IDs end up using as much space as 16-bit pointers.

SavagePencil wrote

1. What happens when you single step through this with your debugger?
2. If you make this only one or two strings, does it work?
3. Are you doing this in VBLANK? Any chance you are running out of time?

CerezaSaturn64 wrote

SavagePencil wrote

1. What happens when you single step through this with your debugger?
2. If you make this only one or two strings, does it work?
3. Are you doing this in VBLANK? Any chance you are running out of time?

Everything i wrote here works perfectly, and I'm not doing this during Vblank, so I'm good there. My main issue is really just wanting to make the DrawComplexString code shorter by looping each half twice before starting back at the beginning again.

So i want the

ld a,(hl)
out (VDPControl),a
inc hl
dec bc

chunk to execute two times, then have the

ld a,(hl)
out (VDPData),a
inc hl
dec bc

chunk execute twice as well before it runs through the last bit of code and loops back to the first chunk.

ichigobankai wrote

You should use stringmap (with tbl file) and a terminator flag for end of Line (a specific byte you'll check to tell " hey, go to next Line" or "stop")
Next Line is generaly simple ; just an addition of the previous setted one (+64)

To reduce dat size, you can use some compression. RLE give good result with map (text is also map)

willbritton wrote

As Ichigo points out, the way you are storing text could be made much much more efficient. Even without RLE you could encode some control characters for null termination but also line feeds, carriage returns, etc. ASCII anyone? :)

But sounds like you're focused on trying to reduce the size of your algorithm as written. Since you're just dealing with data structures of fixed size of four bytes could you make use of the index registers and instructions like `ld a,(ix+d)` to cut down on manual index increments?

Maxim wrote

I think you’re using it exactly correctly.

Maxim wrote

I tend to use fake pseudo-html <tags> for control codes myself.

CerezaSaturn64 wrote

Sorry for not getting back to this sooner, a huge storm knocked my internet out for a few days and I've been real busy with going back to uni.

CerezaSaturn64 wrote

Does this also work with compressed tiles?

Maxim wrote

It’s worth remembering however that unless you are aiming to make physical cartridges with a size limit, compression is not necessary until you run into other limits like the 1MB size limit for older Everdrives and clones. It only acts to slow things down. At the same time, it’s also used extensively in the Phantasy Star retranslation, as part of the goal to fit in the original 512KB ROM size - there is dictionary coding for common words and also conditional Huffman coding for the data itself.

CerezaSaturn64 wrote

Maxim wrote

It’s worth remembering however that unless you are aiming to make physical cartridges with a size limit, compression is not necessary until you run into other limits like the 1MB size limit for older Everdrives and clones. It only acts to slow things down. At the same time, it’s also used extensively in the Phantasy Star retranslation, as part of the goal to fit in the original 512KB ROM size - there is dictionary coding for common words and also conditional Huffman coding for the data itself.

If I remember correctly, the original game is only around 130-140KB in size, and the original is jam packed with inefficient code and bizarre choices. I was extremely generous with my estimated size limit of 256KB to accurately replicate the original game on the Master System, as I knew I'd need to accommodate for sprites not flipping and other hardware quirks. There is a good chance that I could easily manage with uncompressed text tiles and simply compress standard map tiles for the overworld, towns, and dungeons.

I am, of course, quite far away from a finished product so I have plenty of time to assess and reassess what I need to do to fit in my limits.

segarule wrote

Something as "warrior" =1. "What´s your name 1?" - "Wow, you are a great 1!"

Maxim wrote

Ruining the font to save tiles is only useful if you have VRAM space issues :) it probably saves nothing on the text encoding.

For the majority of an RPG, the text is drawn into a box and you may need to substitute names so it needs to handle word wrapping and pausing at runtime. Concentrate on that - and having the data be simple to edit - and special-case the times when you want to draw somewhere else as they’ll be rarer and likely more deterministic, eg the intro screens can just have a few screen locations and text pointers and it’s only a few dozen bytes.

willbritton wrote

One irritant was that it's apparently not possible to use backslash escaped characters in the table file, so I couldn't do `\0` or `\n`, despite the latter apparently being used in the example in the WLA-DX docs
🤷‍♀️

Quote

[ALL] .STRINGMAP and .STRINGMAPTABLE handle now special characters like "\n" properly.