Infinite "hall-o-mirrors" effect with scaled screen

You can't draw a bitmap/screen onto itself. If you want to scale down, then you'd need to first draw to a bitmap, then draw that scaled to the screen.

you may want to try creating a bitmap the size of your scale, create a screen region and scale that into the bitmap then write the bitmap to the screen. Using the same object as source and destination has mixed results but Can be useful to do some single step fade outs

I'm not sure why you thought this would work other than an intense desire to avoid having to re-locate everything( understandable).
It would only work if you could write the screen to a bitmap, clear the screen and then draw the bitmap at 90%. You might get 3FPS on a Roku3.
On a 2XS? fergetaboutit.

"TheEndless" wrote:
You can't draw a bitmap/screen onto itself. If you want to scale down, then you'd need to first draw to a bitmap, then draw that scaled to the screen.

Sure you can 😛 - although i won't consider the behavior guaranteed across models.
It's pretty much what you get when connecting camcorder live to a TV and then point the camera at the screen: https://www.youtube.com/watch?v=Y-gqMTt3IUg
(@squirreltown - there be some lemonade in that?)

Maybe something can be done by "cutting" piece of roScreen with roRegion and do most all drawing to that roRegion instead of the screen? I have never used it - but drawing to a region directly affects the parent bitmap, no?

Alright, I added a bitmap just after creating my screen, called "sizer", and set all my regions to draw to sizer instead of to screen.
I also added a boolean flag called "shrink" to my global system "sy" variables, which can be changed in the game settings.
Then, just before screen.SwapBuffers() I have:

	IF m.sy.shrink THEN screen.DrawScaledObject(128, 72, 0.8, 0.8, sizer) ELSE screen.DrawObject(0, 0, sizer)
	screen.SwapBuffers()

And it works great, exactly as wanted! 😄

My plan is to offer this for those 17 people out there who play on an old CRT and have too much overscan and can't see the edges of the game which are sometimes important, rather than never being able to use the outside areas for needful things.

"Komag" wrote:
Alright, I added a bitmap just after creating my screen, called "sizer", and set all my regions to draw to sizer instead of to screen.
I also added a boolean flag called "shrink" to my global system "sy" variables, which can be changed in the game settings.
Then, just before screen.SwapBuffers() I have:

	IF m.sy.shrink THEN screen.DrawScaledObject(128, 72, 0.8, 0.8, sizer) ELSE screen.DrawObject(0, 0, sizer)
	screen.SwapBuffers()

And it works great, exactly as wanted! 😄

My plan is to offer this for those 17 people out there who play on an old CRT and have too much overscan and can't see the edges of the game which are sometimes important, rather than never being able to use the outside areas for needful things.

I'm sure you've already noticed, but drawing to a bitmap first, then to the screen will effectively cut your framerate in half. If you're already being governed down to 60fps anyway by SwapBuffers, then it shouldn't be an issue, but worth noting, especially on the slower boxes (I'm looking at you Roku 1).

No, I haven't noticed that, but perhaps there is some performance impact and I'm just not seeing it. How can I measure it? The way my cycle works it doesn't seem like it would cut the framerate in half, I still have do drawAll() on the compositors and SwapBuffers() on the screen regardless. I may be making a newbie mistake in my understanding of how it all works though.

"Komag" wrote:
No, I haven't noticed that, but perhaps there is some performance impact and I'm just not seeing it. How can I measure it? The way my cycle works it doesn't seem like it would cut the framerate in half, I still have do drawAll() on the compositors and SwapBuffers() on the screen regardless. I may be making a newbie mistake in my understanding of how it all works though.

If you haven't noticed an impact, then it doesn't really matter. I monitor my framerate by counting the passes through my event loop and outputting the number of frames every seconds.. something along the lines of...

fpsTimer = CreateObject("roTimespan")
frames = 0
While True
    ' increment the frame counter
    frames = frames + 1

    ' Do screen updates
    screen.SwapBuffers()

    If fpsTimer.TotalMilliseconds() >= 1000 Then
        ? "FPS:"; frames
        ' Reset the timer and frame counter
        fpsTimer.Mark()
        frames = 0
    End If
End While

DISCLAIMER: If you have any level of OCD, doing this is probably a bad idea. I regularly find myself getting distracted trying to get the framerate up one or two points.

"EnTerr" wrote:
Maybe something can be done by "cutting" piece of roScreen with roRegion and do most all drawing to that roRegion instead of the screen? I have never used it - but drawing to a region directly affects the parent bitmap, no?

TheEndless - whatever i said, was that crazy talk? Inquiring mind wants to know

"Komag" wrote:
My plan is to offer this for those 17 people out there who play on an old CRT and have too much overscan and can't see the edges of the game which are sometimes important, rather than never being able to use the outside areas for needful things.

17 is the most random number but i think there are slightly more TVs affected by overscan. My guess is that something like 95% of all sets have overscan=on and you should be prepared of losing 5% on each side almost everywhere. Overscan is the default setting for all TVs for "hysterical" reasons. Theoretically that can be turned off for many TVs but only the most avid gamers know about that setting. Not to mention that (older?!) 720p TVs don't have that. And that doing that on some Samsungs is so hacky, i could not believe when i read it first in forums - i was sure it's an urban legend (works only with HDMI 1 and you have to rename the port to "PC", which has magic effect).

"EnTerr" wrote:

"EnTerr" wrote:
Maybe something can be done by "cutting" piece of roScreen with roRegion and do most all drawing to that roRegion instead of the screen? I have never used it - but drawing to a region directly affects the parent bitmap, no?

@TheEndless - whatever i said, was that crazy talk? Inquiring mind wants to know

A region effectively just offsets your x and y and clips draws to the width and height of the region. Otherwise it's identical to drawing directly to the bitmap/screen. Using a region of roScreen would result in the same "hall-o-mirrors" effect.