Ralph Versteegen wrote:
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?
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.
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
_______________________________________________
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
