Yathosho

12th August 2006 10:02 UTC

Custom BPM
hello, i'm new to this avs thing. can anybody please explain what "reverse" in custom bpm does? :D

ASD5A

12th August 2006 10:34 UTC

"reverse" switches the indication of beat.
ie. if a beat is detected custom bpm will output that there is no beat.
and if there is no beat custom bpm will output that there is a beat.

i hope you understand my crappy explanation.

Tuggummi

12th August 2006 10:37 UTC

In other words

Regular:
sound-sound-sound-sound-!BEAT!-sound-sound-sound

Reverse:
!BEAT!-!BEAT!-!BEAT!-!BEAT!-sound-!BEAT!-!BEAT!-!BEAT!



A explanation even a 3 year old or me could understand.

Warrior of the Light

6th September 2006 16:35 UTC

Another n00b question; I didn't have the balls to create a new thead :o

> What does 'Page Flipping' in the Fullscreen options do?

I'm writing a Quick Start Guide for AVS and I'd like to explain it

jheriko

6th September 2006 16:46 UTC

Page flipping is probably double buffering.

In theory (and in practice) double buffering works like turning a page then turning it back, that it and it claims to make things "smoother but a little slower" which also fits double buffering.

Double buffering is where the renderer draws to an invisible buffer and then renders that to the screen when its finished. This stops the 'tearing' artefact.

I'll test it when I get home... which is soon cos its the end of my work day. Yay!

jheriko

6th September 2006 17:18 UTC

Sorry, now that I am home and have checked... what I describe above is labelled "Wait for retrace"

EDIT: Page flipping is the same, but instead of copying the whole buffer, once the trace is complete, it swaps the pointers to the buffers. since these are 32-bit addresses you can swap the buffers in the time it takes to copy a single pixel, instead of the whole screen of them.

Warrior of the Light

6th September 2006 19:04 UTC

Let's see if I got it straight (in general terms).

Raw projection:
AVS renders to buffer1. buffer1 is projected to the screen.

Wait for retrace:
AVS renders to buffer2.
If buffer2 is full, buffer1 = buffer2. buffer1 is projected to the screen.

Page flipping
(using buffer[0] and buffer[1], a is a boolean)
AVS renders to buffer[a]. buffer[not a] is projected to the screen.
(I know that a isn't an integer but you get the point)
If the render buffer is full, a=not a

--

Is that it? If so, it makes me wonder why the normal wait for retrace option is still used.
Also makes me wonder about the 'slower..' warning. PF should, by this definition, be faster than 'wait for retrace'.

jheriko

7th September 2006 15:24 UTC

I'm not sure why page flipping is slower and smoother it might mean something other than the standard meaning for avs.

Manipulating a single pointer is invariably faster than manipulating a large 2D array. However if the pointer is in software memory then the buffer would still need copying to the graphics card... I will experiment some more when I get home today.

Its possible that page flipping and wait for retrace interact with each other, or that one has precedence over the other. In this case the 'slower and smoother' might be referring to a regular render, since page flipping waits for a retrace it will reduce the framerate (slower) for the benefit of removing the 'cuts' (smoother). I'll have to see if page flipping forces wait for retrace or not.

PAK-9

9th September 2006 19:56 UTC

There is no reason why wait for retrace and page flipping would 'interact' with each other.. and a precidence would imply they are mutually exclusive which they are not.

I do agree though, its a bit confusing as to why it is labelled as 'slower' when in actuality it should be faster.

Warrior of the Light

10th September 2006 22:51 UTC

I'm also puzzled about why it's only in the Fullscreen options and not in Display..

It could be that it simply was not added yet, or there might be a reason why it's not possible for that mode - if it is what we think it is to begin with.

I've been through the soucefile, but I didn't have much luck with finding it so far.
But then, I'm just a C++ newb

--
@Yathosho: sorry for hijacking your thread; I had guessed that everbody but me knew it..

StevenRoy

20th September 2006 22:37 UTC

This is probably more accurate:

"Direct":
AVS copies each frame directly to the screen (more accurately, the "front buffer" in video memory) as soon as it's rendered. (Since the frame is assembled in memory before being copied to the screen, this is actually a form of software double-buffering.)

Wait for retrace:
AVS waits for the next vertical retrace, so it can copy each frame directly to video memory while nothing is actually being drawn on the screen. Results: No "tearing" (unless your computer's slow), smoother animation, and the animation can't go faster than the refresh rate of the monitor (which is as it should be, in my view).

Page flipping:
AVS copies each frame to a "back buffer" in video memory as soon as it's rendered, then instructs the video hardware to swap that buffer for the active front buffer. Depending on the video card, this may happen immediately (with possible tearing) or, more likely, during a retrace. If the video card waits for the retrace, though, AVS is still free to work on the next frame during this time. Thus, it may still be limited to the refresh rate of the monitor (as it should be), but it should be smoother and slightly faster overall than with just "Wait for retrace".

This hardware double-buffering, by the way, can't be used on the desktop, because it'd flip the entire desktop. It only works with full-screen modes, and possibly overlays. That's why it can't be applied to AVS in a window (unless it's running in overlay mode, but I don't think that support is complete).

All of this is assuming, of course, that this part of AVS is programmed the way that I would've done it. I've got the source downloaded, so I might have to take a look at it to confirm that this is right. (Pity I don't program in C++, otherwise I might even try to revive the project. There's so much code there that I could probably optimise...)