Atari BASIC questions

[+MrFish]

 

1 hour ago, IndyJones1023 said:

If I change the text to something longer, how do I change how far indented the text is?

 

160 SCRNX = 2.5 * ( 8 * SCALEX ) : SCRNY = 2.0 * ( 8 * SCALEY )

 

190 SCRNX = 2.5 * ( 8 * SCALEX ) : SCRNY = 3.0 * ( 8 * SCALEY )

 

Change the first numeric value defining SCRNX in these two lines. The values are in character spaces. So, in the above lines they're both inset 2.5 characters (of whatever size the characters currently are scaled to) from the left edge of the screen. So, if your text is longer than in the original program, you want to make the values smaller; if your text is shorter, you want to make the values bigger.

 

[_The Doctor__]

 

 

[_The Doctor__]

see the changes? 120 coordinate changed, 190 half a character distance changed.

[IndyJones1023]

Thanks again for all the help!

[+MrFish]

I just noticed I had 2 lines (the ATASCII definitions) nested one level deeper than they needed to be. So, they were both being executed 7 more times than necessary (for each character).

 

Here's the edited code and updated ATR. I also updated the compiled version (BIGTEXT.CTB) on the ATR.

 

10 GRAPHICS 15 + 16
20 POKE 712 , $98 : POKE 708 , $56 : POKE 709 , $DA : POKE 710 , $0E 

30 CHBASE = PEEK ( 756 ) * 256
40 DIM MYTEXT$ ( 10 )
50 SCALEX = 2 : SCALEY = 4

100 ------------------------------

110 COLOR 3
120 TEXT 68 , 54 , "THE"

150 COLOR 1
160 SCRNX = 2.5 * ( 8 * SCALEX ) : SCRNY = 2.0 * ( 8 * SCALEY )
170 MYTEXT$ = "RETRO" : EXEC RENDTEXT

180 COLOR 2
190 SCRNX = 2.5 * ( 8 * SCALEX ) : SCRNY = 3.0 * ( 8 * SCALEY )
200 MYTEXT$ = "SCENE" : EXEC RENDTEXT

999 GOTO 999

1000 ------------------------------

1010 PROC RENDTEXT

1020   FOR CHAR = 1 TO LEN ( MYTEXT$ )

1030     ATASCII = ASC ( MYTEXT$ ( CHAR , CHAR ) )
1040     IF ATASCII < 96 THEN ATASCII = ATASCII - 32

1050     FOR BYTEROW = 0 TO 7

1060       BYTE = PEEK ( ATASCII * 8 + CHBASE + BYTEROW )

1070       FOR BIT = 7 TO 0 STEP -1

1080         IF BYTE & ( 2 ^ BIT )

1090           X = SCRNX + ( 7 - BIT ) * SCALEX + ( CHAR - 1 ) * 8 * SCALEX
1100           Y = SCRNY + BYTEROW * SCALEY

1110           FOR HEIGHT = 0 TO SCALEY - 1
1120             FOR WIDTH = 0 TO SCALEX - 1
1130               PLOT X + WIDTH , Y + HEIGHT
1140             NEXT WIDTH
1150           NEXT HEIGHT

1160         ENDIF

1170       NEXT BIT

1180     NEXT BYTEROW

1190   NEXT CHAR

1200 ENDPROC
 

Turbo-BASIC XL 1.5 (NTSC).atr

 

[_The Doctor__]

You can also overlay as I have done, and you can overlay different text by changing mytext$ in between the overwrite. I also changed Case to show it works as well. Using the color registers you could also rotate color during the infinite loop.

Edited Friday at 03:54 PM by _The Doctor__

[+MrFish]

Added ability to use an external font file.

 

I couldn't find any Namco font file for the Ataris; so, I whipped one up.

I combined a few characters from 2 different well-known Namco fonts,

and I made a few minor adjustments myself.

 

[Note: Only the alphanumeric characters in the Namco font have been added thus far. Everything else is still Atari default characters.]

 

I left the Atari font still active as the system font. So, it could still be used,

and will be used if the TBXL "TEXT" function is called to render any text.

 

I changed the "THE" at the top to use whatever custom font is loaded.

So, the SCALEX and SCALEY variables are changed appropriately before

rendering that text.

 

Theoretically, any number of fonts could be used here simultaneously. 

