Deprecate VRAM address constants.

[evie-calico]

These 3 lines are completely useless, literally just prefixing a few addresses with _VRAM_. I think replacing them with _VRAM_BG, _VRAM_SHARED, and _VRAM_OBJ (and moving the old constants to the deprecated section with IEF_LCDC) would be much more descriptive. I believe the reason this was not done was because the first 256 tiles can be unified into a single shared section, but I this is actually already solved by hardware.inc: just use the plain _VRAM constant.

[martendo]

Perhaps they should be named something like _TILES_* instead of the less descriptive _VRAM_*, avoiding the possibility of confusing _VRAM_BG for the background maps? For sharing the first 256 tiles across objects and the background, a plain _TILES constant could also be added to express a more specific intent than _VRAM.

[evie-calico]

That's a good point, I've updated the constants.

[ISSOtm]

While it makes sense to deprecate those symbols for the reasons you gave, it makes less sense to define the constants you suggest, simply because laying out VRAM in this way is a convention, not something intrinsic to the hardware.

I'd argue that defining PADF_* like they are is a problem, but it's a convention accepted largely in the community, so I can give it a pass. This, however, is dependent on several factors, and may even vary within a single game. Hence, I'm for rejecting the new symbols.

[evie-calico]

Okay, it seems like I had a different idea of what hardware.inc was for. I've moved those address constants down to the deprecated section and removed the _TILE_ constants I added.

[avivace]

Moving stuff to deprecated looks like something we should mention in #16

[evie-calico]

Oh, good point. This should probably be 4.2.1, not 4.3 (I also forgot to update the version check macro)

[drcouzelis]

I'm new to Game Boy programming... The pandocs refer to three "blocks" in VRAM.

https://gbdev.io/pandocs/Tile_Data.html

I load my object sprites into block 0 and background tiles into block 2. It looks like certain blocks can only be used for certain types of VRAM data. Won't every game need to reference these three blocks at least once at some point? Does it make sense to have some reference to them here?

Or, is having a reference to the three VRAM blocks outside the scope of the "hardware.inc" file?

Thank you!

[aaaaaa123456789]

While it's extremely likely for a program to reference at least one of those three areas, almost all will reference two, and many will reference all three, the reason why they don't belong here is that they don't have a specific meaning that you can name. The only limitation is that sprites' tile data cannot use block 2.
In actuality, the idea of there being three blocks at all comes from the fact that the hardware-defined ranges are partially overlapping: there's really only two tile memory regions (at $8000 and at $8800), but since they overlap in the middle, you get three "blocks" of memory defined by those regions (only the first, overlap, only the second). It is entirely possible to allocate VRAM in a way that only handles the two hardware-defined regions and doesn't use the three-block simulation: for example, you could allocate OBJ tiles starting at $8000 and BG tiles starting at $97f0 and just meet in the middle.

The proper way to address them is to give them a meaning through labels in your own program, typically through VRAM sections. While the $8000, $8800 and $9000 addresses do have some meaning, that meaning is poorly represented by a named constant, and numeric constants (something like _VRAM_9000) are foolish and no better than the raw address itself.