Your Digital Media Has Never Looked So Good

 
User avatar
Komag
Topic Author
Posts: 808
Joined: Fri Aug 22, 2014 3:42 am

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

Tue May 12, 2015 5:58 pm

Have you actually measured how much overscan HDTVs do? From what I've measured it's very minor compared to CRTs, not as much as Roku says for the "safe zone" - I think they're just being conservative.

I tried the FPS code, I like it.

And I just got a used Roku 3 ($50), HOLY CRAP it's fast!!! All this time trudging along working with classic Rokus and other models trying to squeeze performance. I just compared my Roku HD 2500 - first room in game I get around 4000 fps, Roku 3 gets f-r-i-c-k-i-n 80,000 fps!!! I piled on as much activity as I could in the game and it never dipped below 50,000, far above a drawable 60 fps in-game with lots of room to spare. :mrgreen:
 
EnTerr
** Valued Community Member **
Posts: 3834
Joined: Sun Jan 02, 2011 2:41 am

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

Tue May 12, 2015 7:46 pm

Yes, i did some research for "Tangrams" earlier:
  • What i measured was <5%.
  • Roku RTFM recommends allowing 5% edges for "action safe" zone and 10% for "title safe".
  • FireTV UX guidelines say 90% safe zone, 5% margins.
  • Android TV docs are confused, in one place showing 5% margins and right after that speaking in pixels give vertical margin minimum at 27px/1080 = 2.5%. In another place, "10% margin on all sides of your layout. This translates into ... a 27dp margin on the top and bottom" - where "dp" is "density-independent pixels" Android PITA, which after some research translates to vertical margin 36px on 720p TV (=5%).
  • Wikipedia discussed the lack of standard
After weighing in all this, i settled on 5% per side.

Re FPS, your numbers can't be right. You can't get >60 FPS on Roku... ever.
Last edited by EnTerr on Tue May 12, 2015 11:01 pm, edited 1 time in total.
 
User avatar
TheEndless
** Valued Community Member **
Posts: 9231
Joined: Mon Oct 04, 2004 10:15 am
Location: US
Contact:

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

Tue May 12, 2015 8:15 pm

Komag wrote:
And I just got a used Roku 3 ($50), HOLY CRAP it's fast!!! All this time trudging along working with classic Rokus and other models trying to squeeze performance. I just compared my Roku HD 2500 - first room in game I get around 4000 fps, Roku 3 gets f-r-i-c-k-i-n 80,000 fps!!! I piled on as much activity as I could in the game and it never dipped below 50,000, far above a drawable 60 fps in-game with lots of room to spare. :mrgreen:

Sounds like you didn't implement it quite right. As EnTerr noted, it's impossible to get more than 60 fps on any Roku. SwapBuffers() requires 16ms as a minimum.

EnTerr wrote:
In other words, since overscan is the dominant mode - target that from the get-go and handle non-overscan (full resolution) as the exception.

Agreed, but if he's already coded the majority of his game, then that sounds like a v2 optimization. Drawing to an roBitmap and scaling that also gives him the ability to code in a user configurable overscan adjustment.

EnTerr wrote:
FireTV UX guidelines say 90% safe zone, 5% margins.

Interestingly, the FireTV has an overscan adjustment built in via the Display->Calibrate Display setting.

EnTerr wrote:
Android TV docs are confused

Perhaps even more interestingly, Android TV doesn't even provide an option for setting the display resolution, let alone adjust for overscan.
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
 
User avatar
Komag
Topic Author
Posts: 808
Joined: Fri Aug 22, 2014 3:42 am

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

Wed May 13, 2015 2:16 am

Oh I know drawable 60fps is the max that can be displayed. I should call these "cycles" rather than frames. My program uses a tick counter, and essentially what's happening is that it ticks up to 24ms, then does "everything" including swap buffers, resetting the tick counter. So Roku 3 is mostly counting 80,000 cycles in-between frames, around 18 cycles per ms I counted.

My "everything" takes about 7ms on Roku 3 (so it misses counting cycles for that long), about 20ms on Roku 2 XS, and longer on weaker boxes. If it takes longer than 24ms, the game will appear slow, but can be run on 2x speed where it waits till 48ms and moves everything twice as far instead. There is also a 4x speed that waits till 96ms and moves everything 4x as far, so the slowest Rokus can still keep up with overall game speed.

I programmed the whole system before I understood anything about easing functions or even heard of them, and a lot of the system designs rely on the tick counting mechanism for proper timing and interaction. I've entertained the idea of going back and re-factoring almost everything, but the prospect makes me shudder, and it works quite well as-is.
 
