Use SCREEN_WIDTH and remove obsolete comment

[PokefanMarcel]

No description provided.

[Rangi42]

While you're editing this file, can you please update ClearScreen as well? 20 * 18 is SCREEN_AREA.

[Narishma-gb]

ld hl, $600 * 0 and following could perhaps be written lb hl, 6 * 0, 0
See GetRowColAddressBgMap that does the magic conversion

[PokefanMarcel]

Did the first comment, but not super comfortable to do the second just because I don't fully understand how this works.

[Narishma-gb]

Sorry I wasn't so clear. I was looking at some of the places in CopyScreenTileBufferToVRAM where constants can be added.
The number 6 in ld c, 6 and the following lines can be written SCREEN_HEIGHT / 3.
Also, rather than using 2-byte numbers in ld hl, $600 * x, we can use the macro lb hl, .., .. to specify the value for h and l, which in this function are raw coordinates (y, x) on the BG map, that GetRowColAddressBgMap combines with register b to get a memory address into VRAM.
lb hl, 0, 0
lb hl, SCREEN_HEIGHT / 3, 0
lb hl, 2 * SCREEN_HEIGHT / 3, 0
This is only a suggestion, as I am not a maintainer of pokered.

[Rangi42]

Makes sense to me, any time h and l are independent quantities, lb hl, HVAL, LVAL is appropriate.

[PokefanMarcel]

Is it related to one of the macros in coords.asm? For instance hlbgcoord?

Just asking in case there's already an appropriate framework for this even better than lb.

[Narishma-gb]

Unfortunately no, hlbgcoord does the translation to VRAM inside the macro. What we have here is plain integer coordinates in the ROM, and code optimization: instead of loading h and l separately with their respective coord values, ld hl, n16 does it using only 3 bytes of ROM.

[Rangi42]

The XXcoord and XXbgcoord macros take an optional argument for the coordinate "base". pokered uses it rarely, e.g. hlbgcoord 0, 14, vBGMap1 in engine/movie/intro.asm. pokecrystal and pokegold use it more often, mainly for attribute map coords (e.g. hlcoord 13, 5, wAttrmap). But, they also sometimes use 0 as the base (see git grep -nP 'coord .+, .+, 0'). So instead of lb hl, X, Y, this could be hlcoord X, Y, 0. @Narishma-gb do you have any preference for which one feels more intuitive or less awkward to read/write?

[Narishma-gb]

I don't think we have any choice but to use lb.
XXcord gives a result of X + 20 * Y (screen width), if the optional argument is given as 0.
XXbgcord gives a result of X + 32 * Y (tilemap width)
Here to get multiples of $600, we need to perform X + 256 * Y and there is currently no macro for it. The only downside of lb is that it does not let us put (x, y) in the natural order. Instead, this will be lb bc, Y, X

[Rangi42]

Ah, you're right, lb is correct here.

[Rangi42]

Thank you!