It is currently Tue Oct 24, 2017 12:43 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 92 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next
Author Message
PostPosted: Mon Jan 13, 2014 8:50 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
Okk wrote:
Right now I only have thirteen animated tiles, and I think I've been assuming I'd simulate CHR-RAM for that, but I may need to reconsider.

13 tiles is 208 bytes, quite a lot of CHR-RAM data to update in a single frame. If you do update that many tiles during VBlank, there won't be any time left for other VRAM updates. Also, you can't really mix CHR-ROM and CHR-RAM (although a couple of obscure mappers do this, there are limitations), you're gonna have to pick one kind or the other to simulate.

Quote:
I've adjusted it a bit so that the topmost line is entirely black (or should it be a different color?)

It should use the global background color, because that's what's displayed when rendering is off. If the global background color (i.e. "color 0") has to be changed as well, do it before or after the blanked scanlines, so that both are the same color.

Quote:
If this isn't enough to change four background palette colors, scrolling and a set of background tiles, I could conceivably add another blanked scanline on top, eating one scanline from the play area.

I'd go with 2 blanked scanlines, in order to have 3 HBlank periods to perform palette and scroll updates. CHR-ROM swaps can be done even outside of HBlank, so there's plenty of time for that. CHR-RAM updates are out of the question though, as the time of 2 scanlines isn't enough to update even 2 tiles.

Quote:
Blanking scanlines like this doesn't change the position of the tiles below, does it?

Not if you don't want to.

Quote:
Under my status bar is a set of tiles to be swapped in. But you might notice that it doesn't contain the skill icons present on the status bar. There will probably be quite a few icons, so the status bar could actually require up to three sets of tiles to be swapped in. Would I have to do each one on a different scanline?

No, CHR-ROM swaps are incredibly fast... during the 2 blanked scanlines you could easily swap, say, 20 chunks of CHR-ROM without problems.

Quote:
If I'm not mistaken, there would need to be an update to the nametable, is that right? (Either that or sacrifice as many as three tiles from any set that I might be swapping out at the time.)

What? I don't see the need for a name table update halfway through rendering. All name table updates, for the playfield and the status bar, should take place during VBlank.


Top
 Profile  
 
PostPosted: Mon Jan 13, 2014 3:21 pm 
Offline
User avatar

Joined: Thu Dec 19, 2013 9:29 pm
Posts: 23
tepples wrote:
About use of Z and X: German and French keyboards move Z far from X, and a lot of people prefer to play using a USB joystick. You'll want to make keys configurable.
Ah, that's a good idea. I'll start looking into that.

tokumaru wrote:
It should use the global background color, because that's what's displayed when rendering is off. If the global background color (i.e. "color 0") has to be changed as well, do it before or after the blanked scanlines, so that both are the same color.
I was thinking one of the colors changed would be the background, to black.

tokumaru wrote:
What? I don't see the need for a name table update halfway through rendering. All name table updates, for the playfield and the status bar, should take place during VBlank.
If I can change three sets of tiles before any of the tiles start drawing, then it's a nonissue.

So, if I have drawing turned off for two scanlines, then does that mean that any sprite wandering into those scanlines would lose two rows of pixels, like in the attached image?

I also have a question that may not directly relate to graphical capabilities. I've noticed that in some games, out of sight is out of mind. In Mega Man, for example, once an enemy falls offscreen, the game forgets that it exists (or, more importantly, that it doesn't.) Other games, like Super Mario Bros. 3, do the states of offscreen enemies, but I think Zelda only bothers to remember selective information about them. Does the handling of offscreen enemies have something to do with system limitations, or is it completely up to the whims of the developers?


Attachments:
the status bar is not your enemy.png
the status bar is not your enemy.png [ 4.35 KiB | Viewed 953 times ]
Top
 Profile  
 
PostPosted: Mon Jan 13, 2014 3:29 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
Okk wrote:
Does the handling of offscreen enemies have something to do with system limitations, or is it completely up to the whims of the developers?