User avatar
Komag
Topic Author
Posts: 808
Joined: Fri Aug 22, 2014 3:42 am

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

Thu May 14, 2015 12:25 pm

After some more testing, I've discovered that drawing everything to a bitmap and then scaling that (or even just drawing that without any scaling) to the screen was a pretty big performance hit on anything other than Roku 3.

It varied a lot between different models, but in all cases it's much better to just draw to screen normally, sometimes about 10% difference, other times as much as double (or 50%, depending on which way you're comparing!).
 
EnTerr
** Valued Community Member **
Posts: 3834
Joined: Sun Jan 02, 2011 2:41 am

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

Thu May 14, 2015 5:42 pm

TheEndless wrote:
... Going this route would require scaling all of the bitmaps either before or while drawing to the region. Since it sounds like Komag is using the compositor, that would cause a real headache, as it would require scaling the sprites when you create them.

It's not even half as bad as it sounds at first. One would have to down-size every bitmap to 90% only once - on load/creation. (You can probably sketch general function for that on the back of a napkin; i'll have to browse the docs for that). Then drawing speed per frame won't be affected at all (actually will be 10-20% faster but let's not split hairs).

The one annoying part remaining is to re-structure the coordinates/placements - and i share the annoyance, if one had planned for 1280x720 chopped into a grid, suddenly now there is 1152x648 and the numbers meticulously selected to be "round" (in some sense) suddenly will turn "odd".

I think that would be the best option if doing retro-fitting. And i remain of the opinion it's best to design for TV overscan (linear-90% safe viewing area) and consider full-image TVs (100%) the rare exception. Or can someone state less than 80% TV sets are in overscan mode?! As a budding developer for TV, I am very much interested to hear market stats if any exist.

Here is something interesting i just read - which sheds light on how this PITA came out to be - turns out to allow for aging of cathode ray tubes (CRT)!
https://archive.is/D5U23 wrote:
A Little Background on "Underscan:"
Back in the early days of television, the image on their little screens shrunk as TV sets got older because the electron gun that created the picture didn't move as well as it aged. As a result, a black border would appear around the edges of the picture. The electron gun could be recalibrated to fill the whole screen, but that was time consuming and costly. The solution that the TV industry settled upon was to "crank up" the electron guns of new picture tubes to paint the image beyond the borders of the picture tube. Then, as a TV set aged, more of the image would become visible rather than black bands appearing.

While this remedy worked, it created two problems. First, the broadcast industry coined the terms underscan and overscan and gave them counterintuitive meanings: "overscan" is the central part of the image that you can see on standard TV, whereas "underscan" is the full frame, which is visible only a production monitor. So the underscan actually shows more more of the picture than the overscan.

Second, the underscan solution has frustrated videographers and graphic designers to this day because they cannot be sure just how much of the frame will be visible on any given TV set. So they have to make sure that everything essential to scene is visible within the "Safe Area" while also taking care that nothing extraneous creeps into the overscan margin.
So a brand new TV would be showing 90% of the beam (angularly, 81% as area) - and as electron gun ages, the cone will narrow and eventually 100% of the image will be on screen. Later analog margins got abused to encode CC/teletext/EPG in them - and that's how we are in this morass in the era of all-digital flat-screen HD TVs.
 
User avatar
TheEndless
** Valued Community Member **
Posts: 9231
Joined: Mon Oct 04, 2004 10:15 am
Location: US
Contact:

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

Thu May 14, 2015 8:22 pm

EnTerr wrote:
TheEndless wrote:
... Going this route would require scaling all of the bitmaps either before or while drawing to the region. Since it sounds like Komag is using the compositor, that would cause a real headache, as it would require scaling the sprites when you create them.

It's not even half as bad as it sounds at first. One would have to down-size every bitmap to 90% only once - on load/creation. (You can probably sketch general function for that on the back of a napkin; i'll have to browse the docs for that). Then drawing speed per frame won't be affected at all (actually will be 10-20% faster but let's not split hairs).

I don't know what his game looks like, but if he were going this route (and it sounds like he'll have to now that he's run into the performance hit I warned about earlier), it'd make much more sense to just resize all of the source images themselves. No need to scale them in the channel code. If they're character sprites, then he may not need to resize them at all.. just make the game board a little smaller.

EnTerr wrote:
And i remain of the opinion it's best to design for TV overscan (linear-90% safe viewing area) and consider full-image TVs (100%) the rare exception.

And I still agree... ;)
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)

Who is online

Users browsing this forum: No registered users and 5 guests