nesdev.org

Khaz wrote: (Yes I know variables may or may not be defined depending on conditional branching but clearly it could recognize when a declaration does not exist anywhere)

It doesn't know that another function isn't going to create a global variable by that name.

Binary output confirmed working, code uploaded.

Let me know if you have any problems with it!

byuu wrote:> It appears we're ok for this, but has anyone ever considered pushing a little extra tile data using HDMA? You could probably use all 8 HDMA channels.

That would only work on ZSNES.

Why? What hardware rule am I not respecting?

Video memory write ports ($2006-$2007 on NES, $2116-$2119 on Super NES) do not work during active display. HDMA during forced blanking wouldn't buy you any more speed than normal DMA. And besides, HDMA and normal DMA enabled at the same time will often mess up on 1/1/1 consoles like mine.

tepples wrote:Video memory write ports ($2006-$2007 on NES, $2116-$2119 on Super NES) do not work during active display. HDMA during forced blanking wouldn't buy you any more speed than normal DMA. And besides, HDMA and normal DMA enabled at the same time will often mess up on 1/1/1 consoles like mine.

When I meant using HDMA, I meant on the area in the middle of the screen with the picture that isn't undergoing forced blanking.

And besides, HDMA and normal DMA enabled at the same time will often mess up on 1/1/1 consoles like mine.

Strange... You know, what's even the point in console reversions? If you play to the new version when designing something, you're just going to lose compatibility to the older one. That'd be like if Nintendo decided to make a reversion of the NES that doubled the amount of overdraw. That would be fine for enhancing the look of older NES games, but if developers had the increased overdraw in mind when designing their new game, you'd have 96 pixel wide bosses and the like that would look fine on the reversion console, but would cause a ton of flicker on anything older. I know I didn't give the best example, but yeah.

Espozo wrote:

tepples wrote:Video memory write ports ($2006-$2007 on NES, $2116-$2119 on Super NES) do not work during active display. HDMA during forced blanking wouldn't buy you any more speed than normal DMA. And besides, HDMA and normal DMA enabled at the same time will often mess up on 1/1/1 consoles like mine.

When I meant using HDMA, I meant on the area in the middle of the screen with the picture that isn't undergoing forced blanking.

Yeah, HDMA to video memory there won't work.

I'll answer your other question elsewhere.

> When I meant using HDMA, I meant on the area in the middle of the screen with the picture that isn't undergoing forced blanking.

I was hoping you'd just trust me; or at least investigate why on your own. But oh well ...

The CPU can't read from nor write to VRAM during active display, and that includes Hblank. Accesses are completely ignored. This is because the PPU is reading VRAM for various things like sprites to be rendered during the next scanline.

> Strange... You know, what's even the point in console reversions? If you play to the new version when designing something, you're just going to lose compatibility to the older one.

I've often asked the same thing.

And then I found this college football game. It detects the CPU revision to choose between using DMA (r2) or block-move (r1) for transfers around WRAM during active display.

It didn't make the game any faster, so all it did was complicate the code development.

But even if it did, would you want half of your users getting the slow version and half getting the fast version? That sounds like a PR nightmare to throw all r1 users under the bus instead of finding a better solution.

Khaz wrote:Binary output confirmed working, code uploaded.

Thanks!

Khaz wrote:Notes: The binary file goes in order of Tile Set, Tile Map, and then Palettes. The tile set and tile map scale in size to the height of the image.

Hmmm ... Trying it on a 256×168 frame (= 21.504 bytes of tile data), the tile data size is still 32K (0x8000), with padding zeroes from offset 0x5400 to 0x7FFF. Next, the tilemap should be (less than) 1024 bytes, correct? Yet it seems it's exactly 1344 (0x540) bytes in size. So, palette data starts at offset 0x8540, but this one's fine (256 bytes).

Attached are four frames I tried to process (two of which make Quantomatic hang, btw).

Tilemaps are 16-bit, except in Mode 7. 32 wide x 21 high is 672 tiles, so 1344 bytes.

Ramsis wrote:

Khaz wrote:Notes: The binary file goes in order of Tile Set, Tile Map, and then Palettes. The tile set and tile map scale in size to the height of the image.

Hmmm ... Trying it on a 256×168 frame (= 21.504 bytes of tile data), the tile data size is still 32K (0x8000), with padding zeroes from offset 0x5400 to 0x7FFF. Next, the tilemap should be (less than) 1024 bytes, correct? Yet it seems it's exactly 1344 (0x540) bytes in size. So, palette data starts at offset 0x8540, but this one's fine (256 bytes).

Attached are four frames I tried to process (two of which make Quantomatic hang, btw).

I forgot to mention.... You have to specify the number of output rows with -o 21 (for 168 pixels tall), or else it defaults to a fullscreen image. Sorry about that.

