00261: karatblz: Right at the beginning, the heroes are introduced using a zoom effect. Several frames are glitched.

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
00261	Graphics	Minor	Have not tried	Jan 28, 2008, 01:01	Nov 26, 2016, 18:56

Tester	Frotz	View Status	Public	Platform
Assigned To		Resolution	Open	OS
Status [?]	Confirmed			Driver	vsystem/aerofgt.cpp
Version	0.37b4	Fixed in Version		Build
		Fixed in Git Commit		Github Pull Request #

Summary	00261: karatblz: Right at the beginning, the heroes are introduced using a zoom effect. Several frames are glitched.
Description	Right at the beginning the heroes are introduced using a zoom effect. Several frames of the zoom effect are glitched. It looks as if the image was cut into rectangular jigsaw pieces and then re-arranged with all pieces slightly out of place.
Steps To Reproduce
Additional Information
Github Commit

Flags
Regression Version
Affected Sets / Systems	karatblz

Attached Files	karatblz337b4gre_shot1.png (7,074 bytes) Feb 14, 2008, 08:37
Attached Files	karatblz337b4gre_shot2.png (5,260 bytes) Feb 14, 2008, 08:38

No.00513 robiza Developer Apr 3, 2008, 15:25	the problem is the routine to use for handle the zoom with multi-sprite actually in mame there's a linear conversion (with a wrap): ((oy + zoomy * y / 2 + 16) & 0x1ff) - 16; in other words the "x distance" from sprite #1 to sprite #2 : for zoom = 0 is 16 for zoom = 1 is 15,5 for zoom = 2 is 15 and so on (step = 0.5, constant) for a perfect zoom it's necessary to use a non-linear conversion the "x distance" from sprite #1 to sprite #2 : for zoom = 0 is 16 for zoom = 1 is 15 for zoom = 2 is 14,125 for zoom = 3 is 13,25 for zoom = 4 is 12,75 for zoom = 5 is 12,125 for zoom = 6 is 11,5 for zoom = 7 is 11,125 for zoom = 8 is 10,5 for zoom = 9 is 10,125 for zoom = a is 9,75 for zoom = b is 9,375 for zoom = c is 9,125 for zoom = d is 8,625 for zoom = e is 8,375 (guessed, not used in the game) for zoom = f is 8,125 (guessed, not used in the game) yet, i'm not sure if these infos can be used in a acceptable fix can i have a feedback by a dev?
No.00514 Tafoid Administrator Apr 3, 2008, 15:51	Brought to top of list - was added while I adjusted dozens of bugs with the galaxian/galdrvr changes.
No.04756 hap Developer Aug 3, 2009, 12:44	I don't know if the rectangles effect is wrong or not (low quality video), but the wobbly effect during zoom is definitely wrong. Karate Blazers video from PCB: Karate Blazers video from MAME:
No.04760 Tafoid Administrator Aug 3, 2009, 13:29	There also seems to be a slight pitch difference in MAME (a bit higher) than PCB recording.
No.13404 Fujix Administrator Nov 22, 2016, 06:28	Here is an original PCB video of the Japanese version at 10% speed, sprite scaling is smooth not like MAME. Removing the possible tag.
No.13411 Haze Senior Tester Nov 22, 2016, 20:28	I believe there used to be a table in MAME to make this case smooth, but somebody (Nicola?) decided it was incorrect and removed it / suggested that drivers using the non-linear zoom table needed upgrading to the linear one (which causes these glitches) it could be a difference between the older / newer video system sprite chip of course.
No.13428 Mamesick Senior Tester Nov 26, 2016, 18:56	The bug has always been present, since the game was added and the zoom table was used. Re-implementing it now (which is just a couple of line changes) doesn't fix the problem. I guess robiza table should be used or at least the info he provided implemented in a some way.