That's a very nice improvement. Would you mind if I adapted the core ideas and re-implemented them in the main repo? I wouldn't want to straight-out copy the code, even with your approval, for the reasons I layed out in the announcement post above - hence the re-implementation approach. I'd think the important parts are (correct me if I'm wrong): - Using a high resolution timer instead of SDL_GetTicks for the frame timing - A more precise Sleep, namely the one provided by the Framepacer class Both is something the main project would definitely benefit from. My guess would be it's especially relevant with v-sync disabled and the frame cap active?
Glad you found a way to make open source work for you, looks like it's paying off already! Just wanted to chime in and thank you for the Android version, I installed it recently and I'm having a ton of fun with it. I don't play a lot of games on my phone but the classic Sonic games work just fine with a touchscreen and when I saw I could copy over my mods folder from the PC install I was sold, it's great to chew through a playthrough a few minutes at a time. As someone who does and will play this a lot, I felt like I had to share the idea I just had. It would be cool if the game could keep track of your best time/ring/score for a stage during regular gameplay, with an optional notifier if you beat your best records at the score tally. I don't mess with time attack mode that much myself but it would be cool to have a personal inventive to play better in the main mode. Just thought I'd toss it out there!
Go on sunshine! Reimplement if you wish, it's all out there :P The whole point of this after all is to benefit the community as a whole. I saw some people mention the frame pacing could be better and I just went out and did what I could. On the licensing topic in general, I thought I'd ask something though. Can't you just ask contributors to MIT license their changes? I feel that would make it easier for yourself rather than having to replicate any potential engine changes anyone out there makes in the future; and MIT license more-less allows you to do anything you want provided you display the copyright notice. It's not a big deal either way though, because open source contributions are generally very few and far between (from personal experience), but I thought I'd ask anyway. ======= Yeah, the ones you listed are the important parts :P For Windows however, using the timer functions is also very important because by default, unless overwritten Sleep has a granularity of around 15ms; which is really high (too high for us). Other platforms usually have it lower so it's not as much of an issue. Although `NtSetTimerResolution` and `NtQueryTimerResolution` are technically internal APIs, as mentioned in the code itself, they are commonly used by people; even Chrome (the browser) uses those.
Thanks a lot! I've just pushed the changes to the public repo. There's some differences in how the code is set up, like the precise sleep implementation is in the PlatformFunctions class now, and I reworked the already existing HighResolutionTimer so it fulfill the timing functionality. I think in regards of the frame pacing itself, it's doing practically the same thing as the implementation in your fork (hoping that I didn't overlook something important there). Yeah, that's an interesting idea. Next time. :D I tried going with the lowest resolution / highest granularity that NtQueryTimerResolution returned - and that was indeed something around 15ms. When passing that as parameter to NtSetTimerResolution, it had a serious impact on the frame rate and pacing in general. Curiously, I never had any such issues before, so I'd guess the default granularity that Windows applies can vary from machine to machine... Good to now have a solution for that problem.
I'm guessing there isn't a possibility to add an interpolation system similar to the Doom source ports in order to run the game at higher framerates, is there?
Actually yes, and it's already partially implemented in the public sources ("mUsingFrameInterpolation" in the VideoOut class). The approach here is relatively straightforward: track movement of sprites and changes in plane scrolling across frames, and then do some interpolation to generate intermediate frames. This does work quite well most of the time, but there's cases where more work is needed to avoid glitches and stuttering. For instance, many backgrounds don't just scroll (possibly with parallax effects), but also update the drawn patterns in some regions to simulate an additional layer of background scrolling - an example of this is the MHZ background, where the distant hills and trees are scrolling slower than the background's large trees. This is something that would need to be updated for each intermediate frame, in addition to interpolation, to get a clean result. So this is still work-in-progress. I have no idea what that is, but from the first look I'd guess it's possible - if there's someone who feels like porting it over.
Shame no-one seems to want to port Sonic 3 AIR to Vita. Then again, no-one seems to want to port the latest updates of the 1/2/CD decomps to Vita either, with one guy giving all kinds of reasons why he wouldn't update his ports that the RSDK Discord called bs on when I showed them.
Oh that's incredible, I can't wait to see it in action, being able to play Sonic 3 at 144FPS would be incredible considering how rare it is for Sonic games to work properly at higher framerates.
Can Sonic 3 AIR be ported to the PlayStation Classic? I'm giving my nieces and nephews modded PSCs (running Project Eris) for Christmas and somewhere down the road I'd love to add more games and I know one of my nieces LOVE Sonic (I got my nieces and nephews Genesis Minis last year). IIRC they also have phones and/or tablets so if not it might not be much of an issue if S3AIR can't be ported to PSC.
A lengthy post on the Sonic 3 & Knuckles ROM situation You've probably heard, Sega is going to delist Sonic 3 & Knuckles on Steam quite soon. Which is a huge problem for Sonic 3 A.I.R., as buying that has been an easy way to get a Sonic 3 & Knuckles ROM in a legally safe way. It's the method I could always recommend players to get in order to run Sonic 3 A.I.R. With the delisting on May 20th, this source for the ROM will disappear. That's actually not much of an issue for everyone who already owns S3&K on Steam, so all current S3AIR players are unaffected. But new players won't be able to get the ROM this way any more - and consequently can't get S3AIR running, unless resigning to legally grey area ways of getting a ROM. Spoiler: Alternatives? As a side note: There's a quite impressive list of methods put together by Tyranger on how to get a working S3&K ROM by dumping it or extracting it from different collections. However... let's be real, they aren't really feasible for the average player. How could a solution to the ROM problem look like, one that works similarly well as using the S3&K Steam ROM? Before we get into this, some background information... Why is a ROM needed in the first place? This is about the technical reasons, why S3AIR even needs the S3&K ROM. You see, the core game logic of S3AIR is implemented via a lot of script code that closely mirrors the functionality of the original Sonic 3 & Knuckles. It's in fact based on a direct port of the 68K code from the S3&K ROM, just translated into scripts to be easier to read and modify. This also means that most data used (e.g. graphics, emulated music, and all kinds of data lookup tables) is read directly from the ROM, in the very same way that the original game code does it. Because of this, it's the obvious choice to use the ROM itself as data source, instead of trying to extract the data from there, process it to different formats, make it separate files, or similar. Doing that would be an immense amount of work, without any direct benefit. Why not include the ROM in S3AIR's data? A possible solution could be to simply include the ROM into S3AIR's data, right? Well, if you do it that way, like having the ROM file directly in the game data - that's an unauthorized distribution of the game, i.e. piracy. Maybe it could be done by obfuscating the ROM is some way, so it's not too easy to extract it again using the S3AIR source code and data. But that still leaves a problem, related to how Sega would regard such a practise. Because let's not forget, they are a commercial organisation, with an obligation to generate income. And S3AIR could be regarded as a free alternative to a product that they are actively selling on Steam - that product has been S3&K all that time, and Sonic Origins is going to take that same place in the future. That's why S3AIR has always required you to deliver the S3&K ROM by yourself, in most cases by buying S3&K on Steam and giving Sega those few bucks. This way, they don't lose any money from the existence of S3AIR, but even receive a small extra income. Everyone wins.* Spoiler: * * Okay, I know it's a bit cynical to say this, as you reading this are the ones who has to pay. I apologize for that. The point I'm trying to make is that I firmly believe this way of requiring a small obulus helps avoiding trouble with Sega. It might not seem like a real possibility, with Sega usually being cool with fan games, but I wouldn't like to take any risk here. Not if the very existence of S3AIR is on the table. The consequence is, S3AIR will continue to require some kind of "key" to get it running, something that makes Sega still benefit from S3AIR, in the same way that the S3&K ROM served as a key to unlock the game up until now. I'd even say, this gets more important in the future, given that S3AIR is sort of a direct competitor to the Sonic 3 & Knuckles remaster that is part of Origins. Which leads us to the question... what could that key be? Why not use Sonic Origins as key? Well, I guess that would be the most obvious choice. And I seriously considered this, but in the end, there's a few problems with it: Sonic Origins is not available yet, and won't be until June 23th. That leaves us with a gap of more than a month, in which there's no good option to get S3AIR running. At the moment, it's completely unclear how a check for an Sonic Origins installation is going to work. Probably a check for a particular file in there that hopefully won't change when Origins receives updates. In any case, this check can only be implemented after the release of Origins, which only adds to the gap mentioned above. The price point of Sonic Origins is noticably higher than that of S3&K. Which is problematic as it essentially locks out a part of the (future) S3AIR player base, namely young players especially in low-income countries, who just can't effort paying $40. Judging from the system requirements on Steam, Sonic Origins is not going to be released on Mac and Linux, only on Windows. So mac and Linux users would need to install Windows just to get Origins? So unfortunately, Origins does not work well as the requirement for S3AIR. But there's another option, with none of the problems above. Let's use a different Sonic game ROM Sonic 3 & Knuckles is going to be delisted, same for Sonic 1, 2 and CD. But that still leaves some other Sonic games that continue to be easily available via SEGA Mega Drive & Genesis Classics on Steam. I'm thinking of Sonic 3D specifically - a.k.a. Sonic 3D Blast, or Sonic 3D: Flickies' Island. Now that approach also has a little problem (actually one would likely be true for the Sonic Origins solution discussed above as well): The ROMs of other games than S3&K don't contain the data needed by S3AIR. So where to get that data from? Generally speaking, how about a process that allows for creating one ROM (= S3&K) file from another (= Sonic 3D), using a "difference file" somewhere in the S3AIR game installation that stores all needed information needed to construct the output ROM? In our case, you'd buy the Sonic 3D ROM on Steam - yes, that exact version of the ROM, not the Director's Cut or any other hacks. You put in that ROM into the process and it creates the S3&K ROM. That "process" is part of the S3AIR logic that checks the ROM you give it, so in the end, it doesn't matter whether you pass in the S3&K ROM or the Sonic 3D ROM - the result is the same, S3AIR can launch and has all needed data. If done correctly, neither that process algorithm nor the difference file store any data of the S3&K ROM, and are completely useless without the exact right Sonic 3D ROM as an input. Spoiler: Technical details The algorithm for the difference file is actually a very simple one: It's just bit-wise XORing together the difference file and the Sonic 3D ROM. So the difference file simply tells us which bits to flip and which bits to keep like they are in the Sonic 3D ROM. The difference file itself is built by XORing both ROMs together. Both are the same size of 4 MB, so all of this works out fine. Edit: This is actually nothing else as a "XOR cipher", where the difference file is the encrypted S3&K ROM, using the Sonic 3D ROM's entire content as the key for decryption. Let's go through the checklist for that solution: S3AIR gets all the data it needs from the ROM you put in, no matter if it's the S3&K or Sonic 3D. S3AIR itself still does not contain any data from the S3&K ROM. Sonic 3D on Steam is very comparable to S3&K in terms of pricing, which should make it a good replacement in that regard. Only thing different for new players is that they need to buy Sonic 3D on Steam when S3&K is delisted. Spoiler: That means you can get a ROM for free? Maybe a little nitpick remains: Can you use S3AIR to build a S3&K ROM to use in an emulator, if you only legally own a Sonic 3D ROM? Wouldn't this be some convoluted way of piracy? The answer is: No, you can't. S3AIR won't save the resulting ROM to the disk, all operations are done only in RAM. And even there, what's constructed is actually not the full S3&K ROM, but has blanked out a portion of the game code. This way, the constructed ROM can't be used to play S3&K in an emulator - it would just crash away or simply do nothing at all. For S3AIR, all of this is not a problem, as these parts of the ROM are not needed at all. So here we go, that's the plan for the future of Sonic 3 A.I.R. Or at least the one that so far seems the least bad one. It's not necessarily the final decision yet, but right now, I honestly can't think of any solution that would work better.
I do like this to a degree, though I do think that when Origins releases you could make that a key as well.
With all due respect, I don't believe it is your responsibility how the user acquires an S3K rom, before or after its delisting. There exists plenty of source ports for games that are unavailable on modern digital storefronts, and none of them that I've seen are concerned about this issue. Just put up a disclaimer saying you are expected to have your own rom and that absolutely zero support will be provided on how one can go about obtaining one. There is also the issue that you're still distributing S3K code this way and that alone would be legal grounds for Sega to shut down the project. Even if the user can't access S3K without owning S3D, you're still providing a way for them to acquire S3K without paying for it specifically.
Yes, this is a serious concern, I agree. So far, nothing has been decided on the matter yet. I'd ask everyone to view the Sonic 3D idea as just that - an idea open for discussion. It's not at all settled that this is the way to go in the end.
From my (admittedly limited) understanding, there is a precedent that you cannot fully copyright code, and a clean-room reverse engineering effort is completely legal. This is why the Mario 64 PC port still stands on GitHub, and why companies instead patent implementations in the USA. Please correct me if I'm wrong, but from my understanding of Eukaryot's post, S3AIR is a reimplementation of a port derived from a S3&K decompilation. The original ROM is required for anything that would be illegal to distribute. The most questionable thing in this chain is the original decompilation (although that then raises the question of ownership of physical media). Of course, the best way to confirm this is to hire a lawyer specializing in the area and asking them for their opinion, but that's expensive Edit: Whoops, no clue how I mixed that up. Patent =/= trademark
Since S3AIR would be recreating most of the S3K data from the S3D ROM every time you run it, wouldn't that prolong its startup time?
I don't imagine it would by any noticeable amount. XOR is not the least bit computationally expensive, and these ROMs are only a few megabytes in size.