Both. Mostly it has to do with how much CPU time and RAM the developers want to spend on offscreen enemies.


Top
 Profile  
 
PostPosted: Mon Jan 13, 2014 3:35 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6304
Location: Seattle
Okk wrote:
So, if I have drawing turned off for two scanlines, then does that mean that any sprite wandering into those scanlines would lose two rows of pixels, like in the attached image?
Well, you could disable sprites after the edge to make it moot.

Actually, we haven't figured out how to disable rendering midframe without corrupting the sprite data, but if we had, there wouldn't be a pause of N scanlines: instead, sprites would resume as though the lines had never been disabled.
Quote:
Does the handling of offscreen enemies have something to do with system limitations, or is it completely up to the whims of the developers?
The NES only provides 2048 bytes of RAM for the entire state of the game, for every purpose. While some games provide more memory, it cost more money, and so most games decided that keeping track of what things were in what state just wasn't worth it unless it was obviously problematic.


Top
 Profile  
 
PostPosted: Mon Jan 13, 2014 4:36 pm 
Offline
User avatar

Joined: Thu Dec 19, 2013 9:29 pm
Posts: 23
lidnariq wrote:
Well, you could disable sprites after the edge to make it moot.
In that case, sprites would appear to go behind the status bar, right?

lidnariq wrote:
The NES only provides 2048 bytes of RAM for the entire state of the game, for every purpose.
Oh, wow. So for each onscreen enemy, I'd imagine the game would need to track the enemy's ID, animation frame, X and Y position and possibly X and Y velocity, as well as any relevant stats. For games with simpler enemies that might include just a handful of flags tracking the state, but other games might need to track things like health, damage output, weaknesses and resistances, et cetera. And for offscreen enemies, a lot of this becomes irrelevant; I'd imagine some games could even get away with only a single flag indicating whether the enemy was alive (if even that.)

Does the game have to keep track of an enemy's static, or can it get by with just dynamic stats, and read the static ones from the ROM as necessary? If every Hammer Joe is weak to the Hard Knuckle, does that weakness have to be stored in RAM, or could the game grab a list of weaknesses from ROM based on the enemy's ID every time an attack hits it? If Goomba's walking speed is always the same, could its X velocity be replaced by a flag indicating which direction its pointed?

These 2048 bytes of RAM, of course, must also store game-wide information, like how many Triforce pieces you've collected, right? In an RPG, would the game have to track a flag for every single treasure chest in the entire game? Or, could it hypothetically get away with keeping track of the treasure chests in the current dungeon, and then reading treasure chest data from the save file whenever you change maps? (Not that I expect to discover an NES save file can be particularly large.) Does this RAM also store much audio channel information?


Top
 Profile  
 
PostPosted: Mon Jan 13, 2014 5:10 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
Okk wrote:
So for each onscreen enemy, I'd imagine the game would need to track the enemy's ID, animation frame, X and Y position and possibly X and Y velocity, as well as any relevant stats.

That, plus X and Y having multiple bytes of precision for moving a fraction of a pixel per frame.

Quote:
And for offscreen enemies, a lot of this becomes irrelevant; I'd imagine some games could even get away with only a single flag indicating whether the enemy was alive (if even that.)

Super Mario Bros. 3 uses such flags. Super Mario Bros. 2 and Kirby's Adventure and Mega Man series do not, instead choosing to respawn an enemy when the enemy's spawn point leaves and reenters the camera's field of view.

Quote:
If every Hammer Joe is weak to the Hard Knuckle, does that weakness have to be stored in RAM, or could the game grab a list of weaknesses from ROM based on the enemy's ID every time an attack hits it?

The latter.

Quote:
If Goomba's walking speed is always the same, could its X velocity be replaced by a flag indicating which direction its pointed?

Some games do that, but other games just load the velocity to simplify coding. There are often tradeoffs among time, ROM space, and RAM space.

