It is currently Sun Sep 15, 2019 7:25 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Tue Jan 29, 2019 3:16 pm 
Offline

Joined: Sat Apr 07, 2018 7:39 pm
Posts: 46
Location: EN
Hey guys

I'm writing some code for the super-fx, and I managed to get it to complete the task I need it to in under a frame, which is brilliant. However, after the screen is complete, it then takes far too long for the main CPU to copy it into vram (up to a third of a frame after v-blank).
This seems odd, as things like starfox can copy the entire frame - does it copy over multiple v-blanks?
What's the point if you get your frame rendered in a very small amount of time only for the frame copy to take longer?

Thanks,
Molive

_________________
SNES demos are great


Top
 Profile  
 
PostPosted: Tue Jan 29, 2019 3:33 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8557
Location: Seattle
DMA on the SNES always runs at 2.7MB/s. You can do the math to figure out how many scanlines can be displayed at what bit depth and update all of it every vsync...


Top
 Profile  
 
PostPosted: Tue Jan 29, 2019 5:28 pm 
Offline

Joined: Tue Jul 31, 2018 9:37 am
Posts: 8
Starfox usually doesn't update the whole screen unless a 3d object or scaling sprite is really close. The backgrounds, HUD, and ground planes are all rendered by the SNES.

One thing that I think Doom did (I know Wolf 3D did) was write their scene to video memory at a lower resolution and then scale that with mode 7 to fill the screen.

I'm really interested in your project, can you link me to it?


Top
 Profile  
 
PostPosted: Tue Jan 29, 2019 6:31 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1081
IIRC Star Fox reportedly won't even try to exceed 20 fps regardless of overclock, partly because of the multi-frame buffer copy. With the resolution it uses, it should be able to do 30 fps, but it would be tight.

I did a 224x192 2bpp 60 fps bullet hell test on the Super FX. At 256x224 it wouldn't have fit in VBlank, and 4bpp was right out. You only get so much data per scanline with DMA (165.5 bytes for each blanked line) and whatever you do has to fit into that.

secondsun wrote:
Starfox usually doesn't update the whole screen unless a 3d object or scaling sprite is really close.

Have you got a source for that? I was pretty sure it updated the whole 224x192 Super FX layer every time. It would be quite complicated to try to figure out what parts of the framebuffer had been changed and only transfer those.

It's true that a fair bit of the Super FX layer is usually transparent. This actually means the Super FX has to spend extra time clearing the framebuffer before starting each frame. By contrast, Doom renders every pixel every frame and therefore shouldn't need to zero everything first (I won't say it doesn't because I haven't checked).

Quote:
One thing that I think Doom did (I know Wolf 3D did) was write their scene to video memory at a lower resolution and then scale that with mode 7 to fill the screen.

Doom didn't scale the screen; it rendered it in double-wide pixels. Since the Super FX mainly bottlenecks on data processing and pixel cache flushes, doubling the screen width this way is basically free in a column renderer like the Doom engine (except of course that it doubles the DMA time required to get the buffer into VRAM). It also allows you to use hardware dither on the floors and ceilings. Wolfenstein 3D did in fact use Mode 7, but Doom used Mode 3.

A while back I tried to figure out a way to use mosaic with HDMA scroll to fake double-wide pixels without Mode 7. Unfortunately I couldn't get it to work in the hour or two I had available, and every emulator behaved differently; even higan gave me different results than real hardware. Mosaic is weird...


Top
 Profile  
 
PostPosted: Tue Jan 29, 2019 7:09 pm 
Offline

Joined: Tue Jul 31, 2018 9:37 am
Posts: 8
Quote:
Have you got a source for that? I was pretty sure it updated the whole 224x192 Super FX layer every time. It would be quite complicated to try to figure out what parts of the framebuffer had been changed and only transfer those.


So I don't. I was running on the mental model that the Super FX was rendering models and then having them be "sprites", but that would be hilarious overdraw now that I think of that. I was running my mental model based on an old scaling demo I saw where the scaled sprite clipped at the edges of the "original" sprite. But Now that I think about it more that would be more 2d specific. Sorry I haven't really gotten familiar with the SFX yet and clearly I have many wrong ideas about how things are coded under the hood.

Also, can I get a link to your bullet hell demo source? I remember seeing it a while ago.


Top
 Profile  
 
PostPosted: Tue Jan 29, 2019 10:34 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1081
Sure, why not?

Attachment:
FXtest1.7z [108.09 KiB]
Downloaded 133 times

It's a little messy, and not all the lines have helpful comments. Don't believe everything you read in planning or summary comments; check the actual code. I changed the renderer a couple of times, and there may be commented-out stubs of old ideas in there.

Also, it uses an old version of WLA DX. The required binaries are included in the attachment. The initializer is from Neviksti's SNES Starter Kit, as are some style elements of the main code file.

It's not the most reusable code, and I'm sure there are ways to optimize it further, but it works.


Top
 Profile  
 
PostPosted: Tue Jan 29, 2019 10:41 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3503
Location: Richmond, Virginia
Writing the Super FX code like that looks like it would have been hell.


Top
 Profile  
 
PostPosted: Tue Jan 29, 2019 10:55 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1081
Yeah, I hadn't yet gotten up the will to move to ca65, so I was stuck without any way to assemble it.

I actually got tired of manually counting bytes for the branches really quickly, so what I ended up doing was just using 65c816 branches and checking their operand values in a debugger. Then I'd substitute in the correct instructions in .db format and rerun the assembler.

It's kinda fun working in hex, but I don't plan to do the whole game that way...

...

Link to the original thread, in case anyone's interested.


Top
 Profile  
 
PostPosted: Wed Jan 30, 2019 1:10 am 
Offline

Joined: Sat Apr 07, 2018 7:39 pm
Posts: 46
Location: EN
Sorry to not keep up, I went to sleep after I read lidnariq's comment.
I did some calculations and worked out that I could get about 33.3 FPS using 4 buffers SFX side and another 2 VRAM side, but that would be insane to code and manage, so I think I'll stick with the 25 I think I can guarantee.
It's annoying that you can't update VRAM while the screen is drawing, but that's a problem I'll have to code around.

Molive

_________________
SNES demos are great


Top
 Profile  
 
PostPosted: Wed Jan 30, 2019 8:06 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1081
Wait, are you using PAL?

If you can't hit 50/60 fps, it's probably fine to just cap it at 25/30. That way you don't run into issues with uneven frame times at your nominal update speed. Also, it leaves more room to do other stuff during VBlank if necessary (OAM/CGRAM/OBJ/tilemap updates can take a lot of time depending on the game).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 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