Video wird geladen...

Video konnte nicht geladen werden

Zur Startseite

It's finally time for the massive update I know EVERYONE has been eagerly waiting for... Presenting to you over 6 straight minutes of spliced footage directly captured from my actual physical Sega Dreamcast... RUNNING THE LATEST BUILD OF OUR SONIC MANIA PORT!!! I can't even begin to describe to...

87,802 Aufrufe • vor 3 Monaten •via X (Twitter)

0 Kommentare

Keine Kommentare verfügbar

Kommentare vom Original-Post werden hier angezeigt

Ähnliche Videos

The #GTA 3 port to the Sega #Dreamcast has been progressing at an incredible pace. It's been amazing to see the whole DC community come together to tag-team this "impossible" project... Here it is running on a stock DC, no longer requiring the 32MB RAM hardware modification, only a few weeks into development. Since I finally got the time to sit down, build the codebase, and look into some of what I think is the critical path for performance, let's talk about some technical shit, and some of the future steps I think can be taken to further improve performance. First of all, I want everyone to take note that this is NOT a port of the PS2 version. This is a port of the PC version, which has extra content, increased draw distance, improved textures, and other things that have actually increased the challenge here... Whether the DC version will ultimately have these additions or not will remain to be seen, but we're running into plenty of shit that the PS2 didn't have to worry about (like these big-ass PC replay saves won't fit onto a Visual Memory Unit!) Secondly, lets talk about what is and isn't currently optimized, because it's absolutely vital that the DC's hardware is fully utilized here for the sake of performance and achieving a competitive polygon count. Unlike with modern devices, where the whole graphics pipeline is handled by the GPU, both the PS2 and Dreamcast were responsible for transforming and doing lighting calculations for each vertex BEFORE they got submitted to the GPU. The PS2 had a vector coprocessor to do this, while the Dreamcast had a few extremely important SIMD and fast math assembly instructions on its CPU to do these computations. Up until literally just a few hours ago (not shown in this footage), the Dreamcast's SH4 was doing 100% of these operations in slow-ass plain C and C++ code, which is absolutely sub-optimal and is immediately bogging down its CPU with just transforming vertices, bottlenecking the entire graphics pipeline on the fist T&L stage, and also leaving less CPU time for handling other gameplay logic... this is going to absolutely have to be addressed (and already has begun to be). Another issue that is crippling performance here is the fact that the models are all using individual triangles rather than triangle strips, which the Dreamcast's PVR GPU was designed to handle better... Converting these models to use strips rather than individual triangles will result in MANY different gainz for the DC, as you're going from 3N to N+2 vertices per triangle. Converting the models to triangle strips will 1) reduce load times, since model assets will be smaller 2) reduce the amount of video memory required to hold these vertices on the GPU 3) reduce the amount of shit that must be transferred from the CPU to the GPU and 4) give us back a bunch of CPU time, since the SH4 will be less bogged down transforming redundant vertices! TL;DR: This is still EXTREMELY suboptimal in terms of fully utilizing the graphical potential of the Dreamcast. There is going to be a LOT that can be done still to both improve performance and polygon counts, so stay tuned! FINALLY: Mad respect and love to Stefanos Kornilios Mitsis Poiitidis, for doing an amazing job leading this project, and to Frogbull , Esppiral, and everyone else who is helping us stick it to the PS2 by making this happen! #gamedev #retrogaming #cplusplus

Falco Girgis

88,356 Aufrufe • vor 1 Jahr

With all of the excitement from Mario Kart 64 coming to the Sega Dreamcast, I've been getting bombarded with questions about whether any more progress has been made on our Mario 64 port... so here's a direct hardware capture of the latest build running on DC! The answer: HELL YES! Last time most people saw or played this port, it was plagued with performance, audio, and graphical issues... but as you can see from this footage, almost all of them have been resolved, and she's playing like a dream on the DC now! Wtf happened? Well, first of all, in the 5 years since the port initially started, I, along with others, such as UnknownShadow, have made progress optimizing and improving upon our OpenGL 1.2 driver, "GLdc," which drastically improved the overall performance of the port by decreasing the amount of time the Dreamcast's SH4 CPU spent on T&L, processing polygons. Next, chad developer, Bruce (or Bruck or Brucilicious, depending on who you are), went through and applied a bunch of bugfix patches from the upstream repo to the game to fix the majority of the graphical glitches such as clipping issues and Mario's iconic biker mustache from the previous releases (despite me trying to convince him to keep that one, as it's become a Dreamcast trademark). Finally, the original developer behind both the Sega Dreamcast and Sony PSP ports, MrNeo, has returned from hiatus and has begun redoing the audio engine to fix the artifacting and stuttering! Stay tuned for further updates and the inevitable rerelease of this N64 classic on Sega's finest little white box that still refuses to die!

Falco Girgis

34,186 Aufrufe • vor 1 Jahr

