Using a background as a fake game character

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
Señor Ventura
Posts: 242
Joined: Sat Aug 20, 2016 3:58 am

Re: Using a background as a fake game character

Post by Señor Ventura »

SNES AYE wrote: Sun Jun 09, 2024 12:47 amSo, are you basically saying that's possible?
Technically, yes.

You have the head, and two types of body parts (one for the tail, and the rest for its body). You can draw these three parts of the snake separatedly in a background, in every position in wich it moves (except the mirrored ones).

The way is to not draw until the exact pixel of the graphic in its first line, and put it pixel to pixel in a exact part of the screen, then interrumpts again and skips until the next scanline of the background (not screen), repeating the process. This way you get a multijointed snake (not animated), flicker free, and even longer.

It would need a lot of cpu processing, but this cartridge carries a very powerful one xD
93143
Posts: 1733
Joined: Fri Jul 04, 2014 9:31 pm

Re: Using a background as a fake game character

Post by 93143 »

If no scanline has more than one segment of this layer on it, window masking is a better way to isolate the graphic you want. It's much cheaper because it doesn't eat a bunch of CPU time for overhead; you can just use HDMA. And it's even cheaper if there's enough transparent margin around the graphic horizontally that you can just use a rectangle instead of fitting the window to the exact contours of the visible graphic.

If multiple segments are present on a single scanline, interrupts may be required. But while it's theoretically possible to do pixel-perfect IRQs, they are much more expensive than the regular kind because you have to use the observed horizontal position to execute conditional code to land you exactly on the desired point, and depending on the circumstances there may not even be enough time to do this. Depending on the required horizontal separation of the two parts, it may be necessary to do some branching to narrow the IRQ scatter, and since there is the possibility of garbage when doing H-scroll splits, you may want window masking as well, which would restrict you to two or three segments per scanline at most.

Keep in mind that running an H-IRQ for a substantial fraction of the frame is very expensive, especially if you have to do scatter reduction. Like I said upthread, anything you get to do a few times per frame is likely to be a fair bit cheaper than anything you have to do hundreds of times per frame...
User avatar
Señor Ventura
Posts: 242
Joined: Sat Aug 20, 2016 3:58 am

Re: Using a background as a fake game character

Post by Señor Ventura »

93143 wrote: Mon Jun 10, 2024 3:15 pm If no scanline has more than one segment of this layer on it, window masking is a better way to isolate the graphic you want. It's much cheaper because it doesn't eat a bunch of CPU time for overhead; you can just use HDMA. And it's even cheaper if there's enough transparent margin around the graphic horizontally that you can just use a rectangle instead of fitting the window to the exact contours of the visible graphic.

If multiple segments are present on a single scanline, interrupts may be required. But while it's theoretically possible to do pixel-perfect IRQs, they are much more expensive than the regular kind because you have to use the observed horizontal position to execute conditional code to land you exactly on the desired point, and depending on the circumstances there may not even be enough time to do this. Depending on the required horizontal separation of the two parts, it may be necessary to do some branching to narrow the IRQ scatter, and since there is the possibility of garbage when doing H-scroll splits, you may want window masking as well, which would restrict you to two or three segments per scanline at most.

Keep in mind that running an H-IRQ for a substantial fraction of the frame is very expensive, especially if you have to do scatter reduction. Like I said upthread, anything you get to do a few times per frame is likely to be a fair bit cheaper than anything you have to do hundreds of times per frame...
But, in that case, it requires a lot of irq's, so, a co-processor is required.

You use a background with some graphics drawed in it, and you want to put every one on screen like independet objects (multi jointed, or not). Through hdma and a coprocessor you draw line to line every line of the background needed, like a PLOTTER.

That stock 65816 has to be way too slow to something like this, but nowadays you have all the coprocessor power to afford it without timing issues.

Maybe even an SA-1 would not be enough to draw all the body's fragments of that xeno crisi's snake from a backplane... or may be that SA-1 literally fits well, so it would be legit since it is an coprocessor ot its era.
93143
Posts: 1733
Joined: Fri Jul 04, 2014 9:31 pm

Re: Using a background as a fake game character

Post by 93143 »

