[Ohrrpgce] Battle code refactoring

[Ralph Versteegen]

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.