SNES native 3D performance ST-NICC no SFX demo

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
Nikku4211
Posts: 102
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: SNES native 3D performance ST-NICC no SFX demo

Post by Nikku4211 » Fri Aug 21, 2020 9:02 am

Oziphantom wrote:
Fri Aug 21, 2020 7:03 am
turboxray wrote:
Thu Aug 20, 2020 4:44 pm
Oziphantom wrote:
Wed Aug 19, 2020 10:48 pm
The issue is the VBlank time. NTSC has this tiny small useless VBlank period. While PAL has basically double the VBlank this means we can DMA an entire frame to VRAM in 1 Vblank, so we don't have to double buffer VRAM. So while we could run it on NTSC and say its 3 frames on pal, it would drop to 4 frames on NTSC. however 3/50 = 0.06 and 4/60 = 0.066666 so practically the same speed. We would have to double buffer VRAM and lose the sprites.
Yeah, but still PAL *only* demos are pretty lame for systems that are not PAL only.
30 or so years of PAL only C64 and Amiga demos hasn't been a problem. For Demos you want the more powerful version, so they tend to be PAL only to get more out of them. It seems silly to cripple a demo because NTSC exists. This is technically not true on a C64 as the Drean model is the most powerful however they are really really rare so nobody actually targets them.
It's a shame we don't have any PAL required SNES games.
Well, actually, they would be for any C64 and Amiga owners in North America who don't want to deal with import fees. Yes, PAL has 100 more scanlines and gives you more time to do things in V-blank at the expense of a lower frame rate, but you're also going at the expense of how many consoles can run this. If I'm correct, NTSC games run fine on PAL consoles but just a bit slower?

I can see why you'd think it'd be silly to cripple a SNES demo just for compatiblity with some faraway regions, but honestly, I'd still be impressed even at 20 FPS. I already know PAL SNES can do better, but I don't know if NTSC SNES can, so I'd still be impressed if there's a version I can run on my NTSC RetroDuo. Still, it's your demo, if you don't want to do even more work for 525-line regions, that's your decision and I won't hold it against you.

Yes, I know emulation makes this all irrelevant, but c'mon, you know demos often leave emulators shook.

And yes, we do actually have a PAL required SNES game: Tintin and the Prisoners of the Sun struggles to run on my NTSC RetroDuo. The tilemap doesn't update properly and the palettes keep flashing colours. It's literally unplayable in North America.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

lidnariq
Posts: 9659
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: SNES native 3D performance ST-NICC no SFX demo

Post by lidnariq » Fri Aug 21, 2020 11:21 am

Hm. If the objective is to avoid tearing...
and the framebuffer is 128x99...
then there's 29 lines in the mode7 tilemap that can be used to avoid tearing.
meaning that only 70 lines need to be uploaded in one go.
70×128 bytes will take 54.2 scanlines of DMA
and NTSC already provides 37
so we should only need to shave off a little (18 scanlines) of the top of the top to make this fit in NTSC...
I dunno, it doesn't seem too outlandish to make this particular demo work on NTSC.

that said, I haven't checked what else needs to happen during vertical blanking. Other than color updates...

User avatar
Bregalad
Posts: 7951
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: SNES native 3D performance ST-NICC no SFX demo

Post by Bregalad » Fri Aug 21, 2020 11:23 am

Oziphantom wrote:
Fri Aug 21, 2020 7:03 am
30 or so years of PAL only C64 and Amiga demos hasn't been a problem. For Demos you want the more powerful version, so they tend to be PAL only to get more out of them.
I don't know for the C64 and Amiga, but in the case of NES and SNES, the "more powerful" is accidental, it's just the longer VBlank which allows to transfer more data per VBlank. C64 can transfer data to VRAM anytime making this difference irelevant, and I don't know for Amiga.

You're comparing apples to oranges. Commodore computers were (and to some degree, still are) immensely popular in Europe, not so much in the rest of the world. On the other hand, Nintendo consoles, while popular in Europe, originated in Japan and most games were developed in Japan. Of the western-developed games, there's a 50/50 share between northern America and Europe, but most PAL developers had to develop their games with the less powerful NTSC console in mind.
It seems silly to cripple a demo because NTSC exists. This is technically not true on a C64 as the Drean model is the most powerful however they are really really rare so nobody actually targets them.
In the Nintendo world it's silly to rely on PAL console which ran mostly dumbed-down and sometimes glitchy version of the games that were originally developed for NTSC.
It's a shame we don't have any PAL required SNES games.
I don't get it, you blame european developers for wanting to sell their games in the rest of the world ?!
Useless, lumbering half-wits don't scare us.

