First Marvel Super Heroes, Now Samurai Shodown's Earthquake Lands On Sega Genesis

Very impressive!

It's similar to this on SNES:
https://x.com/MaxwelOlinda1/status/1689399746438340608?s=20

Amazing what you can do on these consoles when pushed.

Very interesting. Of course, the one advantage now is not having to worry about ROM size. Still, I'm surprised to see Juggernaut and Hulk look so good and big on the Genesis/Mega Drive. In a way, the Marvel sprites are a good fit for the limited color of the system, because the sprites are drawn to be simple and clean with minimal, but effective, shading. That helps lend the game a comic book or cartoon look, but also means the sprites don't need a ton of colors. With the characters as big as they are, I do wonder how close this would be to the overall and horizontal sprite limit. I also wonder if they'd run into palette issues with other characters. I'd like to see if they go further with this, just to see what's possible as it is already impressive.

@BobaTheFett It says in the very first paragraph that it's running on stock hardware, not via emulation

Pyron is a wizard and totally legit. Can't wait to see where this goes, almost purely for the sheer spectacle of it.

@AJB83 completely agree with you. these guys have a legit history in the rom hacking scene and have proven many times over they are capable of awesome stuff.

@bobathefett a lack of understanding on how to accomplish something doesn’t mean someone smarter than you hasn’t figured it out…

@bobathefett Gabriel Pyron is a scene legend, and you can go out and download his stuff and run them all on stock hardware. He's been doing these large sprite tests for a while now. Seriously, you should educate yourself and actually follow his work and the scene if you're interested. Blanket statements like 'it can't be done' will make you look a little silly when it comes out working on real hardware.

Also, it's not 'clearly running with emulation', because he's got video editing software in the background of that vid, likely capturing from his own hardware.

@bobathefett My mistake on the video editing software thing.

I hope you'll also eat humble pie when you're proven wrong.

@bobathefett Sigh.

@bobathefett So you're discounting all the additional processors NES carts had which ran on the original hardware. SuperFX and SuperFX2, all which ran on and enhanced the original hardware. Right.

This will only require a flashcart because it's the easiest way to run rom files on legit hardware. Just because it's new technology doesn't discount it. This IS playing on original hardware. Using these carts to play roms on original hardware is legit - the hardware doesn't know any different.

Anyways, agree to disagree or whatever, I don't care.

I said hardware a lot.

@BobaTheFett Yes, I basically agree with you.

I don't think people just commenting on the articles necessarily need to be held to such a standard, but it would be great if the articles were as transparent as they can be with any of the details that might be relevant in such cases. I know the guys writing them must be very professional and passionate about retro gaming, and I expect they would want everyone to know that what they are posting about is not unintentionally obfuscating or misleading in some way, so hopefully they can include that kind of stuff in the future, just to give everyone a full context.

Either way though, still cool examples of system-pushing fighting games there.

@BobaTheFett
No "flash cart" can give the MD, let alone SNES/PCE/SMS, more vram. It's impossible. That's a lack of understanding of what VRAM is on your part. And yeah, the largest hardware sprites are 32x32 max.. larger sprites than hardware sprites.. are meta sprites (which how a lot of snes/md/pce/sms/nes games get around the hardware limit.. pretty basic stuff). Developers have been making meta-sprites for generations (including ALL NES games doing this). And quite a bit of the other stuff you've posted are just inaccurate or a complete lack of hardware understanding. This demo is written in C, not even assembly. It doesn't use any special chips. It literally is pretty simple in design - have the storage space for the frames, fit the frame uploads in the allotted vblank bandwidth time, and have the room in vram for it. This doesn't need any special chips for assistance because there's nothing they can offer for this situation. And I can guarantee you this runs on the real hardware, "stock" hardware. No SegaCD or 32x involved here. If you open up the tweet, Pyron even says as much (he always shows off stuff running on real hardware via his CRT).

Calling out Pyron as just a palette swapper? That's quite a bit of an insult. One, he's not the developer/programmer for this, but both people involved are known in the scene and have been demoing stuff on the MD for a couple of years now. You'd know this from following the MD homebrew scene.

@BobaTheFett It doesn't add any more vram. Vram. Video ram. Specialized ram that is attached directly to the VDP, and cannot be accessed either by the CPU or the cart, or anything else beside the VDP. That means nothing on the Everdrive can connect or expand it.
So no, it doesn't add additional vram. There are a few different groups of ram on the MegaCD... none of them are vram. They're just ram. Again, vram has a very special and particular purpose, and no amount of any outside ram can substitute it. I mean, don't reply. It'll save the embarrassment on your side. But I know these things because I actually code for these retro systems. But sure, I lack mental capacity. smh

I love the fact that you think you automatically get twice the processing power from Everdrive simply by enabling MegaCD power. If only.

Based on the track record of Pyron, it was a smarter bet to believe what he was saying. I'm glad he has come out to explain it. If I could understand Brazilian Portuguese(which I've been around a lot, but not enough to figure out anything but certain basic words) I'd watch the whole thing. But he does some demonstrations and has some visual aids that are helpful. Those big sprite objects like Earthquake and Juggernaut use roughly 25 hardware sprites. It also showed how many horizontal and vertical pixels the characters are. Late in the video, he shows Juggernaut attacking and his arm exceeds the horizontal sprite limit and you can see the sprite flicker, which is something I expected as I figured two Juggernauts would be right on that line limit of 20 sprites for 320-wide mode, or 16 is it's using 256. I think it would be difficult to scale up into a full game. Even if that is possible to some level, it would have been impossible back in the day when cart sizes were a huge factor. Great to see more about this.

Of course, @AJB83, when it looks just a little too good to be 100% entirely true:

https://www.youtube.com/watch?v=9yvjGcdmhZc&lc=UgxEhGyd5YhNkq-g0zV4AaABAg (look at the comment this links to, which should be at the top)

Still, if we ignore the inevitable sprite flicker that's accidently been hidden here, it's basically showing exactly what's possible on Genesis.

Either way, these Earthquake demos on both Genesis and SNES are very impressive.