ISSOtm

SECTION "VWF engine",ROM0

; Prints text pointed to by DE
; Text is null-terminated

PrintVWFText::
	ld a, 3
	jr .startupColorID
	
	

ISSOtm

My Two Bugs

Every programmer has that one bug. That bug that couldn't go away, no matter what you try; that bug whose reason was so obscure it took so long to fix. Even though I am a very young coder, while programming for the Game Boy, I've encountered two of these bugs.

Coincidentally, both of them were caused by the same thing, even though they were completely unrelated. Here are their story.

Overshooting It

I originally started developing Aevilia as a simple RPG for the Game Boy Color, taking inspiration from the Pokémon games' code. That is, use one loop per thing you need to do, and jump between them. This eventually proved to be a disaster, because a lot of code was duplicated, and transitions between loops didn't always go so well.

ISSOtm

    ; Perform fast VRAM copy if asked to
    ldh a, [hFastCopyNbReq]
    and a
    jp z, .dontDoFastTransfer
    push de
    push hl
    ; Save sp and set it to source
    ld [wSPBuffer], sp
    ; Get ready to read params

ISSOtm

.87:F000 ROMNameList:    .BYTE 'ZELDA',0
.87:F006 byte_87F006:    .BYTE 0
.87:F007                 .BYTE 0
.87:F008 byte_87F008:    .BYTE 0
.87:F009                 .BYTE 0
.87:F00A byte_87F00A:    .BYTE 0
.87:F00B                 .BYTE 0
.87:F00C byte_87F00C:    .BYTE 0
.87:F00D                 .BYTE 0
.87:F00E byte_87F00E:    .BYTE 0

ISSOtm

; TODO: timings have changed, verify this comment
;
; Be careful with effects on consecutive lines!
; A "double" effect will end a handful of cycles too late if the preceding scanline was really busy
; (approx. 25 M-cycles, HBlank can be as short as 22 cycles plus 1~2 cycles of latency explained below)
; The textbox appears to last up to 22 M-cycles so it should be fine
; The LY=LYC interrupt appears to be unable to trigger in the first (first two?) cycles of a scanline, giving extra leeway
; Anyways, using an effect just after either of the previous conditions may slightly delay it, and repeating the condition will accumulate the delays
; Mode 2 being 20 cycles long, it should be possible to stack the delays somewhat before visible breakage happens, but it's better to avoid it at all

ISSOtm

    ; 1/2
    ld hl, wMovementVector + 3
    sra [hl]
    dec l ; dec hl
    rr [hl]
    dec l ; dec hl
    sra [hl]
    dec l ; dec hl
    rr [hl]
    call .tryMoving

ISSOtm

.fadeIn
    ld a, [wCurStateFirstFrame]
    and a
    jr z, .notFirstFrame
    ; Assume palettes are properly set (ie. we're fading from the proper solid colors)
    ; Perform first fade immediately
    ld a, 1
    ld [wFadeFrames], a
    ; This is the value that will get added to each color
    ; It'll be decremented just below

ISSOtm

; Here's some technical explanation about Game Boy sample playing:
; The "usual" way of playing sound samples on the Game Boy is to use its wave channel
; Basically, let that channel play its 32 4-bit samples, then refill it
; Problem: to refill the channel, you have to disable it then restart it
; However, when doing so, the "sample buffer" is set to 0 **and not updated**
; This means the channel outputs a spike as its first sample, creating a buzzing sound
;
; Why? That's because of how the Game Boy generates sound: each channel produces
; a digital value between 0 and 15, which is fed to a DAC (Digital to Analog Converter)

ISSOtm

#include <stdlib.h>
#include <stdbool.h>
#include <stdint.h>
#include <string.h>

#include "link/main.h"
#include "link/script.h"
#include "link/section.h"

ISSOtm

#include <stdlib.h>
#include <stdbool.h>
#include <stdint.h>
#include <string.h>
#include <ctype.h>

#include "link/main.h"
#include "link/script.h"
#include "link/section.h"