creaothceann
Posts: 253
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: SNES native 3D performance ST-NICC no SFX demo

Post by creaothceann » Fri Aug 21, 2020 11:38 am

Oziphantom wrote:
Fri Aug 21, 2020 7:03 am
It seems silly to cripple a demo because NTSC exists
Nikku4211 wrote:
Fri Aug 21, 2020 9:02 am
emulation makes this all irrelevant
Most PC monitors run at 60Hz, so emulation will have problems with PAL games. Variable refresh rate monitors are a relatively recent development.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

93143
Posts: 1225
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES native 3D performance ST-NICC no SFX demo

Post by 93143 » Fri Aug 21, 2020 1:48 pm

p-sycopathicteen wrote:
Fri Aug 21, 2020 7:15 am
I mean solid as in the 8x8 tile is one solid color, and update the tilemap as well as the tiles.
He means the tiles are all one solid colour each. The picture is drawn into the tilemap; the tiles aren't updated at all.

lidnariq wrote:
Fri Aug 21, 2020 11:21 am
Hm. If the objective is to avoid tearing...
and the framebuffer is 128x99...
then there's 29 lines in the mode7 tilemap that can be used to avoid tearing.
meaning that only 70 lines need to be uploaded in one go.
70×128 bytes will take 54.2 scanlines of DMA
and NTSC already provides 37
so we should only need to shave off a little (18 scanlines) of the top of the top to make this fit in NTSC...
I wonder if this is what he meant when he talked about losing sprites.

It's been demonstrated that it's possible (at least on the model of SNES I have) to force blank during HBlank and use DMA or HDMA to upload data to VRAM. The VRAM address setting persists between transfers so you don't have to write it every line if you're uploading a contiguous data set. In Mode 1, I found that the limit is probably 29 bytes per scanline (at most - it depends on which layer is active) using a carefully aligned DMA transfer, so with HDMA it should easily be possible to do up to 6 channels worth (24 bytes) per line. 16 bytes per line would be more than sufficient for what you're proposing here.

However, this method causes sprites to go insane on the line following a transfer, so you have to turn them off when using it.

creaothceann wrote:
Fri Aug 21, 2020 11:38 am
Variable refresh rate monitors are a relatively recent development.
Do you mean that variable refresh rate flat panels are a relatively recent development? Because I've used (and shopped for) CRT monitors, and they are not like TVs...
Last edited by 93143 on Fri Aug 21, 2020 7:10 pm, edited 1 time in total.

User avatar
Nikku4211
Posts: 102
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: SNES native 3D performance ST-NICC no SFX demo

Post by Nikku4211 » Fri Aug 21, 2020 7:00 pm

creaothceann wrote:
Fri Aug 21, 2020 11:38 am
Oziphantom wrote:
Fri Aug 21, 2020 7:03 am
It seems silly to cripple a demo because NTSC exists
Nikku4211 wrote:
Fri Aug 21, 2020 9:02 am
emulation makes this all irrelevant
Most PC monitors run at 60Hz, so emulation will have problems with PAL games. Variable refresh rate monitors are a relatively recent development.
The emulators I've used seem to emulate PAL games just fine. Prisoner of the Sun didn't have any problems when I played it in SNES9x, a really old emulator.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

Oziphantom
Posts: 913
Joined: Tue Feb 07, 2017 2:03 am

Re: SNES native 3D performance ST-NICC no SFX demo

Post by Oziphantom » Fri Aug 21, 2020 10:31 pm

Bregalad wrote:
Fri Aug 21, 2020 11:23 am
Oziphantom wrote:
Fri Aug 21, 2020 7:03 am
30 or so years of PAL only C64 and Amiga demos hasn't been a problem. For Demos you want the more powerful version, so they tend to be PAL only to get more out of them.
I don't know for the C64 and Amiga, but in the case of NES and SNES, the "more powerful" is accidental, it's just the longer VBlank which allows to transfer more data per VBlank. C64 can transfer data to VRAM anytime making this difference irelevant, and I don't know for Amiga.

You're comparing apples to oranges. Commodore computers were (and to some degree, still are) immensely popular in Europe, not so much in the rest of the world. On the other hand, Nintendo consoles, while popular in Europe, originated in Japan and most games were developed in Japan. Of the western-developed games, there's a 50/50 share between northern America and Europe, but most PAL developers had to develop their games with the less powerful NTSC console in mind.
Commodore is an American company, and the C64 rained supreme everywhere including the USA, although to be fair not so much in Japan. Although in a weird twist the C64 was actually an enhanced version of a machine made for Japan, the Commodore MAX.