No idea why the program would be hanging at this point though, I'll look into that

93143 wrote:Tilemaps are 16-bit, except in Mode 7. 32 wide x 21 high is 672 tiles, so 1344 bytes.

Ah, right ... I knew I was missing something important.

Khaz wrote:I forgot to mention.... You have to specify the number of output rows with -o 21 (for 168 pixels tall), or else it defaults to a fullscreen image. Sorry about that.

Okay, thanks!

Here are screenshots of all the current options for direct comparison:




(ikari's player. Sorry I got the aspect ratio wrong when I converted the video ... This dates from 2012, and I never bothered to release the .msu file. Frame size is only 224×144 px.)





(The current implementation, as based on smkdan's hack. Frame size is 240×160 px = 38.400 + 512 bytes, which pretty much pushes the bandwidth to its limits.)





(Not from a finished movie, but simply a still image with window masking, namely one of the first few frames I processed with Quantomatic for the biggest movie "window" possible (while still retaining the original movie's letterboxed format), i.e. 256×168 px.)

Personally, I think this makes the decision about FMV resolution vs. color depth an easy one, but I'm still open to comments/suggestions, of course.

8bpp simply beats 4bpp. For this project, I think I'll therefore stick with smkdan's player.

Ramsis wrote:

93143 wrote:Tilemaps are 16-bit, except in Mode 7. 32 wide x 21 high is 672 tiles, so 1344 bytes.

Ah, right ... I knew I was missing something important.

There is one thing - if you aren't using sprites (and Quantomatic doesn't do sprites yet AFAIK), you should only need to write the top byte of the tilemap, the one with the palette selector bits in it. If Khaz's program does what I expect it does, the bottom byte should be the same every other frame, there being no reason to move tiles around other than the double buffering.

But in this case the limiting factor is the aspect ratio rather than the DMA bandwidth, so you probably don't care about that right now...

93143 wrote:There is one thing - if you aren't using sprites (and Quantomatic doesn't do sprites yet AFAIK), you should only need to write the top byte of the tilemap, the one with the palette selector bits in it. If Khaz's program does what I expect it does, the bottom byte should be the same every other frame, there being no reason to move tiles around other than the double buffering.

I haven't attempted sprites yet, just because I'm not enjoying the idea of having to either calculate with a limited number of sprites or use 16x16 sprites requiring 2x2 blocks of the same palette. Also because it would force screen size lower again, just having to update OAM...

You're right though about the tilemap. The tile set is always arranged the same way so only the hi byte should need changing. The problem there is you would have to preserve the bottom two bits of the high byte every time, unless your picture is very small...

EDIT: Should also mention. I'm sad but also confused at the low quality my program outputs compared to the other two. I know all of nothing about Mode 7 or anything 256 colour on SNES, but isn't it just a bigger palette size? If that's the case, in a frame with such a low number of colours already, I wouldn't think you should see such hideous losses from my program....

I think what I can say so far is that the Quantomatic works best for very busy images with lots of colour and contrast. Big slabs of all one colour, or god forbid almost-but-not-quite-the-same colour, tend to look awful. I'm working on ways to address this...

Khaz wrote:I haven't attempted sprites yet, just because I'm not enjoying the idea of having to either calculate with a limited number of sprites or use 16x16 sprites requiring 2x2 blocks of the same palette. Also because it would force screen size lower again, just having to update OAM...

The low OAM table (unless you're using multiple sprite sizes, in which case you need the high table too), the top half of CGRAM and the bottom byte of each tilemap word (since you can no longer guarantee a static BG tile mapping). It's still better than 8bpp, and depending on the use case may not actually affect screen size - fullscreen 12 fps may be too marginal (how long does it take after force blank before VRAM will accept data?), but 256x216 at 15 fps should still be possible with reasonably careful coding, and 256x168 at 15 fps has plenty of extra bandwidth.

But I don't think it would be hard to quantize with 8x8 sprites. You wouldn't have to do any complicated case handling; just set it up so that the 8 most-used palettes are BG, and everything else is sprites. Then keep merging until you have no more than 16 palettes total and no more than 128 sprites. In the absolute worst case, you'd still get 9 palettes this way, because even if they're all used about equally often each one would be used in about 100 tiles out of a full-screen image, so the least common palette is guaranteed to be spritable. And it should be faster, since you don't have to merge down as far...

Am I overlooking something?

The problem there is you would have to preserve the bottom two bits of the high byte every time, unless your picture is very small...

I don't see how that's any different from DMAing the whole tilemap, since the tile numbers are in there anyway.

Maybe you could even make it to where it uses a 16x16 if possible so you have more sprite coverage.

You know, I'm stupid. What's the equation for finding how much DMA bandwidth you have?