Mmmmmm....actually, the LSFR idea might not be far off what I had in mind at the start. I hadn't put two and two together. By separating the X and Y components it might be possible to reference a position or offset in a string of X or Y progressions, therefore just needing 2 references for each character. The frame is just then a progression along those strings.djnzx48 wrote: ↑Thu Aug 23, 2018 8:27 am Looks good! Although 1.5K for a font seems quite a lot. Could you somehow use an LFSR to select the pixels that turned on in each character, and so avoid storing them all one by one? The main problem is that it would involve a lot more iterations over each character, unless you somehow got it to only pick from the pixels that actually get drawn, and ignore all the empty space.
Instead of storing an x and y coordinate for each pixel, you could try storing an wrap-around x offset from the previous pixel. Then you could potentially store each pixel using 4 bits or less. Characters like i and j that have 'gaps' in them might pose problems though, and it would slow down as more pixels get drawn. If there aren't many characters using all 15 pixels it might not be too bad.
Proportional Text Print (catchy name TBA)
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: Proportional Text Print (catchy name TBA)
- Ast A. Moore
- Rick Dangerous
- Posts: 2641
- Joined: Mon Nov 13, 2017 3:16 pm
Re: Proportional Text Print (catchy name TBA)
If your font (well, your line, really) is 8 pixels tall, you can use the attribute address for tracking the current print position and then convert it into a bitmap address. It’s quite a bit faster and saves you the trouble of working around the crazy screen layout. It also gives you your carriage return/line feed for “free” (well, to a degree). Finally, if you wish to color in the text as you print it, you also get that automatically.arkannoyed wrote: ↑Thu Aug 23, 2018 8:26 amCurrently nothing as advanced or clever as splitting words. It uses 3 bytes at the start of a line, bit no. (80,40,20,10 etc), then screen address, followed by the text. the line ends with a control character to indicate that theres either a new print position, or its the end of printing.Ast A. Moore wrote: ↑Wed Aug 22, 2018 9:09 pm Does it auto-split words and start a new line when it reaches the righthand edge of the screen? I remember it took me a couple of tries to implement that just right in my proportional-width font printing routine. (I haven’t revisited it since, so the code is bit on the ugly side.)
If your line height is not a multiple of eight, then, yeah, you’re in trouble.
Every man should plant a tree, build a house, and write a ZX Spectrum game.
Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
- arkannoyed
- Manic Miner
- Posts: 438
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: Proportional Text Print (catchy name TBA)
I've used the ATTRs address in a few other routines to track the position. Actually with this routine, as long as you stay within a screen third, then just by incrementing E (of the DE screen address) when the global bit marker indicates to do so, gives no issues.
I'm now deep into examining the character code, trying out a few ideas!
I'm now deep into examining the character code, trying out a few ideas!
- Ast A. Moore
- Rick Dangerous
- Posts: 2641
- Joined: Mon Nov 13, 2017 3:16 pm
Re: Proportional Text Print (catchy name TBA)
Oh, yeah. Long as you’re not crossing a screen third’s boundary, you’re good.arkannoyed wrote: ↑Thu Aug 23, 2018 12:50 pm as long as you stay within a screen third, then just by incrementing E (of the DE screen address) when the global bit marker indicates to do so, gives no issues.
Every man should plant a tree, build a house, and write a ZX Spectrum game.
Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
Re: Proportional Text Print (catchy name TBA)
This is great stuff
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel • NXTP • ESP Update • ESP Reset • CSpect Plugins
SevenFFF / Threetwosevensixseven / colonel32
NXtel • NXTP • ESP Update • ESP Reset • CSpect Plugins
Re: Proportional Text Print (catchy name TBA)
Does it matter in what order the pixels get drawn? What I meant was not to store the pixels as an offset from the top left of the character, but a relative offset as the number of pixels to the right of the previous pixel. Then for a 5 pixel wide character, 4 bits is enough to go three lines down, and 3 bits will get you to the next line and a few pixels to the right, which should be enough to encode most characters (the problems would likely occur with characters that are both wide and have a lot of vertical space, like '_' or ','). Going downwards might work, except thin characters like '!', '.', or '|' would pose problems.
If the order of drawing is important, then you can get semi-random ordering with a 4-bit LSFR determining which pixel gets drawn each time round the loop, maybe with an offset for each character in the text so that they don't all draw in exactly the same way.
Your method sounds much better though so I'd just disregard this idea and go with the referencing thing instead.
If the order of drawing is important, then you can get semi-random ordering with a 4-bit LSFR determining which pixel gets drawn each time round the loop, maybe with an offset for each character in the text so that they don't all draw in exactly the same way.
Your method sounds much better though so I'd just disregard this idea and go with the referencing thing instead.