Quote:
These 2048 bytes of RAM, of course, must also store game-wide information, like how many Triforce pieces you've collected, right? In an RPG, would the game have to track a flag for every single treasure chest in the entire game? Or, could it hypothetically get away with keeping track of the treasure chests in the current dungeon, and then reading treasure chest data from the save file whenever you change maps?

The save file is mapped as an extra 8192 bytes* of RAM. Some of this is reserved for actual saved games; the rest is used for the current state of the game, especially before the player reaches a save point.

Quote:
(Not that I expect to discover an NES save file can be particularly large.) Does this RAM also store much audio channel information?

A music engine might have about 32 to 256 bytes of state, including information as to which instrument and which sound effect is playing on each channel, the current position in the instrument data, which phrase is selected on each channel, the current position in the phrase, how many frames until the next note, etc.

* About a dozen games had more than that, but 8192 bytes was by far the most common size.


Top
 Profile  
 
PostPosted: Mon Jan 13, 2014 8:02 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
Okk wrote:
In that case, sprites would appear to go behind the status bar, right?

Yup.

Quote:
I'd imagine some games could even get away with only a single flag indicating whether the enemy was alive (if even that.)

I like this approach. In only 32 bytes you can store the alive/dead state of 256 enemies... not many games have levels/rooms with that many enemies. In my designs, I also save a few more bytes (128 or so) for objects that need to remember more than whether they're alive/dead. Objects that need this have pointers indicating where in those 128 bytes their memory begins, and they can use as many bytes as they need as long as there are no overlaps and it all fits in 128 bytes.

Quote:
Does the game have to keep track of an enemy's static, or can it get by with just dynamic stats, and read the static ones from the ROM as necessary?

Everything that doesn't change should be in ROM. Even things that do change sometimes stay in ROM if the possible states aren't too numerous. In this case you'd have a pointer/index in RAM indicating which is the current state.

Quote:
In an RPG, would the game have to track a flag for every single treasure chest in the entire game? Or, could it hypothetically get away with keeping track of the treasure chests in the current dungeon, and then reading treasure chest data from the save file whenever you change maps?

Games that need to keep track of tiny details in ridiculously large worlds (as opposed one level at a time) most likely have extra RAM on the cart (in most cases, 8KB of RAM). Carts that are able to save games keep this same extra memory always powered on with a battery.

Quote:
(Not that I expect to discover an NES save file can be particularly large.)

Actually, since the most common RAM expansion size is 8KB, save data is typically 4 times larger than the built-in memory in the NES! It doesn't have to be entirely used for saving though, games are free to use as much of it as regular RAM as they see fit.

Quote:
Does this RAM also store much audio channel information?

Yeah, audio state has to be kept in RAM (the amount of RAM depends on how complex the music/sound engine is: how many channels it can handle, haw many effects each channel can have, etc.), but the actual data (notes, instruments, etc.) should remain in ROM.


Top
 Profile  
 
PostPosted: Mon Jan 13, 2014 10:24 pm 
Offline
User avatar

Joined: Thu Dec 19, 2013 9:29 pm
Posts: 23
Does every game with a save function have added RAM? Maybe I'm wrong but some games seem like they wouldn't need that much extra memory. Zelda 1, for example, seems fairly minimal, at least for its genre.


Top
 Profile  
 
PostPosted: Mon Jan 13, 2014 10:57 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
Okk wrote:
Does every game with a save function have added RAM?

