8x16 and whatever else unreg wants to know

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Gilbert wrote:(but then of course the gameboy only has 4 different shades in total, even after combining the sprites with the background plane, and so this works)
Exactly. That works fine for the GB, but NES games using only 4 colors isn't very impressive, so it kinda kills the point of having more sprites (or any other improvement you can think of).
(I wonder why this is needed, as 160x144 occupies only 360 8x8 tiles and you can just change the tile page used for background midscreen when it uses up 256 of them, instead of rewriting the memory, and there're still enough space for stuff such as border graphics, etc.)
It's probably not rewriting anything, just bankswitching (i.e. it has enough memory for the whole GB screen, and is able to select which parts of it can be seen by the NES), which is not much different from switching pattern pages. Maybe they just didn't want the 6502 to do much.
That isn't much useful for FC/NES game making though, as the WB is just the gameboy hardware in whole.
It proves we can build a mapper with its own PPU that feeds its output to the NES through the pattern/name/attribute tables. But I agree that it's not very useful, because of the 4 colors per tile limitation.
User avatar
Gilbert
Posts: 564
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Post by Gilbert »

tokumaru wrote:It's probably not rewriting anything, just bankswitching (i.e. it has enough memory for the whole GB screen, and is able to select which parts of it can be seen by the NES), which is not much different from switching pattern pages. Maybe they just didn't want the 6502 to do much.
I don't know, but as Chris wrote on the page (unless I misunderstood the wordings):
You see, the Famicom doesn't have enough BG tiles in VRAM to display an entire 160x144 Gameboy screen, so the WideBoy hardware has to write to the same RAM with different graphics halfway down the screen.
and we know that his information are mostly trustable so that made me wonder about its implementation.
I'm not familiar with the cart port and such (too lazy to look this up from the wiki), but can the pins access the PPU ports directly? If it can then the PCB may be able to change the pattern tables itself and ignore the 6502 in the console. If it can't then yes, it's more likely to be bank-switching, as I suspect it's hard to rewrite that large amount of data given limited bankwidth in the middle of a single frame.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Gilbert wrote:I don't know, but as Chris wrote on the page (unless I misunderstood the wordings):
You see, the Famicom doesn't have enough BG tiles in VRAM to display an entire 160x144 Gameboy screen, so the WideBoy hardware has to write to the same RAM with different graphics halfway down the screen.
I see... Well, this might very well be the case if the WideBoy can write to the RAM at the same time as the NES PPU is reading from it. It would just be a matter of overwriting tiles that were already rendered by the NES. Few people have WideBoys, so we have to trust Chris.
I'm not familiar with the cart port and such (too lazy to look this up from the wiki), but can the pins access the PPU ports directly? If it can then the PCB may be able to change the pattern tables itself and ignore the 6502 in the console.
What do you mean by "the pins"? What I know is that NES code can only access VRAM through the PPU ports because the CPU has no direct access to that bus, but a mapper can have access to both buses, so it surely can manipulate VRAM without having to go through the PPU.
User avatar
Gilbert
Posts: 564
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Post by Gilbert »

tokumaru wrote: What do you mean by "the pins"? What I know is that NES code can only access VRAM through the PPU ports because the CPU has no direct access to that bus, but a mapper can have access to both buses, so it surely can manipulate VRAM without having to go through the PPU.
I meant the pins on the cartridge port, but yeah, I now see that you cannot access directly the PPU registers (in the case of switching pattern tables, the PPU port pointed to at $2000) by sending signals (whatever) via the connector pins, so we will need the 6502 to write to the register for this and so manipulating CHR-RAM contents or mapper bankswitching seems to be the simpler solution.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

tokumaru wrote:
unregistered wrote:What are the limits of the meta-sprite system?
That depends on the game. There is no standard for that, and each game has its own implementation of a meta-sprite system designed according to its specs.

For example, some systems might require that all sprites are arranged in a grid and use the same palette, so that the meta-sprite definitions will use less ROM space (no need to store the coordinates and attributes of each sprite). In my game I have a very versatile system, where each sprite's position is relative to the object's coordinates and has its own attributes. As a result, the definitions are larger.
Wonderful to think about, thanks! :)
tokumaru wrote:
unregistered wrote:I remember reading about how Punchout!! required special hardware to draw/animate the humungus enemies.
I'm not aware of that. The mapper used in that game doesn't have any features that would increase the sprite capacity of the system. What you can do sometimes is draw game objects using background tiles, if the background is flat enough. The ring is just a solid color, so it's possible that one of the fighters is actually drawn with background tiles rather than sprites, but I didn't check.
I can't find where I read that. :( Are the background tiles able to be collision detected?
tokumaru wrote:
unregistered wrote:Like what is the largest meta-sprite we could use without improving cart hardware? (Question is from my artist!)
You are the programmer, so you're the one that should have the answer!
:oops: : )
tokumaru wrote:
unregistered wrote:Also... about scrolling; what are possible width and height/depth for scrolling... guess she is wondering how much of a level can we do?
Again, this is up to the programmer. Levels can be as large as you want, it all comes down to the memory necessary to store the level maps. Depending on the type of compression you use, your maps will occupy more or less ROM space. If you implement a system where levels are generated randomly, you could have an endless level.
Sweet! Thank you for all (you are very good at teaching) of this information! :D
tokumaru wrote:
unregistered wrote:Mario 3 has the type of scrolling she is wanting. :)
You have to select the kind of compression that will work best with the kind of levels you want to make, also taking into consideration the decoding process (i.e. how you are going to read the map data, for drawing and for collision with the objects).

