dirkdeftly

18th August 2003 03:31 UTC

Fullscreen overlay mode
Okay, I searched the forum and came up with nothing of relevance - or, I should say, I *tried* to search the forum; apparently the search engine sucks donkey and I can't search for phrases (or at least it's not obvious how).
Anyway, I want to know what the hell fullscreen overlay mode does. I've fiddled with it for the last half hour and I still haven't figured it out.
(Deepest apologies if I missed a relevant thread but all the searches I tried turned up crap)

S-uper_T-oast

18th August 2003 03:35 UTC

As far as I can guess it works just like regular Overlay mode but sets the whole screen to the overlay color.
I usually use fullscreen overlay mode and have only found one glitch with it, it sometimes freezes up winamp and doesn't go fullscreen, and then it locks up mostly everything and my screen gets really messy, but this rarely happens. Don't know if it was talked about anywere else though, don't care either.

jheriko

18th August 2003 07:50 UTC

I think that all it does is use the hardware overlay for fullscreen in the same way that Windows Media Player uses it for fullscreen video. I can't see the use of it since it would mean that on a multi monitor system it would only draw avs to one monitor.. on the flipside it might be a more stable alternative to the regular fullscreen mode (I'm not 100% sure of this), which I have occasionally had problems with (like the drawing of the winamp window every other frame in the middle of my fullscreen avs).

Zevensoft

18th August 2003 07:59 UTC

Fullscreen Overlay is also VERY fast compared to normal Fullscreen. Mainly because it uses your video cards acceleration to grab the AVS frame directly from the hDC and output it through the overlay filter, thus smoothing it or whatever your video card does to help overlays.

jheriko

18th August 2003 09:17 UTC

Doesn't hDC = handle for Device Context, so how can you grab a frame from it? Surely it grabs the frame from the actual 'device', which I'd assume is the square of AVS window that is drawn to, which is probably a control which has a DC because it is set up as a 'window class', right? Then again Windows programming terminology does tend to make no sense, both 'device' and 'window class' don't mean what you think they would.

Zevensoft

18th August 2003 10:08 UTC

hDC's are handles to bitmaps (basically).

Magic.X

18th August 2003 10:15 UTC

... where objects are to be drawn on the screen.

IMHO Fullscreen Overlay draws directly to the overlay and avoids using a hdc. Maybe i'm just wrong but this seems logical to me.

jheriko

18th August 2003 10:41 UTC

Originally posted by Zevensoft
hDC's are handles to bitmaps (basically).

Magic.X

18th August 2003 11:33 UTC

To demystify the hDC:

A device context is a structure that defines a set of graphic objects and their associated attributes, and the graphic modes that affect output. The graphic objects include a pen for line drawing, a brush for painting and filling, a bitmap for copying or scrolling parts of the screen, a palette for defining the set of available colors, a region for clipping and other operations, and a path for painting and drawing operations.

dirkdeftly

19th August 2003 00:45 UTC

lmao. i ask what fullscreen overlay does and i've already gotten 3 entirely different explanations of it (one from nic on #ff). what i can tell you is my comp is doing something entirely different to anything you guys have told me :D

Magic.X

19th August 2003 06:16 UTC

:D
In this case, my dear Atero, why the heck don't you tell us what your comp DOES? :p

Deamon

19th August 2003 07:24 UTC

because he likes it when we ask him for it.

jheriko

19th August 2003 20:51 UTC

Actually the description I gave and the description by Zevensoft are of the same thing... he just knows more about its guts than I do. Its also probably the correct description because there really isn't any other way to use the hardware overlay for fullscreen.

dirkdeftly

20th August 2003 01:23 UTC

well, what my comp is doing is going fullscreen with neither the current windowed screensize or the selected fullscreen screensize OR the current Windows screensize, and it has a hexagonal mesh of dots on it. which makes absolutely no sense to me. hence this post.

Magic.X

20th August 2003 06:15 UTC

Duh! This is weird. Maybe this is caused by some hardware reasons? As this function is based on video card acceleration, maybe your vc has problems displaying it correctly.

Does normal Overlay and Video Fullscreen work?

dirkdeftly

