It is currently Tue Oct 15, 2019 6:37 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 28 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Thu Aug 01, 2019 12:48 pm 
Offline
User avatar

Joined: Wed Dec 09, 2015 2:18 pm
Posts: 43
How SuperFX assisted games displayed?
For example SuperFX chip generates graphics and then it should be transferred to the screen.
SNES has quite low bandwidth.
Is it possible at all to transfer an array of image data to the screen with reasonable fps?
As far I can see so far such games have quite low fps.

Thanks!


Top
 Profile  
 
PostPosted: Thu Aug 01, 2019 1:13 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4210
Location: A world gone mad
I've read through your posts and I can't quite figure out what your experience level is here. Are you actually programming something? Do you know 65816? Are you familiar with working/developing on the SNES? Your posts have a strange feel to them that doesn't particularly give us any understanding of where your experience level lies. They give the impression of someone asking specific questions because they're experienced, but also are strange and give the impression of literally no experience.

Speaking more brashly: I literally cannot tell if you have written a single line of code on the SNES or if you are just asking about weird details and providing little-to-no context (for some reason).

So why would I start off my reply with the above?

A big part of it is the fact that the questions you're asking, if you're experienced, are things that you could self-answer (kind of -- I'll explain). For example, if you're asking about scanline effects using HDMA etc., and also about direct colour, then I am sort of inclined to think you might have SNES development familiarity? But there isn't any real further information provided. And often no context, as I said.

There is one post where you say something like "sorry for being a noob" -- and being a noob is 100% cool/OK! -- except that noobs normally don't go asking about the SuperFX or nuances like the above. Noobs tend to be more concerned with actually starting out and doing something very basic. See why I'm confused? :-)

If you're experienced, then you might know where you find out how the SuperFX works and "fits in" to the overall scheme of things on the SNES, thus answering your own question. If not (or if you aren't sure where to find out the answer), here's a hint: romhacking.net has some particularly, shall I say, "useful" documentation in PDF format on the SuperFX. (I do not link to it, or discuss specifics of it, however, for many reasons that I refuse to go into here out of safety for the retention of said documentation.) Start with that and see where it leads you.

I should be clear about my goal with the above: the goal is to try and teach you how to "help yourself" first, then ask questions here when you've learned what you can but have questions (about code, system, etc.) or to discuss problems/issues you're running into when developing. This allows for better use of everyone's time, but really, the proverb "give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime" is what I'm trying to apply here.

If you are new to SNES development and the console, stop thinking about the SuperFX. Remove it from your mind entirely. It doesn't exist. Think about the basics of starting out, write some code, work your way up gradually. SFX, like SA-1, is highly advanced material.


Top
 Profile  
 
PostPosted: Thu Aug 01, 2019 1:40 pm 
Offline
User avatar

Joined: Wed Dec 09, 2015 2:18 pm
Posts: 43
Hi! Sorry that my question was not exact.
I am not experienced in SNES development.
However I have experience in Sega Genesis development.
Also I have checked SNES' hardware and couldn't find any way to make "direct colour" at a reasonable fps.
I was just curious maybe I missed something and someone much more experienced with SNES could guide me in the right direction.
Without experience I can judge only by the games. For example DOOM.
It runs at 15 fps at most. The visible area is reduced. The overall resolution is low as well.
It makes me think that SNES is not able to make "direct colour".
But it's only my assumption. I hope I am wrong.
But so far I haven't seen any SNES games doing "direct colour" and having a reasonable fps.


Top
 Profile  
 
PostPosted: Thu Aug 01, 2019 5:31 pm 
Offline

Joined: Sun Mar 19, 2006 9:44 pm
Posts: 1005
Location: Japan
Look, he's trying to win the bounty for making a SNES demo that beats Titan's MD efforts, by jumping into the deep end head-first, okay? :lol:

_________________
http://www.chrismcovell.com


Top
 Profile  
 
PostPosted: Thu Aug 01, 2019 6:30 pm 
Offline
User avatar

Joined: Wed Dec 09, 2015 2:18 pm
Posts: 43
What I can see so far is:
There is the Mode 3 having an 8-bit color for each pixel.
Each pixel needs 1 byte.
DMA bandwidth is around 170 bytes per scanline.
To fill the screen with a 256x224 image one needs 57344 bytes.
We get 6.76 fps if we transfer the data from ROM to VRAM only during the vblank.

