Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

This is pretty cool! It reminds me of that Dragon Ball game that does something similar. Have you considered making a version that uses Mode 0? That way, you could have two standard overlapping parallax layers for each view.

I was recently thinking about how fun it would be to make a Mario-style platformer like that, where each player can completely wander off on their own. The screen would split when they move far enough apart in any direction, and with 2bpp visuals, I think it might even be possible for them to enter entirely different levels—all while staying within VRAM limits for tiles and other resources. With some clever use of row and line scrolling for extra faux parallax, it could look really impressive, too.

Of course, it wouldn’t have to be a Mario-style game—it could just as easily be a run-’n-gun, a horizontal shmup, or something entirely different. Mario was just the first example that came to mind.

Just putting the idea out there. :)

Thanks!

That's right I stumbled on that Dragon Ball game while looking for similar effects on the SNES. The game has a really nice implementation, I like how it switches from left to right for instance. Also it's much more advanced, with parallax and all the bells and whistle.

I see no reason to exclude mode 0. I think we could also achieve parallax effect with a single background per player, controlling bg scroll with HDMA. Split-screen only uses a single HDMA channel.

The challenge with multiple levels would be determining the relative positions of players, I guess. VRAM wise, each player would have a dedicated tileset. Also, I was able to cut corners (see the look-up tables) by assuming a 512x512 area.

One challenge that I didn't address would be sprites moving from one screen to the other (enemies, projectiles, ...). Since we have the HDMA table at hand, I guess we could just compare sprites positions with the split-point to hide them before they cross the line, but that could be computationally heavy.