It is currently Sun Nov 17, 2019 6:14 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Fri Aug 02, 2019 1:16 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8681
Location: Seattle
Given two NTSC refreshes (262 scanlines)
524 scanlines
X scanlines drawn
524-X scanlines spent in DMA
(524-X)*165.5 bytes sent during DMA

assuming a width of 256
X*256 bytes consumed during redraw
x*256/2 bytes consumed across two redraws because each byte is used twice
(524-X)*165.5 = x*128
x=295 scanlines across two redraws
x=147 scanlines each redraw

Double-checking the math:
256*147 pixels = 37632 bytes at 8bpp
262-147=115 scanlines for DMA per hardware redraw, 230 per transfer
230*165.5 = 38065 bytes available for DMA.

You can make it taller (and more windowboxed), but it cuts into DMA time so you'll be able to transfer less.


Top
 Profile  
 
PostPosted: Fri Aug 02, 2019 10:44 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1103
Didn't you ask us this already like 4 years ago?

Your Mega Drive video spec in that thread, 288x192 at 30 fps, corresponds roughly to 232x192 on SNES (or MD in H32 mode), which is actually quite achievable in 4bpp. Using an H-IRQ, it's possible to rewrite an entire 4bpp palette every scanline with DMA, so the "hundreds of colors" part works too.

If your goal is a 30 fps 8bpp video mode, you can do 256x144, 232x152, 200x160 or 176x168 with static maps and appropriate fractional buffering. (Actually, 176x168 is small enough to allow true double buffering.) You can also do 208x160 if you don't need to refresh the palette every frame, and you can do display heights that are not multiples of 8 to get more DMA at a given screen width (for example, 208x159 should leave enough time for a palette update, and 240x150 seems to barely work too).

At 15 fps, I think you can do 256x188 in 8bpp. [EDIT: not without tearing. Even with fractional buffering there's not enough VRAM.] If I understand the VRAM port address remapping feature correctly, it allows you to write lines instead of tiles if the display is 256 pixels wide, so you can write a row of partial tiles instead of wasting DMA writing whole tiles that end up partially hidden. (Somebody correct me if I've got that wrong; I haven't needed the feature myself and my brain is tired... even if I'm wrong, you can for sure do 256x184 or 248x189.)

Some have suggested a trick that might increase those numbers at the cost of the ability to display sprites. It is unclear if it will work; AFAIK it has not been tested. Don't sue me if it works and invalidates the above numbers, but also don't be shocked if it doesn't.

(Please note that "direct colour", as commonly understood, does not describe the 8bpp SNES picture modes as normally employed. They are still palettized, just with 256 colours instead of 16. It is possible to set these modes to use the index and palette selector bits as direct RGB colour instead of referencing CGRAM, but the bit depth of the RGB channels suffers when you do that, and it was not often done in commercial games.)

...

Not long after the 2015 thread linked at the top of this post, it was discovered that FantomBitmap, the DMA direct colour trick developed for the Mega Drive and described in the linked thread, can also be done on the SNES. It's not exactly the same technique because the MD and the SNES don't work the same way, but it's the same idea - you get full-screen true 15-bit colour at 60 fps by blasting data into CGRAM with DMA. Unfortunately, while the Mega Drive's DMA is 16-bit (well, 9-bit) when targeting CRAM, resulting in the colour changing every two pixels, the SNES has an 8-bit CPU data bus and takes two cycles to write each CGRAM entry, so the colour changes every four pixels and the horizontal resolution ends up too low to be useful.

It may be possible to make a full-resolution video mode out of a variation of this trick using colour math to combine it with a tiled layer, but it would be lossy and very very hard to render into.


Last edited by 93143 on Sun Aug 04, 2019 3:31 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Aug 03, 2019 3:10 am 
Offline
User avatar

Joined: Wed Dec 09, 2015 2:18 pm
Posts: 49
Thanks a lot for your help 93143!

Yep. It was me around here 4 years ago with the similar question.
Time runs so fast... 4 years passed since then.

256x188 8bpp 15fps. acceptable.
I will try to implement it.

Cool! I didn't know SNES is able to "blast process".
As far I know that colour trick when you are sending DMA directly to the background colour into CRAM gave the name: blast processing.
Unfortunately neither Sega Genesis/MD nor SNES can use it because of doubled or even quaternary pixels.
Sega could use it for some games or at least video playback but there is a bad thing:
because of the memory refresh you have about 5 (doubled) columns of quaternary pixels (each 64 pixels) and it looks like as the image zooms through a lens.
Even tolerant to double pixels games looks ugly with those zooming columns.
It's acceptable if the image doesn't change. But once image changes you see the zooming columns and it becomes unacceptable for usage.

