It is currently Fri Aug 18, 2017 5:05 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 34 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Sat Aug 12, 2017 4:07 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1683
Location: DIGDUG
So, I thought we had talked about this before, and it seemed easy, but I'm scratching my head. All direction scrolling, without showing tiles change, nor attribute table errors...

I was thinking vertical mirroring, would make it easy to scroll left and right without problem. And, leaving BG rendering off for the top 16 pixels would solve up/down scrolling issues. It might be very hard to time this correctly...(NROM) since sprite zero hit won't work with BG off.

Any other suggestions?

Horizontal mirroring with sprites hiding the right and pixels turned off on the left?

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Sat Aug 12, 2017 4:33 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 9884
Location: Rio de Janeiro - Brazil
For a long time I did exactly what you described, but instead of the sprite 0 hit I used a sprite overflow to time the blanking at the top of the screen. Conveniently enough, the 9 sprites also masked any sprites that happened to go up there. The down side is that, besides losing 9 sprites, you have to waste 8 or 16 scanlines worth of CPU time, depending on the height of your sprites.

To avoid headaches once and for all, I finally switched to a 4-screen layout (i.e. no mirroring). If the cartridge uses CHR-RAM, 4-screen comes for free because of the RAM sizes available today.


Top
 Profile  
 
PostPosted: Sat Aug 12, 2017 6:05 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1683
Location: DIGDUG
Sprite Overflow.

4-screen VRAM.

Both good suggestions. Thank you. That's what I was looking for.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Sun Aug 13, 2017 2:39 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 685
Location: Sweden
What mapper do you suggest to use with 4-screen?

Looks like standard MMC3 can do 4-screen and it seems like a good mapper to me. CHR-RAM, PRG-RAM, nametable arrangement control (or 4-screen), scanline IRQ and a good amount of PRG and CHR space.


Top
 Profile  
 
PostPosted: Sun Aug 13, 2017 3:22 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 777
Location: Gothenburg, Sweden
Quote:
What mapper do you suggest to use with 4-screen?

If you can live without scanline irqs, GTROM is great. Powerful for its home tinkerer friendly price per board.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sun Aug 13, 2017 6:16 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 9884
Location: Rio de Janeiro - Brazil
Any mapper can do 4-screen, but some mappers may require more complicated logic on the cartridge than others. On discrete logic mappers with CHR-RAM, the use of 4-screen is trivial: one wire on the cartridge tells the NES to keep its internal VRAM permanently off so the VRAM in the cartridge (which must be at least 16KB) is used not only for attribute tables, but also for name tables.

GTROM is cool and takes things a step further, doubling the CHR-RAM and NT capacity through bankswitching.


Top
 Profile  
 
PostPosted: Sun Aug 13, 2017 9:00 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 685
Location: Sweden
I see. That's good as long as the 4-screen modifications doesn't conflict with any behaviour defined in iNES or NES 2.0 standard, so that it doesn't work properly in emulators or flashcarts.

While GTROM is interesting it seems it only comes in 72-pin. I have no NES and I'd avoid using an adapter if possible.


To get back on topic, if 4-screen can't be used for whatever reason, what other options are there besides sprite overflow?


Top
 Profile  
 
