Parallax Technique General Discussion

Diversion topic from off-topic in Lizard topic

Splitscreen Methods I'm aware of:

• Rewriting Scroll at precise timing, by…
  
  • Mapper-based scanline IRQs!
    
    • Costs producer, customer money for mapper chip.
  • …or cycle IRQs!
    
    • Costs producer, customer money for mapper chip.
  • DPCM IRQ as timer!
    
    • Costs the DPCM channel.
    • "A hassle"--Tokumaru, Rainwarrior
  • Cycle-timing!
    
    • Costs severe programmer time and code flexibility.
  • Sprite 0 hit! (SMB1 for status bar)
    
    • can only do one.
    • requires wait-loop, costing significant CPU time, or issues as with cycle-timing
  • Sprite overflow check!
    
    • Buggy, has to be first
    • Costs 9 sprites
    • requires wait-loop, costing significant CPU time, or issues as with cycle-timing
• CHR banking! (I believe Sword Master and Return of the Joker do this, like Crisis Force)
  
  • costs significant CHR space
• CHR-RAM rewriting! (Battletoads level 2: Wookiee Hole)
  
  • costs precious VBlank cycles
• Vertical split by address rejiggering; must be tile-aligned (e.g. MMC5)
  
  • MMC5 not monetarily feasible to use, hard to replicate
• Faking a band of parallax by sprites over an unmoved blankground
• (auxiliary) Faking layer overlap by sprites

Theoretical one I'd come up with:

• Mapper with an automatic (yet configurable) shifter for one or more ranges of CHR tiles. Easier if one only has a single tile being shift-rotated rather than wider repeat length.

Exceptional NES visual effects animated GIF collection has instances of just about everything, though I'm by no means an authority on which does what.

Scanline IRQs have some advantage over cycle based IRQs too:

• NTSC vs PAL might not require different timing/code to handle. (Sprite-0 and Overflow should have this advantage too.)
• Every IRQ has jitter error, if a cycle IRQ can't automatically restart itself the error will compound with each split.

Also, parallax layer sprites are often "under" an unmoving background too.

(Thanks for creating this thread. Also, I didn't realize lists could nest!)

On the downside, scanline-based IRQs stop counting when rendering is disabled, which is sometimes inconvenient. (Not really for parallax, but for stuff like when you want to enable rendering 20 scanlines into the frame, and things like that.)

Recently I've made plans to write my own CIC implementation so I can migrate from the attiny13 to the stm8s003F6. The primary motive is recuded cost, but it also comes with the side benefit of 16 total I/O. The CIC itself only needs 2-4 of those, leaving 12+ io for any useful ideas.

The bummer is none of the io can be configured as triggers for the chips internal counters with the F6 variant. So there isn't much possibility for a counter based off of any card edge pins. But one could create an IRQ timer based off of the internal 16Mhz/128Khz oscillators.

One of the challenges would be coming up with a "free" communication interface to allow the NES CPU to write (and potentially read) from the mcu. I came up with a method that's free if there's an unused mapper bit in the discrete mapper. It would be a little messy, partially due to the fact the mcu's top priority is servicing the CIC. Some here might be able to come up with a more clever interface than I did. I'll save the off topic details for another discussion, but thought I'd bring it up as it might be of interest if one really wanted a potentially "free" mapper IRQ for discrete mappers.

There are some other features that could be more interesting than an IRQ timer. Things like expansion audio, simpler save data interface than PRG-FLASH, UART/SPI/I2C interface to any number of peripherals.

The real cost comes with the hardware development and efforts to properly emulate aiding game development. My guess is those efforts outweigh the interest in such an idea.. But before long the hardware will be on board with all those extra io wasting away..

So this improved CIC idea...
What about putting in serial input from cartridge writes, and acting as a mapper? So it would kinda be both a CIC and a MMC1-like thing.

One of the PICs (or AVRs) with CLCs would be an ... obvious? place to go for combining hardware for cost reduction.

But that won't really get you anything more exciting than GNROM; they're not really comprehensive enough


I know that with the SuperCIC you need cycle-by-cycle accuracy, because the pins are only driven for a single clock and it checks on exactly the right cycle. But I haven't paid enough attention to the NES's CIC to know whether you could get away not using the external 4MHz clock (or a PLL multiple of it) as your CPU clock?

... could we not have this hardware discussion in § NES Graphics? Open a new thread or move this fragment?

Yes, sorry for straying off topic, detailed discussion moved here.

Limited parallax effects can be done with palette cycling, if one is ever so desperate.

Yeah, palette cycling is a good idea too! You might say "desperate" but it was kind of essential for Rad Racer to be able to make the stripes on the road move without CHR banking. (A good supplement on top of the other 3D simulation techniques?)

It's a pretty common way to make water move differently than the rest of the screen too.