Author |
Topic: Bug - or unrecognised feature? (Read 227 times) |
|
KenDown
New Member
member is offline
Posts: 49
|
 |
Re: Bug - or unrecognised feature?
« Reply #4 on: Dec 22nd, 2017, 05:47am » |
|
Thanks. I've incorportated the WIDTH command and the program runs noticeably faster in consequence. However I still have to use the MultiBytetoWide method every time I change font to find out the height of the font. We need a HEIGHT() command as well!
While I'm at it, there is a major annoyance for me in that under VDU5 text is wrapped - I'm sure that in the BBC Micro VDU5 was not wrapped and simply vanished off the right-hand edge of the screen. It would be good if there could be a flag to set so that either behaviour could be selected.
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: Bug - or unrecognised feature?
« Reply #5 on: Dec 22nd, 2017, 09:18am » |
|
on Dec 22nd, 2017, 05:47am, KenDown wrote:| We need a HEIGHT() command as well! |
|
I disagree. There's no such thing as 'proportional height' text (!) so the complication that different characters have different widths has no equivalent. Whether it's a monospaced font or a proportional font, the value at @vdu%!220 is an accurate measure of the character (row) height in pixels. This is a documented system variable, and has been for a very long time.
Note that, as with most system variables, in BBCSDL you must perform a 'thread synchronisation' before you can read the value reliably. It's harmless to do the same thing in BB4W so it's as well to get into the habit, for example:
Code: sync% = POS height% = @vdu%!220
Quote:| While I'm at it, there is a major annoyance for me in that under VDU5 text is wrapped - I'm sure that in the BBC Micro VDU5 was not wrapped and simply vanished off the right-hand edge of the screen. |
|
You say that you are "sure that in the BBC Micro VDU5 was not wrapped" so how come that when I turn on my BBC Master, enter MODE 1 and then VDU 5,30, text that I type wraps from one line to the next?
Your recollection is faulty, and I would have hoped that you would expect BB4W and BBCSDL to emulate the BBC Micro accurately in this respect, as they do in most others.
Quote:| It would be good if there could be a flag to set so that either behaviour could be selected. |
|
Er, so that would be VDU 23,16... then, which has been implemented (and documented) since the Acorn Archimedes, that's at least thirty years!!
Richard.
|
|
|
|
KenDown
New Member
member is offline
Posts: 49
|
|
Re: Bug - or unrecognised feature?
« Reply #6 on: Dec 22nd, 2017, 1:16pm » |
|
Hmmmm. I repent in dust and ashes!
However, although on its own @vdu%!220 (with or without the POS) returns the right answer for the height of a font, it must conflict with something else in my program because it mucks up the values returned by WIDTH() (or mucks up how I deal with them, or something). I'll have to look into it more.
VDU23,16,64;0;0;0; causes the behavour I'm looking for (scrolling text starting off the screen to the right and ending off the screen to the left). Thanks for that and apologies for not realising that it was there.
Is VDU23,16,0;0;0;0; the default? ie. If I do that after my scrolling routine has finished, will I be back to square one, so to speak?
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: Bug - or unrecognised feature?
« Reply #7 on: Dec 22nd, 2017, 2:02pm » |
|
on Dec 22nd, 2017, 1:16pm, KenDown wrote:| Is VDU23,16,0;0;0;0; the default? |
|
Yes.
Richard.
|
|
Logged
|
|
|
|
KenDown
New Member
member is offline
Posts: 49
|
|
Re: Bug - or unrecognised feature?
« Reply #8 on: Dec 22nd, 2017, 8:42pm » |
|
Thanks. I really appreciate your replies. A very big help.
|
|
Logged
|
|
|
|
KenDown
New Member
member is offline
Posts: 49
|
|
Re: Bug - or unrecognised feature?
« Reply #9 on: Dec 23rd, 2017, 02:21am » |
|
Curioser and curioser. A friend with whom I have been corresponding over this matter sent me the following program.
f$= "FONT Arial,32,B"
a$="Kendall Down"
b$="Kendall "+CHR$18+CHR$0+CHR$9+"Down"
OSCLI(f$)
VDU5
MOVE100,400:PRINTa$, WIDTH(a$)/2, @vdu%!220
MOVE100,300:PRINTb$, WIDTH(b$)/2, @vdu%!220
MOVE100,200:PRINTb$, WIDTH(b$)/2, @vdu%!220
MOVE100,100:PRINTa$, WIDTH(a$)/2, @vdu%!220
VDU4
END
When you run it the numbers in the top and bottom lines are further to the right than the numbers in the middle two lines. Now reverse the order of the lines, so that the two lines with b$ are at top and bottom and the two lines with a$ are in the middle. Run it again and it is *still* the top and bottom lines which have the numbers offset to the right!
I blame the litte green men on Mars, myself.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: Bug - or unrecognised feature?
« Reply #10 on: Dec 23rd, 2017, 10:09am » |
|
on Dec 23rd, 2017, 02:21am, KenDown wrote:| When you run it the numbers in the top and bottom lines are further to the right than the numbers in the middle two lines. |
|
There's nothing strange going on here. What you are forgetting is that there are features of the PRINT statement which work properly only when all the characters output have the same width; specifically they are right-justified printing of numbers (which is the default) and tabulation using the TAB(n) function or the comma delimiter. The program you listed uses both right-justified numbers and the comma delimiter, so it is not surprising that it misbehaves.
PRINT simply counts the characters (bytes) you output - you can get the current value from the COUNT function - and assumes they all occupy the same width on the screen. When it tries to align the text to a specific column it outputs a number of spaces based on the current value of COUNT. If you select a proportional-spaced font, or use UTF-8 encoding, or incorporate 'non-printing' characters in strings, this doesn't work.
In that case you must take responsibility for formatting yourself, so if you want to have numbers printed right-justified, or tabulate output in columns, you cannot rely on the built-in features of the PRINT statement. Instead you will need to convert the numbers to strings (STR$), measure their width (WIDTH) and MOVE the graphics pointer to the appropriate place to achieve the required alignment.
Richard.
|
|
|
|
|
