Parallax Technique General Discussion

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

Post Reply
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Parallax Technique General Discussion

Post by Myask » Wed Mar 08, 2017 10:35 pm

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.
Last edited by Myask on Wed Mar 08, 2017 10:53 pm, edited 1 time in total.

User avatar
rainwarrior
Posts: 7822
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Parallax Technique General Discussion

Post by rainwarrior » Wed Mar 08, 2017 10:48 pm

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!)

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: Parallax Technique General Discussion

Post by thefox » Thu Mar 09, 2017 9:40 am

rainwarrior wrote:Scanline IRQs have some advantage over cycle based IRQs too: ...
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.)
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
infiniteneslives
Posts: 2100
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Parallax Technique General Discussion

Post by infiniteneslives » Thu Mar 09, 2017 10:18 am

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..
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

User avatar
Dwedit
Posts: 4328
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Parallax Technique General Discussion

Post by Dwedit » Thu Mar 09, 2017 1:36 pm

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.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

lidnariq
Posts: 9491
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Parallax Technique General Discussion

Post by lidnariq » Thu Mar 09, 2017 2:41 pm

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?

User avatar
infiniteneslives
Posts: 2100
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Parallax Technique General Discussion

Post by infiniteneslives » Thu Mar 09, 2017 6:18 pm

lidnariq wrote:... 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.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

ccovell
Posts: 1014
Joined: Sun Mar 19, 2006 9:44 pm
Location: Japan
Contact:

Re: Parallax Technique General Discussion

Post by ccovell » Thu Mar 09, 2017 6:59 pm

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

User avatar
rainwarrior
Posts: 7822
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Parallax Technique General Discussion

Post by rainwarrior » Thu Mar 09, 2017 7:06 pm

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.

Post Reply