The SNESdev documentation project

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.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: The SNESdev documentation project

Post by Oziphantom »

you can only draw 4bpp sprites, and the affine transform is only possible on background 1 when you have the mode register set to 7.
UnDisbeliever
Posts: 124
Joined: Mon Mar 02, 2015 1:11 am
Location: Australia (PAL)
Contact:

Re: The SNESdev documentation project

Post by UnDisbeliever »

jeffythedragonslayer wrote: Sat May 28, 2022 3:33 pm I'm curious - what kind of information (the type I would find on fullsnes) are you omitting that an emu author would be interested in, that a game developer would not be?
I'm not entirely sure. I do know I am going to be omitting specific timing information and the initial register values on power-on/reset. A programmer does not need to the initial state of the PPU registers when they write a ResetRegisters routine that resets all the registers in one go. Nor do they need to know the exact H-TIME the PPU reads the scroll registers, nor the exact H-TIME the DMA controller reads HDMAEN (for example).



On a side-note, I never got around to working on the VRAM registers over the last two weeks. I had some annoying problems with my home file server that really sapped my motivation with anything involving computers and snesdev. It's a fresh new week and motivation is returning. I'm not sure when the VRAM document will be done, but I will keep you informed about it's progress.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: The SNESdev documentation project

Post by 93143 »

Oziphantom wrote: Sun May 29, 2022 1:44 am you can only draw 4bpp sprites, and the affine transform is only possible on background 1 when you have the mode register set to 7.
The player won't know that if you use BG3 and warp it with linescroll.

