[Ohrrpgce] Battle code refactoring

[Simon Bradley]

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