SMB3 has some limitations, like the height of the level, which is 2 NES screens tall (minus the status bar), and color glitches at the right of the screen because of the way it uses the name tables (horizontal mirroring). Status bars also affect the way you implement the scrolling if you plan on scrolling vertically (which I assume you do), so I need to know whether you want a status bar in your game and whether your levels can be taller than 2 screens before I suggest the optimal solution for your case.
Status bar would only be 8 pixels high and would have one or two text stats, maybe it could be clear and at the top of the screen, like in Mario (is that a status bar?). We would like our levels to be 4 screens tall. "It's our first game, we're just experimenting." Thank you for your help! :)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

unregistered wrote:Are the background tiles able to be collision detected?
Not by hardware... but then again, neither are the sprites. Unlike the Atari 2600 for example, the NES doesn't have any sort of hardware features for collision detection (the sprite 0 hit is not meant for testing object collisions, it's meant for detecting the position of the beam for raster effects). All collisions between objects, no matter if sprite or background, are done in software, through comparisons of their coordinates in the game world.
Status bar would only be 8 pixels high
Remember that some of the image is cropped by the television, so you shouldn't have important information too close to the screen edges. So even if your information only needs 1 row of tiles to be displayed, it should be 1 or 2 rows away from the edge of the picture.
and would have one or two text stats, maybe it could be clear and at the top of the screen, like in Mario (is that a status bar?).
Yes, it's a status bar. It's not clear though, it just appears to be that way because it uses the same color as the sky for its background. There never is any background going behind it, because the status bar itself is drawn with background tiles, and the NES has only 1 background layer.