PostPosted: Sun Aug 13, 2017 9:16 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 777
Location: Gothenburg, Sweden
Some of its features are probably not implemented in emulation. 7.5kB extra ram accessible via PPU address space, self modification (since it's flash), the two LEDs come to mind. I assume the LEDs were included as an easy way to say "don't shut me off while i'm saving your precious game/modifying myself!"

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sun Aug 13, 2017 9:56 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6028
Location: Seattle
Many years ago, someone (tepples?) observed that "XOR" nametable layout (▞) should make almost-seamless scrolling possible ...

We're pretty certain that no commercial games used it—preventing glitches just wasn't a high enough priority—but the hardware needed is trivial, and any mapper with the ability to arbitrarily configure nametables could be used to develop for it.


Top
 Profile  
 
PostPosted: Sun Aug 13, 2017 10:28 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 250
I find it interesting to observe that besides Tengen's Gauntlet and Irem's Napoleon Senki (and Rad Racer 2, which doesn't seem to use it for actual four-way scrolling), the only other games that use 4-screen VRAM (and that I'm aware of) are Sachen games, namely Jurassic Boy 2, Rocman X and Zhōngguó Dàhēng. Zhōngguó Dàhēng actually uses six nametables --- four on cartridge RAM for the game board, and the two in the console for the status bar.


Top
 Profile  
 
PostPosted: Sun Aug 13, 2017 10:49 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5537
Location: Canada
NewRisingSun wrote:
I find it interesting to observe that besides Tengen's Gauntlet and Irem's Napoleon Senki (and Rad Racer 2, which doesn't seem to use it for actual four-way scrolling), the only other games that use 4-screen VRAM (and that I'm aware of) are Sachen games, namely Jurassic Boy 2, Rocman X and Zhōngguó Dàhēng. Zhōngguó Dàhēng actually uses six nametables --- four on cartridge RAM for the game board, and the two in the console for the status bar.

Well, right now it's no cheaper to get 8k than 64k SRAM, hence why it's basically a "for free" feature if you have CHR-RAM. Those Sachen games you mentioned all came well after the official commercial era of NES games had ended. I don't know what RAM costs were like in the late 90s but there's probably a point in there where it was just really cost effective to have extra nametable RAM + CHR-RAM.


Top
 Profile  
 
PostPosted: Sun Aug 13, 2017 10:54 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5537
Location: Canada
FrankenGraphics wrote:
Some of its features are probably not implemented in emulation. 7.5kB extra ram accessible via PPU address space, self modification (since it's flash), the two LEDs come to mind. I assume the LEDs were included as an easy way to say "don't shut me off while i'm saving your precious game/modifying myself!"

I implemented if in FCEUX about a year ago. Aside from the LEDs, I think it's actually a "complete" implementation. It even does the flashing.

The "extra ram via PPU" thing isn't its own special feature, it's just a side effect of the nametable banking. $3000-3F00 isn't used by rendering, but the SRAM is just mapped flatly across it anyway in case you want to use it.

(It was just after the last stable release of FCEUX, unfortunately, but there's an interim build available on the site that would have it.)


Last edited by rainwarrior on Sun Aug 13, 2017 11:21 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sun Aug 13, 2017 11:09 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18798
Location: NE Indiana, USA (NTSC)
rainwarrior wrote:
Well, right now it's no cheaper to get 8k than 64k SRAM, hence why it's basically a "for free" feature if you have CHR-RAM.

Unless you're already banking the CHR RAM to allow more than 4K for background tiles and 1K for player and boss sprite cels without slowing down background tile animations. Haunted: Halloween '85 uses the same board as Lizard, which provides 8K CHR RAM to allow 256 background tiles at once and double-buffered 256-byte sprite cels that take two frames to load. Its sequel The Curse of Possum Hollow, by contrast, uses separate 4K CHR RAM banks for the playfield, the parallax strips, and the subtitle font, and sprite cels are arranged into 1K sheets each loaded over the course of eight frames. Most of this CHR trickery could have been done with the TQROM setup, but an 8K RAM and 64K ROM is probably more expensive.

It's tricky to use video memory at $3000-$3EFF for game logic because you have to wait for vblank, which may already be chock full of tile and nametable transfers to video memory, and you have to know a frame in advance what memory you're going to need to read.


Top
 Profile  
 
PostPosted: Sun Aug 13, 2017 1:22 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7145
Location: Chexbres, VD, Switzerland
Pokun wrote:
What mapper do you suggest to use with 4-screen?

To be honnest the most elegant mapper which does it is Napoleon Senki's mapper. It does it in a very elegant way using 2kb of CHR-ROM for animated tiles, and using the remaining 6kb for CHR-RAM and leaving 2 extra KB for 2 name tables, combined with the CIRAM for the other 2. It's amazing. Unfortunately this mapper was wasted on a horrible game.

As for your original post:
Quote:
So, I thought we had talked about this before, and it seemed easy, but I'm scratching my head. All direction scrolling, without showing tiles change, nor attribute table errors...

Outside of 4-screen mirroring which I consider a bit cheating, there is only one way to go really for FULLY clean scrolling with no attribute clash, and no sprite popping : Use vertical mirroring with 16 scanlines at the top hidden AND use $2001 to hid the left 8 pixels. If you use 8x8 sprites, you can hide the top and bottom 8 scanlines instead of the top 16, but it'd be hard to achieve without an IRQs mapper. Hiding the top 16 lines however is very much doable without an IRQ mapper. It requires a constant-timed NMI routine but I don't think it's even close to impossible to achieve :)

PS: Technically you could do it with "only" 15 hidden lines, 16 aren't needed, but you get the idea.


Top
 Profile  
 
PostPosted: Sun Aug 13, 2017 2:06 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 9884
Location: Rio de Janeiro - Brazil
Bregalad wrote:
Hiding the top 16 lines however is very much doable without an IRQ mapper. It requires a constant-timed NMI routine

It doesn't require a constant-timed NMI routine. If you can guarantee a sprite 0 hit or a sprite overflow (which is what I use to mask sprites at the top of the screen as opposed to keeping rendering completely off and getting the alternate dot crawl pattern) every frame, you can wait for one of these flags to be cleared in order to detect the end of vblank after you're done with your non-contant-timed NMI handler. Then you wait 16 scanlines with timed code (you can do some contant-timed tasks here if you want), and finally turn background rendering on.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 34 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] and 7 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