It is currently Fri Dec 15, 2017 1:00 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1389 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 93  Next
Author Message
 Post subject:
PostPosted: Tue Feb 08, 2011 10:56 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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).

Quote:
(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.

Quote:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 09, 2011 12:29 am 
Offline
User avatar

Joined: Sun Dec 12, 2010 10:27 pm
Posts: 298
Location: Hong Kong
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):
Quote:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 09, 2011 12:49 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Gilbert wrote:
I don't know, but as Chris wrote on the page (unless I misunderstood the wordings):
Quote:
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.

Quote:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 09, 2011 1:23 am 
Offline
User avatar

Joined: Sun Dec 12, 2010 10:27 pm
Posts: 298
Location: Hong Kong
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 18, 2011 9:57 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 806
Location: cypress, texas
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! :)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 18, 2011 10:44 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.

Quote:
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.

Quote:
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).

Quote:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 18, 2011 12:18 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19348
Location: NE Indiana, USA (NTSC)
tokumaru wrote:
Quote:
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.

Quote:
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

Quote:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 18, 2011 12:38 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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).


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 26, 2011 11:08 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 806
Location: cypress, texas
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:
.space variable 1
. Thats a 5 character word and it must be used a lot! :( Its two counters, one for the
Code:
.data
sections and another for the
Code:
.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?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 26, 2011 11:13 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 27, 2011 12:05 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3968
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!


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 27, 2011 12:09 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 806
Location: cypress, texas
^ 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... :?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 27, 2011 12:14 am 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 27, 2011 7:23 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19348
Location: NE Indiana, USA (NTSC)
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.

Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 27, 2011 7:26 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3488
Location: Indianapolis
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1389 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 93  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: swee and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group