nesdev.org

How do I download this?

Oi Tiago!
Tem algum contato ou insta?

Apparently this video is getting some attention.

https://www.youtube.com/watch?v=J4LNM8b9Vg4

Also I looked at the first page and didn't see any rom download links so I'm confused. Also if you made an engine for the SNES it would be great if it were somehow available to the SNES homebrew community as a bases to make new SNES games. Thanks.

As the author stated he removed the download link because he's going to make a better version available when it's ready. So maybe stop asking for it here, do not create an account to do so.

The original demo is up on few places online, Retro RGB are linking to it in their article about it.

Oh cool. I hope he makes it even cooler than what it currently is!

I made an account to give a suggestion.

With emulation we can do a lot of things, such as speeding up the SNES CPU. But better yet, why not build this engine around one of the SNES enhancement chips such as the SA-1 chip?

For example the work by a guy named VitorSuperMarioWorld

Gradius III: https://www.youtube.com/watch?v=pmJyQiL9wYg

and

Contra III: https://www.youtube.com/watch?v=fTkKE1NURrY

and here's one last one https://www.youtube.com/watch?v=pfDtOvUP5Pg

Vase wrote: ↑Thu Aug 20, 2020 12:03 amBut better yet, why not build this engine around one of the SNES enhancement chips such as the SA-1 chip?

What's the fun in that? Proving that the SNES can handle Sonic just fine is this project's biggest selling point! The SNES is fairly capable as it is, there's no need to indiscriminately throw enhancement chips at it!

Plus that would limit it to emulators and sd2snes. No carts without mutilating existing games.

tokumaru wrote: ↑Thu Aug 20, 2020 12:14 am

Vase wrote: ↑Thu Aug 20, 2020 12:03 amBut better yet, why not build this engine around one of the SNES enhancement chips such as the SA-1 chip?

What's the fun in that? Proving that the SNES can handle Sonic just fine is this project's biggest selling point! The SNES is fairly capable as it is, there's no need to indiscriminately throw enhancement chips at it!

It's just my personal thing, cutting away all limitations that were there back in the day. More memory, more power, etc. Such as Sonic 3 AIR, Sonic Complete.

tokumaru wrote: ↑Thu Aug 20, 2020 12:14 am What's the fun in that? Proving that the SNES can handle Sonic just fine is this project's biggest selling point! The SNES is fairly capable as it is, there's no need to indiscriminately throw enhancement chips at it!

Yeah, and there's also the decade-strong myth that Sonic scrolls faster because of blast processing and the fast clock of the 68000 in the Megadrive - ignoring the scientific evidence that the scroll speed and CPU speed are totally unrelated.

Throwing an extention chip at this is exactly what they do DOT want to do.

Regarding the music I think it's silly to simulate FM-synthesis on the SNES because that's not what the system was designed for. Simply recording FM-synth audio and playing it back as a sample, that will be scaled with frequency and thus poorly represent the original sound at some far-reached octaves, is still by far close enough.

Do the sonic 1 demo could run with backgrounds at 512x224?, the only constraint should be to double the bandwidth rate i guess (64 Bytes per tile instead of 32 Bytes per tile).

The image still draws at 8:7 ratio screen, right?, any real wide screen mode would mean that the sprites in its field moves pixel to pixel, but encompass two pixels in the background field.

Señor Ventura wrote: ↑Thu Aug 20, 2020 2:05 amDo the sonic 1 demo could run with backgrounds at 512x224?

I've been contemplating something similar. The short answer is no. The slightly longer answer is yes. The practical answer is maybe.

Running in Mode 5 leaves you with only two BG layers, meaning the HUD would have to be sprites. No big deal; the MD version had to do that anyway because it only has two BG layers. But BG2 in Mode 5 is 2bpp. The far background in Sonic kinda looks like you could almost cram it into 2bpp with some careful subpalettizing, and maybe some windowing and/or sprite patches, but right now it's done with a 4bpp layer, and you only get one of those in Mode 5.

Using pseudo-hires mode is also a possibility. The only advantages I can think of are that you can trick the PPU into scrolling the foreground layer in half-dots instead of full dots, and you can leave the far background layer in normal resolution rather than having to convert it. But the far BG probably still has to be 2bpp (BG3 in Mode 1), because you need both BG1 and BG2 to build a pseudo-hires 4bpp layer.

Those collapsing cliffs have grass on top, and they're done with sprites, so the contrast between the high-resolution BG tiles and the low-resolution sprites could be obvious. I'm trying to think of a way to exploit how main/sub screen works in hires/pseudo-hires mode to fix this, but it may not be possible...

Aspect ratio is an important decision. Simply using the existing assets at high resolution may be feasible, but note that the use of 16-pixel-wide tiles imposes additional constraints that could cause problems, and going to pseudo-hires mode doesn't help this. Also, the graphics would look extremely skinny and the sense of speed would be diminished - unless you used interlace to do 512x448, which would double the tile data requirement for everything (including sprites) and that's just not going to fit.

Converting the assets to an aspect ratio of 8:5 to match the Mega Drive's display might be unmanageably complicated without modifying the level design. Converting them to an AR of 3:2 might be more feasible, particularly if incidentals such as the checkerboard pattern or the grass don't need to be at the correct AR. Still, there's not a lot of free VRAM even in the SNES version (which has a lot less sprite tile data stuffed into VRAM), and it could turn out that none of this actually works without making cuts or fiddling with the level design. Hard to say before trying...

the only constraint should be to double the bandwidth rate i guess (64 Bytes per tile instead of 32 Bytes per tile).

No, it turns out there is no increase in DMA load. In fact, sprites would probably be redrawn to be narrower, with the result that they would require less bandwidth and it would be easier to deal with large numbers of enemies.

Sonic puts all its BG tiles in VRAM at once. The only thing you need to update is the tilemap. In Mode 5 the tiles are always 16 pixels wide, so the scroll load doesn't get any worse (in the case where the graphics are not adjusted for aspect ratio, it would be better), and there's nothing else in the DMA schedule that depends on BG resolution.

EDIT: in the case where the graphics are not adjusted for aspect ratio, you could have more enemies on screen at the same time, which could require more DMA time per frame in the worst case to update them all. On the flip side, if they were narrower to match the aspect ratio, that could gain back a lot of the time due to having fewer tiles to transfer... Still, I think just squishing the game horizontally would look silly and isn't worth doing. Adjusting the graphics to the correct aspect ratio is the way to go IMO.

...

Maybe I should back up and ask you a question. What exactly do you mean by "bandwidth rate"?

The image still draws at 8:7 ratio screen, right?

The SNES doesn't draw an 8:7 screen. It draws a 64:49 screen (nominally) because the pixels (or "dots") also have an 8:7 aspect ratio. (This is for NTSC. PAL is more vertically squished because the scanlines are thinner, so the graphics look short and fat.)

In hi-res mode, the pixels (or "half-dots") have a 4:7 aspect ratio (NTSC), so the screen is still nominally 64:49.

It's just my personal thing, cutting away all limitations that were there back in the day. More memory, more power, etc. Such as Sonic 3 AIR, Sonic Complete.

If you want to use the SA-1, I think it's more suitable for a new game that takes full advantages of the Sa-1 power than a simple conversion like sonic wich can be done on a stock machine, mainly if you want to prove that the snes can do it.

Nikku4211 wrote: ↑Tue Aug 18, 2020 10:41 amBut the ARMv3 is slower than both of them, and even worse, it's ARMv3, rather than ARMv4T like the ARM7TDMI is and ARMv5TE like the ARM946E-S is. And how accurate is the DS at emulating the Mega Drive's sound anyway?

I will admit that I cannot say for certain how accurate the DS is at Mega Drive / Genesis audio emulation.

As for the DS's ARM CPUs, that unfortunately seems to be the lowest-end ARM device that a Mega Drive / Genesis emulator was developed for, so I don't really have much in the way of a better comparison.

It may at least be worth mentioning that SNES emulation was actually achieved on the GBA (admittedly not with the greatest accuracy, though the biggest issue was actually just a sprite layer incompatibility), however this was achieved by simply having no sound at all.



Even if emulating the Yamaha synthesizer directly is completely unfeasible, I couldn't help but at least throw the idea out there as another such "seemingly unthinkable" solution (the other being "Sonic on the SNES" in general) was just too blasphemous to leave stewing in my head (kind of like the admittedly slow DS emulator for the PSP).

I'm sorry, but why the heck are people suggesting a enhancement chip? The game is running like a dream.
I totally understand why Tiago taked off that early demo. So much non-sense complains.
Awesome work!