Longer Vblank helps on the C64 as you have more time to shift and update the screen before it starts display easing the limits before you play "chase the raster". Its about what you can get done in a frame as well, you can multiplex more sprites on PAL because you have longer to sort and organize.
Amiga likewise, you get more CPU time where DENISE doesn't steal clocks, more COPPER and BLITTER time to render the next frame etc.
Its more a "You have X clocks to make the next frame" problem where having more clocks helps.
Here is an example of how VBlank time and Machine power helps. This is a NTSC C64 vs PAL C64 vs NTSC C128 vs PAL C128 and its doing a full screen scroll. You can see the % of time vary quite a lot and having C128 VBLank times + C128 enhancements really change things.
RobynHood_dev1.png
Bregalad wrote:
Fri Aug 21, 2020 11:23 am
It seems silly to cripple a demo because NTSC exists. This is technically not true on a C64 as the Drean model is the most powerful however they are really really rare so nobody actually targets them.
In the Nintendo world it's silly to rely on PAL console which ran mostly dumbed-down and sometimes glitchy version of the games that were originally developed for NTSC.
It's a shame we don't have any PAL required SNES games.
I don't get it, you blame european developers for wanting to sell their games in the rest of the world ?!
No, I don't think they should have given us Dumbed-Down glitcty versions rather we should have had the better version, they had a year or 2 to fix it after all. The things they had to cut to make it work on NTSC should have been kept for PAL. I.e Final Fight should have more than 2 enemy types on the screen because we have the bandwidth to get a 3rd in. This is a limitation they didn't want forced upon them by NTSC. Earthworm Jim had frames dropped from the MD version because the SNES compression was slower and the VRAM bandwidth was less, well if you have the anims sitting there, PAL has more put them back in.
However the SNES doesn't have its Mayhem in Monsterland or its Sam's Journey the machine's potential has not been reached. But the TinTin games give as glimpse of what animation we could have had in the other animation heavy games such as Earthworm Jim, Aladdin, Mickey Mania et al. But they didn't give two hoots and were barely interested in giving us things in the first place.

Terranigma getting a PAL release but not a US-NTSC release shows that near the end, going PAL only would have been a viable strategy as the PAL market was alive longer.

Oziphantom
Posts: 913
Joined: Tue Feb 07, 2017 2:03 am

Re: SNES native 3D performance ST-NICC no SFX demo

Post by Oziphantom » Fri Aug 21, 2020 10:38 pm

creaothceann wrote:
Fri Aug 21, 2020 11:38 am
Oziphantom wrote:
Fri Aug 21, 2020 7:03 am
It seems silly to cripple a demo because NTSC exists
Nikku4211 wrote:
Fri Aug 21, 2020 9:02 am
emulation makes this all irrelevant
Most PC monitors run at 60Hz, so emulation will have problems with PAL games. Variable refresh rate monitors are a relatively recent development.
TVs can work as monitors and they will handle 50fps mostly. It seems some in the USA of really struggle and still don't handle 50hz. As people found out with the C64mini. Back in the day monitors ran from 50hz to 75hz. MDA was 50hz for example. But when when you get into all the VGA timings the refresh rate is all over the place. Multi Sync monitors have been a thing for quite some time. Then 16:9 60hz HD took over the LCD panel business and ruined it ;)

Oziphantom
Posts: 913
Joined: Tue Feb 07, 2017 2:03 am

Re: SNES native 3D performance ST-NICC no SFX demo

Post by Oziphantom » Fri Aug 21, 2020 10:53 pm

93143 wrote:
Fri Aug 21, 2020 1:48 pm
lidnariq wrote:
Fri Aug 21, 2020 11:21 am
Hm. If the objective is to avoid tearing...
and the framebuffer is 128x99...
then there's 29 lines in the mode7 tilemap that can be used to avoid tearing.
meaning that only 70 lines need to be uploaded in one go.
70×128 bytes will take 54.2 scanlines of DMA
and NTSC already provides 37
so we should only need to shave off a little (18 scanlines) of the top of the top to make this fit in NTSC...
I wonder if this is what he meant when he talked about losing sprites.
Loosing sprites was about not having VRAM, the sprites eat 32K, so if you need to double buffer MODE7 there isn't enough room to hold 2x MODE7 + 32K of sprites.
Shaving off 18 lines at the bottom wouldn't be too bad, might look a little cheap with a black border though. 9 and 9 might not look so bad. There are some palette updates as well. So probably need to expand to say 24 to be safe. Although the DMA does eat up the whole VBlank.. I wonder what he is doing..

