05780: raiden2 and clones: Screen parameters/refresh rate

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
05780	Graphics	Minor	Always	Nov 11, 2014, 08:25	Nov 26, 2014, 13:46

Tester	kamilz	View Status	Public	Platform	MAMEUI
Assigned To	Kale	Resolution	Fixed	OS	Windows Vista/7/8 (64-bit)
Status [?]	Resolved			Driver	seibu/raiden2.cpp
Version	0.155	Fixed in Version	0.156	Build	64-bit
		Fixed in Git Commit		Github Pull Request #

Summary	05780: raiden2 and clones: Screen parameters/refresh rate
Description	This is not a bug, just a suggestion. I'm one of the Soft15KHz users. I like to manually tune up perfect detailed screen resolutions for CRT 15Khz monitors. Most cases I can able to do this and generate a modeline. In this game (Raiden2) I couldn't manage set perfect settings (or very close). In these cases I examine the source file to see timings. For this game what I found is: "MCFG_SCREEN_RAW_PARAMS(XTAL_32MHz/4,546,0,408,264,0,328) /* hand-tuned to match Note: 00055.47 */" It seems game is manually tuned, I tried to same to match 8 mhz pixel clock and 15.625 KHz horizontal refresh rate (this used by many games) and I get 55.407. Since game uses 55.47, I begin to think there may be a typo in source. Please examine picture below to see my settings. My suggestion is this game Vertical Refresh rate maybe 55.407 Hz not 55.470. Just a suggestion. I didn't test this on CRT. But I'm pretty sure picture will show up.
Steps To Reproduce
Additional Information
Github Commit

Flags
Regression Version
Affected Sets / Systems	raiden2 and clones

Attached Files	raiden2_320x240@55.407Hz.jpg (96,857 bytes) Nov 11, 2014, 08:25 Uploaded by kamilz
Attached Files	55.470.png (19,979 bytes) Nov 11, 2014, 22:00 Uploaded by zaxxon

No.11239 NekoEd Senior Tester Nov 11, 2014, 19:16	I'll give this to the devs to look at.
No.11241 Kale Developer Nov 12, 2014, 21:43	Looks legit, and that tool proved to be quite useful.
No.11242 kamilz Tester Nov 13, 2014, 02:13	Thanks. That tool I use (and you might already know) CRU, Custom Resolution Utility by ToastyX. While I'm examining the source code I see many games doesn't have raw parameters, and usually refresh rates are hard coded as like this: MCFG_SCREEN_REFRESH_RATE(60) I won't bother you unless I see some legit evidence in source like known Pixel Clock to check/test. Some games and systems are impossible to exactly match, this is because of I believe hardware and driver limitation. For example Pixel Clock precision is 2 digit after point. For example; C64 Pal pixel clock is 7.882 MHz, that becomes 7.88 and it slightly affects refresh rate exactness. Lastly one of the systems (cave.c) has this setting: MCFG_SCREEN_REFRESH_RATE(15625/271.5) and games reports 57.550644, but 271.5 vertical scan line isn't seems legit on PC (expects integer) although real H/W probably can do that. And in these situations (my opinion) it's best to round it to 272 or 271 scan lines. Groovymame and similar ports I'm pretty sure just tries to match refresh rate, to do this alters Vertical and H.lines at will. Thanks again.
No.11245 Haze Senior Tester Nov 13, 2014, 13:37	> and games reports 57.550644, but 271.5 vertical scan line isn't seems legit on PC (expects integer) although real H/W probably can do that. > And in these situations (my opinion) it's best to round it to 272 or 271 scan lines we have to use the proper rates where they are known, this is especially true on home systems where you have copy protection mechanisms that expect exact timings, not 'almost' not 'rounded' but exact to the degree where 0.5 would matter. we aim to be correct where possible, not convenient for us on a PC.
No.11248 AWJ Developer Nov 13, 2014, 18:20	I've actually been curious about that cave.c "271.5" for a while. It would make sense if (and only if) the hardware actually outputted an interlaced signal... does it? None of the games runs at an interlaced resolution, they're all 240 lines.
No.11255 Calamity Developer Nov 17, 2014, 11:29	> I've actually been curious about that cave.c "271.5" for a while. It would make sense if (and only if) the hardware actually outputted an interlaced signal... does it? I'm not saying this is the case but it could be perfectly possible for the hardware to alternate between odd/even frames with 271-272 total lines, and still get a progressive signal.
No.11268 Haze Senior Tester Nov 26, 2014, 13:46	fwiw I don't think this was fixed in 0.156, the fix caused some major graphical problems (it was probably incomplete and an automatic timed sprite buffer is needed ) it needs reviewing again now that the release is out