Misconception about GBC / GBA interlacing

Discussion of programming and development for the original Game Boy and Game Boy Color.
Post Reply
User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

Misconception about GBC / GBA interlacing

Post by mikejmoffitt »

So I hear a lot of people say things like, "The Game Boy Color's screen is interlaced", and the same for the GBA. Attempts to recreate this have involved sending even and odd lines to be updated, effectively halving the amount of data sent.

However, from doing some tests with objects flashing at 30hz and just playing the thing it appears this is not the case. The LCD itself is interlaced, but not at 30hz, and the data itself thus will not be interlaced - otherwise, objects moving horizontally would have odd striping effects like with all interlaced content that updates its content faster than the interlacing occurs.

Just wondering if anyone had thoughts on this or data to back it up / repute it.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Misconception about GBC / GBA interlacing

Post by tepples »

The LCD alternates each frame between drawing odd scanlines slightly dark and even scanlines slightly light and vice versa. Objects do have subtle striping artifacts. The Farbrausch demo "fr018: aGb" relies on this for the intro and tunnel effects. I have made a GBA ROM that demonstrates this with a static picture that looks very different on a GBA from how it looks on a Game Boy Player.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Misconception about GBC / GBA interlacing

Post by lidnariq »

Using my digital camera that can record video at 240Hz, it certainly looks to me like it's drawing a new field, but not redrawing the full display, every 60Hz.

Here's an animated GIF of the pillar of light from the end game of Castlevania: Circle of the Moon on my GBA.
cvcotm-interlace-demo.gif
cvcotm-interlace-demo.gif (543.66 KiB) Viewed 7513 times
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Misconception about GBC / GBA interlacing

Post by Bregalad »

tepples wrote:The LCD alternates each frame between drawing odd scanlines slightly dark and even scanlines slightly light and vice versa. Objects do have subtle striping artifacts. The Farbrausch demo "fr018: aGb" relies on this for the intro and tunnel effects. I have made a GBA ROM that demonstrates this with a static picture that looks very different on a GBA from how it looks on a Game Boy Player.
Oh, this explains everything ! In some games I noticed that there was horizontal stripes appearing on the screen, but only when scrolling vertically.
nitro2k01
Posts: 252
Joined: Sat Aug 28, 2010 9:01 am

Re: Misconception about GBC / GBA interlacing

Post by nitro2k01 »

I've made a test ROM for investigating this effect. Explanation and usage described below. Please share thoughts about details I might have gotten wrong.

Code: Select all

Altframe
========

This is a test ROM to investigate the interlacing effects on GBC and GBA
displays. The ROM draws alternating lines of two settable colors. On each
frame, it is toggled whether color 1 and 2 are shown on odd and even lines,
and vice versa.

Usage:
A:     Swap color 1 and color 2.
Left:  Toggle the red component of color 1.
Up:    Toggle the green component of color 1.
Right: Toggle the blue component of color 1.

If the GBC display was truly interlaced, or "144i", such that every second
line was omitted in every second frame, you would expect this test to show
color 1 or color 2 solidly every frame. This is not what is being observed.
The colors are blended together, which means that in one way or the other,
the color information from every line is being used 

However, it interesting to note that on GBC (at least on my GBC) one of the
colors is dominant. In my case this is color 2 (the right one.) If you swap
the same two colors back and forth, you would expect them to be mixed the
same way, such that the blended tone is identical no matter whether you toggle
colors 1 and 2.

My theory is that the display is driving the bias voltage for each pixel in a
bipolar fashion where a (sub)pixel's bias voltage is first driven on one side
on one frame, and then with the complentary value on the next frame. For some
reason, the polarization is not changed until the second voltage is applied.

Imaginary example, using -1V as the off bias voltage and +1V as the on voltage:

Let's say a green subpixel is constant on.
On frame 1, terminal 1 is driven to 1V.
On frame 2, terminal 2 is driven to 0V.
This gives a bias voltage of +1 between terminal 1 and 2, and the pixel's state
becomes visible on frame 2.

Let's say a green subpixel is constant off.
On frame 1, terminal 1 is driven to 0V.
On frame 2, terminal 2 is driven to 1V.
This gives a bias voltage of -1 between terminal 1 and 2, and the pixel's state
becomes visible on frame 2.

Now let's take a less trivial example where the green subpixel is toggled each
frame by the program. Depending on when this toggling started, one of two 
things maybe be happening:

On frame 1, terminal 1 is driven to 1V. (Corresponding to on for frame 1)
On frame 2, terminal 2 is driven to 1V. (Corresponding to off for frame 2)
This gives a bias voltage of 0 between terminal 1 and 2, right between -1 and 
+1. The colors are mixed and the pixel's state becomes visible on frame 2.

On frame 1, terminal 1 is driven to 0V. (Corresponding to off for frame 1)
On frame 2, terminal 2 is driven to 0V. (Corresponding to off for frame 2)
This gives a bias voltage of 0 between terminal 1 and 2, right between -1 and 
+1. The colors are mixed and the pixel's state becomes visible on frame 2.

In theory, those two scenarios should be the same, as the resulting bias
voltage across each pixel should always be the same. no matter which 
complentary voltage levels were used to arrive at the bias voltage. However
the transistors might be non-ideal, so that one of the terminals has a constant
voltage offset.

I believe this explains the observed behavior that one of the colors is
dominant whe
Attachments
altframe.zip
(2.05 KiB) Downloaded 317 times
Post Reply