Discussion in 'Fangaming Discussion' started by 360, Apr 7, 2019.
This is perfect! Maybe we might mimic the ROM hacks using this.
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?
Is it possible to port S3AIR to EmuElec? I know the Sonic 1/2/CD ports are on 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.
EmuElec is basically what many SBC gaming devices use to run various emulators and ports.
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.
Separate names with a comma.