They would just be loaded into their own strings (as I've done) or some

other area of memory, and the CHBASE variable needs to point to

whatever font is desired, before rendering any text.

 

10 GRAPHICS 15 + 16
20 POKE 712 , $98 : POKE 708 , $56 : POKE 709 , $DA : POKE 710 , $0E 

40 DIM MYTEXT$ ( 10 ) , FONT$ ( 1024 )

60 CHBASE = ADR ( FONT$ )
70 OPEN #1 , 4 , %0 , "D:Namco.fnt"
80 BGET #1 , CHBASE , 1024
90 CLOSE #1

100 ------------------------------

110 SCALEX = 1 : SCALEY = 1
120 COLOR 3
130 SCRNX = 8.4 * ( 8 * SCALEX ) : SCRNY = 6.58 * ( 8 * SCALEY )
140 MYTEXT$ = "THE" : EXEC RENDTEXT

150 SCALEX = 2 : SCALEY = 4
160 COLOR 1
170 SCRNX = 2.5 * ( 8 * SCALEX ) : SCRNY = 2.0 * ( 8 * SCALEY )
180 MYTEXT$ = "RETRO" : EXEC RENDTEXT

190 COLOR 2
200 SCRNX = 2.5 * ( 8 * SCALEX ) : SCRNY = 3.0 * ( 8 * SCALEY )
210 MYTEXT$ = "SCENE" : EXEC RENDTEXT

999 GOTO 999

1000 ------------------------------

1010 PROC RENDTEXT

1020   FOR CHAR = 1 TO LEN ( MYTEXT$ )

1030     ATASCII = ASC ( MYTEXT$ ( CHAR , CHAR ) )
1040     IF ATASCII < 96 THEN ATASCII = ATASCII - 32

1050     FOR BYTEROW = 0 TO 7

1060       BYTE = PEEK ( ATASCII * 8 + CHBASE + BYTEROW )

1070       FOR BIT = 7 TO 0 STEP -1

1080         IF BYTE & ( 2 ^ BIT )

1090           X = SCRNX + ( 7 - BIT ) * SCALEX + ( CHAR - 1 ) * 8 * SCALEX
1100           Y = SCRNY + BYTEROW * SCALEY

1110           FOR HEIGHT = 0 TO SCALEY - 1
1120             FOR WIDTH = 0 TO SCALEX - 1
1130               PLOT X + WIDTH , Y + HEIGHT
1140             NEXT WIDTH
1150           NEXT HEIGHT

1160         ENDIF

1170       NEXT BIT

1180     NEXT BYTEROW

1190   NEXT CHAR

1200 ENDPROC

 

 

Turbo-BASIC XL 1.5 (NTSC).atr

 

[_The Doctor__]

Deleted as I see you've done it, and made mention of it re: mutliple fonts anywhere on screen

Edited Friday at 05:59 PM by _The Doctor__

[+MrFish]

7 minutes ago, MrFish said:

Theoretically, any number of fonts could be used here simultaneously. 

They would just be loaded into their own strings (as I've done) or some

other area of memory, and the CHBASE variable needs to point to

whatever font is desired, before rendering any text.

2 minutes ago, _The Doctor__ said:

Since these are effectively plotted to the screen, fonts could be changed per render, allowing multiple fonts anywhere on the screen. Nice touch if added.

Yes, I mentioned that.

 

[_The Doctor__]

For sure, I was posting at the same time as you, twice! I deleted /edited my post and changes with example as you've already done it.

Thank you for allowing me to play within your thread and program

Edited Friday at 06:03 PM by _The Doctor__

[+MrFish]

1 hour ago, _The Doctor__ said:

For sure, I was posting at the same time as you, twice! I deleted /edited my post and changes with example as you've already done it.

Ah, I see.

 

1 hour ago, _The Doctor__ said:

Thank you for allowing me to play within your thread and program

No problem; have at it. The overlay text was a good idea. If you use 0.5 increments, you can get a more-subtle look too. If you use 4 underlays of the same color (offset in 4 different directions) with one overlay, you should be able to get something akin to outlining each letter. Will take a while to render, though.

 

I'll simplify the parameter editing part of the program, and maybe add some kind of interface, or at least some parameter input options.

 

[+MrFish]

Added a machine language routine to plot the fat pixels. All the nested loops and calculations are still in TBXL, but the fat pixels aren't drawn by looping a PLOT statement anymore.

 

Everything's the same for changing parameters, except for picking a color. Instead of using the BASIC COLOR statement, a color is chosen by one of the following.

 

COLRNUM = COLR1

COLRNUM = COLR2

COLRNUM = COLR3

 

I haven't provided a way to choose the background color (COLOR 0) to draw in (yet), as it's not really needed; but I'll add it for completeness and the ability to use it for some special cases that can be devised.

 

At this point, render speed should be very close to the same for a given string at any scaling.

 

Turbo-BASIC XL 1.5 (NTSC).atr

 

 

[_The Doctor__]

You will have your rotating colors free of charge

Edited yesterday at 04:22 AM by _The Doctor__

[+MrFish]

I was able to coax some dither out of the new fat-pixel renderer. This effectively gives 9 colors (10 counting background). It's restricted to X-axis scaling of 2x at the moment. It will work with Y-axis scaling in any even multiples.

 

Effective use of it depends on color selections, of course.

 

 

 

 

 

[_The Doctor__]

Our     T     is about 1 unit off to the right on all of our renders, if adjusted in the font itself will it help or hurt?  Or some special case adjust in the render? Single letter kern so to speak?

[+MrFish]

24 minutes ago, _The Doctor__ said:

Our     T     is about 1 unit off to the right on all of our renders, if adjusted in the font itself will it help or hurt?  Or some special case adjust in the render? Single letter kern so to speak?

It doesn't have anything to do with the renderer. It has to do with Namco choosing to define their characters in an uneven number of pixels (7). The Atari sys font doesn't exibit this with the "T" character, because its characters are defined in an even number of pixels (6). Certain characters can't fill the character space completely and look right; the "T" is one of them in the Namco font. This is also partly a symptom of working with monospaced fonts. Character geometries can't always adhere to dimensions where other characters work fine.

 

The pixel difference becomes more noticeable as the font gets scaled up.

 

[_The Doctor__]

That I understand but maybe we can adjust it is what I was getting at. We could do RE then TRO ourselves and adjust the start point but that's a bit of fun most won't want to do. For now that's what I'll check and see.

[+MrFish]

57 minutes ago, _The Doctor__ said:

That I understand but maybe we can adjust it is what I was getting at. We could do RE then TRO ourselves and adjust the start point but that's a bit of fun most won't want to do. For now that's what I'll check and see.

Good luck. You'll end up throwing something else off when you do that. The upper case "I" in the Namco font (and the "Y") also exhibits the same issue; but it probably ends up being a little-less noticeable because it has two horizontal bars to fill up the overall space better. In the case above (where I'm demonstrating dithers), it's also at the end of the word ATARI, so there's no spacing to compare it with on the right side.

 

Here are the Namco and Atari fonts. You can see that the Atari font ends up with spacing problems to the right of both its "M" and "W" (one pixel to the right of all the other characters), whereas these are no problem in the Namco font. You trade one problem for another with mono-spaced fonts. The Namco font is kinda nice, because there's more space to define each characters.

 

Namco Font

 

Atari System Font

[+MrFish]

1 hour ago, _The Doctor__ said:

That I understand but maybe we can adjust it is what I was getting at. We could do RE then TRO ourselves and adjust the start point but that's a bit of fun most won't want to do. For now that's what I'll check and see.

Sorry, it's late here. So, I didn't think through what you were asking; I was just focused on what you were saying about moving the two halves of the word separately. Actually, if you want to render the "T" in a string by itself, you can accomplish something here; because a font pixel is bigger than a screen pixel, in this case. So, you would render the word "RE RO", as a string, then you would render the "T" offset to the left by "0.05" of a scaled character. So, since the word "RETRO" starts getting rendered at 2.5, the "T" would be at 4.5 - 0.05 = 4.45.

 

So, you'd end up with this, which is what I think you're trying to accomplish. I didn't fix all the other occurrences (of "T"s and "I"s), just the "T" in RETRO, but it'd be the same process for them all. And, yeah, it actually looks pretty decent like that.

 

 

 

 

 

[_The Doctor__]

Exactly, that's what I was about to post with example. Now that I think on this, it could actually be automated with a flag or code in the render parser since we don't use all the char codes, we could assign one for adjust right and one for adjust left.

 

I think we're beyond the original ask on this one, and it's nice and simple right now. I have to download the next version and put in my edits again

 

um, I don't see the last multi color dither version file, or the one with the re ro t trick

[+MrFish]

33 minutes ago, MrFish said:

then you would render the "T" offset to the left by "0.05" of a scaled character. So, since the word "RETRO" starts getting rendered at 2.5, the "T" would be at 4.5 - 0.05 = 4.45.

Actually, this isn't exactly right -- but apparently it's close enough to work. I was trying to get to half a scaled pixel (hence the 0.05); but scaled pixels aren't 0.1 here, because a pixel is 1/8th of a character, not 1/10th. So, 1/8th is 0.125, which equals one scaled pixel; then half of that would be 0.0625 (rather than 0.05). So, the adjusted value would be 4.5 - 0.0625 = 4.4375. Might not matter at this scaling, but at a higher scaling (where there's more precision in pixels) it could matter.

 

