Hack S1Fixed: A successor to ReadySonic

I've been following this project on Github for a couple of weeks now, and I'm impressed with the huge amount of mods and fixes as well as the frequent updates! This will most certainly help me add some last minute bug fixes and optimizations to my own project. I just want to say a wholehearted thank you to both of you for all the work you've done, and to everyone else who contributed. This is a great asset for the whole hacking community.

 

A Z80 driver would offload a ton from the 68k, so I see absolutely no reason as to why you shouldn't. No real point in keeping it consistent with the vanilla version when you've already added a billion additions. And the type of people that I see using this certainly aren't going to be touching the sound driver for any reason.

 

If the clone driver will improve performance like Kilo said, then I say go for it. I just have one question - will the clone driver have MegaPCM 2 as well?

 

Oh, no no no no, you got that wrong, the Clone Driver runs on the 68k as well, it's explicitly said in its FAQs ("this is not a Z80 driver").

What you want is Flamewing's modified S&K driver, which indeed runs on the Z80, and is thus a good idea.

Yes, this is my way of saying "go for it, improve the performances with a better driver", but make sure that that driver is the correct one, hence why I won't vote in your current poll.

 

Oh well, I tried

 

And yet, you're not going with the option which would actually improve the performances. Then again, I don't hack anymore, so it's not like I have any use for this anyway. I'll refrain from making any more posts in this topic, but I wish you the best of luck with your project.

 

Let's be real, optimizing the sound driver is not going to improve performance of the engine much. Sonic 1's engine has multiple parts that could be improved, and the sound driver is actually quite minor in comparison. One major thing that comes to mind is stage drawing, in which pretty much everything is done during V-BLANK (or after H-BLANK if there's water near the top of the screen, which is done to prevent the water coloring from glitching out a bit due to potential timing issues), including recalculating VDP commands and block addresses for each block, and then sending them to VRAM. Of course, there's also stuff related to object processing and drawing as well.

Here's a visual example regarding the stage drawing code. I used the window plane to effectively make it a "performance meter":



Notice how the top of the meter doesn't shift when the foreground isn't moving, but does once new blocks are drawn as the camera is moving. This is because of how the stage drawing code is making the V-BLANK interrupt code last too long to where it goes into active scan before it's done (the performance meter is set up to show at the end of the V-BLANK interrupt code, and to disappear at the end of a single game update). Hell, I even straight up disabled SMPS from running in my test, and the results were only slightly less egregious.

And of course, once you start loading in a bunch of objects at once, the end of the meter goes down pretty low:



So, no, if you are looking to improve performance, the sound driver is not where you should be looking at.

HOWEVER, let's not be mistaken. When it comes to stuff like this, ease of use is more important, and in regards to game development, also game design and general stability. Obviously, making sure your game isn't lagging all the time is important, but if it works well enough, then what's the problem? And what if you did need to use Mega PCM 2 for its features? You can't just also add SMPS Z80 on top of it due to the fickle nature of manually streaming PCM data to the YM2612's DAC, while also ensuring good enough audio quality (and good luck trying to do software mixing of multiple PCM channels with all of that in mind). So, a m68k driver will have to do, and that's fine, IMO. I think a pure Z80 driver would be more useful in regards to saving RAM space and saving time during V-BLANK for more timing critical things (like graphical raster effects done mid-frame, especially if it starts towards the top of the screen).

Honestly, just speaking in general here, if you want to make something that's super focused on optimizing performance, you might as well just write a brand new engine from scratch. Even then, no matter what, there will be cases where sacrifices will need to be made, depending on the features that are desired. Plus, there are cases where attempting to improve the performance of a piece of code would make it harder to work with, and even bloat it (i.e. unrolling loops, duplicating code, etc.). You must find a good balance.

 

I guess when I said offloading from the 68k I should have also mentioned that I was referring to the RAM footprint too. Sonic 1's driver uses nearly 1.5kb of 68k RAM, and on a console with only 64kb of RAM it's helpful to squeeze out as much of that as you can. So I still think a Z80 driver would be the better route here, personally. The performance boost would be negligible, but still a bonus too. Granted, I don't know what users of this project would use the RAM for, so maybe MegaPCM is more useful to them...

 

Now we need Ristar in S3K engine. :P

in all seriousness, this is fantastic and will surely make an excellent basis for so many hacks.

On a subjective note not so much about this hack, but rather Sonic 1’s design in general, is that Sonic 1’s level design isn’t very friendly with the lack of speed caps in 3K, and the SCD style lack of a roll-jump lock is throwing me off. I’ve also been playing the prototype a little bit and TBH it feels a bit easier in some of the tighter spots compared to the final, even if it was largely the result of a lot of physics quirks such as losing speed on objects and the lower jump velocity, and in some cases the lack of velocity culling on ceilings.

 

I will say that freeing up the RAM taken up by a m68k driver would make implementing things like a ring manager or better stage drawing system a lot easier, so in a way, a Z80 driver would open up the doors to better performance... but the driver itself is not what's causing performance issues.

Even then, if you use something like Project Two-Eight, then RAM area 0xFF8000-0xFFA3FF will already be freed up for you by default, considering that there's still a maximum of 256 chunks, and thus the chunk data buffer will only ever go up to 0x8000 bytes of usage instead of the 0xA400 that Sonic 1 allocates. That's a lot more RAM freed up compared to switching drivers! You could even implement something like Kosinski Moduled for much faster graphics loading (one decompressed module is 0x1000 bytes long), AND still have plenty of RAM left for other stuff! From what I see, S1Fixed is based on Two-Eight, so it already has that extra RAM ready to go.

 

S1 Fixed also has S2/3's ring manager implemented. Where that's slotted into in RAM I'm not sure, but it's there. So using a Z80 driver would allow for just free RAM for whatever else the user wants.

 

Oh, yeah, I see that! Cool! I did count the minimum free RAM, and I only managed to count around 0xDC4 bytes, so that extra RAM space from switching to a Z80 driver would definitely be useful if Kosinski Moduled were to be implemented. Well, at least, that would be the easiest thing to do. But, ultimately, RetroKoH technically doesn't need to do that, as what he has right now seems to work well enough, considering his goals for this project, and that's really all that matters. 0xDC4 bytes is still plenty, too.

 

There's always Dual PCM - FlexEd for two PCM channel support if you keep the 68k driver

On a serious note, you'll do fine implementing a Z80 driver, most people want the sound driver out the way and unbreakable, so a Z80 isolated driver seems to me to be the best route if you're making an easy to use, quick, pre-setup disassembly of Sonic 1 for people to work on.