04705: turfmast: On hole one of Japan course the moving clouds are cut off two rows two soon

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	neogeo/neogeo.cpp
Version	0.145	Fixed in Version		Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	04705: turfmast: On hole one of Japan course the moving clouds are cut off two rows two soon
Description	Stumbled over this here: http://mamedev.emulab.it/haze/2012/02/14/ultimately-mia/comment-page-1/#comment-19959 Tested on real HW MV2F. Does not happen there. Edit: 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
Github Commit

Flags	Verified with Original
Regression Version
Affected Sets / Systems	turfmast

Attached Files	turfmast.png (894,633 bytes) Feb 25, 2012, 16:58 Uploaded by Reyn

No.08271 Reyn Tester 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.
No.08272 Reyn Tester Feb 25, 2012, 17:04	Uploaded video taken. The quality isn´t good. I have no other cam at hand. http://www.sendspace.com/file/w6ctot
No.08273 NekoEd 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.
No.08275 Fujix Administrator 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.
No.08283 Mamesick 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); 654 655 parse_sprites(machine, scanline); 656 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); 654 655 parse_sprites(machine, scanline + 2); // not sure about this... 656 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?
No.08284 Haze 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
No.08285 Mamesick 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)
No.08286 Haze 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 :-)
No.08290 Reyn Tester Feb 28, 2012, 18:33	Updated report with another bug, see Edit in description. Proof: http://www.sendspace.com/file/kb6ty7 "Fix" from Mamesick does not fix this one.
No.08291 pri88 Viewer Feb 28, 2012, 19:35	using the latest mameuifx i couldnt see the mentioned bug in turfmasters