There are ways to do 2bpp sprites. The simple and obvious one is to encode them in NES format and do an 8-bit transfer to half of the 16-bit VRAM port. They take up the same amount of VRAM as 4bpp sprites (unless you don't need transparent colour #0, in which case you can pack them in like Bad Apple on Mega Drive), but storage and DMA time are halved.

A Mode 7 BG can be used as a sprite (see SMW), and if you limit it to 2bpp you can do a 256x256 image.

...

Perhaps this is what is meant by the difference between an emulation-focused doc and a programmer-focused one...
coto
Posts: 102
Joined: Wed Mar 06, 2019 6:00 pm
Location: Chile

Re: The SNESdev documentation project

Post by coto »

93143 wrote: Sun May 29, 2022 3:35 am
Oziphantom wrote: Sun May 29, 2022 1:44 am you can only draw 4bpp sprites, and the affine transform is only possible on background 1 when you have the mode register set to 7.
The player won't know that if you use BG3 and warp it with linescroll.

There are ways to do 2bpp sprites. The simple and obvious one is to encode them in NES format and do an 8-bit transfer to half of the 16-bit VRAM port. They take up the same amount of VRAM as 4bpp sprites (unless you don't need transparent colour #0, in which case you can pack them in like Bad Apple on Mega Drive), but storage and DMA time are halved.

A Mode 7 BG can be used as a sprite (see SMW), and if you limit it to 2bpp you can do a 256x256 image.

...

Perhaps this is what is meant by the difference between an emulation-focused doc and a programmer-focused one...
Spot on. ;-)
coto
Posts: 102
Joined: Wed Mar 06, 2019 6:00 pm
Location: Chile

Re: The SNESdev documentation project

Post by coto »

Oziphantom wrote: Sun May 29, 2022 1:44 am you can only draw 4bpp sprites, and the affine transform is only possible on background 1 when you have the mode register set to 7.
Affine transformation over hardware has nothing to do with what I said earlier. HDMA can be used to apply custom matrix (2d) transformation to, say, sprites. IIRC that's done on GBA on Pokémon attacks such as Double Team or splitting backgrounds per player, moving each one along its sprite when the battle initializes.
User avatar
Nikku4211
Posts: 569
Joined: Sun Dec 15, 2019 1:28 pm
Location: Florida
Contact:

Re: The SNESdev documentation project

Post by Nikku4211 »

93143 wrote: Sun May 29, 2022 3:35 am There are ways to do 2bpp sprites. The simple and obvious one is to encode them in NES format and do an 8-bit transfer to half of the 16-bit VRAM port. They take up the same amount of VRAM as 4bpp sprites (unless you don't need transparent colour #0, in which case you can pack them in like Bad Apple on Mega Drive), but storage and DMA time are halved.
Wait, you have to encode them in NES format, instead of the GB format used by the SNES for some backgrounds in certain video modes?
93143 wrote: Sun May 29, 2022 3:35 am A Mode 7 BG can be used as a sprite (see SMW), and if you limit it to 2bpp you can do a 256x256 image.
But how? Mode 7 has only 1 palette, no tile flipping, has a constant tileset and tilemap address that is fixed at the beginning of VRAM, and only has 256 unique tiles.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: The SNESdev documentation project

Post by 93143 »

Nikku4211 wrote: Sun May 29, 2022 10:49 amBut how? Mode 7 has only 1 palette, no tile flipping, has a constant tileset and tilemap address that is fixed at the beginning of VRAM, and only has 256 unique tiles.
Simple. Make it so each tile has four texels in it. There are just enough tiles to represent all possible combinations if each texel is 2bpp. Then you zoom out. It's a variant of the tilemap-as-bitmap trick used by Jurassic Park.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: The SNESdev documentation project

Post by Oziphantom »

coto wrote: Sun May 29, 2022 9:46 am
Oziphantom wrote: Sun May 29, 2022 1:44 am you can only draw 4bpp sprites, and the affine transform is only possible on background 1 when you have the mode register set to 7.
Affine transformation over hardware has nothing to do with what I said earlier. HDMA can be used to apply custom matrix (2d) transformation to, say, sprites. IIRC that's done on GBA on Pokémon attacks such as Double Team or splitting backgrounds per player, moving each one along its sprite when the battle initializes.
Yes the GBA has affine sprites, so you can do a affine transform on a sprite on a GBA. The SNES doesn't there is no transform on sprites, you can change a sprites X and Y down the screen but no rotation or scaling. Only 1 background on Mode 7 will give you an affine transform.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: The SNESdev documentation project

Post by Oziphantom »

93143 wrote: Sun May 29, 2022 3:35 am
Oziphantom wrote: Sun May 29, 2022 1:44 am you can only draw 4bpp sprites, and the affine transform is only possible on background 1 when you have the mode register set to 7.
The player won't know that if you use BG3 and warp it with linescroll.

There are ways to do 2bpp sprites. The simple and obvious one is to encode them in NES format and do an 8-bit transfer to half of the 16-bit VRAM port. They take up the same amount of VRAM as 4bpp sprites (unless you don't need transparent colour #0, in which case you can pack them in like Bad Apple on Mega Drive), but storage and DMA time are halved.

A Mode 7 BG can be used as a sprite (see SMW), and if you limit it to 2bpp you can do a 256x256 image.

...

Perhaps this is what is meant by the difference between an emulation-focused doc and a programmer-focused one...
no that is still a 4bpp sprite and still eats the same amount of VRAM as a 4bpp sprite. It's just a 16 colour sprites you only use 4 colours in. And its pallete is set by 4bpp rules not 2bpp rules placing limits on your pallete placement.
coto
Posts: 102
Joined: Wed Mar 06, 2019 6:00 pm
Location: Chile

Re: The SNESdev documentation project

Post by coto »

Oziphantom wrote: Mon May 30, 2022 1:25 am
coto wrote: Sun May 29, 2022 9:46 am
Oziphantom wrote: Sun May 29, 2022 1:44 am you can only draw 4bpp sprites, and the affine transform is only possible on background 1 when you have the mode register set to 7.
Affine transformation over hardware has nothing to do with what I said earlier. HDMA can be used to apply custom matrix (2d) transformation to, say, sprites. IIRC that's done on GBA on Pokémon attacks such as Double Team or splitting backgrounds per player, moving each one along its sprite when the battle initializes.
Yes the GBA has affine sprites, so you can do a affine transform on a sprite on a GBA. The SNES doesn't there is no transform on sprites, you can change a sprites X and Y down the screen but no rotation or scaling. Only 1 background on Mode 7 will give you an affine transform.
The GBA doesn't matter. The SNES can do the same since it's got the HDMA hardware, and by that I mean it allows to raise an interrupt each time a new scanline triggers on the TV, by that you can apply special effects over pixels (including backgrounds and sprites). I never referred to the SNES hardware affine transformation over backgrounds, or even sprites, so stop trying to make a point where it doesn't make sense.

It seems to me you need a crash course on custom matrix transformation (2d) and HDMA, here you go:
https://www.mathsisfun.com/algebra/matr ... sform.html

-

And as for the 2bpp, it was an example, since it's known the SNES doesn't do 2bpp in hardware but the SDK can work around that, like 93143 said earlier. Specifically because of NES devs porting their game over, prior to improving them back in the days.
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: The SNESdev documentation project

Post by creaothceann »

Nitpick: HDMA doesn't involve interrupts.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
coto
Posts: 102
Joined: Wed Mar 06, 2019 6:00 pm
Location: Chile

Re: The SNESdev documentation project

Post by coto »

creaothceann wrote: Mon May 30, 2022 10:37 am Nitpick: HDMA doesn't involve interrupts.

H-DMA (H-Blank DMA)
H-DMA transfers are automatically invoked on H-Blank, each H-DMA is limited to a single unit (max 4 bytes) per scanline. This is commonly used to manipulate PPU I/O ports (eg. to change scroll offsets)...
http://problemkaputt.de/fullsnes.htm#sn ... ingunitppu

if that isn't an interrupt, then I don't know what it is
User avatar
Nikku4211
Posts: 569
Joined: Sun Dec 15, 2019 1:28 pm
Location: Florida
Contact:

Re: The SNESdev documentation project

Post by Nikku4211 »

coto wrote: Mon May 30, 2022 9:48 am The GBA doesn't matter. The SNES can do the same since it's got the HDMA hardware, and by that I mean it allows to raise an interrupt each time a new scanline triggers on the TV, by that you can apply special effects over pixels (including backgrounds and sprites). I never referred to the SNES hardware affine transformation over backgrounds, or even sprites, so stop trying to make a point where it doesn't make sense.
I've never seen a single SNES game change a sprite's position while the sprite is still rendering.
From what I've heard, you have to force-blank in order to change the OAM table.

This of course would break any shear effect you'd want to do with sprites, unless you want to have the whole game looking like it's running in 120p by blanking every 2nd row.
coto wrote: Mon May 30, 2022 9:48 am It seems to me you need a crash course on custom matrix transformation (2d) and HDMA, here you go:
https://www.mathsisfun.com/algebra/matr ... sform.html
And even if it weren't for this limitation of the SNES, it's still not enough to compare it to affine transformations, since you can't use it to rotate a sprite or horizontally squish/stretch it.
coto wrote: Mon May 30, 2022 9:48 am And as for the 2bpp, it was an example, since it's known the SNES doesn't do 2bpp in hardware but the SDK can work around that, like 93143 said earlier. Specifically because of NES devs porting their game over, prior to improving them back in the days.
So ROM-wise, the sprite graphics are 2BPP, but VRAM-wise, the sprite graphics are 4BPP due to the way the graphics are DMA'd.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.
coto
Posts: 102
Joined: Wed Mar 06, 2019 6:00 pm
Location: Chile

Re: The SNESdev documentation project

Post by coto »

Nikku4211 wrote: Mon May 30, 2022 11:04 am I've never seen a single SNES game change a sprite's position while the sprite is still rendering.
From what I've heard, you have to force-blank in order to change the OAM table.
I'm not asking you to reverse engineer games using affine transformation on sprites, because the SNES can't do that. Stop being off-topic.
Nikku4211 wrote: Mon May 30, 2022 11:04 am And even if it weren't for this limitation of the SNES, it's still not enough to compare it to affine transformations, since you can't use it to rotate a sprite or horizontally squish/stretch it.
While that's true (about the affine transformation part), that doesn't mean you can't affect IO ports like scroll registers and apply custom effects through it, like wavy lines or something.


Anyway, I've seen dozens of your supposed work on things and what ifs and you never come to something useful. How about getting some work done before writing and acting like you supposedly know about an issue? I'd be really interested in seeing how progress goes so far.



@OP, sorry the offtopic, but I hope the main point makes sense.
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: The SNESdev documentation project

Post by creaothceann »

coto wrote: Mon May 30, 2022 10:45 am if that isn't an interrupt, then I don't know what it is
It's not an interrupt because the 65c816 isn't interrupted (and then running an interrupt handler), it's paused. The 5A22 then takes over and progresses the HDMA channels.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Post Reply