Register
I haven't pushed any of my changed to svn yet. Waiting until there are no known introduced bugs.
Fri Jun 12, 2020 1:59 pm 
I'm pretty busy, but did steal some time from more urgent tasks. Continuing to be shocked by how much work this text layout engine is. Implemented line and character limits in text slices (not trivial due to line wrapping backtracking), and opaque backgrounds for edged text. Had actually planned to work on italic, bold, and variable-width font variants today, probably would have been easier than line/char limits
I haven't pushed any of my changed to svn yet. Waiting until there are no known introduced bugs.
I haven't pushed any of my changed to svn yet. Waiting until there are no known introduced bugs.
Thu Jun 18, 2020 11:54 pm
I know I've asked this before, but it's been a while, and it seems that plans change over time. Since you're working on text now, I was wondering if you're also going to introduce variable box width, not just height. Sometimes 40 characters is perfectly fine. Sometimes 40 characters at a larger font in a larger box is better. Sometimes 60 characters makes the most sense, especially when dealing with markups, especially when that text and those markups are imported.
So . . . my actual question is are you redesigning text for full customization, especially since the engine is capable of displaying images up to HD sizes and native textboxes currently look like thumbnails (or tooltips!) at higher resolutions?
And, are you going to make it so that imported text will automatically wrap to the next line (if selected) instead of crop off when exceeding the character limit for that line (unless otherwise selected)?
In other words:
1. Will textboxes have variable heights and widths?
2. With variable character ranges per line exceeding 40 characters if needed?
3. With markups ignoring limits to length?
4. With boxes capable of displaying more than eight lines at a time if needed (in the case of flavor text, for example)?
5. With custom import options that can respect or ignore margin rules, or even shape boxes based on wrapper rules, so that textboxes can be written as a single line in Notepad and imported without corruption?
6. Without having to create a scripted text slice to accomplish it all?
And to clarify #5, would we be able to write instructions like these:
And import them into a dynamic box that can wrap the text into however many lines it takes to fit it all in, instead of doing it the classic way?
NOTE: I moved the markup around "don't" to the next line because under the current rules, the "i" and the bracket would've been cut off since they exceed the 40th character.
NOTE 2: In my first example, I've all-capsed the word "BOX" as a signal to the engine that this should refer to the text box, not be printed inside of it. This would eliminate the need to copy lines of dashes and equal signs to each new box.
I think #5 is an important feature because it a.) allows for the writer to keep up a text-writing and editing flow without having to think about the 40-character-limit rules, and b.) it makes it easier to run the text through editing and proofreading software prior to committing to the engine (if the designer has access to editing and proofreading software, as I do).
And while we're still on the topic, could we add an extra (optional) field to textboxes for character name text frames in the same way that we have portrait boxes as a separate entity? This would be really easy to accomplish with slices, but since the engine has a dedicated textbox creation tool, it would be nice if we could fully customize it as if it were a slice collection, complete with text box, portrait box, and character name box, instead of having to leave the text editor and accomplish everything in the slice editor.
OR, option #3 (and probably the smartest option if it's not already planned) would be to allow the ability to copy and paste slice collections directly into each of CUSTOM's various menus and options to create new custom layouts, including those for text boxes or enemy formations, so that we never have to bug you for new options within CUSTOM ever again. (This may be what the editor editor is; that's not really discussed anymore.)
Just some thoughts while your attention is on textboxes.
Place Obligatory Signature Here
So . . . my actual question is are you redesigning text for full customization, especially since the engine is capable of displaying images up to HD sizes and native textboxes currently look like thumbnails (or tooltips!) at higher resolutions?
And, are you going to make it so that imported text will automatically wrap to the next line (if selected) instead of crop off when exceeding the character limit for that line (unless otherwise selected)?
In other words:
1. Will textboxes have variable heights and widths?
2. With variable character ranges per line exceeding 40 characters if needed?
3. With markups ignoring limits to length?
4. With boxes capable of displaying more than eight lines at a time if needed (in the case of flavor text, for example)?
5. With custom import options that can respect or ignore margin rules, or even shape boxes based on wrapper rules, so that textboxes can be written as a single line in Notepad and imported without corruption?
6. Without having to create a scripted text slice to accomplish it all?
And to clarify #5, would we be able to write instructions like these:
Code:
BOX 1
PENGUIN:
I once was a bird who knew how to fly. But one day I lost my jetpack, and now I'm once again grounded with all of these deadbeat pigeons, and I [i]don't[/i] like pigeons!
BOX 2
PIGEON:
We don't like you, either. Jerk.
PENGUIN:
I once was a bird who knew how to fly. But one day I lost my jetpack, and now I'm once again grounded with all of these deadbeat pigeons, and I [i]don't[/i] like pigeons!
BOX 2
PIGEON:
We don't like you, either. Jerk.
And import them into a dynamic box that can wrap the text into however many lines it takes to fit it all in, instead of doing it the classic way?
Code:
======================================
Box 1
--------------------------------------
PENGUIN:
I once was a bird who knew how to fly.
But one day I lost my jetpack, and now
I'm once again grounded with all of
these deadbeat pigeons, and I
[i]don't[/i] like pigeons!
======================================
Box 2
--------------------------------------
PIGEON:
We don't like you, either. Jerk.
Box 1
--------------------------------------
PENGUIN:
I once was a bird who knew how to fly.
But one day I lost my jetpack, and now
I'm once again grounded with all of
these deadbeat pigeons, and I
[i]don't[/i] like pigeons!
======================================
Box 2
--------------------------------------
PIGEON:
We don't like you, either. Jerk.
NOTE: I moved the markup around "don't" to the next line because under the current rules, the "i" and the bracket would've been cut off since they exceed the 40th character.
NOTE 2: In my first example, I've all-capsed the word "BOX" as a signal to the engine that this should refer to the text box, not be printed inside of it. This would eliminate the need to copy lines of dashes and equal signs to each new box.
I think #5 is an important feature because it a.) allows for the writer to keep up a text-writing and editing flow without having to think about the 40-character-limit rules, and b.) it makes it easier to run the text through editing and proofreading software prior to committing to the engine (if the designer has access to editing and proofreading software, as I do).
And while we're still on the topic, could we add an extra (optional) field to textboxes for character name text frames in the same way that we have portrait boxes as a separate entity? This would be really easy to accomplish with slices, but since the engine has a dedicated textbox creation tool, it would be nice if we could fully customize it as if it were a slice collection, complete with text box, portrait box, and character name box, instead of having to leave the text editor and accomplish everything in the slice editor.
OR, option #3 (and probably the smartest option if it's not already planned) would be to allow the ability to copy and paste slice collections directly into each of CUSTOM's various menus and options to create new custom layouts, including those for text boxes or enemy formations, so that we never have to bug you for new options within CUSTOM ever again. (This may be what the editor editor is; that's not really discussed anymore.)
Just some thoughts while your attention is on textboxes.
Place Obligatory Signature Here
Fri Jun 19, 2020 12:41 am
great ideas Pepsi!
I doubt I could have expressed it better myself
this is my life now
I doubt I could have expressed it better myself
this is my life now
Fri Jun 19, 2020 11:29 am
Long-term, the plan is to replace the textbox file format to remove all the limits and add flexible conditionals. That's quite a bit of work, so I decided to stagger the project of upgrading textboxes. I want to start by salvaging the existing file format by repurposing the text data as 304 characters (with no line limit) instead of 8 lines of 38 characters, plus extending it maybe around 300 more characters. 300 more characters per box, for example, increases the size of POWERXE.rpg (assuming 10,000 textboxes, probably more by now?) by about 3MB.
But dealing with all the resulting interconnected problems, like updating the textbox text editor and import/export textbox functions (while continuing to support old exported .txts), will probably be one of the hardest parts of the whole textbox upgrade project. So it will delay other features until later (and I don't know if even that first step will make it into the next release).
The lines of dashes are certainly annoying to copy-paste (that's the problem, right?) The start, end, and properties segment of each text box needs to be unambiguous though. How about something that's easy to type by hand, like an arbitrary number of <'s to start followed by the same number of >'s? Or start with -'s and end with ='s? E.g.
Character name boxes would be cool; I never thought of that.
Yes, editing the builtin collections will be very powerful once it's available. Still a high priority.
But dealing with all the resulting interconnected problems, like updating the textbox text editor and import/export textbox functions (while continuing to support old exported .txts), will probably be one of the hardest parts of the whole textbox upgrade project. So it will delay other features until later (and I don't know if even that first step will make it into the next release).
The lines of dashes are certainly annoying to copy-paste (that's the problem, right?) The start, end, and properties segment of each text box needs to be unambiguous though. How about something that's easy to type by hand, like an arbitrary number of <'s to start followed by the same number of >'s? Or start with -'s and end with ='s? E.g.
Quote:
Box 1
Backdrop: 1
<<<
Here's some text
>>>
Box 2
<<
<<< You can still use angle brackets in your text
>>> If the number is different from the start/end markers
>>
Box 3
--
Would this be better?
==
Backdrop: 1
<<<
Here's some text
>>>
Box 2
<<
<<< You can still use angle brackets in your text
>>> If the number is different from the start/end markers
>>
Box 3
--
Would this be better?
==
Character name boxes would be cool; I never thought of that.
Yes, editing the builtin collections will be very powerful once it's available. Still a high priority.
Fri Jun 19, 2020 10:18 pm
TMC wrote:
Long-term, the plan is to replace the textbox file format to remove all the limits and add flexible conditionals. That's quite a bit of work, so I decided to stagger the project of upgrading textboxes. I want to start by salvaging the existing file format by repurposing the text data as 304 characters (with no line limit) instead of 8 lines of 38 characters, plus extending it maybe around 300 more characters. 300 more characters per box, for example, increases the size of POWERXE.rpg (assuming 10,000 textboxes, probably more by now?) by about 3MB.
It's been a while since I checked, but 10,000 sounds about right. Quick check = 10,682 boxes. At some point, whenever I finally implement a questing journal (which will track important characters by default) I'll want to finish isolating every character to his or her own box, which could increase box count to over 15,000. I don't know how that will look. It's another reason why simplified external editing would really useful. It would also give me an excuse to start cutting out some fat.
I'm still in the process of rewriting my scripts for all of my existing games, so I'm not really adding new content to anything right now. This will become more important to me after the rewrites are finished.
TMC wrote:
But dealing with all the resulting interconnected problems, like updating the textbox text editor and import/export textbox functions (while continuing to support old exported .txts), will probably be one of the hardest parts of the whole textbox upgrade project. So it will delay other features until later (and I don't know if even that first step will make it into the next release).
If there's a way to use this time to implement new export destinations (like Excel, for example, or anything that has sorting and reordering capability), that might be a good idea. It would make editing text so much faster and easier.
It also makes me wonder if it's worth it provide an alternate way to attach text to assets. For example, maybe NPCs can have a separate script option for dialogue trees, and maybe the textboxes related to those trees can have their own script elements that run before the text displays, while the text is on display, and/or when the text advances (instead of the "instead of text" option they already have). This would make character or portrait animations during conversations more dynamic. Pair that with a user-defined scripting library for character actions, and you could end up with a robust story-development system inside the engine. Something to think about.
TMC wrote:
The lines of dashes are certainly annoying to copy-paste (that's the problem, right?) The start, end, and properties segment of each text box needs to be unambiguous though. How about something that's easy to type by hand, like an arbitrary number of <'s to start followed by the same number of >'s? Or start with -'s and end with ='s?
I think Option 3 is the fairest. Ideally though, it should be something that users would never use as text. Something like !~ or !# would make sense. Or even open/closed brackets, since that wouldn't require the use of SHIFT.
Example:
Code:
Box 1
-
This would be better
[]
Box 2
-
So much faster
[]
-
This would be better
[]
Box 2
-
So much faster
[]
Or, even better:
Code:
[Box 1]
Simple
[Box 2]
Effective
[Box 3]
Super fast
Simple
[Box 2]
Effective
[Box 3]
Super fast
That could work, too.
On a related note, I kinda miss the old way of cycling through text. While I appreciate the snapshots we have now, I find that inputting text numbers is a pain. Maybe create a dedicated box for typing in numbers so that we don't accidentally land on the wrong text when the system interprets our request faster than we can type it out? The old system was faulty, but at least we could call up the exact text we wanted without issue.
Place Obligatory Signature Here
Sat Jun 20, 2020 12:48 am
I doubt anyone (even you) wants to import/export textboxes to a spreadsheet. You can just place textboxes out-of-order in the .txt file. (It's maybe not well tested though.)
At some point there will be text markup to modify/animated portraits (no scripting needed), and more script triggers too.
By "Option 3" you mean "start with -'s and end with ='s"? I don't agree that [] is easier to type than ==. In fact you have to hold Shift+AltrGr to type [] on a lot of non-US keyboards (eg Dutch). But I already settled on [] for text markup regardless. "[Box 1]" looks nice but it also looks too similar to text markup, and you still need another separator between settings and text.
I don't know what you're referring to.
At some point there will be text markup to modify/animated portraits (no scripting needed), and more script triggers too.
By "Option 3" you mean "start with -'s and end with ='s"? I don't agree that [] is easier to type than ==. In fact you have to hold Shift+AltrGr to type [] on a lot of non-US keyboards (eg Dutch). But I already settled on [] for text markup regardless. "[Box 1]" looks nice but it also looks too similar to text markup, and you still need another separator between settings and text.
Quote:
On a related note, I kinda miss the old way of cycling through text
I don't know what you're referring to.
Sun Jul 05, 2020 2:44 pm
I took a break from OHRRPGCE work for a couple of weeks. Getting back, I implemented slice collection names. The names are displayed in the in-game slice debugger, and you can see the collection ID a slice was loaded from too.
It might appear to be wasted effort but I plan to store other data next to the name in future.
(It just occurred to me that collection names ought to be exported to the .hsi file)
Then I got back to text.
Looking at this you might think I was working on fonts or other features; no, I spent a week fixing painful edgecase bugs in finding the character under the mouse and measuring text slice size. Absolute nightmare. And much of it will hardly ever be used (in the text editor only), if at all.
But now I can work on something more interesting.
It might appear to be wasted effort but I plan to store other data next to the name in future.
(It just occurred to me that collection names ought to be exported to the .hsi file)
Then I got back to text.
Looking at this you might think I was working on fonts or other features; no, I spent a week fixing painful edgecase bugs in finding the character under the mouse and measuring text slice size. Absolute nightmare. And much of it will hardly ever be used (in the text editor only), if at all.
But now I can work on something more interesting.
Sun Jul 05, 2020 4:23 pm
Okay, that *does* look amazing :D
Tue Jul 07, 2020 2:41 pm
Actually, I haven't started working on the fun stuff yet. Instead I spent two days on text markup-aware text editing. So more excruciating problems dealing with edgecases in going backwards from screen position to text offset. I nearly lost hope.
But that's finished now, so I did some code cleanup. I finally threw away the awful text editor that was used for editing (for example) text slice text and replaced it with a generalised version of the F1 help viewer/editor (which it was originally copy-pasted from and then diverged. Copy-pasting bad.).
Good news is that using markup in textboxes already works semi-OK without me needing to make a single change, and making it totally functional looks like it'll be easy, so I think I'll do that next.
Don't know why I'm currently working on text editing undo/redo.
I've been holding back my patches from SVN (nightlies) for over a month due to bugs and a compatibility-break. No known bugs left but I need to fix that break and stop hoarding.
But that's finished now, so I did some code cleanup. I finally threw away the awful text editor that was used for editing (for example) text slice text and replaced it with a generalised version of the F1 help viewer/editor (which it was originally copy-pasted from and then diverged. Copy-pasting bad.).
Good news is that using markup in textboxes already works semi-OK without me needing to make a single change, and making it totally functional looks like it'll be easy, so I think I'll do that next.
Don't know why I'm currently working on text editing undo/redo.
I've been holding back my patches from SVN (nightlies) for over a month due to bugs and a compatibility-break. No known bugs left but I need to fix that break and stop hoarding.
Fri Jul 10, 2020 1:31 pm
Working on text undo was definitely a mistake. The last gif didn't demonstrate the bugs. I wasted a couple days either rewriting it or planning a rewrite on paper at least 4 times. I think it's fine now, and even if it's not I'm not touching it again unless it crashes.
I also investigated and solved the problem with sprite dissolves use a mess of wrong colours (like everything else, the fix isn't in nightlies yet).
But now I'm going to switch to working on Mac and gfx_sdl2 stuff for a while. I really want to make gfx_sdl2 the default in the next release, because it would fix so many bugs. And we can't make a change like that right before release. Actually, I'm starting with bug 26.
I also investigated and solved the problem with sprite dissolves use a mess of wrong colours (like everything else, the fix isn't in nightlies yet).
But now I'm going to switch to working on Mac and gfx_sdl2 stuff for a while. I really want to make gfx_sdl2 the default in the next release, because it would fix so many bugs. And we can't make a change like that right before release. Actually, I'm starting with bug 26.
Sat Jul 18, 2020 7:32 am
As usual, I've been switching between a lot of different topics in the last few days
-looking for a minimal terminal emulator to embed in Custom on Mac to fix bug 26, I forked hackterm and started making improvements to it...
-working on fixing gfx_sdl2 on Mac
-looking into other gfx_sdl2 and gfx_sdl problems
-fixed some bugs including a frame skipping bug (broke 60fps games on Mac); error messages; random colors when using sprite transparency; and more
-optimised blitting in 24-bit color mode
-rewrote screen fades (see below)
-wrote up Plan for Canvas slices
-installed a wiki extension
-reviewed my unmerged stencil slice branch; I think I decided on how to do multi-slice stencil. But not for the next release, because stencils are currently incompatible with 32-bit color mode, so it's one or the other
-start on adding an argument to dissolvesprite to control what happens afterwards
And I haven't touched the font/text system since.
The following gifs have been slowed down to 1/2 the usual speed.
Fades look like this in Gorgonzola. Note that the palette gets washed out, and fading in and out look different:
I rewrote it to uniformly fade the whole palette in/out (equivalent to drawing a transparent rectangle over the screen), but I didn't like how it suddenly drops to black:
After a lot of experimenting, I settled on a custom cubic interpolation function which eases in/out at the start and end of the fade:
Yet another thing noone asked for (and I know someone is going to complain).
But the reason I'm working on screen fading is because it's the thing holding up 24-bit color mode.
-looking for a minimal terminal emulator to embed in Custom on Mac to fix bug 26, I forked hackterm and started making improvements to it...
-working on fixing gfx_sdl2 on Mac
-looking into other gfx_sdl2 and gfx_sdl problems
-fixed some bugs including a frame skipping bug (broke 60fps games on Mac); error messages; random colors when using sprite transparency; and more
-optimised blitting in 24-bit color mode
-rewrote screen fades (see below)
-wrote up Plan for Canvas slices
-installed a wiki extension
-reviewed my unmerged stencil slice branch; I think I decided on how to do multi-slice stencil. But not for the next release, because stencils are currently incompatible with 32-bit color mode, so it's one or the other
-start on adding an argument to dissolvesprite to control what happens afterwards
And I haven't touched the font/text system since.
The following gifs have been slowed down to 1/2 the usual speed.
Fades look like this in Gorgonzola. Note that the palette gets washed out, and fading in and out look different:
I rewrote it to uniformly fade the whole palette in/out (equivalent to drawing a transparent rectangle over the screen), but I didn't like how it suddenly drops to black:
After a lot of experimenting, I settled on a custom cubic interpolation function which eases in/out at the start and end of the fade:
Yet another thing noone asked for (and I know someone is going to complain).
But the reason I'm working on screen fading is because it's the thing holding up 24-bit color mode.
Sat Jul 18, 2020 8:08 am
this is my life now
Sat Jul 18, 2020 10:05 am
Incredible!
Sun Jul 19, 2020 5:33 am
Sun Jul 19, 2020 1:22 pm
Bird wrote:
Maybe a quick question fitting the current topic... why did the old palette have the colours in the way, they were ordered? It looks somewhat unlogical compared the newer palettes.
The old pallette looked like that because I was just randomly throwing things at the wall to see what stuck. There was no planning behind it.
EDIT: except the first row, that is based on the 16 color EGA palette