It's not visible well on a static image. I made a video 4 years ago to show those columns:
https://www.youtube.com/watch?v=TwGmg6S00_k


Attachments:
sf5_example.png
sf5_example.png [ 28.56 KiB | Viewed 5590 times ]
Top
 Profile  
 
PostPosted: Sat Aug 03, 2019 8:08 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1103
It should also be possible to do 256x172 at 20 fps. EDIT: not in 8bpp, it's not. Not enough VRAM for fractional buffering, so you'd get tearing.

Are you trying to make a Super FX demo or a video mode?

The SNES version of DMA direct colour manages to get around the DRAM refresh issue because it has a couple of extra layers of cause and effect between the DMA and the display. So it's possible to start the line early and prebuffer enough colours to cover the 10-pixel pause in the middle of the screen. Unfortunately this still only gives you the resolution of the MD version's refresh pauses over the whole screen, and you end up feeling like you need glasses:

Attachment:
Wii_kids_DMA15.png
Wii_kids_DMA15.png [ 22.86 KiB | Viewed 5524 times ]
Attachment:
The_Magnificent_Hong_Kong_64x224.png
The_Magnificent_Hong_Kong_64x224.png [ 31.28 KiB | Viewed 5524 times ]

However, it is possible to use sprites and BG3 even with this version of the technique, and VBlank is free. It's like an Atari VCS on steroids...


Last edited by 93143 on Sun Aug 04, 2019 3:30 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sun Aug 04, 2019 3:23 am 
Offline
User avatar

Joined: Wed Dec 09, 2015 2:18 pm
Posts: 49
Really cool! Despite 4 pixel wide "pixels" it's still cool just as a demo.

256x172 20 fps is quite enough for a playable game. 4bpp right?

I plan to make a game (first person shooter) using an additional GPU to produce graphics and I need to display it.
But I would like to display it a bit faster than the DOOM did.


Top
 Profile  
 
PostPosted: Sun Aug 04, 2019 3:27 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1103
greatkreator wrote:
256x172 20 fps is quite enough for a playable game. 4bpp right?

No, 8bpp.

Wait...

Aw nuts... I may have misled you. I should have remembered this; it's basic, and in fact I've done these calculations before and run into this exact issue...

...

The 256x188 8bpp frame takes 48128 bytes in VRAM. You can only transfer about 12247 bytes per frame with a picture that high, meaning that even if you don't change the palette, you still need to have loaded 35881 bytes of the next frame before you overwrite any of the current frame. Combined with a pair of tilemaps, this results in a total VRAM load of no less than 85 KB.

With 256x172 at 8bpp, you have 14895 bytes per frame of DMA, which means you need to have transferred 29137 bytes before the final update, and the VRAM load is at least 76 KB or so.

So I retract my claims above. You cannot do 8bpp graphics at 256x188 or even 256x172 at any frame rate, unless you want to put up with visible tearing due to overwriting part of the visible framebuffer. It simply doesn't fit. (You can still do 256x146, 240x150, 208x159, etc. in 8bpp at 30 fps. They all fit.)

...

At 8bpp, 256x152 fits, and you can transfer it at 20 fps. But that's not much bigger than 256x146, which should work at 30 fps. Narrower, taller windows might be more optimal, because they're smaller and might still work at 20 fps despite the reduced DMA bandwidth: for example, 216x176 at 8bpp should barely work at 20 fps even with a palette update.

You get much larger framebuffers and higher rates at 4bpp (not least because VRAM is no longer an issue). Star Fox was 224x190 (presumably with a 224x192 framebuffer) and could have run at 30 fps with a fast enough chip. I once worked out what a Super FX TIE Fighter port might look like in 4bpp, and it turned out that I could do a 240x200 rendered window with a 240x208 active area, and still maintain 20 fps. Basically, the Mega Drive doesn't have an advantage over the SNES in this area unless you exploit the fact that DMA to VRAM still sort of works during active display.

greatkreator wrote:
I plan to make a game (first person shooter) using an additional GPU to produce graphics and I need to display it.
But I would like to display it a bit faster than the DOOM did.

Keep in mind that if you use a status bar below the main rendered area, it will eat directly into your DMA time. Doom had a 216x144 rendered window, which by itself would allow 30 fps, but the status bar extends it to 176 pixels of display height, reducing the available DMA bandwidth and limiting the achievable frame rate to 20 fps. Sprites in the display area would not cause an issue, and have an advantage over BG2 in that they don't require VRAM space for an extra tilemap (no SAT in VRAM on SNES; OAM is separate).

If you want to display the player's gun using sprites or BG2, instead of rendering it with the coprocessor, the display probably won't end up any bigger than the one in Doom unless you drop to 4bpp. Even status sprites might take up too much room to permit a fully fractional-buffered 216x176 rendered layer in 8bpp.


