tepples wrote:
kevtris wrote:
Speaking of, does anyone know how that game performs that black bouncing text on the title screen? I have not been able to figure it out, even using the debugger on an emulator.
Might it be related to the so-called "Demotronic trick"?
Yeah that is possible... I was thinking they might've been writing to the LCD in real time, but it'd be pretty tricky to do. There's a few things about it that bug me though.
The resolution appears to be 8 pixels across (i.e. 1 character) and seems to have some modicum of fine scroll in either direction. This would require them writing a new value to the LCD control register(s) every 8 pixels, which is every 2 instructions. Possible I guess, if a load (LD A,value) and store (LD lcdreg,A) takes 4 cycles each. (or LD A,B and LD A,C for the "on" and "off" values).
I *did* find this....
http://www.mobygames.com/developer/shee ... Id,207764/
which has the following:
"Prehistorik Man identified sprites likely to cause incorrect graphics and replaced them with software sprites copied into the video ram. "
"It also ported an Amstrad CPC trick to draw big scrolling messages."
I have not been able to find any information on this "cpc trick" that he's talking about.
I watched that demotronic demo, and their trick appears to be writing to Yscroll during rendering, which is combinatorial. This causes stretching and other Y effects, which is what their demo appears to be showcasing.
It seems they get character granularity which is possible, if it's running on a GBC because there will be 16 CPU cycles per character, which should be plenty to update yscroll each character cell.
On checking CPU cycle timings for the possible Prehistorik tricks, it looks like there IS a way to do this. You can write to the LCD control register 2 different values using LD (hl),n. This instruction takes 8 cycles. They appear to play with the palette register. So, to write the scrolling message they could simply do something like this:
ld b,normalpalette ;this is the normal background palette
ld c,0ffh ;solid black palette
ld hl,0ff47h ;palette register
ld (hl),b ;normal palette
ld (hl),c ;black palette
ld (hl),b ;normal palette
ld (hl),c ;black palette
ld (hl),b ;normal palette
ld (hl),c ;black palette
ld (hl),b ;normal palette
ld (hl),c ;black palette
ld (hl),b ;normal palette
ld (hl),c ;black palette
ld (hl),b ;normal palette
ld (hl),c ;black palette
This code will theoretically draw alternating black bands on the LCD. This is also how the demotronic probably works, but I suspect they do something like this:
ld hl,scrollvalues ;place where Y scroll values are stored
ld de,yscroll ;LCD Y scroll register
ld a(hl+)
ld (de),a
ld a(hl+)
ld (de),a
ld a(hl+)
ld (de),a
ld a(hl+)
ld (de),a
ld a(hl+)
ld (de),a
ld a(hl+)
ld (de),a
ld a(hl+)
ld (de),a
... repeated 20 times total
That will take 16 cycles per character, but on the GBC that's exactly how many cycles there are when the CPU is in 2x speed mode.
One other thing- for P.Man's fine scrolling on the large text, this is fairly easy to do using sprites. Since the sprite delays the rendering 6-11 cycles, it's possible to use them to fine tune the position on the screen where the palette changes occur. This would be required to compensate for the background scroll (which "eats" up to 7 cycles in and of itself). 2 sprites can be used then to fix the position where the palette changes occur, because a single sprite can only do 6 pixels' worth of change.
So, that's how I am guessing both tricks are done. I don't know all the ins and outs of GB yet so this is all just supposition. comments?