A few Japanese carts used EEPROMs (reprogrammable chips that retain data when not powered, but can't be used as RAM) for saving, but the vast majority used extra RAM powered by a battery.

Quote:
Maybe I'm wrong but some games seem like they wouldn't need that much extra memory. Zelda 1, for example, seems fairly minimal, at least for its genre.

It may not have needed if, but the fact is it does have this much extra RAM. 8KB may sound like overkill in some cases, but that was probably the size of RAM that could be obtained for cheap at the time (as larger memory becomes more popular, sometimes the smaller chips become more expensive). This game was originally released on the Famicom Disk System though, in the form of a floppy disk, so the saves probably occupied less than 8KB of the disk.


Top
 Profile  
 
PostPosted: Mon Jan 13, 2014 11:15 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
tokumaru wrote:
Quote:
I'd imagine some games could even get away with only a single flag indicating whether the enemy was alive (if even that.)

I like this approach. In only 32 bytes you can store the alive/dead state of 256 enemies... not many games have levels/rooms with that many enemies.

I believe that Zelda had just a counter for each room in the dungeon, so it used log2 n the number of bits (e.g. a room with 7 enemies only used 3 bits). If you defeated a weaker enemy and re-entered, the strongest enemy would be gone, so this was also an easter-egg.


Top
 Profile  
 
PostPosted: Tue Jan 14, 2014 7:40 pm 
Offline
User avatar

Joined: Thu Dec 19, 2013 9:29 pm
Posts: 23
Thanks again for all your help. I have an eclectic assortment of questions now.

How does the dialogue box in Final Fantasy 1 work?

Why does SMB3 have scrolling artifacts even in areas with no vertical scrolling

Dragon Warrior 1 has some dark dungeons that include a halo of light effect. This was done by making most of the background tiles black (which is why the halo is square-shaped and also gridlocked) right? Does that involve changing the nametable a lot?

Earlier on, Grapeshot mentioned that black outlines became a common element of the NES aesthetic to avoid dot crawl. Would dark colors other than black work for that?

Also, I checked out the various demos that you guys have linked me to, and those are some pretty awesome effects. Stuff like that probably didn't show up much in commercial NES games though, I'd assume... Do those kinds of fancy effects largely monopolize the NES' resources? Or could other things be going on at the same time in a game?


Top
 Profile  
 
PostPosted: Tue Jan 14, 2014 7:42 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5736
Location: Canada
If you want to see what's going on in SMB3, open it in FCEUX, go to the debug menu and open the Nametable viewer. It will show you visually exactly what is happening with the scrolling better than I could describe it to you.

The short answer is, though, is that all horizontal levels are two screens tall, even if the camera doesn't go up. This limitation makes it easier to implement the status bar while still allowing the vertical camera motion, but of course it means no level is more than 2 screens tall (except the vertical-only areas like in 5-2).

Check out the first fortress. Even though you can't see the hidden door to the whistle onscreen, it's there in the nametable for the upper part of the level.

Actually most of the things you're asking about can be seen visually in FCEUX's Nametable and PPU viewers. You should really take a look. For instance, I just looked, and Final Fantasy 1 appears to create a copy of the current screen on the currently not-visible half of the nametable space where it overlays the dialog box. Then it gradually displays that copy screen with the dialog with a scanline scroll split.


Top
 Profile  
 
PostPosted: Tue Jan 14, 2014 8:39 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
Okk wrote:
How does the dialogue box in Final Fantasy 1 work?

Never played it, but from looking at a YouTube video I guess you mean how they smoothly scroll in and out? I'd have to debug the game to be sure, but I would just draw the text box to the hidden name table (along with the background that remains visible around it) and use timed scroll changes to switch from the name table with the text box to the name table without the text box during rendering, moving the switch point down every frame.

Quote:
Why does SMB3 have scrolling artifacts even in areas with no vertical scrolling

Because it uses the same engine regardless of the height of the level. Developers would hardly code a different scrolling engine just to get rid of the glitches in some levels.

Quote:
Dragon Warrior 1 has some dark dungeons that include a halo of light effect. This was done by making most of the background tiles black (which is why the halo is square-shaped and also gridlocked) right? Does that involve changing the nametable a lot?

Man, RPGs are really not my thing... time to check YouTube again! =) Well, it's such a small area that it could very well be updated completely every frame, or even use the traditional scrolling technique, which is drawing only the new row/column of tiles and moving the camera (in big 16-pixel increments), with the added step of erasing the row/column that was left behind. Either way it requires less name table updates than regular scrolling, because the area is so small.