It's actually pretty easy if you only have one segment max per scanline. The S-CPU could handle it by itself, no trouble.

If you have two or more segments per scanline, the H-IRQ pattern may be set up by the coprocessor, but it has to be executed by the S-CPU. Because the S-CPU is slow, and because the S-PPU doesn't respond instantly to control inputs (it loads things in chunks sequentially, and various inputs have various delays and can produce garbage temporarily during the split), it is impossible to do this at all in the general case; you'd need enough space between the segments to physically have time to make the switch. It's not something I'd recommend in general; it's very expensive for what you get.

Short version: you cannot manipulate the S-PPU pixel by pixel like a plotter. There are hard limits on how fast you can redirect it during a scanline. By contrast, manipulating it line by line is extremely easy.

The way to do this with a single background layer in the general case (arbitrary numbers of overlapping segments on the same scanline) is to actually draw the graphics using a Super FX or something, and transfer the whole canvas into VRAM to be displayed as is. The title screen of Yoshi's Island does this to display a large quantity of fake sprites (ironically it is displayed on an array of sprites rather than a BG layer, since it has to coexist with Mode 7). Unfortunately this is very heavy on DMA and doesn't usually work at 60 fps without letterboxing, unless the area that needs to be drawn to is very small and/or low-bit-depth (the Super FX segment of the Yoshi's Island title screen runs at 15 fps).
User avatar
Señor Ventura
Posts: 242
Joined: Sat Aug 20, 2016 3:58 am

Re: Using a background as a fake game character

Post by Señor Ventura »

93143 wrote: Tue Jun 11, 2024 2:05 pm It's actually pretty easy if you only have one segment max per scanline. The S-CPU could handle it by itself, no trouble.

If you have two or more segments per scanline, the H-IRQ pattern may be set up by the coprocessor, but it has to be executed by the S-CPU. Because the S-CPU is slow, and because the S-PPU doesn't respond instantly to control inputs (it loads things in chunks sequentially, and various inputs have various delays and can produce garbage temporarily during the split), it is impossible to do this at all in the general case; you'd need enough space between the segments to physically have time to make the switch. It's not something I'd recommend in general; it's very expensive for what you get.

Short version: you cannot manipulate the S-PPU pixel by pixel like a plotter. There are hard limits on how fast you can redirect it during a scanline. By contrast, manipulating it line by line is extremely easy.

The way to do this with a single background layer in the general case (arbitrary numbers of overlapping segments on the same scanline) is to actually draw the graphics using a Super FX or something, and transfer the whole canvas into VRAM to be displayed as is. The title screen of Yoshi's Island does this to display a large quantity of fake sprites (ironically it is displayed on an array of sprites rather than a BG layer, since it has to coexist with Mode 7). Unfortunately this is very heavy on DMA and doesn't usually work at 60 fps without letterboxing, unless the area that needs to be drawn to is very small and/or low-bit-depth (the Super FX segment of the Yoshi's Island title screen runs at 15 fps).
Well, the head of that snake has several frames of animation, but for the rest of the body we are talking about two kind of segments, with only 3 frames to animate the turnings in every 4 directions.

24 drawings of about 32x32 pixel, more or less... It leaves much more space into the canvas (background), to allow a coprocessor afford all the necessary interruptions.


In fact, my idea consisted of about a very few objects in that background (two or three different graphics), but repeated a lot of times, filling the screen with "fake sprites" without overload the sprite limit per scanline.

Two of these "fake sprites" too near through the line buffer would be problematic, but, What about alternating?... Sprite + fake sprite + sprite + fake sprite + sprite + fake sprite + sprite...
93143
Posts: 1733
Joined: Fri Jul 04, 2014 9:31 pm

Re: Using a background as a fake game character

Post by 93143 »

Yeah, that's one way to make it work. You might want to use more real sprites and fewer fake ones, depending on how big they are and how close they can get to one another horizontally.

Remember that the SNES supports up to 128 hardware sprites at sizes up to 64x64, and people are used to flicker and dropout in scenarios like this, so if the entire purpose of the coprocessor is just to avoid that, it seems a bit like killing an ant with a sledgehammer...
Post Reply