pixel jitter
JanGunheD opened this issue · comments
Some games, especially Super Hang On, show pixel jittering.
Looking closely, all pixels jitter a tiny bit around. This becomes especially apparent when combined with filters like shadow masks.
A similar thing happened with the first split versions of the Xain'd Sleena core (just in case that might help).
Using vsync_adjust=2 (just in case this only happens in this low latency mode).
According to Jotego, this is a problem in the framework if I understand correctly:
jotego/jtcores#226
I think that the problem comes from the ASCAL operating at an unrelated clock speed (is it 100MHz?) to the core pixel clock. MiSTer framework then re-samples the video signal without any proper filtering.
The current Super Hang On core has some kind of timing issue with HDMI. The OSD is also affected which is generated after the scaler.
All other cores work perfectly with the scaler so I don't understand why you are blaming the scaler.
HV integer scaled HDMI capture at 1080p(720p has the same issue):
I think that the problem comes from the ASCAL operating at an unrelated clock speed (is it 100MHz?) to the core pixel clock. MiSTer framework then re-samples the video signal without any proper filtering.
Completely wrong assumption. Scaler doesn't resample video signal by 100MHz.
Issues in Template should be posted ONLY if it affects many cores as some common issue. This issue doesn't happen on open source cores from MiSTer-devel.
Completely wrong assumption. Scaler doesn't resample video signal by 100MHz.
But it resamples the video signal, doesn't it?
Issues in Template should be posted ONLY if it affects many cores as some common issue. This issue doesn't happen on open source cores from MiSTer-devel.
I have seen it in cores whose pixel clock is not 6MHz. I don't know the details of the different clocks and timing considerations taken in the template. I may be doing something wrong. Maybe you are expecting the pixel clock enable to be centered at the pixel? If there are some design guidelines for cores, please kindly link to them.
But it resamples the video signal, doesn't it?
It saves pixels into memory at core's pixel clock then read it back at HDMI clock and interpolates according to selected video filter.
I have seen it in cores whose pixel clock is not 6MHz. I don't know the details of the different clocks and timing considerations taken in the template. I may be doing something wrong. Maybe you are expecting the pixel clock enable to be centered at the pixel? If there are some design guidelines for cores, please kindly link to them.
Issue shown on screenshots above has nothing to do with core's pixel clock or clock enable. It's happening because HDMI timings didn't meet requirements. Did you check TimeQuest Timing Analyzer Summary - is there any negative slacks?
It may be due to design of core which may have hard to route paths so it affected HDMI part as well. Or may be some synthesizer/router settings are wrong. May be constraints are wrong. You don't use quartus IDE to compile, so it's possible some constraints are missing or MiSTer framework has modifications lead to that issue.
The current Super Hang On core has some kind of timing issue with HDMI. The OSD is also affected which is generated after the scaler.
Yes, this same exact issue occurred with outrun over HDMI for quite some time, I haven't tried the latest update from Jotego for that though. That core was the first time I had ever seen this issue. Years of arcade cores and I hadn't seen the problem before. I understand that Outrun and Super Hang-On have their own framebuffers in original hardware, maybe there is some marginal timing as a result.
The current Outrun core doesn't seem to have this problem. Maybe because the core was changed from 100Mhz to 50Mhz.
I observed the same change and suspected the added sprite framebuffer and the resulting frequency drop to have solved this for outrun.
Looks like fixed according to posts i've saw on FB.
It saves pixels into memory at core's pixel clock then read it back at HDMI clock and interpolates according to selected video filter.
This is the best approach indeed.
Issue shown on screenshots above has nothing to do with core's pixel clock or clock enable. It's happening because HDMI timings didn't meet requirements. Did you check TimeQuest Timing Analyzer Summary - is there any negative slacks? It may be due to design of core which may have hard to route paths so it affected HDMI part as well. Or may be some synthesizer/router settings are wrong. May be constraints are wrong. You don't use quartus IDE to compile, so it's possible some constraints are missing or MiSTer framework has modifications lead to that issue.
This was very good feedback. Thank you. The timing constraints get checked and printed out if something failes in my workflow. But, I must have added a false path statement that shouldn't be there that affects the HDMI subsystem.
Thanks for the comments :-)
It seemed to be solved for a while, now with the latest updates it is happening again.
You need to open issue in a specific core, not here. It's not an issue of template.
Yes, I think we you can close it here, @JanGunheD. I'm looking into it.