Quote:
Do those kinds of fancy effects largely monopolize the NES' resources? Or could other things be going on at the same time in a game?

We'd have to tear apart each effect individually, but a lot of amazing effects I've seen require big look-up tables (which eat away space otherwise used by actual game content), intensive CPU-PPU synchronization (keeping the CPU busy with things other than game logic for long periods) or are very controlled and hard to pull off dynamically (upon player input instead of being scripted), so yes, many effects are impractical in actual games. I'm sure some of them could be utilized in games, but I bet they'd be more like gimmicks than integrated gameplay elements.


Top
 Profile  
 
PostPosted: Wed Jan 15, 2014 1:07 am 
Offline
User avatar

Joined: Thu Dec 19, 2013 9:29 pm
Posts: 23
I took a peek at the nametables. It took me a bit to figure out what was going on, and I'm still not entirely clear on it (like everything onscreen apparently appearing twice), but I think I get the gist of it now. The camera borders move around and only a row or column is updated. Final Fantasy and Dragon Warrior have movement that snaps to the grid so it only needs to update on one axis at a time. And, indeed, the text boxes are drawn onto the offscreen half of the nametable. Looks like there's a delay of several frames as it puts it all down before it even starts to appear onscreen.

The hidden door is certainly visible in the first fortress of Super Mario Bros. 3. So, even if all the action is happening offscreen, does the terrain still have to be in the nametable for the player to interact with it? I also noticed that, in the nametable, SMB3's status bar was kind of a mess...

Dragon Warrior's dark dungeon was different, though. As tokumaru suggested, the borders don't move around, and the visible area is small enough to update the entire thing every frame. I think there's a spell that creates a wider halo of light, but maybe it's still small enough to be handled the same way. How much of the nametable can be updated in a frame?

How would a similar Halo of Light effect handle in a game with a bit more freedom of movement? Even if the player doesn't snap to the grid, the aura would have to, since it's actually part of the background, right? Could it move around by eight pixels at a time? Would it make a difference if the halo followed the player, but the camera only moved on one axis, or not at all? I'd guess that at least some of the sprites would have to go behind the scrolling layer, which would mean the walkable floor would have to be completely transparent.


Top
 Profile  
 
PostPosted: Wed Jan 15, 2014 1:32 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
Okk wrote:
(like everything onscreen apparently appearing twice)

That's a side effect of mirroring. The NES can address 4 screens (name/attribute tables), but it only has memory for 2. This means that the other 2 have to be clones/mirrors. Carts get to pick whether this mirroring is vertical or horizontal. The extra name table we talked about before is so that no mirroring takes place, and the NES actually sees 4 different screens.

Quote:
So, even if all the action is happening offscreen, does the terrain still have to be in the nametable for the player to interact with it?

Well programmed games will separate the graphics (view) from the logic (model) entirely, so this shouldn't be the case.

Quote:
I also noticed that, in the nametable, SMB3's status bar was kind of a mess...

Since games are allowed to change the scroll, palettes and tilesets during rendering, the debugger window is drawn based on the state of a specific scanline. Look for it and you'll see a field where you can type scanline numbers. If you put an scanline where the status bar is rendered, you'll see it with the correct tiles but the playfield will be a mess, because that point comes after a CHR bankswitch.

Quote:
How much of the nametable can be updated in a frame?

You can update around 200 bytes of VRAM (although that number starts to drop as you also have to manage addresses and stuff) and perform a sprite DMA under normal VBlank time. Using a few tricks to speed up the code, it's possible to update a row and a column of metatiles (128 tiles + their attributes).

Quote:
How would a similar Halo of Light effect handle in a game with a bit more freedom of movement?

We had a whole thread about this recently.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users 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