Oziphantom
Posts: 913
Joined: Tue Feb 07, 2017 2:03 am

Re: SNES native 3D performance ST-NICC no SFX demo

Post by Oziphantom » Fri Aug 21, 2020 10:55 pm

Nikku4211 wrote:
Fri Aug 21, 2020 7:00 pm
creaothceann wrote:
Fri Aug 21, 2020 11:38 am
Oziphantom wrote:
Fri Aug 21, 2020 7:03 am
It seems silly to cripple a demo because NTSC exists
Nikku4211 wrote:
Fri Aug 21, 2020 9:02 am
emulation makes this all irrelevant
Most PC monitors run at 60Hz, so emulation will have problems with PAL games. Variable refresh rate monitors are a relatively recent development.
The emulators I've used seem to emulate PAL games just fine. Prisoner of the Sun didn't have any problems when I played it in SNES9x, a really old emulator.
Scrolling is the issue, it is never smooth, because you have to sample 50 over 60 you get judders in it.

User avatar
Nikku4211
Posts: 102
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: SNES native 3D performance ST-NICC no SFX demo

Post by Nikku4211 » Sat Aug 22, 2020 1:23 pm

Oziphantom wrote:
Fri Aug 21, 2020 10:55 pm
Nikku4211 wrote:
Fri Aug 21, 2020 7:00 pm
creaothceann wrote:
Fri Aug 21, 2020 11:38 am



Most PC monitors run at 60Hz, so emulation will have problems with PAL games. Variable refresh rate monitors are a relatively recent development.
The emulators I've used seem to emulate PAL games just fine. Prisoner of the Sun didn't have any problems when I played it in SNES9x, a really old emulator.
Scrolling is the issue, it is never smooth, because you have to sample 50 over 60 you get judders in it.
Guess I never noticed because it was still playable.
Bregalad wrote:
Fri Aug 21, 2020 11:23 am
Oziphantom wrote:
Fri Aug 21, 2020 7:03 am
30 or so years of PAL only C64 and Amiga demos hasn't been a problem. For Demos you want the more powerful version, so they tend to be PAL only to get more out of them.
I don't know for the C64 and Amiga, but in the case of NES and SNES, the "more powerful" is accidental, it's just the longer VBlank which allows to transfer more data per VBlank.
The demoscene is all about exploiting accidental advantages. Hardware 3D acceleration didn't exist for consoles back in 1990, but here we are streaming vector data to fake it. Still, though, I feel like requiring a PAL SNES is not that much different from requiring a Super FX chip, for anyone who isn't in Europe, Africa, most of Asia, Oceania, or some parts of South America.
Bregalad wrote:
Fri Aug 21, 2020 11:23 am
You're comparing apples to oranges. Commodore computers were (and to some degree, still are) immensely popular in Europe, not so much in the rest of the world. On the other hand, Nintendo consoles, while popular in Europe, originated in Japan and most games were developed in Japan. Of the western-developed games, there's a 50/50 share between northern America and Europe, but most PAL developers had to develop their games with the less powerful NTSC console in mind.
It seems silly to cripple a demo because NTSC exists. This is technically not true on a C64 as the Drean model is the most powerful however they are really really rare so nobody actually targets them.
In the Nintendo world it's silly to rely on PAL console which ran mostly dumbed-down and sometimes glitchy version of the games that were originally developed for NTSC.
It's a shame we don't have any PAL required SNES games.
I don't get it, you blame european developers for wanting to sell their games in the rest of the world ?!
This. The issue with adding more requirements means that compatibility is broken, and that less people can run your game or demo. The difference is that developers would want their games to work overseas so that they can make the most $ from their game, while demos are free, so their developers don't need to care about compatibility since they're not making $ anyway.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

creaothceann
Posts: 253
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: SNES native 3D performance ST-NICC no SFX demo

Post by creaothceann » Sat Aug 22, 2020 1:31 pm

Oziphantom wrote:
Fri Aug 21, 2020 10:55 pm
Scrolling is the issue, it is never smooth, because you have to sample 50 over 60 you get judders in it.
Yep... Kid Klown in Crazy Chase's options screen is my go-to screen for testing emulators in that regard.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

93143
Posts: 1225
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES native 3D performance ST-NICC no SFX demo

Post by 93143 » Sat Aug 22, 2020 3:26 pm

