50 Hz

[muta...@gmail.com]

My understanding is that European TVs did a scan from
top to bottom 50 times a second, but it was only ever
every second row (ie interlaced).

There were only 25 genuine frames per second.

And the 50 Hz was a limitation of light decay from
phosphor.

For the goal of "beating the human eye" as far as
smooth motion is concerned, I don't know what the
number is. 25 may be overkill.

And my understanding is that with monitors, especially
LCD monitors, 50 Hz is not a consideration.

So.

If I want to display a cartoon on a monitor, using PDOS,
how many frames do I need to draw per second?

The only timer I have that I'm aware of is 18.2 ticks per second.

So what I can do is display one frame, and then, if I displayed
it quickly enough, I can wait for the next tick to arrive.

So my question is - is 18 frames per second enough to beat
the human eye, at least for cartoons?

Thanks. Paul.

[JJ]

On Sat, 11 Feb 2023 09:32:18 -0800 (PST), muta...@gmail.com wrote:
>
> So my question is - is 18 frames per second enough to beat
> the human eye, at least for cartoons?

Disney initially used 12fps for TV format. So, I think 18fps is enough.

[muta...@gmail.com]

Ok, great!

Which is exactly what I'm after in fact.

https://en.wikipedia.org/wiki/Steamboat_Willie

Under current copyright law, Steamboat Willie will enter the US public domain on January 1, 2024.

Beginning in 2022, Republican lawmakers vowed to oppose any future attempt to extend the copyright term due to their opposition to some of Disney's progressive political stances


There are no more US elections before 2024-01-01, so we're in
with a reasonable shot of getting hold of this.

Some people have insisted it will never happen, but I believe we
will run out the clock.

It would be good if PDOS was ready for it.

I assume this is thus covered under the 12 fps. The Wikipedia
article didn't explicitly say that.

BFN. Paul.

[wolfgang kern]

On 11/02/2023 18:32, muta...@gmail.com wrote:
> My understanding is that European TVs did a scan from
> top to bottom 50 times a second, but it was only ever
> every second row (ie interlaced).
>
> There were only 25 genuine frames per second.
>
> And the 50 Hz was a limitation of light decay from
> phosphor.
>
> For the goal of "beating the human eye" as far as
> smooth motion is concerned, I don't know what the
> number is. 25 may be overkill.

no it's not overkill in terms of health and comfort.
Higher frequency gives you lesser headache and you can
watch longer before eyes start yo blur.

> And my understanding is that with monitors, especially
> LCD monitors, 50 Hz is not a consideration.

Most European power-grids are at 50 Hz and it was cheap
to use this as a frame time base. But newer Monitors and
Graphic cards prefer 60 Hz which gives you comfortable
30 fps on LCD or plasma.

> So.
>
> If I want to display a cartoon on a monitor, using PDOS,
> how many frames do I need to draw per second?
> The only timer I have that I'm aware of is 18.2 ticks per second.

the PIT timer is programmable, mine runs at 1.0 KHz aka 1 mSec.

> So what I can do is display one frame, and then, if I displayed
> it quickly enough, I can wait for the next tick to arrive.

> So my question is - is 18 frames per second enough to beat
> the human eye, at least for cartoons?

enough to have your toons look as moving smooth, but I wouldn't
recommend to watch such for longer periods.

It's not for nothing that all my monitors work 30fps or more.
But the main speed issue is the amount of data per frame, so
many modern games break frames down to avoid flicker.
__
wolfgang

[muta...@gmail.com]

On Sunday, February 12, 2023 at 3:38:33 PM UTC+8, wolfgang kern wrote:

> > So my question is - is 18 frames per second enough to beat
> > the human eye, at least for cartoons?

> enough to have your toons look as moving smooth, but I wouldn't
> recommend to watch such for longer periods.
>
> It's not for nothing that all my monitors work 30fps or more.

Sorry, I'm confused. Isn't the refresh of the monitor
separate from updating the buffer?

Even if I only do a full screen worth of BosWritePixel() calls
once per second, doesn't some piece of hardware read that
buffer independently and refresh the physical screen as often
as required, so 30 fps (all frames identical) as per recommendation?

Or is the issue that I need to complete that write of the
screen within 1/30 second so that a partial screen is
not read and acted upon by the hardware?

Thanks. Paul.

[wolfgang kern]

On 13/02/2023 13:01, muta...@gmail.com wrote:
> On Sunday, February 12, 2023 at 3:38:33 PM UTC+8, wolfgang kern wrote:
>
>>> So my question is - is 18 frames per second enough to beat
>>> the human eye, at least for cartoons?
>
>> enough to have your toons look as moving smooth, but I wouldn't
>> recommend to watch such for longer periods.
>>
>> It's not for nothing that all my monitors work 30fps or more.

> Sorry, I'm confused. Isn't the refresh of the monitor
> separate from updating the buffer?

what would you encounter if not both act in sync ...?

> Even if I only do a full screen worth of BosWritePixel() calls
> once per second, doesn't some piece of hardware read that
> buffer independently and refresh the physical screen as often
> as required, so 30 fps (all frames identical) as per recommendation?

DOSwritepixel ? it's awful slow AFAIR.

yes, as long you don't alter screen contents in between.
but as these old TV like monitors had to refresh all pixels at
their frame rate anyway the software checked on beam-RETRACE:
see RBIL for vertical retrace info bit in the VGA-section.
but see more about that below.

> Or is the issue that I need to complete that write of the
> screen within 1/30 second so that a partial screen is
> not read and acted upon by the hardware?

the hardware will just stupid follow its setup timing,
which depends on resolution and monitor abilities.
So you need to avoid altering screen contents in the middle
of a hardware frame display.

And even modern graphic cards are double/triple buffered today
it's easy to produce flicker/garbage/tiling w/o taking care.

fill a full graphic page will take some time
(depends on speed of BUS, DRAM and Graphic RAM) and it should be
done within one time frame
but the write have to go to a current invisible graphic page
which is then swapped to become visible during V-retrace.
__
wolfgang