-
-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
3wonders (jtcps1): Missing background colors on some screens #657
Comments
Thank you for the detailed report. This is video footage from real PCBs. They look like JTCPS1: https://www.youtube.com/watch?v=UbJuP4HQMXc |
I found this thread on the MAMEWorld forums that explains what is going on: https://www.mameworld.info/ubbthreads/showflat.php?Cat=2&Number=380374&page=&view=&sb=5&o=&vc=1 "The screen is red on real hardware, this is verified, although some monitors glitch out and strip all red from the image instead. (this happens whenever background colours are used on CPS1 games with said monitors) MAME correctly emulates the original CPS1 background colours in all situations. Some bootlegs may differ. If you're using one of the monitors that can't handle the signal from the board it will look different tho, yes." Apparently what's happening is that the game is changing the background color during Vblank in such a way that it confuses the circuitry in a lot of arcade monitors, causing the color to be subtracted from the rest of the image instead (I have seen this with certain games on my own CRT setup). You'll notice that the game selection screen in that thread has a cyan tint to it because of this, and there is a weird gradient on Midnight Wanderers where the monitor is trying to show the purple background. According to the thread, there was a CPS1 hardware hack that fixed the issue, and some bootlegs apparently do output black instead of color, which might contribute to the confusion. Also, for what it's worth, the official Capcom Arcade 2nd Stadium collection does show a red background on the game selection: |
Thank you for the reference. Note that the boards in the videos I linked were not bootlegs. The description talks about a glitch during blank that confuse the color reference for some monitors. I think the expected output by the designers is the one that the core produces so I will not take any action on this. Thank you for bringing it up. |
The videos of the PCB shows that the CRTs removes all the red color of all graphics of the 3wonders Game Select screen. Obviously that is not the designer intent and it should show the red colors + red background. Most likely Capcom used CRT monitors that did not have issues with the wrong blank level. Mame says color code 0xBFF should be used for blank pixels for CPS1. /* Blank screen */
if (m_cps_version == 1)
{
// CPS1 games use pen 0xbff as background color; this is used in 3wonders,
// mtwins (explosion during attract), mercs (intermission).
bitmap.fill(0xbff, cliprect);
}
else
{
// CPS2 apparently always forces the background to black. Several games would
// show a blue screen during boot if we used the same code as CPS1.
// Maybe Capcom changed the background handling due to the problems that
// it caused on several monitors (because the background extended into the
// blanking area instead of going black, causing the monitor to clip).
bitmap.fill(m_palette->black_pen(), cliprect);
} The DL-0921 RE (LUT storage page) also shows that 0xBFF should be used as you have also said in your source code: `ifdef CPS2
localparam [13:0] BLANK_PXL = { 2'b11, 12'hBFF }; // according to DL-0921 RE but it doesn't look
// good on CPS1/CPS1.5 games. CPS2 is fine with that
`else
localparam [13:0] BLANK_PXL = ~14'd0;
`endif What did not look good about using 0xBFF with CPS1? |
Using I can, however, accept using the I have compiled a MiSTer core using |
Thank you for the detailed reply. The color mixer must no be falling correctly to select the background. I will check it. |
First of all, thanks to Jotego for the amazing core. It's so good I didn't bother firing up the old CPS1 board for years. I finally did last week in order to check its suicide battery and immediately noticed the difference in the background colors as well. I captured the attract sequence on real hardware (no sound and apologies for the terrible Framemeister video noise): Findings:
Except for Lou's gun going out of the frame in max piccinato's video, it looks consistent with all three videos Jotego shared. I am adding a couple of extra videos for lukemorse1 which seems to show the exact same behavior: Since the Framemeister offers a "Color Invert" mode, I tried capturing each screen: I hope this helps. Let me know if you think some other tests could be useful to solve this! |
Thank you for the video footage. I was not aware of the gun problem. I have created a new issue for that one, #667. The three of them may be related but it is easier to track them one by one. I do not know what to do with the inverted color images. But I can see that there might be a hint of pale red in the game selection screen in your footage, which was the topic of the present issue. Thanks for sharing it. |
You are welcome. Apologies for mixing the two topics. Researching on the other topic, I came across Japanese Game Center livestreams where the screen goes black when the GAME SELECT screen is supposed to appear (sync drop due to the upscaler or capture device not handling the weird color/signal?):
This one is struggling a bit but doesn't loose sync: https://youtu.be/m4L2ULic3Cw?si=DEW-IChkpphZpK8D&t=70 This one (quality is poor) is showing similar behavior as my capture, but it might be because it's also using the Framemeister: https://youtu.be/MwN0coQmPGU?si=L1_SilzaO78ODvDW&t=1161 Unfortunately, I don't own a CRT anymore to run more test. |
I assume the red color used for blanking in the back porch area breaks the video. Probably the programmers wanted to have a red background, but didn't consider that in the real blanks, it shouldn't be red. Actually I think it's an oversight from the hardware designers, if they allowed to program a background color, but didn't really blank the back porch area at least. |
There was a bug in color DMA, which explains the color palette difference shown by paulb-nl. |
I tested CPS2 and these four games had graphical problems; ALIEN vs PREDATOR "I" of ALIEN on the title screen is missing. Commit: d68d306 |
Thanks for testing. I added a small fix. |
What about something like this: obj1st = obj_prio > scr_prio[2:0];
obj_sel = ~blank(obj_pxl) & (obj1st | blank(scr_pxl);
pxl <= (obj_en & obj_sel) ? {3'd0, obj_pxl[8:0]} : scr_pxl; |
It seems logical, and also seems to work, thanks! |
Thanks Paul for the hint! |
The DMA works actually, it was the blanking logic which had to be changed, as the colors are corrected. |
We have tested most games without problems. We'll finish the testing tomorrow. If it goes well, I'll merge the PR |
We have tested all games of CPS1 and CPS2 without problems. |
Thank you all. I've merged the PR. |
Certain screens that should have background colors do not. Comparing MAME and the MiSTer core (MAME on left):
I actually reported this as an issue in MAME years ago, and I think the consensus was that the method this game uses to set the background color wasn't used in (any?) other games, possibly because it causes color problems on some arcade monitors. I don't know the technical details, though.
The text was updated successfully, but these errors were encountered: