03954: garou: Background loop sequence is broken on the Terry's 3rd round.

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
03954	Graphics	Minor	Always	Jul 24, 2010, 06:47	Mar 31, 2023, 06:37

Tester	Samurai Fox	View Status	Public	Platform
Assigned To	galibert	Resolution	Fixed	OS
Status [?]	Resolved			Driver	neogeo/neogeo.cpp
Version	0.138u4	Fixed in Version	0.253	Build	64-bit
		Fixed in Git Commit	74971c2	Github Pull Request #

Summary	03954: garou: Background loop sequence is broken on the Terry's 3rd round.
Description	On the 3rd round of Terry's stage (the one with the looping background), the loop sequence is messed up.
Steps To Reproduce	start a 2 player game and select Terry for both players. Make the fight last into the 3rd Round.
Additional Information	(Link to private video removed)
Github Commit

Flags
Regression Version
Affected Sets / Systems	garou

Attached Files	garou.gif (517,359 bytes) Jul 25, 2010, 04:36

No.06424 Tafoid Administrator Jul 24, 2010, 11:50	What in particular is wrong with the background (be specific)? Generally, snapshots are good to support a case as well as denoting where in the game you have to play to get to said stage. Adding save states are important, too, if you have an issue that cannot be verified quickly. As it stands, I'm ready to close this mostly due to the fact that there is no supporting evidence which is required for all Neo-Geo graphics bug submissions. (Refer to RULES and GUIDELINES). Not properly researching against actual sources simply wastes Developer time looking for an issue that potentially does not exist on actual hardware, no matter how obvious one person might think a bug might be.
No.06428 Samurai Fox Tester Jul 24, 2010, 18:30 edited on: Jul 24, 2010, 18:53	In the 3rd round of Terry's stage, the "3D" movement in the background stutters a great deal when it should be running smoothly. It looks as though the animations in the background aren't being finished at all. This used to not be a problem before, even after the driver rewrite. My evidence is that if you look at the bottom part of the animations of the background, you can see that it's running smoothly. The middle apart is where it acts very screwy. Also, messing around with the CPU0 clock settings seems to sometimes fix this (move the slider to about 130, then back to 100). Screenshots would not explain this problem, but if you want to check it out as quickly as possible, start a 2 player game and select Terry for both players. Make the fight last into the 3rd Round.
No.06429 Fujix Administrator Jul 25, 2010, 04:40 edited on: Jul 25, 2010, 04:44	The animation sequence of the background bridge is broken. I uploaded a composite image. And Samurai, this is not a raster effect, but a simple animation. It is important to show something for others to help understanding your report. Fixing the report description and setting confirmed.
No.06441 Reyn Tester Jul 28, 2010, 15:09	Tested in MameUI 138u4 and no repro here. If it matters, ATI GFX card with 10.5 catalyst used
No.06442 Haze Senior Tester Jul 28, 2010, 23:51	it definitely happens, and it could be raster interrupt related, there is a definite split in the image where it breaks. maybe there are some rules about when the auto-animation flags can be changed. it could of course be a real game bug, the neogeo is full of them, especially if it only occurs sometimes.
No.06447 Reyn Tester Jul 30, 2010, 16:20	I added a video recorded on TV with my consolized 2 slot MVS Can't see a difference between Mame and HW. But I am not good at this. Someone please compare my video with Mame
No.06452 Haze Senior Tester Jul 30, 2010, 23:58	the background scrolling is correct in your video, it jumps around missing frames and splitting very obviously in MAME. Sometimes it seems to work in MAME tho (but most of the time it doesn't) You should watch it more closely to see the difference, then try a few more times on the PCB to ensure it never happens there.
No.06453 Reyn Tester Jul 31, 2010, 06:26 edited on: Jul 31, 2010, 07:29	I did some testing with MameUI 0.139: As long as the following video options are OFF, everything works fine: . Tripple buffering . Sync to monitor refresh . Wait for vertical sync Tested 4 times. I noticed at the ~ 1st second of the 3rd stage the effect happens then behaves normally -> Compared with my video the HW doesn't have this effect. It scroll's perfectly from second 1. If you activate Tripple buffering and/or Sync to monitor refresh, the described effect always happens. When activating only Wait for vertical sync the effect occures sometimes, sometimes not. Edit: @Haze: What happens if you disable the speed optimization in video\neogeo.c (Line 423) Could this be related? Sorry if I am wrong here, I am no programmer. If possible, could you post a diff that disables that optim.? Edit2: I will run some more test on HW this afternoon.
No.06455 Haze Senior Tester Jul 31, 2010, 11:11 edited on: Jul 31, 2010, 11:14	that's somewhat disturbing, those options should have no impact on the quality of the emulation in this way... I have none of them on, and it's glitched. The speed optimization isn't related.
No.06456 Reyn Tester Jul 31, 2010, 11:20 edited on: Mar 20, 2014, 06:56	Did some testing on HW: After entering the 3rd Terry stage several times the error does NOT occur. Scrolling always is fine.
No.06478 Reyn Tester Aug 1, 2010, 19:53	I remembered that ElSemi's Nebula emulator had some issues with garou. Went through changelog and found this: v2.18: Fixed garou 3rd Terry stage background animation (requires rasters enabled) Maybe this info helps for a fix.
No.06490 Haze Senior Tester Aug 3, 2010, 13:36	MAME always has rasters enabled (display is updated on a scanline basis for all drivers all the time, the raster enable/disable stuff mentioned in Nebula / old MAME is a speed hack) This is why MAME correctly emulates some of mid-screen tearing that occurs on real NeoGeo games, and other emulators don't. However, in this case something appears to be causing the raster interrupts to either trigger on the wrong line, or, the auto-anim handling is wrong in the case of raster updates which changes them mid-screen. It's hard to say.
No.10370 hap Developer Mar 18, 2014, 20:55	I'm pretty sure this specific bug is due to missing 68000 waitstates
No.11974 samsho2 Tester Aug 19, 2015, 15:02	I'm able to manipulate this behavior predictably. If you overclock the main CPU to 124% (at any time the machine's running), this background will display correctly. While you're still on this stage, if you reset the CPU speed to 100%, it will still display correctly. However, after the match is over, when you can see the background behind the character's victory portrait, it will show the skipping/glitch if you had reset the CPU speed to 100% before the victory screen displayed. If you leave the CPU overclocked, the background will still display correctly on the winner's victory screen. So it seems that simply overclocking the main CPU prevents this error from showing. Would it be possible to get some useful information out of the debugger by monitoring it while overclocking and resetting the main CPU?
No.11976 hap Developer Aug 19, 2015, 20:19	If you want to crudely simulate M68000 waitstates, underclock it.
No.11977 samsho2 Tester Aug 20, 2015, 02:12	If it's the waitstates, why does overclocking it significantly also work? Shouldn't the problem be even worse if it's going even faster? It displays correctly with the machine at 15mhz.
No.11978 hap Developer Aug 20, 2015, 10:24	under, or overclocking the CPU changes the screen location where the raster effect is applied. For example, game x starts a new video frame, does some AI or whatever calculations, and then writes to a video register immediately(instead of timing it with a line interrupt).
No.11983 samsho2 Tester Aug 22, 2015, 15:09 edited on: Aug 22, 2015, 15:09	One more disturbing thing I noticed while testing: using the same binary, the behavior is different on different machines. Two boxes (one i7 3770k CPU and one i7 4790k CPU), the 3770k still has the messed up background when clocked at 15mhz, but the 4790k doesn't have that error clocked at 15mhz. I realize that overclocking it is wrong, but it's still a little disturbing that it behaves differently on different computers. It makes me wonder if there's more to this than just the missing wait states. This was with a 64bit build on Windows 10 with no optimization flags. I'm going to try a 32bit build out of curiosity to see whether there's any difference.
No.13340 Fujix Administrator Nov 9, 2016, 10:14	Moved attached original movie to YouTube.
No.16156 bedrock Tester Feb 19, 2019, 14:10	CPU% slider at 98% also works to fix the background animation even up to a rematch round in that particular stage. Precise setting is 983/1000. (note: some of these sliders being in xx% the actual fine granularity doesn't show, which is impractical, should be xx,xx%)
No.21236 samsho2 Tester Mar 30, 2023, 06:16	This should be re-verified. It looks like the new 68000 core might have fixed it.
No.21238 hap Developer Mar 31, 2023, 06:37	Yeah, it appears fixed between 0.252 and 0.253, most likely the 68000 rewrite.