jnmartin and I just spent the last 12 hours straight locked into an epic tag-team, binge-coding session. We've decided to return to perfect our port of Mario Kart 64 to the Sega Dreamcast, bringing with us all of the skills, knowledge, and tools at our disposal that we gained from every port we've been involved with since we originally released MK64 DC to the public. 1) jnmartin has just completely redone the audio synthesis and mixing code. It was originally emulating the Nintendo 64's RSP in software, on our CPU, and wound up being a total resource hog, despite us going to hell and back again, substantially boosting its performance by vectorizing it with our SH4 SIMD instructions. 2) Now that the audio is actually offloaded to the AICA, we can leverage its DSP to put back in effects such as reverb and echo that we simply didn't have the CPU budget to implement before... so the overall audio quality of the port will be SIGNIFICANTLY improved. 3) jnmartin has been working on many small bugfixes, such as the near-Z clipping edge-cases that would cause corrupted triangles to draw over the players' screens sometimes in 3 and 4 player modes. 4) jnmartin just kicked GLdc--our OpenGL 1.1 driver, built atop of KallistiOS--to the curb and has instead implemented a bare-metal renderer that raw-dogs KOS's lowest-level PVR GPU driver directly, giving us more control and better performance within the renderer. 4) I just implemented support for playing with the Sega Dreamcast keyboard peripheral as a controller, partially as a flex, and partially because jnmartin kept complaining that he only had 3 controllers for testing... 🤣 4) I have taken my entire accelerated math and linear algebra library, SH4ZAM--which was born just after this port was originally released--back with me this time and am optimizing every freaking thing I can get my hands on with it. Every matrix multiplication, vector transform, memcpy-call, and scalar or trig routine is getting swapped out for the corresponding hand-optimized, meticulously benchmarked, and rigorously unit-tested equivalent within SH4ZAM, which now ships as part of kos-ports. As you can see from this series of direct hardware captures, overlaid with the terminal window which was capturing the FPS logging reports from my actual Sega Dreamcast, the performance is now SIGNIFICANTLY better than it was previously, and it already ran on-par or slightly better than the N64 original under most circumstances! Sooo many GAINZ to be had! 💪

Falco Girgis

12,615 Aufrufe • vor 11 Tagen

JNMARTIN HAS BROUGHT US CHRISTMAS EARLY THIS YEAR!!! His port of Star Fox 64 to the Sega Dreamcast is officially complete and was just released! Here's 9+ minutes of spliced direct hardware captures, featuring footage from every mission running on an actual physical DC at 480p! I have to say, the game feels incredibly smooth and responsive on the DC and controls extremely well. Also... as you can see, at twice the resolution with progressive scan, she looks gorgeous even with my cheap-ass HDMI cables and USB capture card. While jnmartin had the game up and running on DC within (literally) 2 days, there was an enormous amount of time and energy invested into faithfully recreating the experience graphically, implementing various bugfixes, and hunting for performance gainz... the man has never been satisfied with anything short of amazing with his ports, and it really shows. Like his Mario Kart 64 port, Star Fox 64 is also using my SH4ZAM library to hardware accelerate the math and linear algebra routines for DC; however, unlike last time, he's gotten so good at performance gainz that I barely did anything at all on that side, other than writing a few little inline SH4 ASM routines to cover some operations that I didn't already accelerate within the API... Suffice to say, though, that everything from the vertex TnL pipeline, to audio decoding, to gameplay-related trigonometry routines has been optimized for the SH4's FPU... jnmartin even got to bust out the SH4's MMU to accelerate the translation of of the segmented address scheme used by the game on N64 (which was apparently some suggested memory management model in the N64 docs) into the DC's virtual address space--which previously had to be done in software... So even more gainz! Sorry, though... but pretty sure this is why the game won't work in the Flycast emulator currently... whoops! 🤣 Shout-out to darcagent for contributing DREAMCAST RUMBLE PACK SUPPORT (among other things) to the release. Rumble support has historically been a pain-point within our KallistiOS homebrew DC SDK, as many 3rd party rumble packs are non-compliant and either do what they want with certain rumble commands or screw up the entire maple bus when they receive something they have decided not to fully implement... Great job getting that shit sorted out and tested with so many packs. All of my exotic (and cheapo) 3rd party rumble devices that I was able to test with seemed to work great! Finally, lets give SonicDcer a round of applause for being the lead dude behind the original N64 decompilation--as it was his original work that allowed for any of this to even be possible. He also continued to offer support and advice throughout the entire porting process, like a total chad. Here's the link to the official GitHub repo with instructions for building a Dreamcast image from a StarFox N64 ROM:

Falco Girgis

30,965 Aufrufe • vor 7 Monaten

