-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rHDMAx alternative names #36
Comments
after looking into it a bit more, here are more suggestions/questions i have:
|
Do we have any registers with an underscore in their name? (On that point, this might overlap #26.) If we are renaming those registers, I'd go the extra mile and call them
At that point, why not one for the number of palettes, or the byte size of a colour? Why that specifically? Arguably, That constant is nothing particular, and if we start being opinionated, @aaaaaa123456789 won't let me hear the end of it. |
|
That is what I was replying to.
Okay, maybe a |
That makes little sense, because (1) it's the identity for all palettes, not just BGP and (2) it's just a random constant. Unless the goal of hardware.inc is to pollute people's namespaces as much as possible... Please remember this is not a "library of good stuff"; it's a file meant for hardware constants. You could argue that the default palette mapping is a hardware constant, but that's the worst slippery slope ever: how long until every register gets its constant? |
I didn't want to include it as "the default mapping" either, but as "the palette you will want for your SGB VRAM transfers", I think it makes sense. I don't think that rationale is a slippery slope, either? |
okay so to make sure were all on the same page
|
This is just a convenience, and at worst, a convention. If you always have your palette set to some other color permutation, you can perfectly set up the SGB data to use that permutation so that you don't have to switch palettes. (I wonder if this is more efficient.) Likewise, you can, as we discussed earlier, manipulate that value for effects — the fact that few games can take advantage of those effects doesn't make them not exist. |
Since I haven't commented on the register name issue: I'd rather not have hardware.inc invent register names. As I said: it is not a "library of good stuff". The alternate names that are already there have to remain there for backward compatibility, and at the same time, they were already in use by the community. But the goal should never be to sanction names that don't exist yet: it is a terrible idea for a project like this to become a source of descended-from-above invented conventions that two or three people decide in a random backroom for everyone to use. If you want to create your own names for your own projects, there's a million better ways that don't intrude on other people's code. |
only now did i realise you meant my suggested and i agree with ax6, should we close the issue? |
There is, in fact, a good reason to invent register names: what good are they if they're opaque? I can give Besides, we already have a precedent, in the form of the audio registers, and I remember the addition being well-received. |
how about an "experimental" update? the constants get a clear "these may be removed at any point" label, and depending on user feedback they will either stay, or be deprecated/removed? |
some registers have alternative, more "user friendly" names (
rKEY1
,rNRxx
, CGB palette registers, CGB banking registers)but since
rHDMAx
registers dont have alternative names and (according to hardware.inc and pandocs) are big-endian, this could result in some nasty suprises if someone doesnt double check the ordermy suggested alternative names for
rHDMAx
registers would be:rHDMA_SRC_HI
,rHDMA_SRC_LO
,rHDMA_DST_HI
,rHDMA_DST_LO
, andrHDMA_LEN
The text was updated successfully, but these errors were encountered: