TiagoSC, the same guy from Genesis MegaMan X, ported Green Hill Zone to the SNES. It's really impressive to see Sonic running perfectly in the SNES; worthy mentioning.
The original topic(?) and ROM It's quite clever... as long as you ignore the fact it's the wrong aspect ratio. There are a lot of circular things in Sonic the Hedgehog. Also I'm not sure there was any doubt that the SNES could run Sonic 1. It just didn't.
This is a very cool port. TiagoSC has been making further improvements since the last publicly released rom. Sonic previously only dropped a maximum of 8 rings when hit, since upped to 32 like the Genesis version. Even when next to the spike bridge and swinging platform. No, there have always been heated debates on whether Sonic 1 could run on SNES. Here's an example thread containing quite a number of replies (including yourself) saying it's likely too slow and requires special chips- https://forums.sonicretro.org/index.php?threads/porting-any-sonic-megadrive-game-to-snes.33501/
There is some debate to had with how this handles a lot of the more complex parts of the engine, such as tile/block/chunk format, it may simplify that, or the fact that in the end, Sonic 1's engine is really unoptimal. With more RAM and not using the main processor for audio, you could probably get comparable results at a much slower processor. However, you will also have to use more ROM and RAM to accomplish the same things, not to mention of a very much customized engine. Still though, its really impressive someone was able to port this over. I'll have to have a closer look, but I wouldn't be surprised if most of the work went into optimizing the code its based on for the SNES, because you could really make it much better (and less laggier!) with just that alone. It's really cool to see stuff like this, though
Oooh my younger self mentions aspect ratio too. Okay maybe I'm a bit torn then - I seem to be pretty sure it couldn't happen in 2014, and yet I'm not surprised in 2020. Maybe my brain was skewed more towards Sonic 2 and 3.
...but, but...how did it do this without the full power of BLAST PROCESSING? I feel like I've been lied to my whole childhood! :O
It does surprise me that nobody has tried porting Super Mario World to the Mega Drive - that game's been ripped apart (and then put back together as something different).
Getting pretty sick of these youtubers throwing around the idea that blast processing existed and its the possibility of showing more colors on the mega drive. So a coder found a way to push high color images onto the screen? What gives them the right to assume that's the blast processing that was being advertised?
The fact that we have the word of the guy who invented the word to back it up. As presented in our video. "Sadly I have to take responsibility for that ghastly phrase. Marty Franz [Sega technical director] discovered that you could do this nifty trick with the display system by hooking the scan line interrupt and firing off a DMA at just the right time. The result was that you could effectively jam data onto the graphics chip while the scan line was being drawn – which meant you could drive the DAC's with 8 bits per pixel. Assuming you could get the timing just right you could draw 256 color static images. There were all kinds of subtleties to the timing and the trick didn't work reliably on all iterations of the hardware but you could do it and it was cool as heck. So during the runup to the western launch of Sega-CD the PR guys interviewed me about what made the platform interesting from a technical standpoint and somewhere in there I mentioned the fact that you could just "blast data into the DAC's" Well they loved the word 'blast' and the next thing I knew Blast Processing was born. Oy." We're not "Youtubers" btw. I've been part of this community since 97. Regarding this SNES demo, it seems the guy is doing no tile decompression on the fly as the math is too expensive. He's squeezing everything into VRAM. I would guess that's why there is no boss or end of act sign posts or such, nothing left over to decompress the assets on the fly. I would assume he'd have much more trouble on more demanding levels.
Looking at that thread, the very last post got me a bit. I mean, it was as if TiagoSC read that and accepted the challenge. Even the part where you yourself mentioned it'd be neat to see with some added visual enhancements, which if you look closely he did manage to do although very subtly. (and even fixed Sonic's shoe error when bouncing off of springs. lol)
That's not the blast processing that was being advertised. The guy didn't invent the word. he said "blast data into the DAC's". The advertisers came up with 'Blast Processing'. ' "What does blast processing do?" - Proceed to show sonic running fast, ecco moving fast, etc. '. It was about some magic processor that was able to make games perform faster. None of the games in the advertisements used the special high color dac blasting you're talking about. So it's not the advertised blast processing. It's misleading to tell people that blast processing existed all this time. Blasting data into the DAC exists. Blast Processing simply doesn't exist and is a miscommunication. As you've obviously put in an exhausting amount of energy on this, i doubt you'll agree. But we're on a forum where the truth should be strongly sought after, regardless of how mundane and picky it may seem.
Or, "blast processing" was just a more marketable term they coined with for the "blasting data into the DAC" process they were told of, and the ads just misattributed the games they were trying to sell to it, either due to technical ignorance or as a marketing ploy (probably both).
To be fair, Super Mario World appears very basic by comparison to Sonic The Hedgehog, and given remakes of Starfox, Zero G, and Wolfenstein on the Mega Drive by GASEGA68k, I would say it's more of a factor of "would you really want to?". Not knocking SMW as a game, I enjoyed playing it, but it's not exactly a challenge, and I wouldn't think it'd be worth wasting time on it unless you want publicity, thinking about it, it is just a simple 2D game and the special effects (which are in short supply) can be achieved with relative ease. The compression used for Art for Sonic 1 is extremely demanding, even for the 68k. It's a nybble RLE based system, with an entropy/Huffman tree, with XOR capabilities. The nybble part is already a slow aspect right there, and the entropy data is stored in an inconvenient way where the 68k has to waste time rearranging the data before it can use it. Sonic games using this format usually only decompress 3 tiles per frame during a level. There are other compressions though, and later games moved over to LZSS based algorithms which are much faster to decompress and thus more tiles could be produced. I would suspect the SNES would be capable of real-time decompression if it were LZSS based, even if it only decompressed 3 tiles per frame to match the original game.
i think if the person who ported this wanted to take this further he really needs to check out the SA-1 pack for SMW over at SMWCentral! Features: Increases the maximum amount of sprites *on screen* to 22. Increases the maximum amount of sprites *per level* to 255. Moves the sprite processing code to SA-1, making all sprites gets processed 4 times as normally Optimizes some routines to make the level loading faster. Moves almost all non standard sprites, such as shooters, generators, cluster, extended, minor extended, bounce, score and smoke to SA-1 CPU. Moves the block/map16 handling to SA-1 CPU. Moves almost all overworld code to SA-1 side, leaving minimal CPU usage on overworld. All other SA-1 features like 6 and 8MB support, 10.74 MHz CPU, Character Conversion DMA, fast RAM, etc I mean this is from the SMW hack read me and I am not 100% sure this would all translate to the Sonic 1 Source but most of it looks like it could apply?
I love Mario World (first real video game I ever played and owned), but yeah it's extremely simple and would almost certainly work fine on the Genesis. The gameplay and physics also don't differ much from Mario 3, which was an NES game. World also rarely uses more than 2 bg layers and has a pretty basic color palette (even the crappy Mario World 64 Genesis bootleg seems faithful to the colors). There are only a couple of levels that use 3 background layers. Level 1-4 uses a 3rd for water. However, it's a dithered checkerboard mesh and has only 1 color below the surface. The palette trick in Sonic's water levels would eliminate the need for a 3rd layer and would look much better. As far as I know, the only levels that use real transparency are the ghost houses. Those are the only elements that might not come out 100% intact, but I dunno. All but two bosses use mode7. But it's a simplistic usage and the CPU could probably handle them. Mega Turrican has a handful of software rotated sprites, heck i've even seen smooth sprite rotation on SNES without special chips (from a homebrew Gunstar-like demo called Alisha's Adventure). Probably not a huge roadblock.
Is there a good SMW disassembly? I've given a Mega Drive port some thought in the past, and the only things that can't be done easily are: - Rotating bosses/backgrounds. - Ghost house transparency. - Keyhole transition. - Pixellated transition. - Music/sfx might not be perfect. And unfortunately, the name "Mega Mario World" is already used by a hack.
Does Marble Garden's Robotnik boss in Sonic 3 use real time software scaling, or is it just a sprite animation?
It might be comparatively easy in 2020 but it's not been attempted in 30 years (ignoring Super Mario World 64 of course). I'd have thought it would have happened by now, even if it's just to continue old console wars. There's a bit of sprite scaling for the bosses too. IIRC it uses mode 7 for these effects, and as a consequence there aren't any real backgrounds during these fights. Mind you the Koopa Kids are all the wrong colours in SMW too. Plenty of room for improvement across the board, come to think of it.