nesdev.org

I noticed that FCEUX 2.something seems to cut off the top eight pixels. I have to constantly remind myself about the overscan areas when developing with Nintendulator

By default, FCEUX displays lines 8 to 231. This can be changed in the GUI (Windows) or at the command line (others).

As a godlen rule you should avoid putting important information in the first 12 lines and the last 12 lines. It's also best to avoid putting some really ugly glitches there.

Most emus cut 8/8 but I've heard actual TVs might cut even more, while PAL TVs will definitely cut nothing !

For left/right, it's pretty much the same, you should avoid putting important information in the left/right 8 pixels or so as they might be invisible. The left/right 2 pixels will always be cut of on PAL TVs too (they aren't even rendered).

I always configure all emulators to show all scanlines.

What I meant is, for development purposes, you should ideally make the game looks "allright" both with all scanlines visible, and with all the scanlines that could be cropped, not visible.

In other words if you always have all scanlines visible like toku, you could end up putting important information in the edges by forgetting this could be hidded.

If you always have all borders masked, you would end up with sprites popping (which is in fact inevitable) and BG scrolling glitches.

Bregalad wrote: In other words if you always have all scanlines visible like toku, you could end up putting important information in the edges by forgetting this could be hidded.

Note to self: add an option to an emulator to render the safe area markers on top of the emulated image (FCEUX can already do this with LUA..).

Bregalad wrote:What I meant is, for development purposes, you should ideally make the game looks "allright" both with all scanlines visible, and with all the scanlines that could be cropped, not visible.

Ah, sure. I was just saying I don't like programs hiding things from me (the very first thing I do after installing Windows is configure it to display file extensions, hidden folders/files and system folders/files), so I configure my emulators to show all scanlines. But of course, I avoid placing important info too close to the edges.

If you always have all borders masked, you would end up with sprites popping (which is in fact inevitable)

They're not really inevitable... If you mask the top of the screen to hide scrolling glitches, and mask the left of the screen using the built-in PPU feature, you can have sprites enter/leave the screen smoothly in any direction.

In my game I do mask the top of the screen, but not the left. Having that area blanked (and reducing the horizontal resolution from a nice 256 pixels to an odd 248) bothers me more than sprites popping! =)

Oh you're right it's not inevitable, but you see what I mean... If you use a game with a simple mapper and don't want to have headaches, you're not going to avoid that.

In fact there is 3 ways this can be avoided :
- Waste one CHR-ROM bank, make it all blank and use it on all banks to hide the top 8 scanlines. Of course if you use CNROM you won't be wasting 8KB of your 32kb CHR just for that
- Do it the Battletoads way, but restrict the forced blanking area to 8 scanlines. However I'm not a huge fan of this method for some reason, I just don't like forced blanking being used other than during game transitions.
- Disable BG but not sprites via $2001, and use 8 blank high-priority sprites to hide sprites. This is the most economical way as it only waste 1 tile and 8 sprites

Anyways all 3 ways requires timed code, and you're likely to have to deal with the constant VBlank timing stuff if you want them, which is really not my cup of tea.

Bregalad wrote:Of course if you use CNROM you won't be wasting 8KB of your 32kb CHR just for that

True... But with CNROM you can actually get away with 4KB of blank tiles if you make sprites and background use tiles from the same pattern table. Even if you use 8x16 sprites from both pattern tables you can temporarily set them to 8x8 to force them to fetch patterns from the blank pattern table, and after the masked area you can set them back to 8x16. 4KB of CHR-ROM is still a lot of what's available in CNROM, but it's a lot better than 8KB.

Well you are right that 4KB wouldn't be nearly as bad.
Anyway I don't see any reason to do this over the third method I mentioned.

Unless you absolutely need all 64 sprites to be displayed and can't allow to be restricted to only 56. Or if you use 8x16 sprites (I never do) and don't want to hide lines 8-15.

tokumaru wrote:I imagined using the first few scanlines of the frame to draw the status bar (since those scanlines are outside the safe area you wouldn't want any information there anyway) and then a sprite hit would indicate the end of the status bar. At that point you might need to blank a few more scanlines, in order to avoid vertical scrolling glitches. Please let us know if you code something like this!

I did a little proof of concept about this as well: http://kkfos.aspekt.fi/downloads/status-bar.zip. The ROM is set to FME-7 but doesn't use IRQs or anything. It uses vertical mirroring. Still needs some tweaking to make it look better (and to actually have something in the status bar instead of blank tiles) but anyway I think it's a really nice little technique. It's great to be able to have glitch free multiway scrolling + status bar on simple configs such as UxROM!

Pretty cool. I guess this is a perfectly valid way to have a status bar and free scrolling. And in the process you even get rid of scrolling artifacts.

thefox wrote: I did a little proof of concept about this as well: http://kkfos.aspekt.fi/downloads/status-bar.zip. The ROM is set to FME-7 but doesn't use IRQs or anything. It uses vertical mirroring. Still needs some tweaking to make it look better (and to actually have something in the status bar instead of blank tiles) but anyway I think it's a really nice little technique. It's great to be able to have glitch free multiway scrolling + status bar on simple configs such as UxROM!

I don't think your proof of concept proofs anything... It's likely way too much work to update the whole status bar every time your cross a tile horizontally (potentially every frame).

You'd say that if the status bar is small enough and if you blank extra lines this might become possible but then why not do it like Jungle Book instead, which seems more clever.

Bregalad wrote:I don't think your proof of concept proofs anything... It's likely way too much work to update the whole status bar every time your cross a tile horizontally (potentially every frame).

You'd say that if the status bar is small enough and if you blank extra lines this might become possible but then why not do it like Jungle Book instead, which seems more clever.

The code already handles nametable crossing. I also made it better today so that it actually displays something meaningless (altho I forgot to update the attributes, so I need to find CPU time to write 8 more bytes). The extra blanking is not a problem for me.

How does Jungle Book do it? I can't make sense out of it because it sets the palette to black in the bottom of the screen so the nametable viewers of emulators are almost useless. It seems to keep the status bar always in the first nametable but I don't understand how that can work with vertical mirroring...

EDIT: Ah, I think I got it (when I was trying to figure it out on paper I was wrongly thinking that the visible (playfield) area is 256x240). So you're right, moving the status bar vertically is better (CPU usage wise) than moving it horizontally, which I was doing in my example. For what it's worth, here's my latest attempt: http://kkfos.aspekt.fi/downloads/status-bar2.zip. It displays some actual text, but doesn't update attributes yet. (FYI the player character starts behind the status bar.)

thefox wrote:How does Jungle Book do it?

From what I can see, it's the same basic idea, but instead of redrawing the entire thing every frame it progressively draws stacked copies of the status bar as the vertical scroll changes. That way, even if he playfield overwrites one of the copies, at least one copy will be usable at any given time.

The advantage is that it requires less VRAM updates, at the expense of a significant area of the status bar, since the area that would normally be occupied by one has to be used for two, so it can't be as tall.

So you're right, moving the status bar vertically is better (CPU usage wise) than moving it horizontally, which I was doing in my example.

I came to the same conclusion after seeing your first demo. The main advantage is that you have to set the VRAM address fewer times.

For what it's worth, here's my latest attempt:

Looks great.