Skeetendo

I feel like all the note files don't have enough words and explanations and I don't think anyone is going to be able to understand what you've done so far.
Could you possibly elaborate in each of those files? I really do want to fully understand this and make huge progress on this. Perhaps you could stick around and help out long enough for me to get a good grasp on things?

As I've told you in IRC already, I'm starting to get the hang of this and how it works, a little.

So much that I can help you out with a bug. You changed 2117 and 211A from D0 to E4, to represent the palette shades. You missed one, however, at 3DE1, which I was able to easily find with the disassembly. This should fix the Pokemon menu in the start menu. Actually, I found this one first, and then had to use the changelog I made of your hack to find where those two were.

But so yeah...

Okay, so here's my disassembly part of the VBlank routine that you added. I'm can't exactly follow it though; I've only got the jist of it. If you'd like to explain some of it to me, add comments, fix the labels, etc., that would be extremely helpful.

It seems to me your interpretation of the way registers $FF47 and $FF48 work might not be right, because
1. When the screen should fade to black, it fades to white, and vice versa.
2. When the screen is solely white (when changing menus, for example, selecting the Pokemon menu from the start screen or selecting to use fly), it tends to blink black occasionally (I think the reason it's not just solid black the entire time is because the game disables the screen to while writing to the VRAM so you don't get an incomplete picture, but then doesn't fade right away so the black, which should be white, seeps through).

Just for clarity (on both your part and mine), here's the way it should work.

Any given graphic has 4 indexes to use. Under ordinary circumstances, index 3 is assigned to "color 3" (always black on a DMG), index 2 to color 2, etc. However, this only holds true because, under ordinary circumstances, the value in the register is $E4. This is interpreted thusly (this helps):

$E4 to binary is 11100100.
The first two bits are "11", or the value of 3, and so thus index 3 is assigned palette 3.
The next two bits are "10", or the value of 2, and so thus index 2 is assigned palette 2.
etc.

However, when fading the screen, other values are put in there so as to "move each color lighter by one until all 4 are white" to fade to white, or "move each color darker by one until all 4 are black" to fade to black, or something like that.

But anyways, here's the code, which may be slightly modified since I've been working on it.

NewVBlankHandlerFar:
    push af
    push bc
    push de
    push hl
    ld a, $2
    ld [$FF70], a
    ld a, [$FF47]
    ld b, a
    ld a, [$d087]
    cp b
    jr z, .asm_b484a
    ld a, $80
    ld b, $0
    ld hl, $ff68
    ld [hli], a
.asm_b4819
    ld c, $0
.asm_b481b
    ld a, [$FF47]
    push bc
    and a
    jr nz, .asm_b4826
    call asm_b48cc
    jr .asm_b4839
.asm_b4826
    cp $ff
    jr nz, .asm_b482f
    call asm_b48d8
    jr .asm_b4839
.asm_b482f
    xor a
    cp c
    ld a, [$FF47]
    call nz, asm_b4894
    call asm_b48a2
.asm_b4839
    pop bc
    inc c
    ld a, c
    cp $4
    jr nz, .asm_b481b
    inc b
    bit 3, b
    jr z, .asm_b4819
    ld a, [$FF47]
    ld [$d087], a
.asm_b484a
    ld a, [$FF48]
    ld b, a
    ld a, [$d088]
    cp b
    jr z, .asm_b488c
    ld a, $80
    ld b, $8
    ld hl, $ff6a
    ld [hli], a
.asm_b485b
    ld c, $0
.asm_b485d
    ld a, [$FF48]
    push bc
    and a
    jr nz, .asm_b4868
    call asm_b48cc
    jr .asm_b487b
.asm_b4868
    cp $ff
    jr nz, .asm_b4871
    call asm_b48d8
    jr .asm_b487b
.asm_b4871
    xor a
    cp c
    ld a, [$FF48]
    call nz, asm_b4894    
    call asm_b48a2
.asm_b487b
    pop bc
    inc c
    ld a, c
    cp $4
    jr nz, .asm_b485d
    inc b
    bit 4, b
    jr z, .asm_b485b
    ld a, [$FF48]
    ld [$d088], a
.asm_b488c
    xor a
    ld [$FF70], a
    pop hl
    pop de
    pop bc
    pop af
    ret
asm_b4894:
    rlca
    rlca
    dec c
    jr nz, asm_b4894
    ret
asm_b48a2:
    and $c0
    swap a
    rra
    rra
    xor $3
    add a
    ld d, a
    ld a, b
    add a
    add a
    add a
    add d
    ld d, $d0
    ld e, a
    ld a, [de]
    push hl
    ld hl, $ff41
.asm_b48b9
    bit 1, [hl]
    jr nz, .asm_b48b9
    pop hl
    ld [hl], a
    inc e
    ld a, [de]
    push hl
    ld hl, $ff41
.asm_b48c5
    bit 1, [hl]
    jr nz, .asm_b48c5
    pop hl
    ld [hl], a
    ret
asm_b48cc:
    push hl
    ld hl, $ff41
.asm_b48d0
    bit 1, [hl]
    jr nz, .asm_b48d0
    pop hl
    ld [hl], a
    ld [hl], a
    ret
asm_b48d8:
    push hl
    ld hl, $ff41
.asm_b48dc
    bit 1, [hl]
    jr nz, .asm_b48dc
    pop hl
    ld [hl], a
    ld a, $7f
    ld [hl], a
    ret

Well, like I said, I tried explaining how the fading is supposed to work, so you should try reimplementing it like that.

Here's a visual demonstration of how the fading should work: http://stag019.no-ip.org:10000/clzwrg/

The images labelled "sgb" are how it would work on a Super Gameboy, or a regular Gameboy if you greyscaled the colors. The ones labelled "cgb" are how it works with your VBlank handler if I set the colors to the default SGB colors.

Which made me notice something funny, this is one case where the screen is supposed to blink (from black to white, before loading the screen) whereas in your case it doesn't because it fades to white instead of fading to black.

Well, since you didn't want to help, I spent a coupla hours really trying to figure it out.

You were right in that the order of the bits is reversed compared to the order of the colors in a palette. However, you actually read the data in the wrong order, and then simply invert the bits. That obviously means the only value that would work is the default value of E4.

asm_b4894:
    rlca
    rlca
    dec c
    jr nz, asm_b4894
    ret
asm_b48a2:
    and $c0
    swap a
    rra
    rra
    xor $3
...

That's how you did it, and below is how I fixed it:

asm_b4894:
    rrca
    rrca
    dec c
    jr nz, asm_b4894
    ret
asm_b48a2:
    and $3
...

The code is less involved and therefore also correct. On top of that, you don't need your separate subroutines for when the value is $00 or $FF, because those values are handled correctly now.

I just implemented this in my own version; now I'm going to put it in your version and see if that helps things out at all.

Edit: Well, it definitely makes the fading look a lot better. Another example is the GameFreak logo at the beginning of the game. However, the separate subroutines for $00 or $FF are necessary in your version, because I can see graphical artifacts like you said. However, the two routines should be switched, I believe.

Last edited by stag019 (2013-02-08 01:58:08)

Yes, that's exactly correct. That's why after my edit I said you shouldn't remove those two cases. I still think you should correct the routine that emulates to FF47 and FF48 registers though.

Yeah, but I'm working on a different way of doing the project.

Perhaps when I'm done with my project, I'll pick this up, completely disassemble and comment your routines, and then release it for others to work on.

Cool.
Please tell me the Offset and Pointer of the Unused Song used if NonGBC.