[Ohrrpgce] Battle code refactoring

[Ralph Versteegen]

On Tue, Sep 2, 2008 at 9:29 AM, Simon Bradley <neworiginal at gmail.com> wrote:
> On Mon, Sep 1, 2008 at 6:09 PM, Ralph Versteegen <teeemcee at gmail.com> wrote:
>> On Mon, Sep 1, 2008 at 7:46 AM, Mike Caron <caron.mike at gmail.com> wrote:
>>> Ralph Versteegen wrote:
>>>>
>>>> On Sun, Aug 31, 2008 at 5:22 PM, James Paige <Bob at hamsterrepublic.com>
>>>> 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 <Bob at hamsterrepublic.com>
>>>>>> 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 <Bob at hamsterrepublic.com>
>>>>>>>> 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?
>>>
>>> Split the lump into two lumps, textbox.tab and textbox.dat. The .dat lump
>>> contains the variable-length string data, in a format like this:
>>>
>>> Type StringData
>>>  dataSize as short ' storage space
>>>  dataLen as short ' actual string size, -1 means its unused
>>>  data as string ' the string itself
>>> End type
>>>
>>> The .tab lump contains all the meta data, and an index into the .dat file.
>>> When the string data changes, you need to do one of two things:
>>>
>>> 1. If the string is the same size or shorter than the existing string, you
>>> can reuse the same data area.
>>>
>>> 2. If the string is longer, you need to search for an unused string big
>>> enough to hold it. If no such string exists, just append one to the end. Set
>>> the old string's length to 0.
>>>
>>> Then, once in a while (when you save?), you can "defrag" the string data, by
>>> writing out all the strings into a new file of appropriate length.
>>>
>>> Perhaps, when creating a new string data storage unit, you can make it
>>> bigger by a certain percentage, to reduce the fragmentation problem.
>>
>> Yeah , I suppose we could store the length of each allocated block
>> with the string rather than use a separate bitmask/table.  It would be
>> slower but simpler. The first record in the file could hold special
>> data instead of a string (like position of the first free block of
>> size x to speed up searching, or whatever is helpful)
>>
>> I'd also like to handle indentation in a special way. It would be nice
>> to set an indentation level for a piece of text rather than use spaces
>> to align it. This way, we can have in-game dynamic wrapping of
>> indented text. I'm thinking that it could also be handled with in-text
>> tags, but I'm not sure yet how this would work in Custom.
>
> I'd favour rewriting the whole text file with no slack every time.
> It'd be a lot easier to deal with. You could keep the index consistent
> (so string 20 remains string 20 even if you delete string 19 - 19
> would be recycled later or left blank) but keep the actual data clean.
> I don't think the overhead would be sufficiently bad to warrant some
> complicated space reallocation. Although as long as the index is
> right, I guess it wouldn't really matter if there were gaps in the
> data.
>
> Cheers,
> Simon

Well, I'll try that out, and if I get lag when editing textboxes in
SoJ (3MB .SAY lump), I try out something else.

Oh! I just realised, after seeing the question "How can I make more
than two choices in a text box?" on the wiki, that we could/had
suggested changing the way that the choicebox is implemented at the
same time to be menu-based. Existing choiceboxes could be translated
into menus (is this pointless?). I think it would be silly if 2-choice
textboxes and 3-choice textboxes were made in completely different
ways, and 3 choices are much harder.
At the least, when we allow menus to be linked to textboxes, it would
be nice to be able to go to the menu editor and create a new menu
straight from the textbox editor. Maybe we can add tighter
integration, like actually show the textbox while you are editing,
have default settings for the menu and menu items appropriate to
choice boxes, automatically name the menu, and so on. Ideas? Waste of
time?