The completely underappreciated possibilities of Mode 0 on SNES. . . .

[Kirk_Johnston]

2 hours ago, Kirk_Johnston said:

Well, if it's a boss using a background layer it can be as tiny as 8x8 or as big as the screen and even more (I think up to two screens wide or two screens high). If it's an actual sprite made up of objects, it can't take up more than the 512 8x8 unique sprite tiles total that are available for sprites in its visual design (and you'd need to use some of them for the player, enemies and projectiles and stuff too) but can again be as big as the screen depending on the size of sprites used (although, the bigger it is, the more likely you'll be using repeating tiles in its design). There's probably more to be explained than that, but that's the gist of it or thereabouts.

Oh, and background layers can generally have a maximum of 1000 unique tiles each too, not accounting for any memory that's taken up with the tilemaps and the like. In Mode 0 I think I could easily have say 500 unique tiles per map and have more than plenty of memory left for everything else that shares it.

[Creamhoven]

1 hour ago, jeffythedragonslayer said:

Yeah, this page has a picture showing the different screen repetition settings:

 

https://archive.org/details/SNESDevManual/book1/page/n117

Wow very technical.

Edited May 28, 2023 by Creamhoven

[Creamhoven]

7 minutes ago, Kirk_Johnston said:

Oh, and background layers can generally have a maximum of 1000 unique tiles each too, not accounting for any memory that's taken up with the tilemaps and the like. In Mode 0 I think I could easily have say 500 unique tiles per map and have more than plenty of memory left for everything else that shares it.

I dont know what that means, but maybe its enough if you understand it. ^^

[Creamhoven]

Would something like this be possible on the snes:

[jeffythedragonslayer]

2 hours ago, Creamhoven said:

I dont know what that means, but maybe its enough if you understand it. ^^

To save VRAM, games don't store the entire level as one huge image, because there are lots of repeating patterns in it.  Think of the blocks in Super Mario Bros - only one unique block image needs to be stored in the tileset, and then the tilemap just contains entries that tell the PPU, "put a block here - you know what they look like."  In fact, in SMB the bushes and the clouds actually use the same unique tiles, just painted with a different palette.

 

2 hours ago, Creamhoven said:

Would something like this be possible on the snes:

Sure, if you are ok with resizing it and converting it to 15-bit direct color.  It would probably look the best in Mode 3.

Edited May 29, 2023 by jeffythedragonslayer

[Kirk_Johnston]

10 hours ago, Creamhoven said:

Would something like this be possible on the snes:

Well, if it's just a flat image you want then it could be done in background Mode 3 or Mode 4 as an 8bpp 256-colour image. If you want all those things as separate elements, like actual characters moving about the scene separately, it would be harder to keep quite that look and quality. In principle though, you could use Mode 1 and have the whole red background scene use the 2bpp 24-colour layer (this palette would be part of the 120 colours available for all layers total), Toad and the cat dude use one of the 4bpp 120-colour layers each (the two layers share the one 120-colour palette here), and then Tanooki, the dog-looking thing and the turtle-looking thing use sprites. So, yes, it could be done basically, with slightly different visual results based on the mode used.

 

I mean, here's how the image would look if it were done in Mode 3 for example:

 

You simply reduce the image to 256x224 in whatever graphics package and then use the Quantization tool to output it with a single palette of 256 colours, a shared colour of the main red area I'd say, and with dithering turned on and set to slow. Or at least that's what I just did.

 

And I think I recall someone saying you could store around 50 full-screen, all unique tiles, 8bpp 256-colour images like this on a decent SNES cartridge (I might even be underestimating this number). So, if your aim was to make a little graphic novel or similar using just a sequence of nice images, you could do something pretty decent and certainly good looking that way. I mean, even as a demonstration of just one aspect of the SNES capabilities, I wouldn't mind seeing nothing more than a really good picture book story made up of 50 or so images and maybe a little story text and some dialogue you can read through on each image (I'm sure there's enough memory left to add a font or two, which you could then just add over the images using sprites as one option), just so people can see what can be achieved there.

Edited May 29, 2023 by Kirk_Johnston

[Kirk_Johnston]

8 hours ago, jeffythedragonslayer said:

To save VRAM, games don't store the entire level as one huge image, because there are lots of repeating patterns in it.  Think of the blocks in Super Mario Bros - only one unique block image needs to be stored in the tileset, and then the tilemap just contains entries that tell the PPU, "put a block here - you know what they look like."  In fact, in SMB the bushes and the clouds actually use the same unique tiles, just painted with a different palette.

 

Sure, if you are ok with resizing it and converting it to 15-bit direct color.  It would probably look the best in Mode 3.

I'm curious--and this is something I've been wondering about for a while now--does this mean that you could store a single enemy on the tilesheet and then have multiple different coloured versions of them on-screen at once, even on the same scanline and moving freely around and up and down the screen? Or, is changing the palette on multiple instances of the same enemy like this only possible using some kind of raster/DMA/HDMA-type palette swap part way down the screen, so you'd effectively only be able to use it if the different coloured versions of the same enemy instance don't move higher or lower than the other ones on-screen?

Edited May 29, 2023 by Kirk_Johnston

[Kirk_Johnston]

And another little test using Mode 3 or Mode 4:

 

The description should tell you the rest.

[JurassicDope]

6 hours ago, Kirk_Johnston said:

And I think I recall someone saying you could store around 50 full-screen, all unique tiles, 8bpp 256-colour images like this on a decent SNES cartridge (I might even be underestimating this number).

For some reason I'm in the mood to break this down with some math time!

 

So of course 8bpp means "8 bits per pixel". Whoa, thats a pretty hefty pixel for it to be worth a whole Byte! Why 8 bits per pixel? If you are familiar with counting binary, you know that 8 bits is worth 256 values, ranging from 0-255.

 

You know what else amounts to 256 values? The total number of color entries in SNES' indexed palette😎 So you can literally assign any color in your indexed palettes to any pixel each within an 8bpp tile!

 

Back to storage stuff...

 

So how many pixels are in a 8x8 character (tile)? 64 pixels. If each pixel is 8 bits:

 

64 * 8 = 512... each tile is 512 bits! 🙀

 

You know, we only want enough tiles to display full screen 256x224 images. So let's see how many tiles we are working with:

 

Full screen width is 256 pixels divided by 8 (a tile is 8 pixels wide). This equals to a screen width = 32 tiles.

 

Height wise, 224 fits into 28 tiles. So to get the amount of tiles that'll fit in a full screen, we do 32width * 24height:

 

896 tilesfills up a 256x224 screen. So how much data are we talking about if using 8bpp? Remember that each tile is 512bits worth of data:

 

512 * 896 =

 

458,752 bits... about 458kb

 

For perspective in comparison of VRAM, which has 64kB (capital 'B' denotes 'byte', lowercase 'b' is bit), lets convert 458,752 bits into bytes. Divide by 8:

 

57,344 bytes... about 57.3kB

Phew... cutting kinda close to the max 64kB of VRAM! So you kinda have a little under 7kB to fit sprites and any gfx for the other plane. I say "kinda" because you also gotta share that 7kB with tilemap data so the ppu will know which tile goes where. I think it shares with something else, but I don't remember what, hmmm... Sprite attributes? We'll figure it out later, but yes, these 8bpp images are indeed quite hefty. So if each image is about 57 kilobytes, how much is 50 of 'em stored into the cartridge?

 

57,344 * 50 gets you 

 

2,867,200 bytes

 

Or about 2.8 megabytes... just small enough to fit into a 3 megabyte rom. I don't quite remember, but aren't the typical LoRom / HiRom modes max cart size 4 Megabytes (32 megabit power!)? So yeah, if that's correct, you can store about 50 fullscreen 8bpp images into a 4mB lorom cart for a very pretty visual novel, and still have 1mB for the code and jammin' tunes! 

 

6 hours ago, Kirk_Johnston said:

I'm curious--and this is something I've been wondering about for a while now--does this mean that you could store a single enemy on the tilesheet and then have multiple different coloured versions of them on-screen at once, even on the same scanline and moving freely around and up and down the screen? Or, is changing the palette on multiple instances of the same enemy like this only possible using some kind of raster/DMA/HDMA-type palette swap part way down the screen, so you'd effectively only be able to use it if the different coloured versions of the same enemy instance don't move higher or lower than the other ones on-screen?

If I'm understanding you correctly, yes, you can display any (under normal circumstances) number of sprites using the same tile data but assigned any of the 8 different palettes each (however, if you want multiple palettes per a sprite, I think you need to do a metasprite).

 

For planes, such as scrolling the background as pseudo sprites (like the Robotnik mecha in your demo), that can only move up and down, the answer is also yes. As long as multiple enemies on the same plane stay in their lane you can make multiple convincing pseudo sprites. This is possible in modes 2, 4, and 6. They can use the use any tile gfx and with the granularity of assigning each 8x8 tile its own palette, crossing each other's vertical position via column scrolling.

[Kirk_Johnston]

45 minutes ago, JurassicDope said:

For some reason I'm in the mood to break this down with some math time!

 

So of course 8bpp means "8 bits per pixel". Whoa, thats a pretty hefty pixel for it to be worth a whole Byte! Why 8 bits per pixel? If you are familiar with counting binary, you know that 8 bits is worth 256 values, ranging from 0-255.

 

You know what else amounts to 256 values? The total number of color entries in SNES' indexed palette😎 So you can literally assign any color in your indexed palettes to any pixel each within an 8bpp tile!

 

Back to storage stuff...

 

So how many pixels are in a 8x8 character (tile)? 64 pixels. If each pixel is 8 bits:

 

64 * 8 = 512... each tile is 512 bits! 🙀

 

You know, we only want enough tiles to display full screen 256x224 images. So let's see how many tiles we are working with:

 

Full screen width is 256 pixels divided by 8 (a tile is 8 pixels wide). This equals to a screen width = 32 tiles.

 

Height wise, 224 fits into 28 tiles. So to get the amount of tiles that'll fit in a full screen, we do 32width * 24height:

 

896 tilesfills up a 256x224 screen. So how much data are we talking about if using 8bpp? Remember that each tile is 512bits worth of data:

 

512 * 896 =

 

458,752 bits... about 458kb

 

For perspective in comparison of VRAM, which has 64kB (capital 'B' denotes 'byte', lowercase 'b' is bit), lets convert 458,752 bits into bytes. Divide by 8:

 

57,344 bytes... about 57.3kB

Phew... cutting kinda close to the max 64kB of VRAM! So you kinda have a little under 7kB to fit sprites and any gfx for the other plane. I say "kinda" because you also gotta share that 7kB with tilemap data so the ppu will know which tile goes where. I think it shares with something else, but I don't remember what, hmmm... Sprite attributes? We'll figure it out later, but yes, these 8bpp images are indeed quite hefty. So if each image is about 57 kilobytes, how much is 50 of 'em stored into the cartridge?

 

57,344 * 50 gets you 

 

2,867,200 bytes

 

Or about 2.8 megabytes... just small enough to fit into a 3 megabyte rom. I don't quite remember, but aren't the typical LoRom / HiRom modes max cart size 4 Megabytes (32 megabit power!)? So yeah, if that's correct, you can store about 50 fullscreen 8bpp images into a 4mB lorom cart for a very pretty visual novel, and still have 1mB for the code and jammin' tunes! 

 

If I'm understanding you correctly, yes, you can display any (under normal circumstances) number of sprites using the same tile data but assigned any of the 8 different palettes each (however, if you want multiple palettes per a sprite, I think you need to do a metasprite).

 

For planes, such as scrolling the background as pseudo sprites (like the Robotnik mecha in your demo), that can only move up and down, the answer is also yes. As long as multiple enemies on the same plane stay in their lane you can make multiple convincing pseudo sprites. This is possible in modes 2, 4, and 6. They can use the use any tile gfx and with the granularity of assigning each 8x8 tile its own palette, crossing each other's vertical position via column scrolling.

Yeah, it was this previous discussion I had where I learned about some of the possibilities and restrictions regarding Mode 3 and 8pp backgrounds (or probably actually Mode 4 would be better in my example), which is how I knew it was not only possible to display a full screen 8bpp image with unique tiles (plus an extra row or column to allow scrolling), along with the necessary tile maps and stuff, but still have enough space left over for a simple second background layer (like my example is original SMB simple, so only a handful of 2bpp tiles) and some sprites like in my video:

 

https://forums.nesdev.org/viewtopic.php?p=282127#p282127

 

The second bit about sprites is great to hear, because that means I could effectively make one enemy type look like a lot more varied enemies on-screen really just by changing palettes for visual variety between instances, and maybe even make them look like a few totally different things on-screen to the untrained eye, just like the clouds/bushes in Mario. And, because SNES has 8 16-colour palettes available for sprites alone, I think there's potentially a whole lot that could be done with that to convince people there's far more sprite variety than there actually is on-screen. This, in some small but meaningful way, can make up for the relatively small amount of memory the SNES has available in VRAM for unique sprite tiles. In the right hands, I think some neat feats of optical illusion could be achieved here, like literally making one sprite look like a totally different sprite simply by using only say half of the colours in one form and the other half of them to show a very different form--two unique character designs for the price one! 

 

If you want an idea of what I mean by getting more forms from the one sprite image just by using different colours in the palette, think of what the guy did to make this logo animate and then apply a version of that same idea in principle to an enemy type in a game to make one enemy type actually look like more than one type or indeed maybe even fake some animation by manipulating that palette rather than using up more sprite tiles for the same thing: 

 

Edited May 29, 2023 by Kirk_Johnston

[jeffythedragonslayer]

20 minutes ago, JurassicDope said:

If I'm understanding you correctly, yes, you can display any (under normal circumstances) number of sprites using the same tile data but assigned any of the 8 different palettes each (however, if you want multiple palettes per a sprite, I think you need to do a metasprite).

This is correct - see the 3 palette bits on the far right of my table:

https://snes.nesdev.org/wiki/OAM_layout

[JurassicDope]

35 minutes ago, jeffythedragonslayer said:

This is correct - see the 3 palette bits on the far right of my table:

https://snes.nesdev.org/wiki/OAM_layout

It's pretty funny the x position is split up like that 😅

 

Edit: your diagram is amazing, btw, I mean to say the SNES hardware works a little funny sometimes 😎

Edited May 29, 2023 by JurassicDope
Clarification

[Kirk_Johnston]

1 hour ago, JurassicDope said:

For some reason I'm in the mood to break this down with some math time!

 

So of course 8bpp means "8 bits per pixel". Whoa, thats a pretty hefty pixel for it to be worth a whole Byte! Why 8 bits per pixel? If you are familiar with counting binary, you know that 8 bits is worth 256 values, ranging from 0-255.

 

You know what else amounts to 256 values? The total number of color entries in SNES' indexed palette😎 So you can literally assign any color in your indexed palettes to any pixel each within an 8bpp tile!

 

Back to storage stuff...

 

So how many pixels are in a 8x8 character (tile)? 64 pixels. If each pixel is 8 bits:

 

64 * 8 = 512... each tile is 512 bits! 🙀

 

You know, we only want enough tiles to display full screen 256x224 images. So let's see how many tiles we are working with:

 

Full screen width is 256 pixels divided by 8 (a tile is 8 pixels wide). This equals to a screen width = 32 tiles.

 

Height wise, 224 fits into 28 tiles. So to get the amount of tiles that'll fit in a full screen, we do 32width * 24height:

 

896 tilesfills up a 256x224 screen. So how much data are we talking about if using 8bpp? Remember that each tile is 512bits worth of data:

 

512 * 896 =

 

458,752 bits... about 458kb

 

For perspective in comparison of VRAM, which has 64kB (capital 'B' denotes 'byte', lowercase 'b' is bit), lets convert 458,752 bits into bytes. Divide by 8:

 

57,344 bytes... about 57.3kB

Phew... cutting kinda close to the max 64kB of VRAM! So you kinda have a little under 7kB to fit sprites and any gfx for the other plane. I say "kinda" because you also gotta share that 7kB with tilemap data so the ppu will know which tile goes where. I think it shares with something else, but I don't remember what, hmmm... Sprite attributes? We'll figure it out later, but yes, these 8bpp images are indeed quite hefty. So if each image is about 57 kilobytes, how much is 50 of 'em stored into the cartridge?

 

57,344 * 50 gets you 

 

2,867,200 bytes

 

Or about 2.8 megabytes... just small enough to fit into a 3 megabyte rom. I don't quite remember, but aren't the typical LoRom / HiRom modes max cart size 4 Megabytes (32 megabit power!)? So yeah, if that's correct, you can store about 50 fullscreen 8bpp images into a 4mB lorom cart for a very pretty visual novel, and still have 1mB for the code and jammin' tunes! 

 

If I'm understanding you correctly, yes, you can display any (under normal circumstances) number of sprites using the same tile data but assigned any of the 8 different palettes each (however, if you want multiple palettes per a sprite, I think you need to do a metasprite).

 

For planes, such as scrolling the background as pseudo sprites (like the Robotnik mecha in your demo), that can only move up and down, the answer is also yes. As long as multiple enemies on the same plane stay in their lane you can make multiple convincing pseudo sprites. This is possible in modes 2, 4, and 6. They can use the use any tile gfx and with the granularity of assigning each 8x8 tile its own palette, crossing each other's vertical position via column scrolling.

By the way, because I can't do the math on any of that (it fries my noggin), how many images would that mean if maxing out one of the SNES 48Mb cartridges like the one used for Star Ocean?

 

Edit: Wait, I think I'm being daft here. If you say it's about 50 images for a 3MB/24Mb cart, it would be about 100 for a 6MB/48Mb cart--unless I'm being dafter than daft.

Edited May 29, 2023 by Kirk_Johnston

[JurassicDope]

1 hour ago, Kirk_Johnston said:

Yeah, it was this previous discussion I had where I learned about some of the possibilities and restrictions regarding Mode 3 and 8pp backgrounds (or probably actually Mode 4 would be better in my example), which is how I knew it was not only possible to display a full screen 8bpp image with unique tiles (plus an extra row or column to allow scrolling), along with the necessary tile maps and stuff, but still have enough space left over for a simple second background layer (like my example is original SMB simple, so only a handful of 2bpp tiles) and some sprites like in my video:

 

https://forums.nesdev.org/viewtopic.php?p=282127#p282127

 

The second bit about sprites is great to hear, because that means I could effectively make one enemy type look like a lot more varied enemies on-screen really just by changing palettes for visual variety between instances, and maybe even make them look like a few totally different things on-screen to the untrained eye, just like the clouds/bushes in Mario. And, because SNES has 8 16-colour palettes available for sprites alone, I think there's potentially a whole lot that could be done with that to convince people there's far more sprite variety than there actually is on-screen. This, in some small but meaningful way, can make up for the relatively small amount of memory the SNES has available in VRAM for unique sprite tiles. In the right hands, I think some neat feats of optical illusion could be achieved here, like literally making one sprite look like a totally different sprite simply by using only say half of the colours in one form and the other half of them to show a very different form--two unique character designs for the price one! 

 

If you want an idea of what I mean by getting more forms from the one sprite image just by using different colours in the palette, think of what the guy did to make this logo animate and then apply a version of that same idea in principle to an enemy type in a game to make one enemy type actually look like more than one type or indeed maybe even fake some animation by manipulating that palette rather than using up more sprite tiles for the same thing: 

 

Noice!! Yeah, NesDev seems like a treasure trove of discussion there!

 

I have heard about using that multi-image baking in tiles for sprites, but I think you have to use the same silhouette shape. If that's true, a circular enemy could be something like a Chomp from Mario, and the alt texture maybe a fireball or giant eyeball. Shelled shape enemies could share graphics, like Koopa and those Beetles from SMB3, etc.

31 minutes ago, Kirk_Johnston said:

By the way, because I can't do the math on any of that (it fries my noggin), how many images would that mean if maxing out one of the SNES 48Mb cartridges like the one used for Star Ocean?

 

Edit: Wait, I think I'm being daft here. If you say it's about 50 images for a 3MB/24Mb cart, it would be about 100 for a 6MB/48Mb cart--unless I'm being dafter than daft.

109 8bpp 256x224 images in ROM, only 40KB left over in that 48meg cart.

 

Edit: You'd probably have to bake the text into the image if you make a VN like this.

Edited May 29, 2023 by JurassicDope

[Creamhoven]

I can't express how exciting it is to work with such intelligent, knowledgable and talented people.

17 hours ago, jeffythedragonslayer said:

To save VRAM, games don't store the entire level as one huge image, because there are lots of repeating patterns in it.  Think of the blocks in Super Mario Bros - only one unique block image needs to be stored in the tileset, and then the tilemap just contains entries that tell the PPU, "put a block here - you know what they look like."  In fact, in SMB the bushes and the clouds actually use the same unique tiles, just painted with a different palette.

Ah I think I understand. It is a library of small graphics that can be copied and pasted.

17 hours ago, jeffythedragonslayer said:

Sure, if you are ok with resizing it and converting it to 15-bit direct color.  It would probably look the best in Mode 3.

Nice.

9 hours ago, Kirk_Johnston said:

Well, if it's just a flat image you want then it could be done in background Mode 3 or Mode 4 as an 8bpp 256-colour image. If you want all those things as separate elements, like actual characters moving about the scene separately, it would be harder to keep quite that look and quality.

Okay, so for still images mode 3 is a good choice. For movment of elements it is important to work in certain resolution and color restrictions, which maybe is more useful in gameplay scenarios.

9 hours ago, Kirk_Johnston said:

In principle though, you could use Mode 1 and have the whole red background scene use the 2bpp 24-colour layer (this palette would be part of the 120 colours available for all layers total), Toad and the cat dude use one of the 4bpp 120-colour layers each (the two layers share the one 120-colour palette here), and then Tanooki, the dog-looking thing and the turtle-looking thing use sprites. So, yes, it could be done basically, with slightly different visual results based on the mode used.

Okay, this would still look okay I think.

9 hours ago, Kirk_Johnston said:

I mean, here's how the image would look if it were done in Mode 3 for example:

That is awesome.

9 hours ago, Kirk_Johnston said:

You simply reduce the image to 256x224 in whatever graphics package and then use the Quantization tool to output it with a single palette of 256 colours, a shared colour of the main red area I'd say, and with dithering turned on and set to slow. Or at least that's what I just did.

What program do you use?

9 hours ago, Kirk_Johnston said:

And I think I recall someone saying you could store around 50 full-screen, all unique tiles, 8bpp 256-colour images like this on a decent SNES cartridge (I might even be underestimating this number). So, if your aim was to make a little graphic novel or similar using just a sequence of nice images, you could do something pretty decent and certainly good looking that way.

I know you are not a fan of this but with the Msu1 chip you could store up to 4gb.

9 hours ago, Kirk_Johnston said:

I mean, even as a demonstration of just one aspect of the SNES capabilities, I wouldn't mind seeing nothing more than a really good picture book story made up of 50 or so images and maybe a little story text and some dialogue you can read through on each image (I'm sure there's enough memory left to add a font or two, which you could then just add over the images using sprites as one option), just so people can see what can be achieved there.

That is interesting. I will think about it.

 

I hope to attract a snes rom coder that can realize our great work. Next step would be checking out the possiblities of 32kHz SNES audio and if it doesnt work for me recording the OST in 44.1kHz 16bit Msu1 audio. Unfortunatly I cant record at the moment but hopefully I can work on the OST in future. I want to tell a cautiknary tale about untempered greed and the shocking consequences.

Edited May 29, 2023 by Creamhoven

[Kirk_Johnston]

18 minutes ago, JurassicDope said:

Noice!! Yeah, NesDev seems like a treasure trove of discussion there!

 

I have heard about using that multi-image baking in tiles for sprites, but I think you have to use the same silhouette shape. If that's true, a circular enemy could be something like a Chomp from Mario, and the alt texture maybe a fireball or giant eyeball. Shelled shape enemies could share graphics, like Koopa and those Beetles from SMB3, etc.

109 8bpp 256x224 images in ROM, only 40KB left over in that 48meg cart.

 

Edit: You'd probably have to bake the text into the image if you make a VN like this.

Wouldn't the text character font basically be tiny in the grand scheme of things, taking up like 50 or so 2bpp tiles to cover all characters, and probably even be done with sprites?

 

I dunno, so just speculating.

 

Also, yeah, you'd probably wanna stay enough images below the max to give you comfortable room to try some other stuff with a handful of separate background and sprites tiles, just in case you need some GUI elements and the like too. So maybe go with say 80 images for good measure.

 

You could probably still use that trick I mentioned/showed above to get three letters out of every tile just by messing around with the colour palettes or something like that, if you were really tight for space and if you went with the one white end colour for the text like in the example video.

 

Again, just speculating on how that might be done.

Edited May 29, 2023 by Kirk_Johnston

[JurassicDope]

17 minutes ago, Creamhoven said:

I hope to attract a snes rom coder that can realize our great work. Next step would be checking out the possiblities of 32kHz SNES audio and if it doesnt work for me recording the OST in 44.1kHz 16bit Msu1 audio. Unfortunatly I cant record at the moment but hopefully I can work on the OST in future. I want to tell a cautiknary tale about untempered greed and the shocking consequences.

If you go the MSU-1 route, can probably do a voice over narration too, lol.

 

Is... is that Kirby stuffing a whole waddle-dee in his mouth in that background??? 😰

17 minutes ago, Kirk_Johnston said:

Wouldn't the text character font basically be tiny in the grand scheme of things, taking up like 50 or so 2bpp tiles to cover all characters, and probably even be done with sprites?

 

I dunno, so just speculating.

 

Also, yeah, you'd probably wanna stay enough images below the max to give you comfortable room to try some other stuff with separate background and sprites tiles, just in case you need some GUI elements and the like too. 

 

You could probably even use that trick I mentioned/showed above to get three letters out of every tile just by messing around with the colour palettes or something like that, if you were really tight for space.

More so 8-bit arrays of dialogue needs to be stored too, to make sentences out of those text characters. Iirc the max size of exHiRom carts is 7MB? Get that extra MB in the cart and still have a 100 images 👍

Edited May 29, 2023 by JurassicDope

[Kirk_Johnston]

58 minutes ago, JurassicDope said:

More so 8-bit arrays of dialogue needs to be stored too, to make sentences out of those text characters. Iirc the max size of exHiRom carts is 7MB? Get that extra MB in the cart and still have a 100 images 👍

Sweet.

Edited May 29, 2023 by Kirk_Johnston

[Creamhoven]

1 hour ago, JurassicDope said:

If you go the MSU-1 route, can probably do a voice over narration too, lol.

Yes, that should be possible. As far as I understand the format the Msu1 uses is pcm. Not sure if it is as efficient as FLAC or even compressed at all.

1 hour ago, JurassicDope said:

Is... is that Kirby stuffing a whole waddle-dee in his mouth in that background??? 😰

That is the terrible Saturn eating a Toadling (or however they are called)

1 hour ago, JurassicDope said:

👍

 

[jeffythedragonslayer]

13 hours ago, JurassicDope said:

It's pretty funny the x position is split up like that 😅

I think Nintendo knew from experience on the NES that having only an unsigned 8-bit sprite x coordinate causes problems with not being able to place a sprite partially off the left-hand side of the screen.  Most platformers progress the level by scrolling to the right though, and the player is typically more focused on enemies they have yet to overcome than on enemies they've jumped over or items they've ignored.  So it wasn't a big deal, but they did want it fixed on the SNES.

 

What you see in that table is my 2022 interpretation of an old document describing the structure of OAM.  I recall at one point reading somewhere some weird explanation that the x coordinate is a 9-bit unsigned int, and so there's this second "virtual screen" on which sprites could go that shares its left side with the physical screen's right side, and this virtual screen also had this magical ability to wraparound the sprite to the physical screen if it goes off its right side.

 

But now I see that the high x bits are just sign bits, and the second virtual screen is actually to the left of the physical screen, where it can accommodate sprites that have their x position go below zero and still be drawn.

 

It seems kind of silly now that such a weird way of visualizing the high x bits ever got into my head in the first place, but it just goes to show you yet another example of how convoluted the whole SNES scene is.

13 hours ago, JurassicDope said:

Edit: your diagram is amazing, btw, I mean to say the SNES hardware works a little funny sometimes 😎

A little?  It's totally bonkers.

 

But thanks. Posts like this motivate me to continue improving the way I teach people how the SNES works.  The next time I create this table, with better markup than ascii, I'm thinking of flipping it upside-down so that lowoam is at the bottom and highoam is at the top.  Would that make things clearer, or do people expect address zero to be at the top?  (like the way the official dev manual does memory maps, although the addresses are written sideways.)

Edited May 30, 2023 by jeffythedragonslayer

[Aaendi]

16x16, 32x32 and 64x64 sprites popping up on the left side of the screen is a lot more noticeable than 8x8 sprites popping up on the left side of the screen.

[JurassicDope]

22 hours ago, jeffythedragonslayer said:

I think Nintendo knew from experience on the NES that having only an unsigned 8-bit sprite x coordinate causes problems with not being able to place a sprite partially off the left-hand side of the screen.  Most platformers progress the level by scrolling to the right though, and the player is typically more focused on enemies they have yet to overcome than on enemies they've jumped over or items they've ignored.  So it wasn't a big deal, but they did want it fixed on the SNES.

Yeah it's not a big deal, all my years playing NES as a kid I never noticed the sprites pop in and out of existence by the left border. Would this also happen at the top border?

 

22 hours ago, jeffythedragonslayer said:

What you see in that table is my 2022 interpretation of an old document describing the structure of OAM.  I recall at one point reading somewhere some weird explanation that the x coordinate is a 9-bit unsigned int, and so there's this second "virtual screen" on which sprites could go that shares its left side with the physical screen's right side, and this virtual screen also had this magical ability to wraparound the sprite to the physical screen if it goes off its right side.

 

But now I see that the high x bits are just sign bits, and the second virtual screen is actually to the left of the physical screen, where it can accommodate sprites that have their x position go below zero and still be drawn.

 

It seems kind of silly now that such a weird way of visualizing the high x bits ever got into my head in the first place, but it just goes to show you yet another example of how convoluted the whole SNES scene is.

Wrapping is indeed magic! I always rationalized I'd have to render it manually, lol. Heck for some reason I could've sworn I read that LoRom maxed out at 3mB, and ExHiRom maxed out at 7... but turns out, Lorom is 4mB, and ExHiRom can go up to 8mB... I just found that out last night 😅

 

Back on the wrapping, I just realized wouldn't a 64x64 sprite not completely go off screen vertically since Y position is just a byte? Though I doubt 64x64 sprites are very popular, maybe something to keep in mind for vertical Shmup bosses or fighting game characters where it might be used.

22 hours ago, jeffythedragonslayer said:

A little?  It's totally bonkers.

 

But thanks. Posts like this motivate me to continue improving the way I teach people how the SNES works.  The next time I create this table, with better markup than ascii, I'm thinking of flipping it upside-down so that lowoam is at the bottom and highoam is at the top.  Would that make things clearer, or do people expect address zero to be at the top?  (like the way the official dev manual does memory maps, although the addresses are written sideways.)

No problem 😊 Documentating is a thankless job, despite the lack of homebrew, SnesDev does feel like it has a lot of love and support thanks to all you volunteers 💪

 

Ps - I'm content at either of those formats. I'm still new to this stuff, so I don't really have expectations on how it should be conventially. When I took a look at the Sega Genesis manual, I had to twist my brain like a pretzel just to wrap my mind around the concept of bitmasks!

 

Edit: we cannot DMA to Vram outside of blanking, but what about CGRAM or OAM? Or is the PPU bus as a whole entirely off limits?

Edited May 31, 2023 by JurassicDope

[jeffythedragonslayer]

37 minutes ago, JurassicDope said:

Edit: we cannot DMA to Vram outside of blanking, but what about CGRAM or OAM? Or is the PPU bus as a whole entirely off limits?

There's official information that Nintendo gave in the manual (read caution #2):

 

https://archive.org/details/SNESDevManual/book1/page/n103/mode/1up

 

and then there's insane tricks like this:

 

https://sneslab.net/wiki/Uniracers_trick

 

There is the Inter-PPU bus, which isn't talked about much because it only connects PPU1 to PPU2 and doesn't connect to anything else, and probably requires decapping to even see on a 1chip console.  And then there is the VRAM address and data buses, but I would avoid calling the 8-bit CPU data bus that DMA uses "the PPU bus" since it connects to more things.  And I don't think that data bus is off limits at all - I've never heard anyone say you have to wait for vblank in order to DMA data from the cartridge into WRAM for example.

Edited May 31, 2023 by jeffythedragonslayer

[JurassicDope]

22 minutes ago, jeffythedragonslayer said:

There's official information that Nintendo gave in the manual (read caution #2):

 

https://archive.org/details/SNESDevManual/book1/page/n103/mode/1up

 

and then there's insane tricks like this:

 

https://sneslab.net/wiki/Uniracers_trick

 

There is the Inter-PPU bus, which isn't talked about much because it only connects PPU1 to PPU2 and doesn't connect to anything else, and probably requires decapping to even see on a 1chip console.  And then there is the VRAM address and data buses, but I would avoid calling the 8-bit CPU data bus that DMA uses "the PPU bus" since it connects to more things.  And I don't think that data bus is off limits at all - I've never heard anyone say you have to wait for vblank in order to DMA data from the cartridge into WRAM for example.

Ahhh, thanks for pointing me to the right places! I should just sit down and read the manual in a few days here 😎

 

As for the PPU Bus thing, I must have misinterpretated what NesDoug mentioned:

 

https://nesdoug.com/2020/05/16/dma-palette/

 

"The main use for DMA is to write to $2104, $2118, and $2122 (OAM data, VRAM data, and CG data). DMA is just a hardware copy loop for transferring data from the CPU bus (ROM and RAM) to the PPU bus (VRAM, palette, and OAM). You should use a DMA when you are transferring more than a dozen bytes to any of these RAMs."

[jeffythedragonslayer]

35 minutes ago, JurassicDope said:

DMA is just a hardware copy loop for transferring data from the CPU bus (ROM and RAM) to the PPU bus (VRAM, palette, and OAM).

Yeah this sentence I find confusing - it sounds like it's saying there are two data buses involved, which I don’t think he meant, unless he means it's the same bus by two different names.  You could ask Doug for clarification.

 

One semi-official place you'll see a familiar bus called by a different name is in the Super FX patent, which uses "HA" for "host-address" bus, which is not a phrase you see when programming the games that don't use enhancement chips.

Edited May 31, 2023 by jeffythedragonslayer