Sounds like great progress, and thanks for the continued write-up!
Is there some interesting reason (I'm guessing maybe something to do with text compression and top bit set bytes?) why you redefine "#" with the brick character rather than using (say) 128? Do you have to define it back afterwards or is this character not used otherwise? Edit: Is this maybe because you use "#" in mode 7 as it is the most brick-like character available in the unmodifiable character set, and this way it "just works" regardless of mode?
I did find the existence of these "comment only" entries a bit odd when reading the Quill documentation you posted the other day, especially on the 32K BBC. But I guess when you're editing the database via the Quill's own editor what you'd save by not storing these probably isn't enough to compensate for the extra code needed to special case the editing.
I have read about this but I don't remember reading why - is there some good reason the BBC has this inverted or was it just an oversight on someone's part BITD?Flipped the light/dark sense over (BBC is inverted).
Does this mean the user gets to choose which mode they want to run the game in? Or is this flexibility there to allow building the game to run in different modes, but after building the mode for that specific build is fixed?Allow text fragments to be assigned a flag which determines which modes they apply to. For example, the Dunshalt Donut prints a line of what I guess are meant to be bricks using a UDG and a red background. That's fine in mode 1, but needs a fallback for mode 7.
If I'm reading the code right, the issue is that when the screen scrolls upwards the newly created blank line at the bottom gets the current background colour. Yes, this is fun, isn't it? I have to work round this in Ozmoo as well. Do I also infer correctly that you never print a character in the very bottom right cell on the screen? Edit: Actually, maybe I should limit my inference to being that you never print a "#-brick" in the very bottom right cell?Spent a couple of hours fiddling about with this trying to figure out how VDU 17,128 behaves when used at the very end of a line. Not quite what I expected but I managed to code round it using some shenanigans.Code:
AGMessage M107 = game.AddMessage(107, "\n"); M107.AppendControlCodes(AGModeType.Bitmap, 23, 35, 0x10, 0x10, 0x10, 0xff, 0x01, 0x01, 0x01, 0xff); M107.AppendControlCodes(AGModeType.Bitmap4Colour, 17, 129); M107.AppendRepeatCharacter('#', 0); M107.AppendControlCodes(AGModeType.Bitmap4Colour, 17, 128); M107.AppendRepeatCharacter(AGModeType.Bitmap, ' ', 0); M107.AppendControlCodes(AGModeType.All, 11);
Is there some interesting reason (I'm guessing maybe something to do with text compression and top bit set bytes?) why you redefine "#" with the brick character rather than using (say) 128? Do you have to define it back afterwards or is this character not used otherwise? Edit: Is this maybe because you use "#" in mode 7 as it is the most brick-like character available in the unmodifiable character set, and this way it "just works" regardless of mode?
It all adds up, right?Removed word 1 and word 2 from the generated status table as they are not needed (they are in the Quill database as "comments") in by the interpreter and there's no loadable database now. Saves a whopping 2 bytes per entry.
I did find the existence of these "comment only" entries a bit odd when reading the Quill documentation you posted the other day, especially on the 32K BBC. But I guess when you're editing the database via the Quill's own editor what you'd save by not storing these probably isn't enough to compensate for the extra code needed to special case the editing.
Statistics: Posted by SteveF — Wed Sep 11, 2024 8:10 pm