On Sun, Aug 31, 2008 at 5:22 PM, James Paige <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 31, 2008 at 03:51:43AM +1200, Ralph Versteegen wrote:
>> On Sun, Aug 31, 2008 at 2:49 AM, James Paige <[EMAIL PROTECTED]> wrote:
>> > On Sun, Aug 31, 2008 at 02:10:58AM +1200, Ralph Versteegen wrote:
>> >> On Sat, Aug 23, 2008 at 3:50 AM, James Paige <[EMAIL PROTECTED]> wrote:
>> >> > As you may have already noticed, I have started on a major battle code
>> >> > refactoring quest. I plan to:
>> >> >
>> >> > * subify every single gosub in bmod.bas
>> >> > * make bmod and bmodsubs both compile with OPTION EXPLICIT
>> >> >
>> >> > In this process I am also gathering various stray data into TYPEs. I am
>> >> > doing this in many small commits, which I am making a big effort to test
>> >> > completely.
>> >> >
>> >> > If I am clobbering anybody's uncommited battle patches, I apologize,
>> >> > and I offer my assistance in fixing any patches that conflict. If
>> >> > anybody has a conflicting working version of bmod.bas or bmodsubs.bas,
>> >> > just send me a diff against the last non-conflicting revision (which
>> >> > I am guessing will probably be 2134)
>> >> >
>> >> > ---
>> >> > James Paige
>> >>
>> >> Wow, great! The textbox cleanup is going to be very nice too.
>> >>
>> >> It looks like my changes to the textbox editor don't conflict at all,
>> >> because they are specially to text editing (word wrapping).
>> >
>> > Cool.
>> > How do you plan on making word wrapping work?
>>
>> I'm still treating a textbox as 8 lines of at most 38 characters. When
>> in word wrapping mode (which can be turned off but I think should be
>> on by default) several effects will occur:
>> -hitting enter splits a line (if there's room - the lines below are
>> moved down 1 to make room, or a blank line is overwritten)
>> -typing off the end of a line creates a new one (if there's room...)
>> -backspace/delete at the beginning/end of a line concatenates and then
>> resplits the lines (this can actually cause 3 lines to be needed
>> though!)
>> Plus changes to controls for moving about.
>> I also added an auto-indent mode.
>
> That sounds pretty cool.
>
>> This is pretty good, but this doesn't behave as you expect in a few
>> cases such as adding to the middle of a paragraph, because stuff that
>> falls off the line isn't automatically prepended to the next one. Now
>> I'm wondering whether I should instead store lines internally to any
>> length as long as they fit in the box. But this will help only in the
>> cases where the user is editting something they just typed (unintended
>> hard newlines won't appear), not when editing old text.
>> But it's not so serious a problem because you can manually delete
>> unwanted newlines.
>
> Hmmm... what about the case where somebody writes a line with a ${} code
> in it that expans and makes the line too long. Is there any reasonable
> way to handle that case at run-time rather than edit-time?

If we switch text format to one which tells us what text is
continuous, and what's meant to have newlines. I doubt guessing for
old boxes would work very well. But what about box sizes? Maybe we
could add a (default) autosize option (which would also autoadjust the
box placement if it goes over the bottom).
Or would you rather focus on existing games?

>
>> Since we wanted to add font/colour/display effect tags anyway and
>> those will require more space, and all your cleanup is very enabling,
>> what about changing the text format to a string with user-placed
>> newlines?
>
> That would be cool. The .SAY format is HORRIBLE. I think it is seriously
> one of the worst lumps.
>
> I do like the idea of one big string with newlines. I think the old
> textboxes can be converted into that very cleanly.

Hmm. How to store dynamic sized strings. I suppose it would be best to
allocate variable lengths of fixed size blocks for text in another
lump to keep size down (the .SAY lump for POWEREX.RPG is already
1.3MB). We could store the allocation bitmask in a 3rd lump?

>
> I would also like to allow textboxes to be more than 8 lines. I see no
> reason why a full-screen textbox shouldn't be allowable. (and I can't
> remember why I limited it in the first place)

Ah, I hadn't thought of it.
>
> ---
> James Paige
_______________________________________________
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Reply via email to