Been optimizing my ASS OFF now that jnmartin has pushed all of his progress on his Star Fox 64 Sega Dreamcast port to a private GitHub repo to collaborate with a bunch of us DC devs before release. MAN this thing is HIGHLY optimized already... We're essentially running a high-level emulator for the N64's RSP coprocessor, doing graphics transforms, matrix math, and display list conversions not only on the main SH4 CPU, but also sitting atop a high-level OpenGL driver, in real-time. Not only that, but once again, we're doing all audio synthesis and mixing also on the main SH4 CPU, so this thing is doing a literal asston on the main CPU with what might seem like a relatively straightforward port. 99% of the time, everything runs flawlessly, but when you drop a bomb on a shitfest of enemies in a densely populated area, as with the N64 original, the FPS can dip momentarily. Here's a direct hardware capture of me testing a new SH4 optimized routine out for gainz on my Sega Dreamcast... this mofo is meant be used for one-off 3D vector transforms by a single matrix which has not been preloaded into the XMTRX FP register matrix back-bank. Rather than doing a full 4x4 load on the matrix just to do a single 4D transform via the FTRV instruction, we're simply peforming 3 3D dot products against a single 3D vector, allowing us to pipeline the loads, dot products, and store operations better than doing a load all at once followed by a transform, and we aren't wasting a lane on the FPU for a 0.0f W component!

Falco Girgis

36,911 Aufrufe • vor 7 Monaten

Been up almost the entire night making big audio gainz on the SH4 CPU for the Sega Dreamcast port of Mario Kart 64! It took about 3 of us pitching ideas and optimizing together, but holy shit, the 200Mhz SH4 is keeping up 99% of the time doing all synthesis and mixing in SW! What you're seeing is the first hardware capture of Mario Kart 64 running on the Sega Dreamcast with working audio playback... and trust me, it was not easy to get here! First of all, all of the audio signal processing for synthesizing individual notes from sampling instruments then mixing the SFX channels and the BGM together into a single audio stream is being done completely in SW on the DC's 200Mhz SH4 CPU--while it was done in HW on the N64. It is also carrying the whole T&L load for rendering with extra overhead per draw call due to us using our OpenGL 1.1 driver for graphics (GLdc). You can currently see a teeny little bit of slowdown at the beginning of the race when all 8 karts are bunched together, emitting their own SFX, which all has to get mixed in SW, bogging down the CPU... but don't worry, plenty of gainz left! On the left is a very interesting routine which proved to be incredibly gainzy when accelerated... So lets jump into what we did to this "aResampleImpl()" routine! 1) Compiler Optimizations: Everything is compiled with -Os by default to save RAM, because jnmartin is preloading almost everything up-front; however, we've created a "hot file" listing within the Makefile which allows us to build specific perf-critical translation units at with the -O3 optimization flag. 2) Manually managing the data cache: notice how many prefetches and barriers are in this routine in order to phenangle GCC's codegen to be somewhat similar to the ordering we've done things in C. Additionally, I've gone through hell in Compiler Explorer to ensure that all of the buffers used here can be prefetched in a timely manner, so that they're cache-resident before they're actually used. 3) SIMD: While we were discussing this routine in Discord, Paul noticed that the sample calculation was essentially performing a dot product of 2 4D vectors... which... GUESS WHAT. The SH4's FPU can do with a single instruction, FTRV, which is what "shz_dot8f()" provides an intrinsic around... The gainz were pretty substantial, despite having to convert back and forth between int16_t and floats. The new FP SIMD code can be enabled with "SH4_SIMD_GAINZ," otherwise the slow integer path is taken, so you can see the code difference. 4) Custom memcpy() routines: The builtin memcpy() routine that we're given in GCC15 from Newlib for the SuperH architecture is EXTREMELY slow... about as slow as copying byte-by-byte in ASM, so doing any sort of multi-byte loads and stores (provided adequately aligned buffers), even in C code, offers substantial gainz. Anyway, that's it for today! Stay tuned for more gainz!

Falco Girgis

15,547 Aufrufe • vor 11 Monaten

Got something totally different, but exceptionally badass today to share! Here is a bunch of direct hardware captures of the (F)ixed (F)unction and (F)ast (F)ourier (T)ransform (T)esting audio visualization demos, running on my Sega Dreamcast! This incredible piece of science, engineering, art, and music started off as a crazy idea to port a bunch of GPU-based, Shadertoy audiovisual demos to the Sega Dreamcast, to play with combined digital signal processing and rendering on legacy fixed-function hardware. As you can see from the video, the FFFFTT repo includes a wide array of different demos, each providing different kinds of visualizations, each featuring different types of signal transformations and analyses, with many of them also being interactive, all done in real-time! Not only that, but you ALSO can freaking pause the playback and analyze the signals in real-time... crazy! The final resulting FFFFTT demos are an epic full-stack conglomeration of Ray's raylib, providing the backing infrastructure and graphics framework, which sits atop our GLdc driver for rendering, using David Reid's miniaudio library for sound playback, with its FFT and vector algebra accelerated for the SH4 CPU using my SH4ZAM math library... all ontop of KallistiOS, running on the Sega Dreamcast! Congratulations to meisei4 for the fantastic accomplishments, and a heart-felt thanks from me for bringing everything together to make this happen! You just laid the framework for some epic audio-based gameplay mechanics and other crazy science experiments in the future for whole community!

Falco Girgis

12,566 Aufrufe • vor 17 Tagen