Oziphantom wrote:
Fri Aug 21, 2020 10:53 pm
Loosing sprites was about not having VRAM, the sprites eat 32K, so if you need to double buffer MODE7 there isn't enough room to hold 2x MODE7 + 32K of sprites.
But you can't double buffer Mode 7. The tilemap is where it is. That's why you need high bandwidth to do large frame sizes - with fractional buffering, the portion of the frame that can't be double buffered has to be updated in one shot, and the portion that can be double buffered is no larger than the free space you have once the full frame is stored, which in Mode 7 is not very large. The bigger the data, the smaller the double buffer has to be and the larger the single shot has to be.

Also, if those sprites eat 32 KB, it's because the display is being handled inefficiently. A good chunk of that frame is just solid colours, which could be done with repeated tiles, or even backdrop colours. And a ton of the sprite area doesn't share scanlines with Mode 7, so there's no reason not to use a BG mode for those areas, removing any concerns about sprite size/count and allowing (in principle) enough VRAM HDMA bandwidth to fractional-buffer the frame on NTSC.

(Why are people talking about 99 lines? It looks like a 126x94 viewport to me... 99 would still barely work with 24 bytes per line, but of course that leaves no HDMA channels for anything else, so switching BGMODE would have to be done with an IRQ, and more importantly there would be no free channels available for line filling, so it's probably best to limit the data size to what it actually needs to be...)

32 KB of sprites, eh? I wondered if that was what your IRQ was for...

lidnariq
Posts: 9659
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: SNES native 3D performance ST-NICC no SFX demo

Post by lidnariq » Sat Aug 22, 2020 3:57 pm

93143 wrote:
Sat Aug 22, 2020 3:26 pm
Why are people talking about 99 lines?
Because when I look at the mode7 tilemap itself, the lower left corner is (126,98) - 99 lines of 127 tiles per line. The rest of the tilemap is black.

But I agree that the viewport is only 126x94. The leftmost single column and bottom five rows are masked. Don't know how much of an improvement not drawing those would help.

Also, the DMA that copies from the scratch buffer to the mode 7 tilemap is copying $3880 bytes = 113 lines?

... also, I love that this uses the DMA unit to rasterize the polygons.

93143
Posts: 1225
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES native 3D performance ST-NICC no SFX demo

Post by 93143 » Sat Aug 22, 2020 4:59 pm

lidnariq wrote:
Sat Aug 22, 2020 3:57 pm
Don't know how much of an improvement not drawing those would help.
Depends on whether or not you're trying to make it work on NTSC.

To do that without changing the displayed results, you'd have to use VRAM HDMA (which AFAIK is still not confirmed to work on every model of SNES, but I see no reason why it shouldn't). If you were to do this, all the sprite graphics outside the scanline range of the Mode 7 viewport would have to be done with BG graphics instead, so as to leave enough sprite-free scanlines to get the necessary bandwidth. You can't use VRAM HDMA before a line with sprites on it because they will freak out.

...

(!!! I just realized that this would probably cause the demo to be incompatible with the rev.1 CPU, as mixing DMA and HDMA is a big no-no on that version... Considering the massive IRQ jitter induced by the frequent DMA transfers, I can see why one might decide to do the whole frame as sprites rather than risking an HDMA channel on BGMODE, although I still think there are enough single-colour or blank areas that you shouldn't need 32 KB...)

...

With 94 lines of Mode 7, you're left with up to 131 lines that can have VRAM HDMA on them (presumably you'd run the lines below the viewport on the frame before the update, and the lines above the viewport on the update frame right after the big VBlank DMA transfer). With a 128x94 framebuffer, you can double buffer 4352 bytes, leaving 7680 bytes to transfer in one frame. With 16 bytes per scanline of HDMA, you can transfer about 2 KB, leaving about 5.5 KB for VBlank proper. It fits comfortably, and you still have two free DMA channels, one to poke BGMODE and one to help draw the picture.

With 99 lines of Mode 7, you have 126 lines of HDMA. You can double buffer 3712 bytes, leaving 8960 bytes to transfer in one frame. The absolute limit of VRAM HDMA is 24 bytes per line, because you need two channels to handle blanking (cycle-aligned H-IRQ DMA can do 29 bytes per line but costs far too much CPU time). At 24 bytes per line, 126 lines gets you 3024 bytes, leaving 5936 bytes for VBlank proper. This leaves no free channels for rendering, so the drawing process would most likely be slowed down dramatically.

So yeah, in that case it matters a lot.

Post Reply