Is clipping done automatically for PRINT?

[spicypixel]

Just curious to know if PRINT is clipped for what is displayed onscreen. Similarly if I have a Wide sprite are the edges clipped when offscreen.

I am presently using PRINT for a long text to scroll. I have written code for the PRINT to display only what can be displayed using MID$ and updating a pointer for the scroll and incrementing the MID$ start point but this won't work unless the font is fixed width and as my font is using kerning I decided to simply use LEN(Scrolltext$,TRUE) to find the max pixel length of the scrolltext and then use this as a pointer to wrap. So ideally it'd be nice to know if things are offscreen they're not using CPU and are clipped.

I also wondered is Viewport clipped, and if so I could use that to assist in speed if the PRINT isn't clipped.

Thanks in advance

[Slydog]

I don't know the answer to if PRINT or VIEWPORT is clipped.
I would guess other items would be clipped if they were entirely off screen, but I'm not sure how PRINT handles it.
And, I'm guessing that if PRINT isn't clipped normally, it won't be clipped inside a VIEWPORT.

I'm not sure how long your text string is, but you still have another option.
Instead of one long sprite, create say 10 sprites, each with a portion of the message.
Then you can control which of those 10 sprites to display depending on the scroll position and sprite widths.

Or move over to a custom print / font library using polyvectors, then you have full control over everything.

[spicypixel]

I can use MID$ as I mentioned and only display the chars for the line but it only works with a fixed width font. The text isn't that long so unlikely to be  a problem but thought I'd ask

[Slydog]

I don't see a command like 'PRINTWIDTH(str$)' that would return the width in pixels of a text string using the current font.
That may have been handy.

Although you could create this function, but it'd be slow, used mainly for situations like this for initializing.
Just plot the text and use SPRCOL() calls with a vertical single pixel bar, to find the left and right bounds.

But what I was suggesting was to print the string (using a proportional font) to a screen buffer (CREATESCREEN) that is large enough to hold the entire string.
Then create 10 more sprites by grabbing 1/10th each of the message.  (It would be a hard cut, most likely mid-character)
(Oh, and can you create screens larger than the display?  I'd hope so.)

[MrTAToad]

Use LEN(a$,TRUE) to return the pixel width of text

[spicypixel]

I don't see a command like 'PRINTWIDTH(str$)' that would return the width in pixels of a text string using the current font.
That may have been handy.

LEN(textstring$,TRUE) gives the value of the full length of the string in pixel width. I'm actually using this to determine when to loop the PRINT command but I see how you could use it if I wanted to split the string into a fixed number of created image sprites. For now I'm gonna stick with the PRINT command as the text is small but I may experiment with blitting screen width portions of the large text string sprite.

[Slydog]

Ha, I had thought there was a command for that!  I gave up looking too soon.
Looking into the LEN() command, is there no way to get the pixel width for a string using a FIXED WIDTH font? ha

[MrTAToad]

Could use it for that too most likely...

[spicypixel]

LEN(string$,FALSE) would work I'm sure

[Crivens]

I thought it was LEN(word$,kern%)? So without kern% it gives you the numbers of characters in the string, but using kern% it will give the pixel width of the string using the currently selected font (using the kern value you want to use with the print command).

Cheers

[Kitty Hello]

GLBasic does all the clipping for you. Viewport that is.

[spicypixel]

GLBasic does all the clipping for you. Viewport that is.

So am I correct in thinking the viewport would be better to use for a PRINT that went off screen than simply letting the text go off screen with just PRINT? I should use an FPS counter really I'm a lazy duffer lol

[Kitty Hello]

Yes, sure. That's much faster than tinkering with strings beforehand.