Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
03954 Graphics Minor Always Jul 24, 2010, 06:47 Nov 9, 2016, 10:14
Tester Samurai Fox View Status Public Platform
Assigned To Resolution Open OS
Status [?] Confirmed Driver neodriv.hxx
Version 0.138u4 Fixed in Version Build 64-bit
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
Flags
Regression Version
Affected Sets / Systems garou
Attached Files
gif file icon garou.gif (517,359 bytes) Jul 25, 2010, 04:36
Relationships
There are no relationsihp linked to this issue.
Notes
19
User avatar
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.
User avatar
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.

User avatar
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.

User avatar
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
User avatar
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.
User avatar
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
User avatar
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.
User avatar
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.

User avatar
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.

User avatar
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.

User avatar
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.
User avatar
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.
User avatar
No.10370
hap
Developer
Mar 18, 2014, 20:55
I'm pretty sure this specific bug is due to missing 68000 waitstates
User avatar
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?
User avatar
No.11976
hap
Developer
Aug 19, 2015, 20:19
If you want to crudely simulate M68000 waitstates, underclock it.
User avatar
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.
User avatar
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).
User avatar
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.

User avatar
No.13340
Fujix
Administrator
Nov 9, 2016, 10:14
Moved attached original movie to YouTube.