03672: tgm2, tgm2p: Sprite zooming effects are not pixel accurate.

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
03672	Graphics	Minor	Always	Jan 18, 2010, 03:49	Jun 8, 2012, 02:58

Tester	colour_thief	View Status	Public	Platform	MAME (Official Binary)
Assigned To		Resolution	Open	OS	Windows Vista/7 (64-bit)
Status [?]	Acknowledged			Driver	psikyo/psikyosh.cpp
Version	0.136u1	Fixed in Version		Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	03672: tgm2, tgm2p: Sprite zooming effects are not pixel accurate.
Description	When compared to direct video capture from the PCB, MAME does not have pixel accurate zooming. I have attached 2 pictures comparing the PCB (left) with MAME (right) in trivial to test cases. 1. PLUS For the plus version of TGM2, there is a "PLUS" written (normal size) in the bottom right corner of all gameplay (pictured above in the attached image). The PCB and MAME match in this case. On the title screen a zoomed in version of this same PLUS appears. I have marked the incorrect pixels with red x marks. In MAME the P and S have bigger gaps in their corners which is quite noticeable if you're used to looking at the real thing. Note, I have hand edited the colours of the PCB capture in this picture to make the comparison easier. That's why it looks so clean on both sides. 2. GO Whenever you start a game, READY GO slides onto the screen, with the game squishing the text more when it's far away from the center. I have provided a comparison of GO fading in, and the first 2 frames look substantially different from MAME. Note, I did not do any hand editing of the PCB capture in this image other than simply cropping and pasting them together.
Steps To Reproduce	1. PLUS Just look at the title screen in tgm2p. 2. GO Simply start any mode. I recommend P and then shift+P for frame stepping.
Additional Information	This probably affects the whole driver, not just the 2 games mentioned. If additional comparisons are useful I can provide them on request, as there are many other places where zooming is used.
Github Commit

Flags	Verified with Original
Regression Version	0.99u4
Affected Sets / Systems	tgm2, tgm2p

Attached Files	PLUS.png (8,426 bytes) Jan 18, 2010, 03:49
Attached Files	GO.png (26,494 bytes) Jan 18, 2010, 03:51

No.05527 colour_thief Tester Jan 18, 2010, 13:47	Is this the sort of thing a decapped chip would help? Or is it purely a MAME issue?
No.05529 Tafoid Administrator Jan 18, 2010, 14:07	The graphics rendering is in a state of being worked on right now. This might already be fixed with recent SVN work.
No.05531 Haze Senior Tester Jan 18, 2010, 14:15 edited on: Jan 18, 2010, 14:16	not something a decap would help with. Assuming it doesn't upload a zoom table, then the best thing that can be done are reference shots for various zoom levels, using known graphics. With enough shots the correct zooming algorithm for the hardware can probably be figured out, as it was for NeoGeo etc. This can be done with a trojan (and should be done for both the sprite and tile zoom, in both x and y directions) This type of bug probably affects almost all games in MAME using zooming / rotating hardware as every manufacturer had their own chips, and implementations which could easily differ from the MAME generic implementation.
No.05538 colour_thief Tester Jan 18, 2010, 15:49	Should I compile more PCB reference images or will it all be trojaned? I don't mind adding more if it's useful, but it's time consuming so I just want confirmation it'll help. Looking forward to more changes. I'll be sure to test things in the next release.
No.05540 Tourniquet Developer Jan 18, 2010, 16:10	I have the hw, if no-one else beats me to it I will work on it eventually. Not the highest priority now. Thanks for the detailed reports.
No.05546 Tourniquet Developer Jan 19, 2010, 19:26	Hmm, looking at the sprites again. We _are_ using an uploaded zoom table. he games upload 256 16-bit values in 6.10 fixed point (i.e. 0x400 is 1:1). Unzoomed sprites have a zoom of 0x3F which corresponds to 0x400. The 'plus' is 0x5F which we lookup to 0x2AB for TGM2. indicating that it's doubled to nearly twice the normal size. Each letter is an individual sprite. There's actually a couple of bits in each sprite that we're not using that TGM2 sets. There's also a table of 4 6-bit registers in the vid regs that we're not using. I wonder if they're related.
No.05548 Haze Senior Tester Jan 19, 2010, 23:17	Well, it's not quite the same as the neogeo tables, which IIRC are pixel masks for each zoom level (draw,skip,draw,draw,skip etc.) In this case, it's just a level of indirection for the zoom. How it decides if a pixel is drawn or not drawn when zooming is the issue here, and there are different algorithms that can be applied there.
No.05549 Tourniquet Developer Jan 20, 2010, 00:43	Well, it's the 'skip' value (and these are fixed point unlike the neogeo tables), so I'm pretty confident they're correct. What I think is incorrect is the starting offset. drawgfx always starts at the top-left of the top-left pixel. If I change it to start at the middle of the top-left pixel then the horizontal zoom matches the 'plus' perfectly. The vertical zoom doesn't though so the algorithm is slightly different there.
No.08725 colour_thief Tester Jun 8, 2012, 02:58	I looked at bit more at this hoping to find some magical y starting offset. I was able to determine that no constant starting offset is pixel accurate for all zoom levels. For the 10 frames of 'GO' that are referenced above, their zoom factors increase by an index of 5 each frame, as follows: Frame 1 = 0x0D = 0x1249 Frame 2 = 0x12 = 0x0D79 Frame 3 = 0x17 = 0x0AAB Frame 4 = 0x1C = 0x08D4 Frame 5 = 0x21 = 0x0788 Frame 6 = 0x26 = 0x0690 Frame 7 = 0x2B = 0x05D1 Frame 8 = 0x30 = 0x0539 Frame 9 = 0x35 = 0x04BE Frame 10 = 0x3A = 0x0457 Frame 11 = 0x3F = 0x0400 For the following calculations, keep in mind that 'GO' has a black pixel border not easily visible over the black background. Also, I'm counting rows of pixels starting with 0. Frame 1: Row 3 of the zoomed sprite uses row 14 of the unaltered sprite. Emulation is using row 13. How short is it falling? 0x1249 * 3 = 0x36DB 0x400 * 14 = 0x3800 0x3800 - 0x36DB = 0x125 =< y-offset Frame 4: Row 4 of the zoomed sprite uses row 8 of the unaltered sprite. Emulation matches hardware. But how close is it to choosing row 9? 0x8D4 * 4 = 0x2350 0x400 * 9 = 0x2400 0x2400 - 0x2350 = 0x50 > y-offset This gives us the following impossible condition the starting offset would have to meet: 0x125 < y-offset < 0x50 So whatever is going on, it must be more dynamic than a constant offset. And given that there are 11 examples showing y-axis zoom and a single one showing x-axis zoom, I would expect that no constant x-axis starting offset would be pixel accurate. Probably not an observation of much help, but I thought I'd share it anyways. :)