--- In gbadev@yahoogroups.com, Groepaz <groepaz@g...> wrote:
> On Wednesday 01 January 2003 20:14, Patriek Lesparre wrote:
> > >Will the GBA display controler display the change of HOFS
> > >of a background layer while he is already in HWRITE? For
> > >example, the first 40 y values of a certain scanline will
> > >be displayed with a HOFS value of 0, the next 200 y with
> > >a value of 1?

It is possible. Read on...

> > >I have tryed it on VisualBoyAdvance, but it doesn't work.
> >
> > I haven't tested it, but I would assume it's possible. The
> > emulator is probably using a line-based renderer

Even on the NES, where some of the games do some real nasty
raster tricks with the background and the emulators try to keep
up, most NES emulators still use line-based rendering code, and
games such as "Pirates" that bankswitch tile data during draw
time don't work.

> > instead of a (slow) pixel-based one, so you won't be able
> > to see the effect.

It's possible to make a hybrid line/pixel based renderer in
much the same way that emulators' sound engines work. Simply
time-stamp all video register writes, and when drawing the
frame, draw portions of scanlines between register writes.
This keeps full speed for the common case of no mid-scanline
writes, but it goes down to pixel accuracy. I think the NES
emulator 'Nintendulator' does something similar.

> i wouldnt bet on that... imagine how the display controller
> works and how much memory (ie registers) access it had to do
> if every register-change would have an immediate effect on
> per-pixel basis.

Remember... the registers are local to the display controller.
Look how much mid-scanline register writing was necessary to
get ANYTHING to display on the Atari 2600 console, which had
128 bytes of RAM and about half a scanline's worth of video RAM.

> this might work for some "simple" things, like colors
> (good old "rastersplits" :))

I've known that mid-scanline palette writes on the GBA work
for quite some time.

> but for more complicated stuff, like displaying actual
> character data (which x-offset belongs to), registers
> are probably fetched once per scanline, or atleast not
> per-pixel, but per character-cell.

It's fetched per character-cell.


The long story:

Somebody asked about writing to the GBA's scroll registers for
"text mode" backgrounds (mode 0 bg 0-3 and mode 1 bg 0-1) during
draw time (as opposed to hblank or vblank time). I've done some
tests on my GBA, by setting up timer 3 as a faux LCD_X register
(speed: 16 MHz; initial count: 65536-1232), and then spinwaiting on
timer 3 and setting the scroll registers. Here are the results:

Changes to BGSCROLL[0].y during draw have an effect that may not
be familiar to programmers who grew up with graphic systems such
as the NES PPU where writing 16 to the Y scroll register caused
background line 16 to be drawn on the next scanline. The GBA,
however, considers BGSCROLL[0].y as an *offset* from (0, 0), and
while it draws the background, it *continuously* adds the value
in BGSCROLL[0].y to LCD_Y. Thus, writing 16 to BGSCROLL[0].y on
scanline 20 will cause an immediate switch to background line 36.

Changes to BGSCROLL[0].x have similar effects, with the same
"offset" scheme.

However, a scroll write does cause an area of background
corruption about 8 pixels wide. This could be due to a tile
data prefetch within the compositor. (The NES PPU performs
some prefetch as well.)

One should be able to do a vertical status bar or vertically
split screen with this. But with the large sprites, four
backgrounds, and windows that the GBA provides, why would a
fellow want to waste CPU or DMA time on this technique?

E-mail me at d_yerrick@... if you want the source or
binary that I used.

--
Damian