18 minutes ago, _The Doctor__ said:

um, I don't see the last multi color dither version file, or the one with the re ro t trick

I'll have to upload it tomorrow; it's really late here.

 

[_The Doctor__]

Turbo-BASICXL1.5NTSC-RetroScene.atr

Run "D1:RTROSCN.TTB"

[IndyJones1023]

Amazing work, gentlemen!

[+MrFish]

7 hours ago, _The Doctor__ said:

That method works; but then you end up off adjustment at the end of the two lines. It still looks good, though.

 

[+MrFish]

Here's the version that allows dithering for text with 2x scaling on the X-Axis (combined with any even number scaling on the Y-Axis).

 

Dithers are assigned in the same way colors are.

 

COLRNUM = DITHER1

COLRNUM = DITHER2

etc...

 

The dithers are defined as follows.

 

DITHER1: Colors 1 & 2

DITHER2: Colors 2 & 3

DITHER3: Colors 1 & 3

DITHER4: Colors 1 & 0

DITHER5: Colors 2 & 0

DITHER6: Colors 3 & 0

 

There's a copy of the program that includes an example of the adjusted letter spacing as discussed above.

The name of the program using adjusted spacing is BGTXTADJ.TTB. The program without adjusted spacing is BIGTEXT.TTB.

 

Compiled versions of both programs are included. They use the same filenames as above, but with the extension CTB.

 

Spacing Adjusted

 

Normal Spacing

 

Turbo-BASIC XL 1.5 (NTSC).atr