SuperRT – Realtime Raytracing on the SNES
shironekolabs.com
shironekolabs.com
> Thus the full image can only be refreshed once every two frames, effectively limiting the maximum framerate to 30FPS - although the test scene runs at closer to 20FPS (primarily due to some bottlenecks with the logic on the SNES side at present).
Getting around this would make this even more interesting. Like most other console PPUs of it's day, due to bandwidth/etc the normal 'flow' is to have a background and a series of 'character' sprites preloaded into VRAM and then shuffled around (this is why in some 'busy' games you would see clipping or game elements disappear on early consoles; too many sprite objects for the PPU to keep track of.)
To that same end, I'd be curious to see what could be done like this on Genesis/Mega Drive hardware
You can see the bones of such technology in real products:
https://en.wikipedia.org/wiki/Satellaview
http://nectaris.tg-16.com/GB-KISS-LINK-FAQ-2-hudson-gameboy-...
https://shop.insidegadgets.com/product/wireless-gameboy-cont...
...I hope NES programming is similar to GB/Z80, since as far as retro gaming tools go that's all I know right now, haha.
Play Crysis or Cyberpunk "on" a SNES.
https://zelda.fandom.com/wiki/BS_The_Legend_of_Zelda:_Ancien...
As the Wi-Fi hardware inside the cartridge would be custom, the ROM would have to contain instructions that would not be emulatable by a flash cart (or any other means.)
Edit- Missed "online play?" in your comment. Yes, that's the idea, new homebrew games with actual working online, made for systems released 25-30 years ago.
I got linked a Genesis Wi-Fi cartridge elsewhere in this thread: https://github.com/doragasu/mw
Exciting that this idea is already out there! I'm very happy.
So now I know of NES and Genesis implementations of this idea. That is super encouraging, I thought I was dreaming into the wind alone for years.
This is not real-time raytracing on standard SNES hardware, as the title implies.
Still a very impressive project, of course.
Is Star Fox with the Super FX chip also considered cheating?
I'm not sure the title implies that. Performant raytracing on SNES hardware would be (to my understanding) pure magic - SNES modes may have been good, but none of them were that good. Just reimplementing raytracing in software on a SNES would also not really be that interesting technically. It can already do any kind of calculation, if slowly.
Expansion cards are established ways to improve the SNES's hardware capabilities, as many cartridges did, especially toward the end of the console's lifetime. It's not dishonest to describe using one as doing something "on the SNES" - especially when part of the writeup is about technical challenges interfacing the expansion chip with the actual console.
Sort of like the Commodore demo scene. What they can accomplish with the original hardware is amazing. If they were relying on additional hardware to do so, it's less interesting (but may still be interesting, and an accomplishment, as this is).
A more accurate title based on how people might think of this might be "SuperRT – Hacking SNES hardware to support realtime raytracing" (and even then you're going to get people assuming it's all original hardware).
Where you may be making a valid point is that I don't know how many people outside the dev scene know how common cart-based extra CPUs were. But doing this feels entirely in the spirit of how development on the SNES actually worked, even at the time--and as someone who's done some SNES development work, I knew from the headline alone roughly how it would necessarily be implemented. The closest analog I can think of would be like seeing a blog post, "calling native Win32 from pure JavaScript," and then being disappointed that ffi was involved. That's literally the only way it could possibly work in the first place, so of course that's what it is going to have to be about.
This and the Super FX - not to mention the Sega CD or the Sega SVP used in Virtua Racing - etc. all just uploaded video data via the cartridge port and blitted it to the screen console-side.
The only reason the 32X needed to do the weird video interception kludge was to get around the Genesis' poor colour depth, and exactly the same thing would be needed if you wanted to do that on the SNES (the SNES had less of a need for that, but...)
Sure it does.. it says "Realtime Raytracing on the SNES". To any normal person "SNES" means a super nintendo you would have at home.. not one that has expansion cards etc.
Anyway cool project but the title is indeed a bit misleading.
The title may be skewed towards an audience that knows slightly obscure details of SNES history, rather than misleading the general audience.
Almost any popular SNES game you can think of came with extra technology included in the cartridge and commercials often bragged about it, like the SuperFX chip used by Star Fox.
Heck if it weren't for expansion chips, you wouldn't even be able to play Super Mario World or Zelda, since the SNES had no persistent storage, all save games were stored physically on the cartridge itself.
This is just like Nintendo adding their own co-processors over the lifetime of the system, albeit with more advanced technology. If Mario Kart is running on the SNES, so is this.
You couldn't download this demo into a ROM image and run it on an emulator. To make it run, you'd have to beg the author of the emulator to actually support your chip.
This is more than a silly, pedantic distinction; emulators are probably the way that >95% of the current SNES playerbase runs the software, and they're likely to remain that way … forever? I don't see the interest in running SNES games ever really going away, since they're fun in a timeless way (like classic books/film), so emulators that support it are likely to stick around for several centuries, barring civilizational collapse. Actual hardware's pretty close to dying out (the recent "SNES Classic" physical devices, afaik, are just neatly packaged emulators).
So I think it really does matter whether it runs in an emulator or not.
(Not to diminish the fairly awesome technical prowess of this hack)
https://en.wikipedia.org/wiki/List_of_Super_NES_enhancement_...
Many SNES games include one-off chipsets that common SNES emulators implement as well; for example just something simple like saving your game can't be done on an SNES and needs an expansion chip.
If you were to write a SNES emulator that only emulated the console itself, it would not be able to run the many SNES games that use addon chips. SNES emulators include code that emulate the addon chips originally contained in the cartridges[1].
So, I think your test is a false one. Games run in the emulator because the emulator added emulation for the chips in the game. This game cartridge would also run on a SNES emulator if you emulated its chips.
[1] Code to emulate the behavior of the DSP chip in Super Mario Kart (among many others): https://github.com/bsnes-emu/bsnes/tree/master/bsnes/sfc/dsp
But even beyond that, this isn't the case - the core logic for scene creation runs on the SNES and then the instruction opcodes are shipped to the expansion chip. So it's a GPU for the SNES, and a perfect analog to the SuperFX chip from which it takes its name.
A far cry from simply "using the SNES as a video adapter" as the full SNES hardware is still running the "game logic" to accept input and set up the scene.
It's all about expectations...
The inherent limitations of an SNES cartridge are the power consumption (although some cartridges actually included batteries) and the memory bandwidth (it's a 16 bit system so the cartridges have 16 pins).
It was not uncommon to have expansion chips: even early games such as Super Mario Kart had a (DSP-1) chip to help with 3d calculations. Later chips such as Super FX 1/2 (Star Fox, Doom, Yoshi's Island), Cx4 (Megaman X2/X3), and SA-1 (Kirby's Super Star, Mario RPG) were used in a significant portion of the library.
The SA-1 was basically an additional 10Mhz SNES CPU (which was a 65c816 at about 4Mhz)
Of course many games shipped with mappers, but if you're willing to put no limit to the amount of hardware you put on said mapper you might as well interface a full high end PC and play Cyberpunk 2077 on "standard SNES hardware".
Basically once you've figured out how to best use the SNES hardware to output fullscreen, decent FPS video from the cartridge port to the TV you can do whatever you want.
It's still a very cool hack but I was hoping for some ultra-optimized software-only SNES raytracer when I read the title.
Bruh. It's in the third paragraph.
> Of course many games shipped with mappers
No. You're thinking of the NES. The SNES handled memory mapping natively. The SNES chips had specific calculation functions, or ended up being co-processors, or both.
> It's still a very cool hack but I was hoping for some ultra-optimized software-only SNES raytracer when I read the title.
Not even the SNES games in the 90s did 3d without an expansion chip. You can't do any raytracing, or any 3d for that matter (without SEVERE compromises) with 3.5 Mhz.
If you read the article, the guy designed his own 3 core chip at 50Mhz... Yes it's more powerful than any chip that was in an SNES, but, it's not entirely period-incorrect.
FPGA design, and graphics programming generally, requires higher-order math. I have always struggled mightily with trigonometry; something about it just doesn't click in my brain. Calculus I can handle, but spatial math breaks down in my head.
I could probably figure it out given enough time, but it would take much more time than it would take someone whose brain is aligned for it.
If you're just starting out, then you've gotta begin with the basics: blinking a few LEDs, etc. From there you can progress to more and more complex circuits as you learn to code in VHDL or Verilog.
I'd recommend buying a couple of 2nd hand books on VHDL and/or Verilog to get familiar with the syntax. There are some good free books too:
http://freerangefactory.org/pdf/df344hdh4h8kjfh3500ft2/free_...
This little book is great if you're interested in how to build video game hardware for FPGA:
https://gumroad.com/8bitworkshop#JGZkq
I also have a repo of examples I wrote for the DE10 Nano:
Look no further than this article itself:
> The idea originated when I was trying to think of an interesting idea for a project to help me learn Verilog and FPGA design, and the notion of building a simple raytracer came to mind (partly inspired by a scarily smart friend of mine who is building his own GPU).
The way this author describes his friend who is working on a challenging design is 'scarily smart.' IMO "that other skill domain" seems intimidating from here but if you start small and are willing to put in the time, you can do it.
The people who work on biochemistry, mechanical engineering, auto repair, digital hardware -- they're all just people, after all.
It takes advantage of the fact that pixels that are close together in screenspace are likely to be similar enough to interpolate from it's neighbours where possible. It focuses the computation time on areas where neighbouring pixels are very different, such as object boundaries, shadow boundaries and large lighting differences.
https://web.archive.org/web/20101123123238/http://exceed.hu/...
At 20 FPS you're already pretty laggy; dropping the FPS further to manage game logic will likely make playing the game an unpleasant experience.
But I think Nintendo would gladly like to accept your suggestions :-)