20th August 2003 07:50 UTC

fullscreen works...overlay has that same mesh of dots :wierd:

pure-krypton

20th August 2003 08:05 UTC

wtf's a bpp? Beat per pixel???


The only difference i could pick up was the colours. Fullscrean overlay, duller colours.
Without fullscrean overlay, brighter colours and sharper viewing but it's a few FPS's slower though

Zevensoft

20th August 2003 08:16 UTC

Atero, you're using a 16 bit (or lower :igor: ) resolution. Try 24/32 bit instead.

pure-krypton

20th August 2003 08:29 UTC

Is it posible to edit someone elses message?

Magic.X

20th August 2003 08:33 UTC

Use the http://forums.winamp.com/images/edit.gif Button to edit your posts (should work for 3 hours after the post has been made). Of course you can NOT edit others Messages.

pure-krypton

20th August 2003 08:41 UTC

I know ho to edit my messages, but I wasn't sure if you could edit someone elses messages. I would had some fun if that was possible. Oh well

Deamon

20th August 2003 09:29 UTC

*sigh*, the misunderstandings afterwards would be so extremely big, you could have figured that out yourself, right?

Magic.X

21st August 2003 08:54 UTC

Originally posted by Zevensoft
Atero, try 24/32 bit

Deamon

21st August 2003 09:20 UTC

I guess 24 won't. Though 32 might, since AVS is originally calculated in 32bit. Every other setting has to be recalculated and therefor slower.

UnConeD

21st August 2003 15:31 UTC

In case you're wondering what overlays are, here's the deal... when you're playing video on the screen, it has to be updated a lot. But in effect, it's only one small area that is updated, and it's located somewhere in the center of the screen (windowed) or all over the place (full-screen). That's quite memory/cache intensive.

So someone thought of overlay mode: rather than doing all the copying in software, just put the video in a separate buffer, and let the videocard draw it as it sends the image to your monitor. After all, a video card is continuously scanning over the image anyway as it sends it to your monitor, so doing a simple switch between video and regular screen at the appropriate pixels is no big deal. On top of that, the video-card can scale/stretch the image very fast, because that sort of stuff can be put into silicon at no cost.

Unfortunately, there's the problem that in a windowed system, the video-area can be partially (or wholly) occluded. There's no easy way to get this info from windows, and even if you could, building support for irregularly shaped viewports for overlay would defeat the whole point because then the videocard would need a lot of extra logic too.

So, they use colorkeying: the video-area is filled with an uncommon, unique color, and the overlay is only drawn inside the designated viewport and when the color in the framebuffer (the 'screen') matches the color-key.

Now fullscreen overlay mode. Normally, going fullscreen required a resolution change, because otherwise the stretching would be done in software, which is either slow (bilinear) or ugly (point). Plus it wouldn't be able to handle arbitrary sizes anyway. So mediaplayers use the overlay functionality for the entire screen. This has some advantages:

- Bilinear filtering is done for free
- No resolution change is required
- Arbitrary sizes are allowed (though not in AVS)

Unfortunately, the overlay buffer's format is not RGB I believe, but YUV or a similar one. YUV or YCrCb stores the color as a brightness 'Y' plus a redness/blueness factor. It's halfway between HSL and RGB.
Interpolating in YUV gives you great results for natural photos and film, but looks like crap for computer generated stuff because the color can bleed at sharp edges.

As far as grabbing the image from the hDC, that would be very slow on Windows. I'm pretty sure AVS just creates a 32-bit DIBs (CreateDIBSection) and uses the returned pointer to directly read/write to the bitmap's pixels.

dirkdeftly

21st August 2003 17:04 UTC

d00d...that is so not cool...one of my m$ games musta set my mon to 16 bit while i was looking >_< yea it did help get rid of that mesh, thanks

Deamon

21st August 2003 22:13 UTC

Now that certainly cleared some things up over here, thanks UnConeD.

Magic.X

22nd August 2003 07:17 UTC

UnConeD = Computer Encyclopedia :D

Thank ya!

Deamon

22nd August 2003 10:08 UTC

lol, yep, that's a pretty accurate description. :)