Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
04705 Graphics Minor Always Feb 25, 2012, 16:58 Feb 28, 2012, 19:35
Tester Reyn View Status Public Platform MAME (Official Binary)
Assigned To Resolution Open OS Windows Vista/7 (64-bit)
Status [?] Confirmed Driver neodriv.hxx
Version 0.145 Fixed in Version Build Normal
Summary 04705: turfmast: On hole one of Japan course the moving clouds are cut off two rows two soon
Description Stumbled over this here:

Tested on real HW MV2F. Does not happen there.

2nd bug: Select course Germany. On second hole there is a black line across the screen.
Also tested on real HW. Does not happen there.
Uploaded video turfmast_germany_hole2 for proof.
Steps To Reproduce Start game.
Select Japan course.
Watch clouds moving on hole one.
Additional Information
Flags Verified with Original
Regression Version
Affected Sets / Systems turfmast
Attached Files
png file icon turfmast.png (894,633 bytes) Feb 25, 2012, 16:58 Uploaded by Reyn
There are no relationship linked to this issue.
User avatar
Feb 25, 2012, 17:00
For non hardware owners this can be checked against Final Burn Alpha.
FBA shows the correct behavior as observed on real HW.
User avatar
Feb 25, 2012, 17:04
Uploaded video taken.
The quality isn´t good. I have no other cam at hand.
User avatar
Senior Tester
Feb 25, 2012, 19:33
I'd confirm this one, but my judgement says to wait for a second opinion, I just don't trust my eyes on what I'm looking at.
User avatar
Feb 26, 2012, 06:51
edited on: Feb 26, 2012, 06:52
The "Side-by-Side" category is obsoleted, it was used for a general working confirmation with the original PCB.
Now please use a direct category, for example in this one, select "Graphics", and add the "Verified with Original" flag.

Thank you.
User avatar
Senior Tester
Feb 27, 2012, 19:05
edited on: Feb 27, 2012, 19:13
This can be fixed in VIDEO/NEOGEO.C:
650      /* we are at the beginning of a scanline -
  651         we need to draw the previous scanline and parse the sprites on the current one */
  652      if (scanline != 0)
  653          machine.primary_screen->update_partial(scanline - 1);
  655      parse_sprites(machine, scanline);
change to:
650      /* we are at the beginning of a scanline -
  651         we need to draw the previous scanline and parse the sprites on the current one */
  652      //if (scanline != 0)
  653          machine.primary_screen->update_partial(scanline + 1);
  655      parse_sprites(machine, scanline + 2);   // not sure about this...
Note that this code fixes also some raster effects in other games... as it is stated in source code in NEOGEO.C:
* Graphical Glitches caused by incorrect timing?
             - Some raster effects are imperfect (off by a couple of lines)
Though I'm not completely satisfied by this... how this bug is handled in FBA?
User avatar
Senior Tester
Feb 27, 2012, 21:30
edited on: Feb 27, 2012, 21:40
IIRC FBA doesn't attempt to emulate proper video timings and just hacks it to use the line where the raster was called, not the line where video actually changes.

the fix proposed here is just a hack tho.

it's possible the actual raster is happening on the wrong line, the 68k execution is taking too long and pushing it over to the next one, or the hardware is grabbing the sprite lists 2 lines in advance of time (that would mean the first 2 lines get rendered with data in memory at the very END of the last frame tho)

the time at which the sprite list gets grabbed by the hw for rendering is key

something is amiss however, because the implementation in there now is based on extensive testing, but simply kludging it as you have doesn't really solve the issue (and will probably break rasters if used on the bottom / top lines) It wouldn't surprise me if there was some kind of 2 line buffer logic however, megadrive for example will render *sprites* to a buffer on the previous line, whereas tilemap register changes will have an (almost) immediate effect.

timing bugs are some of the nastiest around
User avatar
Senior Tester
Feb 27, 2012, 21:55
edited on: Feb 27, 2012, 22:04
I agree... my code was simply an attempt to test things. Infact "parse_sprites()" always skip the first two lines of the screen...
But... if FBA uses *only* the IRQ raster register, then they don't emulate properly some nice effects which are used in e.g. MOSYOUGI where the effects are performed without using the raster IRQ but simply changing video RAM on the given scanline (IIRC)
User avatar
Senior Tester
Feb 27, 2012, 22:10
edited on: Feb 27, 2012, 22:13
It's been a while since I looked at FBA, but I think they have a separate renderer for those cases, which also updates on scanline position reads.

There's probably an error been made when measuring things / behavior which isn't documented in the manuals.

If you're trying to test raster effects by changing something like the *palette* you might find that the effect onscreen is immediate, because the palette data is read in realtime during the horizontal scan.

Altering the sprites at the same time you alter the palette might have no effect until the next line (when the hardware reads the sprite list) or even 2 lines ahead if the hardware has buffering.

The Text layer, who knows, it's possible you can't do rasters on it (it doesn't scroll so it would be hard to know) or also possible it's buffered entirely at the start of a scanline.

The horizontal position at which the buffering occurs can also be important, does it happen at the very start of a scanline, or the very end of the visible area of the previous..

As you can imagine, this makes testing just as hard as implementing, and there is plenty of room for error, or mistakenly thinking something is having another effect than it is due to things not changing until later.

These are just some of the factors to consider. Zed Blade also has visible issues, and I'm not too happy about the Sammy logo in Viewpoint either.

You can't just force partial update on one line AHEAD of the current position (your +1) because some effects might occur on the same line, even if the sprite ones don't appear to. Even my megadrive implementation is wrong for similar reasons, although there are sufficient docs to correct that, I just didn't understand / interpret them properly at the time :-)
User avatar
Feb 28, 2012, 18:33
Updated report with another bug, see Edit in description.

"Fix" from Mamesick does not fix this one.
User avatar
Feb 28, 2012, 19:35
using the latest mameuifx i couldnt see the mentioned bug in turfmasters