I don't know if it's possible for SNES but it is so then we can turn the screen of a bit earlier and get extra 32 lines of vblank for each frame. Minus 16 pixels in the top and 16 pixels in the bottom.
Also we can make the viewport narrower. Thus we have 224x192 = 43008 bytes per "frame".
We have 38 + 32 = 70 vblank lines.
We get 16.6 fps.

As long as it seems to me unreal I don't take in account double buffering (though it likely will be needed).

16.6 fps is not perfect but playable enough. Especially for SNES players who are not used to high frame rates.

If I made any mistakes please correct me. Thanks!


Top
 Profile  
 
PostPosted: Thu Aug 01, 2019 6:45 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4210
Location: A world gone mad
greatkreator wrote:
Hi! Sorry that my question was not exact.
I am not experienced in SNES development.
However I have experience in Sega Genesis development.
Also I have checked SNES' hardware and couldn't find any way to make "direct colour" at a reasonable fps.
I was just curious maybe I missed something and someone much more experienced with SNES could guide me in the right direction.
Without experience I can judge only by the games. For example DOOM.
It runs at 15 fps at most. The visible area is reduced. The overall resolution is low as well.
It makes me think that SNES is not able to make "direct colour".
But it's only my assumption. I hope I am wrong.
But so far I haven't seen any SNES games doing "direct colour" and having a reasonable fps.

You've now changed the subject of the thread (re: direct colour, a.k.a. CG direct). Let's stay on topic please. I will answer this and then immediately switch back to what this thread is about: SuperFX.

I only mentioned direct colour because it was an example of something you had inquired about previously, compounded with other strangely specific details of the SNES, yet I couldn't discern whether or not you really had any experience with the system. Your above post tells me what I need to know: you have no SNES/65816 experience, but have Genesis/68K experience. I myself am the exact opposite (and I also intentionally avoid the "expansion" chips on the SNES, e.g. DSP, SFX, SA-1). What I CAN tell you is that two systems are *substantially* different, i.e. the way you go about things and think about things (see: solutions) on each console is often vastly different.

If you are expecting to make a SNES title exclusively use CG direct mode and nothing else, you will likely get no where. I don't think this is feasible; you are approaching things from a very obtuse/weird angle. You haven't stated why or what you'd need this for anyway. The feature is limited to modes 3 and 4 where you'd get 2048 total colours, and mode 7 where you'd get a fixed 256 -- and in all cases you get only 1 background and sprites are no longer a thing. All it lets you do is use raw PPU RAM for raw RGB colour/pixel data, rather than relying on CGRAM (palette lookup). Thus, based on this design, IMO it's mainly intended for one thing alone: displaying still pictures/photos.

Now back to on topic:

I don't know of anyone who has "extensively" reverse-engineered SNES Doom to find out the reason for the lower frame rate. There is probably a very good reason for it. Randy Linden, AFAIK, is still around. If you really, truly, deeply wanted to know the reasons for this, you could probably track him down and ask him. SuperFX games did not inherently make things "better" and "overall faster" -- it's just a RISC CPU that provides a lot of fast/native mathematical operations, and (going off memory here) some X/Y colour plotting features (i.e. draw a pixel, rather than the usual SNES's tile-based system). I don't think anyone knows *how much* of the SuperFX was used in Doom (vs. stock 65816) either. As for the resolution, well, it's a 256x224 title vs. the PC's 320x200 -- those 64 extra pixels in width make a big difference -- but the SNES version also has a black border around the main part of the image making it effectively 216x144. There's a wiki page that talks about some of the nuances of SNES Doom, and I suspect part of it stems from the fact that it looked to have been ported from the Jaguar version (with bits/pieces from the PC version). I should add that StarFox has a pretty "meh" framerate as well. Yoshi's Island had a good framerate (60fps IIRC), but I get the impression most of the SFX features were used for sprite scaling and other whatnots, and *not* a focus on doing "3D things" like the other two games. Finally -- and I am hoping someone like byuu or Sour or anyone else more familiar with this chip corrects me if I'm wrong -- but I remember the SuperFX's graphical operations only applying to either cartridge RAM or system RAM, and *not* PPU RAM (i.e. DMA transfers from CPU to PPU still had to be done in 65816). Anyway, I really do insist that if you want to find out the answers about SNES Doom, to track down Linden and have a chat. Else read this interview/write-up.

It is fairly obvious that games *not* using the SFX were able to achieve 60fps, and that's because those were games designed with the tile-based system in mind. Everything from the ground up was designed that way. SNES Doom was a port focused on software 3D and per-pixel drawing, and Star Fox was a game focused on 3D polyfill and lines. Do you see the connection there with the slowdown? Think about it. :-) The SNES is not a "fast" or "high bandwidth" system in general. You design games/things with that in mind.


Top
 Profile  
 
PostPosted: Fri Aug 02, 2019 1:03 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1086
According to sources presumed to be familiar with the matter, the Super FX was not the bottleneck in SNES Doom, nor was the DMA speed.

Supposedly the SNES-side engine was in C, and the whole game could have been about 30% faster with an optimized assembly engine.

...

But yes, the Super FX can only write to Game Pak RAM, so to get the results to VRAM you have to use the SNES DMA unit, and there are limits to how fast you can do that.

Super FX games were often something like 224x192 at 4bpp, with other BG layers and sprites used to provide backdrop and HUD graphics. Black areas above and below the active area can be forced blank, which allows free access to VRAM, CGRAM, and OAM. With a bit less than 70 lines of DMA at 165.5 bytes per line, there's barely enough room for 30 fps if you don't have to fully refresh both CGRAM and OAM, or plenty of room for 20 fps if you do. Star Fox caps at 20 fps for this reason. But preparing the frames is the bottleneck in most situations, so it's rare to see the game actually run that fast.

Doom is 8bpp (as is Stunt Race FX; this should be taken into account when comparing it with Virtua Racing, as it doubles render time, buffer clear time and DMA time). This reduces the peak frame rate. On the other hand, the framebuffer is smaller in those games - Doom is 216x176, or 216x144 without the status bar, so while 30 fps is unrealistic, there's more than enough bandwidth for 20 fps. I doubt the rendering is fast enough to hit that speed with any regularity (the walls in Doom are probably rendered in vertical lines, and as mentioned in the linked thread, rendering vertical lines on the Super FX is very slow because of the bitplane format), but as mentioned above it seems the S-CPU code was even slower...

In other words, the type of games that were made for the Super FX were not radically bottlenecked by the DMA speed. It's not like Star Fox and Doom would have been 60 fps without that limitation; the power of the chip was reasonably well matched to the capabilities of the console.

...

Non-Super FX games were typically 60 fps, sometimes with drops, sometimes pretty solid - even with fast action games. Same as the Mega Drive. I don't know what you're on about with this "SNES players who are not used to high frame rates" stuff; if I didn't know better I'd swear it was bait...


Top
 Profile  
 
PostPosted: Fri Aug 02, 2019 3:22 am 
Offline
User avatar

Joined: Wed Dec 09, 2015 2:18 pm
Posts: 43
Thanks a lot guys for your help!
Now everything is clear.

Concerning a lower frame rate: I have played a lot of Sega games and a lot of SNES games and I found that the latter ones have lower frame rates.
Maybe it's not so. I haven't checked it very well. It's just my assumption. Maybe it's my biased perception.
I understand that both consoles have very similar possibilities (except CPU but it doesn't matter too much).
There was no reason for a lower frame rate.


Top
 Profile  
 
PostPosted: Fri Aug 02, 2019 4:20 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1086
A bunch of early high-profile SNES games had a lot of slowdown. There are a few reasons for this - for instance, the CPU was significantly harder to program, much less widespread/popular, and somewhat less powerful than the one in the Mega Drive (more powerful per MHz, but slower, especially with early SlowROM carts), and the sprite system was less flexible and more fiddly to use than the MD's, even though it was more powerful on paper. Later games tended to have less slowdown, the standout example being Rendering Ranger's shmup sequences. Even early titles could be pretty solid if they didn't overreach (F-Zero was a solid 60 fps, and I recall only one instance of slowdown in Super Mario World despite its engine being reportedly very inefficient), but developers definitely got better at it - compare Super R-Type to R-Type III.

By the way, Super Mario Kart is locked 60 fps. Thunder Force IV is not. I don't know why people seem to think otherwise.

Race Drivin' was a disaster, possibly because the SNES graphics format is much more difficult to render into than the MD format. This may be one reason the Super FX has its complicated PLOT circuitry, while the SVP chip wasn't even specialized for rendering (then again, maybe if it had been, it might have been somewhat cost-competitive with the Super FX...).

It's true that MD games were often quicker and more twitchy than SNES games, which may contribute to the popular perception. But Sparkster works perfectly fine on SNES...


Top
 Profile  
 
PostPosted: Fri Aug 02, 2019 4:25 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4210
Location: A world gone mad
I can list off numerous Genesis games that can have "bad frame rates", and probably just as many on the SNES that have the same thing.

Small font time because off topic:

One thing that should probably be kept in mind -- and this is my own opinion, but it's based on how prevalent the chip was at the time: the 68000 was a CPU that "more" people overall were familiar with during the 16-bit era. It was often used in arcade systems as the primary CPU. As you know, it's a CPU with eight (8) 32-bit registers with ways to access/address each half of the register purely via the operand/addressing mode, in addition to things like native multiplication and division opcodes and up to 32-bit addressing space -- it's beefy and very capable, and also makes a decent CPU for higher-level PLs like C. The 65816 in contrast offers only three (3) 16-bit registers, only one of which can be used for general purposes/operations while the other two are purely used for indexing within addressing space (the total of which is 24-bit), and has no multiplication/division outside of the obvious bitshifts for x2/x4/x8... or ÷2/÷4/÷8... There's a lot more "messing about" on the 65816, and it does not cater well to any languages other than assembly and certain others (BASIC interpreters were common). My point is: more prevalence means generally people were more familiar with it, especially arcade companies, and this was compounded by having more breathing room/capability CPU-wise.

The 65816 was chosen on the SNES almost certainly because it was the successor to the 6502 in the NES (or 65C02 by that point), since it's backwards-compatible and thus existing NES/6502 programmers (read: companies making games for the SNES) would have some general familiarity with it, and see it as an upgrade (see: 16 bit registers, 256 opcodes, new addressing modes, 24-bit addressing support, etc.). But the fact remained, unlike with the 6502, it was an incredibly niche processor: the only things that used it that were mainstream or commonplace for the time period were the Apple IIGS and the SNES (I can't think of anything else that did, and it doesn't really matter). So that should make you ask: why did Nintendo go with the 6502 on the NES to begin with? The reason is actually known: Nintendo intentionally chose it because they deemed it obscure, nobody had heard of it / was using it widespread in Japan, and Nintendo was fearful of piracy/clones (ironic considering how many were made after the fact). So, with the SNES, they chose to use a 16-bit version of a CPU that was backwards-compatible (and just as obscure in Japan) with their previous choice from their earlier console (but with substantially better graphics. The SNES blows the NES out of the water.) Oh, and the 65816 was probably substantially cheaper; the 68K was known for being both expensive and physically large. Nintendo is still to this day well-known for making systems that are cheap/low cost to allow for maximising profit -- and that was in full effect in the 80s/90s too.

Sega, on the flip side, had been making arcade games and some (Z80) home console systems for some time, so their familiarity with both the Z80 and the 68000 should come as no surprise. Plus, their VDP stuff on the Genesis is very much along the lines as what some of their arcades did (an arena Nintendo was not familiar with). As such, this made the Genesis a really good candidate for ports of arcade games -- and there are plenty. There's a lot more work that goes into porting something to 65816, *especially* if you have things like ports of 68000 games. Want a good example of something that did port really well but certainly took a huge undertaking? Capcom's Magic Sword, which was CPS-1 (10MHz 68000 CPU + 4MHz Z80 for sound engine + YM2151) on the arcade, but was ported or converted to SNES (2.8/3.6MHz 65816 CPU + SPC700 (digital, no FM!)). That's a game that runs at nearly 60fps the entire time and is a very good port. Another example, also from Capcom: UN Squadron/Area 88. For other companies like Konami, they had Gradius 3 as a launch title, which was also 68000 ported to 65816. That game does have slow down during some levels, such as the bubble level, and reverse engineering analysis (gets into the nitty gritty in later pages) has proven it's not "CPU speed" or "system limitations" as much as it is some rushed or badly-engineered sprite management/collision -- i.e. not the hardware.

Finally: please remember the games I'm talking about came out in 1990 through 1992/1993. Time period/era is very important when it comes to talking about any of this. If you're too young to remember this era (i.e. you didn't live through it as either a late teenager or adult) then all of this will be lost on you and you will make silly comparison mistakes like assuming hardware was as cheap as it is today back then. Nope, it all was much, much more expensive.


Top
 Profile  
 
PostPosted: Fri Aug 02, 2019 5:56 am 
Offline
User avatar

Joined: Wed Dec 09, 2015 2:18 pm
Posts: 43
It seems something psychological caused my false perception.

Am I right that double buffering is impossible if I use 224x192 8bpp resolution because there is no room for double buffer in 64 kB VRAM?
I was able to made double buffering on Sega having 64 kB VRAM because Sega was able to transfer 50% of data while VDP is rendering the previous half of the screen.

Am I right that If you are using double buffering you are limited to 32 kB viewport (about 224x140)?

And is it possible for SNES to turn the screen off and make forced VBlank for higher DMA transfers?


Top
 Profile  
 
PostPosted: Fri Aug 02, 2019 7:40 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21626
Location: NE Indiana, USA (NTSC)
Full-screen double buffering is possible, just not anywhere near 60 fps. Forced blanking is also possible, and unlike on NES, there aren't severe sprite restrictions if a frame ends in forced blanking, so you can still use sprites for the HUD and the like.

224x192 is 80 percent of the width and height of the 4:3 frame. The markings for a 224x192 area on Nintendo's NES background planning sheet implies that Nintendo must have recommended that developers keep all important score indicators and the like in this area. It also happens to be the size of the picture rendered by the Super FX MARIO chip in Star Fox.

224x192 means there are 43,008 pixels on the screen. At 4 bits per pixel, this amounts to 21504 bytes, or 21 KiB. At 165.5 DMA bytes per scanline, it takes 130 scanlines' worth of DMA timeto send an entire picture.

224x192 means there are 193 active scanlines: one to bring the PPU cleanly out of forced blanking and 192 to display lines of picture. Subtract this from the 262 total lines of the NTSC NES and Super NES, and this leaves 69 usable to transfer data, or enough to transfer half a picture.

You can even get away with one and a half buffers. Divide the first 31.5 KiB of VRAM into three 224x96 pixel buffers, 10.5 KiB each. The top half of the screen is then double-buffered, while the bottom half isn't. In theory, if streaming from a sufficiently fast GPU, a game can follow the following four-field cadence for 30 fps operation:

  1. Send top half to buffer 1, then display 2 and 3
  2. Send bottom half to buffer 3, then display 1 and 3
  3. Send top half to buffer 2, then display 1 and 3
  4. Send bottom half to buffer 3, then display 2 and 3

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Fri Aug 02, 2019 8:49 am 
Offline
User avatar

Joined: Wed Dec 09, 2015 2:18 pm
Posts: 43
224x192 4bpp 30 fps.
Not bad!
However bad that 4bpp only.


Top
 Profile  
 
PostPosted: Fri Aug 02, 2019 9:22 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21626
Location: NE Indiana, USA (NTSC)
Unfortunately, a mild amount of letterboxing doesn't quite save 60 fps.
224x160: 35840 pixels, 17920 bytes, 109 lines' worth of DMA, but only 101 blanking lines. That's not quite enough for 60 fps.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Fri Aug 02, 2019 12:55 pm 
Offline
User avatar

Joined: Wed Dec 09, 2015 2:18 pm
Posts: 43
60 fps isn't the objective at all.
It's obvious it's unreachable for direct colour.

We know that this (224x192 + 4bpp + 30 fps + double buffer) is possible.

At this moment I would really like to know what the max viewport I could achieve for a 8bpp color and 15-20 fps ( I don't know for sure but I guess 30 fps is unreachable)?


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

All times are UTC - 7 hours


Who is online

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