If you have little information to display, you could use sprites to display the status, like in Mega Man or Sonic The Hedgehog (not NES, I know, but it's a good example). It's simpler that way, because you don't have to worry about splitting the background, something that can be particularly hard if you are scrolling vertically. The disadvantage of using sprites is that since you can only show 8 of them side by side, you can't have a lot of information laid out horizontally (hence why Mega Man's energy bar is vertical).
We would like our levels to be 4 screens tall. "It's our first game, we're just experimenting." Thank you for your help! :)
Then SMB3's solution is not very good for you. You can use either vertical or horizontal mirroring (it depends on whether you prefer to have scrolling artifacts at the top and bottom or left and right of the screen - notice how SMB3 has some color issues at the right side because it uses horizontal mirroring) if you decide to display the status with sprites, and single-screen mirroring (one name table for the gameplay and the other for the status bar) if you stick to a background status bar.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

tokumaru wrote:
Status bar would only be 8 pixels high
Remember that some of the image is cropped by the television, so you shouldn't have important information too close to the screen edges. So even if your information only needs 1 row of tiles to be displayed, it should be 1 or 2 rows away from the edge of the picture.
Image
Top: SMB1. Bottom: SMB1 with its status bar collapsed to 8 pixels tall (not unlike the GBC port) and 24 pixels from the top of the picture.
If you have little information to display, you could use sprites to display the status, like in Mega Man or Sonic The Hedgehog (not NES, I know, but it's a good example).
Other examples include Super Mario Bros. 2, Contra, Metroid, Ikari Warriors, and this shop of SMB1 with a heavily Ikari-inspired status bar:
Image
Then SMB3's solution is not very good for you. You can use either vertical or horizontal mirroring (it depends on whether you prefer to have scrolling artifacts at the top and bottom or left and right of the screen - notice how SMB3 has some color issues at the right side because it uses horizontal mirroring) if you decide to display the status with sprites
I seem to remember that one of the Double Dragon games uses another solution: horizontal mirroring, and whenever the camera starts to move into the status bar, move the status bar to the other nametable. With a semi-unrolled loop, it should be possible to push up to 4 rows of status bar to VRAM plus the corresponding attributes during one NTSC vblank.


I won't go into Crystalis's solution because discrete mappers and current CPLD mappers lack the needed scanline counter, and dpcm_split is an even more advanced trick. Nor do I feel ready to go into the diagonal mirroring (CIRAM A10 = PA10 xor PA11) that MMC5 and T*SROM theoretically support.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

tepples wrote:I seem to remember that one of the Double Dragon games uses another solution: horizontal mirroring, and whenever the camera starts to move into the status bar, move the status bar to the other nametable. With a semi-unrolled loop, it should be possible to push up to 4 rows of status bar to VRAM plus the corresponding attributes during one NTSC vblank.
Yes, this is a valid solution that we don't talk about much (I didn't even know it was used in Double Dragon). The fact that you'd have to give up the regular PPU updates for a frame just to reposition the status bar makes this option less interesting IMO, but you could probably make a more dynamic system that progressively draws one status bar as the vertical scrolling changes (i.e. the closer the screen gets to one status bar the more of the other is drawn).
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

Thank you tokumaru and tepples! :) The scrolling is going to be a fun challenge for me; but, i have not chosen an assembler yet. From other threads i have learned that dasm is rough to learn and that noone has used, from whayt i've read, Ophis. Why dont yall use ophis? It sounds really good... except that to reserve a variable you use

Code: Select all

.space variable 1
. Thats a 5 character word and it must be used a lot! :( Its two counters, one for the

Code: Select all

.data
sections and another for the

Code: Select all

.text
sections, sound really helpful and interesting; but, no-one uses Ophis; why? Which assembler is best to use??? I want to use the one that allows us to do the most. ....................................What assembler did Nintendo use? Did they send the development studios that assembler? ............................What assembler to you use? What do you like about it and what do you hate about it?
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

Either go with NESASM for simplicity, but I'd go with something better like CA65 or whatever it's called. Seems alot nicer. I am going to dump NESASM for something that allows for + and - tags after I get done with this project.
User avatar
Dwedit
Posts: 4921
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit »

unregistered wrote:Like what is the largest meta-sprite we could use without improving cart hardware?
64x128. That eats up all 64 sprite slots with each hardware sprite being 8x16 pixels in size.

As for which assembler to use, I recommend ASM6 because it just works.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

^ Thank you 3gengames for answering! :) Ophis allows for + and - tags... edit: and thank you Dwedit for mentioning ASM6... tokumaru like that one the best in 2009... will check it out, thanks! :)

It seems to me that the nes development community would be much easier to enter if we all used the same assembler... :?
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

Yeah, but I like ease of use. NESASM is exactly that when you get it set up. It's just a standalone utility. But I am hurting for some other assemblers features. I will look into it late, but it also seems like ASM6 is popular and pretty good. I'm sure if you pick a big name other then NESASM3(.0.1), It will be better. But the way you set up the program files/roms might be different. I don't know if any other assemblers offer this, but NESASM also can include other files. I use this to keep all subroutines, engine(s), etc in seperate program files and combine them all when I need them in the main one with one line of code.


If you want more help feel free to mail me, I'd be interested in learning a new assembler, too.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

3gengames wrote:But the way you set up the program files/roms might be different. I don't know if any other assemblers offer this, but NESASM also can include other files.
Pretty much every assembler has the equivalent of C #include. But including one code file from another is considered bad practice in both C compilers and ca65. In these environments, the common practice is to #include a header file with definitions of constants and .global statements, compile each translation unit (that is, source code file) separately to an object code file, and then link them all together at the end.
Last edited by tepples on Sun Feb 27, 2011 7:27 am, edited 1 time in total.
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers »

3gengames wrote: I don't know if any other assemblers offer this, but NESASM also can include other files.
All of them do (I only remember DASM not having .incbin when I used it, but it had been added since). With NESASM though you can't include any file larger than 8kB. My sound data, for one thing tends to be bigger than that.
Post Reply