Consequences of trying to disable CIRAM in clones that don't allow it?

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

User avatar
Gilbert
Posts: 384
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by Gilbert » Wed Jul 22, 2020 1:48 am

You can use that alternate column update glitches to your advantage though.
Just pretend this a FPS set undersea and you call that a feature! :roll:


Just kidding of course. That really looks bad compared to the other forms of tearing shown in this thread.
There are a number of commercial games that got shipped with know bugs or limitations (either too hard or didn't have time to fix) with the manuals mentioning that these were features.

User avatar
tokumaru
Posts: 11742
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by tokumaru » Wed Jul 22, 2020 9:08 am

calima wrote:
Wed Jul 22, 2020 1:25 am
That alternating rows wouldn't even be possible on a NES, I think.
It is possible the way I'm coding the rendering engine. Each pair of software pixels is a separate tile, and I use raster effects to display only 2 scanlines of each row of tiles. If I update odd and even rows of tiles alternatingly, that's the effect you'll get.

User avatar
Ben Boldt
Posts: 557
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by Ben Boldt » Wed Jul 22, 2020 9:26 am

tokumaru wrote:
Wed Jul 22, 2020 9:08 am
calima wrote:
Wed Jul 22, 2020 1:25 am
That alternating rows wouldn't even be possible on a NES, I think.
It is possible the way I'm coding the rendering engine. Each pair of software pixels is a separate tile, and I use raster effects to display only 2 scanlines of each row of tiles. If I update odd and even rows of tiles alternatingly, that's the effect you'll get.
This demo fascinates me, it's really cool.

I can't wrap my head around how you are managing the color palettes for this. You must have the normal 16x16 grid, unless you went to MMC5 which gives you 8x8, or the theoretical max of 8x1 afaik... This creates a great illusion because there are too many colors for just 1 palette and I just can't distinguish where that 16x16 grid is.

Edit:
Each 'software' pixel is 16x16 screen pixels? Is that how? The motion makes it seem higher resolution than that! fantastic

Edit 2:
Would this be an opportunity to use dual-port RAM?

User avatar
tokumaru
Posts: 11742
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by tokumaru » Wed Jul 22, 2020 6:01 pm

Ben Boldt wrote:
Wed Jul 22, 2020 9:26 am
I can't wrap my head around how you are managing the color palettes for this. You must have the normal 16x16 grid, unless you went to MMC5 which gives you 8x8, or the theoretical max of 8x1 afaik... This creates a great illusion because there are too many colors for just 1 palette and I just can't distinguish where that 16x16 grid is.
The animations in this topic are from my really old demo, which can be downloaded here: http://membler-industries.com/tokumaru/ ... ter_01.nes

It uses absolutely no PPU tricks. No raster effects, no bankswitching, it's just a plain NES background. The software pixels are 8x2 pixels, so each tile contains 4 software pixels stacked vertically. If I allowed all colors to appear in all positions, I'd only be able to use 4 colors total (4 ^ 4 = 256 combinations), so instead I applied some restrictions on which pixels could appear together and how.

The basic palette is arranged like this:
0 - black (used for shading the main colors via dithering);
1 - main floor/ceiling color (to be dithered with black to differentiate floors and ceilings);
2 - main wall color A (varies depending on the walls that are found);
3 - main wall color B (varies depending on the walls that are found);

The most basic tiles are the ones that contain only wall pixels (no floor or ceiling pixels). Walls use 1bpp textures (pixels are either light or dark), so that's 2 shades ^ 4 positions = 16 tiles for each type of wall. We have 4 types of walls: color A light face, color A dark face, color B light face, color B dark face, using a total of 64 tiles.

Then come the tiles that contain either ceiling or floor pixels. These are similar to the first 64 patterns, but instead of 4 wall pixels they have 3, 2 or 1 wall pixels, with the remaining space occupied by floor or ceiling pixels:

2 shades ^ 3 positions = 8 tiles. Times 4 types of walls, times 2 types of flats (floor and ceiling) = 64 tiles.

2 shades ^ 2 positions = 4 tiles. Times 4 types of walls, times 2 types of flats (floor and ceiling) = 32 tiles.

2 shades ^ 1 position = 2 tiles. Times 4 types of walls, times 2 types of flats (floor and ceiling) = 16 tiles.

Then comes 1 tile filled with the ceiling pattern, and another filled with the floor pattern. And finally, there's the tiles for the black wall:

4 black pixels = 1 tile;
3 black pixels + ceiling = 1 tile;
2 black pixels + ceiling = 1 tile;
1 black pixel + ceiling = 1 tile;
3 black pixels + floor = 1 tile;
2 black pixels + floor = 1 tile;
1 black pixel + floor = 1 tile;

If I didn't forget anything, that's a total of 185 tiles for the 3D scene, which leaves 71 free for the hud/interface.

Even though each palette only has room for 2 wall colors, by combining 3 palettes we can have 3 wall colors on screen at once:

Palette 0: black, floor/ceiling, wall A, wall B;
Palette 1: black, floor/ceiling, wall A, wall C;
Palette 2: black, floor/ceiling, wall B, wall C;

Each palette affects a 16-pixel wide area, meaning it affects two columns, so these 3 palettes contain all possible pairs out of 3 colors, allowing us to correctly render any pair of walls that happen to meet in the same attribute area. If I was using the MMC5's 8x8 attribute mode, I would be able to fit 6 different wall hues on screen at once.

Anyway, the 3 color slots are allocated dynamically as the walls are hit by the rays that are cast from the player. This dynamic color allocation makes it easy to create colorful levels, since you don't need to explicitly program the palette changes, you simply have to design the maps in a way that no more than 3 wall colors are visible at once.

The demo actually breaks that rule: if you go inside the room with the green blocks and stand close to the door, you can actually get blue, green, red and orange blocks visible at once, and when that happens, the last color that's found will not be drawn correctly (it will be replaced by one of the 3 colors that were found first).
Each 'software' pixel is 16x16 screen pixels? Is that how? The motion makes it seem higher resolution than that! fantastic
The new (unreleased) engine is very different. I wanted more horizontal resolution and more colorful walls (no more simple 1bpp textures), so the basic idea of heavily restricting pixel combinations wouldn't work anymore. So I basically did away with all the careful tile layout and dynamic color allocation from before in favor of having the 256 tiles contain all combinations of 2 out of 16 virtual colors created from dithering the 4 colors of a single palette: 16 colors ^ 2 positions (left and right) = 256 tiles.

Since the colors are arranged in each tile side by side, this means that each software pixel is 8 pixels tall!!! That is obviously unacceptable, so I'm now using raster effects timed with MMC3 IRQs to scale the image vertically, making software pixels only 2 pixels tall. In the end, the horizontal resolution is double that of the old demo, which means that wall textures are much more discernible.
Would this be an opportunity to use dual-port RAM?
I don't think it's absolutely necessary, and I prefer to use common hardware whenever possible. Hence the existence of this thread, which I started because I wasn't comfortable with using hardware with compatibility issues. :lol:

User avatar
tokumaru
Posts: 11742
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by tokumaru » Fri Jul 24, 2020 1:27 am

Gilbert wrote:
Wed Jul 22, 2020 1:48 am
Just pretend this a FPS set undersea and you call that a feature! :roll:
I guess the effect does kinda look like underwater distortion, and I do plan on having underwater sections... hum... :idea:

Anyway, I just thought of another pro of going with horizontal tearing: since images are rendered in columns anyway, the first half of each new frame will be ready for display before the second half is, which means I can start updating the screen even before the whole picture is ready, slightly reducing the amount perceived input lag.

Except that objects may end up preventing this if they're rendered with background tiles, since they're not necessarily rendered from side to side, but from back to front. I guess I could sort objects both horizontally and by depth.

User avatar
Ben Boldt
Posts: 557
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by Ben Boldt » Sun Jul 26, 2020 12:41 pm

I am really impressed by what you have done here within so many constraints. It is so easy nowadays to say, put in an FPGA and 1 GB flash into the cart, rasterized graphics, etc, and that's tempting and interesting but frankly not authentic anymore once you do that. Something of the original charm is forever lost when people do that. Not sure if you have seen Filthy Kitchen for example. That game is very simple but nails the charm of the NES, you can just feel it in your bones.

I feel like what you are doing here, within era-appropriate constraints, pushes this platform in a new direction farther than it has gone before. I wish I had seen your 3D demo earlier. Your creativity making this possible reminds me of SunSoft. Keep up the good work.

User avatar
tokumaru
Posts: 11742
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Consequences of trying to disable CIRAM in clones that don't allow it?

Post by tokumaru » Mon Jul 27, 2020 11:11 pm

Thanks for the compliments!

Post Reply