Naming the registers
Am I the only one being annoyed by those "PPUMASK" "PPUSCROLL" etc... names ? Because Mr Tepples often refers them as it doesn't mean everyone often refers them as it. I like to use plain $2000, $2005, etc... Personally I'd vote for removing references to those names from the Wiki but I don't want to force it if other people disagree. Bregalad 21:29, 24 February 2010 (UTC)
It depends. It's not only Tepples that promoted those names. I'm a firm believer that using symbolic constants makes the code easier to read. As long both are available in the wiki I don't see the issue.
I can give you an example as code. Which one is clearer when you read back the code?
- In another file (nes.h)
- Somewhere in the code
lda #PPU_CTRL_NMI + PPU_CTRL_SPRITE8x16
Once you know the convention, it makes the code easier to read. Of course for the registers only it could be argued for a while since there is not that much on the nes but it's always good to follow good programming practice. In a professional environment, I will always promote the second once since it makes the code clearer.
You don't know how many time I saw code samples for newb with no comments at all and you have to figure out what the hell was done with anonymous labels to make it worst. At the least those constants give some visual feedback on what you're trying to do. It's only a matter of getting used to the naming convention.
In brief, I think it's a good practice to use them but nobody is forcing you do to so. There's just there to try to make a convention and of course not everyone will agree with it (i.e. see how many linux distro..)
Banshaku 01:35, 25 February 2010 (UTC)
Well it's fun because I always do it like your "bad example" exept I write numbers in hex instead of binary, and I never had problems reading it. Symbolic names just makes the thing longer and more confusing. In fact I think it is the exact opposite of what you said - it makes things harder to read in my opinion. Then it depends if you remember best words or numbers - I know I remember numbers better personally.
Like you said, as long as there is both there isn't any problem... but my issue is that I found several pages on the Wiki which ONLY refers the symbolic names which are nothing official anyways. So my proposal would be to not touch this page, but change the others to mirror the numbers (e.g. $2001) instead of symbolic names that makes few sense (PPUMASK really makes no sense to me it sounds like carnival or something).
Again I don't want to force anything but I'd vote for at least replacing all instances which ONLY have the symbolic names to show the true register instead. Bregalad 08:20, 25 February 2010 (UTC)
I was not aware that some page of the wiki only refer to the name. In that case, yes it can be confusing since there is no official standard for naming them. To make both crowd happy, we could always put both at the same time too.
Which pages are like that?
As for using constants For the registers, the benefit is quite negligible since there is not that much but for flags or your own values in your game, it will save you from many headache when you use the same value many time. Of course, if you use long name and you have to remember all of them by heart, everybody will agree with you and say it's quite a pain in the butt (I do agree) but with a good editor, the editor will give you suggestion once you start to type a word. For example, in Visual Studio, Eclipse and many IDE, if I would type PPU, it would give me a suggestion list of all the words that start with PPU. In the case of nes programming this is an issue because there is no such editor that gives that functionality. I wanted to make one for that reason since I cannot remember all my constants, which is normal.
Banshaku 12:05, 25 February 2010 (UTC)
- See GBATEK for the kind of style that I was attempting to follow when I instituted the PPU registers' names in the first place. The GBA community never refers to registers by their address. --Tepples 12:55, 25 February 2010 (UTC)
Tepples there is a big difference : The NES adresses are 16-bit and so you only have 4 digits per adress, which makes them much easier to remember. Another big differences is that all those names are made up - they are nothing official and probably aren't "often refereed as" as this page says Ian Bell uses the following definitions in his open source "tank demo" so if anything were to be official it'd look more like this (and again I doubt it's official it's probably made up by Ian Bell himself) :
VCR: EQU $2000 ; video control reg base address VIDEO0: EQU VCR+000 ; CTRL0 VIDEO1: EQU VCR+001 ; CTRL1 VSTAT: EQU VCR+002 ; video general status register OAM_ADR: EQU VCR+003 ; sprite attribute address register SCROLL: EQU VCR+005 ; scroll h/v registers appear here VRAM_ADR: EQU VCR+006 ; video address register VRAM_DAT: EQU VCR+007 ; video data register SPRITE_DMA_ADR EQU $4014 WRST EQU $4015 ; DMA WRST/RDST CONTROLLER1: EQU $4016 ; Joystick and DMA CONTROLLER2: EQU $4017 ; Ports
So according to what Banshaku said, I guess I can go ahead and remove places where registers are refereed only by their GBA-style name and replace them with true adreses. If this cause problems someone can still undo the changes. --Bregalad 15:10, 25 February 2010 (UTC)
- Game Boy addresses are 16-bit, yet the same fellow behind GBATEK also wrote Pan Docs. --Tepples 16:02, 25 February 2010 (UTC)
We should just be careful thought. It's not because there is no official naming convention coming from Nintendo that we cannot make our own in the first place. If we go that extreme, we could say that we don't agree with Loopy_V/Loopy_T naming convention because that is not official too.
There is nothing wrong to try to make a naming convention that seems simple for new users. The one shown above is not any simpler the the currently proposed one on the wiki. It's all a mater of preference. Don't forget that people have complained many time that the wiki was "not organized" so we shouldn't shoot down people that try new ideas. There is nothing wrong we that.
Banshaku 23:46, 25 February 2010 (UTC)