Top
 Profile  
 
PostPosted: Sun Aug 04, 2019 3:58 pm 
Offline
User avatar

Joined: Wed Dec 09, 2015 2:18 pm
Posts: 49
No problem!
Still cool!

I decided to start learning SNES development.
I will be back after I have some demos.

Thanks a lot for your help guys!


Top
 Profile  
 
PostPosted: Mon Aug 05, 2019 12:17 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7746
Location: Chexbres, VD, Switzerland
I'm going to change the subject, but I don't see why the "direct colour mode" is of much interest. If I undertand it well, this mode does not use a palette, instead it uses the 8-bit palette index of a 8BP tile directly to pick a colour. Probably it is 2 bits for blue and 3 for the remaining colour components because human eye is less sensitive to blue. This means the palette is ignored, and basically you're using 8BP with a hard-wired palette instead.

But if you're using 8BP anyway, it makes much more sense to use the palette and really have the colours you need. This leads to much more flexibility, and it can not get worse than "direct colour". The only instance where "direct colour" would be of any use is if you're debugging and don't have a 256-colour palette ready to use, or if you are using split-screen effects, and use this mode only in a part of the screen where you don't want to use the palette which would be shared with the other part.


Top
 Profile  
 
PostPosted: Mon Aug 05, 2019 12:33 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8681
Location: Seattle
In mode 3, it lets you use a full R3G3B2 TrueColor visual for the 8bpp plane, while simultaneously getting eight 15-color palettes for the 4bpp plane and eight 15-color palettes for sprites. (Mode 4 is less compelling, because the 2bpp layer means that 112 of the palette entries are now unused, instead of only 16).

I used it in my "bus activity" demo for this reason.


Top
 Profile  
 
PostPosted: Mon Aug 05, 2019 2:25 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7746
Location: Chexbres, VD, Switzerland
lidnariq wrote:
In mode 3, it lets you use a full R3G3B2 TrueColor visual for the 8bpp plane, while simultaneously getting eight 15-color palettes for the 4bpp plane and eight 15-color palettes for sprites. (Mode 4 is less compelling, because the 2bpp layer means that 112 of the palette entries are now unused, instead of only 16).

I used it in my "bus activity" demo for this reason.

OK I see the point as a whole.
However in the particular case of double-buffering FMV images, the 2 buffers for FMV themselves will take the entiere VRAM, so there's no room for any extra 4BPP plane nor sprites, if I'm not mistaken.


Top
 Profile  
 
PostPosted: Mon Aug 05, 2019 3:39 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1103
lidnariq wrote:
R3G3B2

Just noting here that the palette selector bits raise that to R4G4B3. Unfortunately the extra bits are per tile, not per pixel... and of course this doesn't work in Mode 7, which has no palette selector bits...

Speaking of Mode 7, it should be possible to use EXTBG and get a direct-colour R3G3B2 BG1 and a 7bpp palettized BG2 with per-pixel priority out of the same pixel data, right? That could potentially be exploited, I'm sure... You can do a palette split without direct colour because of the top bit getting dropped/reinterpreted for BG2, but the sprite palettes kinda get in the way.

Bregalad wrote:
However in the particular case of double-buffering FMV images, the 2 buffers for FMV themselves will take the entiere VRAM, so there's no room for any extra 4BPP plane nor sprites, if I'm not mistaken.

Depends what you want the FMV for. If you're rendering part of a game, you may still want a status display, a gun... really any element that doesn't need to be rendered by the coprocessor. Star Fox is the classic example of a Super FX game with a big colourful full-screen backdrop and a sprite-based HUD - it's conceivable that someone might want to do something like that in 8bpp. Still, 256 colours is a lot, and 8bpp really does eat VRAM for breakfast (as I belatedly realized upthread), so you might want to avoid getting too crazy...


Top
 Profile  
 
PostPosted: Mon Aug 05, 2019 4:00 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8681
Location: Seattle
93143 wrote:
Speaking of Mode 7, it should be possible to use EXTBG and get a direct-colour R3G3B2 BG1 and a 7bpp palettized BG2 with per-pixel priority out of the same pixel data, right?
Isn't the bit that's the priority bit the same as the blue MSBit? Seems like it'd be hard to use unless you specifically want a yellow-ish layer.


Top
 Profile  
 
PostPosted: Mon Aug 05, 2019 4:24 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1103
Or a dim layer, which might actually be what you want with some applications of colour math. You could also dodge around the sprite palettes to get a handful of specific high-temperature highlight colours, or even deliberately leave holes in the sprite palettes for the hot colours you want.

I don't think the direct colour mode was used a whole lot. It's not like Mode 7 or colour math where you've got obvious use cases coming out your ears...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: FitzRoy, kogami and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group