| ID | Category [?] | Severity [?] | Reproducibility | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 07888 | Crash/Freeze | Critical (emulator) | Always | Mar 1, 2021, 01:19 | 8 days ago |
| Tester | Tafoid | View Status | Public | Platform | MAME (Self-compiled) |
| Assigned To | hap | Resolution | Fixed | OS | Windows Vista/7/8 (64-bit) |
| Status [?] | Resolved | Driver | |||
| Version | 0.229 | Fixed in Version | 0.273GIT | Build | Debug |
| Fixed in Git Commit | 77c75b6 | Github Pull Request # | |||
| Summary | 07888: warrior: [debug] Assert after -bench or -str run | ||||
| Description |
Assertion failed: PRIMFLAG_GET_BLENDMODE(prim.flags) == BLENDMODE_NONE || PRIMFLAG_GET_BLENDMODE(prim.flags) == BLENDMODE_ALPHA, file ../../../../../src/emu/rendersw.hxx, line 528 |
||||
| Steps To Reproduce | |||||
| Additional Information | |||||
| Github Commit | |||||
| Flags | Debug build specific | ||||
| Regression Version | 0.223 | ||||
| Affected Sets / Systems | warrior | ||||
|
Attached Files
|
 warrior_lay_works.zip (554 bytes) Nov 18, 2024, 21:40 Uploaded by hap | ||||
| default_test.zip (427 bytes) Nov 19, 2024, 08:50 Uploaded by hap | |||||
 No.20102
Robbbert Moderator
Apr 28, 2022, 10:36
|
Tested just now with debug build, no crash |
|---|---|
 No.20119
Tafoid Administrator
Apr 28, 2022, 20:27
edited on: Apr 28, 2022, 20:28
|
Still happens for me with 0.242 Debug build and release243 branch Debug build. The line number changed but the issue is the same. [MINGW64] R:\mame243>mamed warrior -bench 10 |
|
No.20122
Robbbert Moderator
Apr 29, 2022, 05:07
|
Yes, I can reproduce it now mamed warrior -bench 10 -artpath artwork will crash as you say. But if there's some external artwork, it seems much happier. |
|
No.20124
Robbbert Moderator
Apr 29, 2022, 05:58
|
The problem appears to lie in the internal artwork. It was created by Aaron (which is where this bug started), and then updated by Vas 6 weeks later (and the bug was not detected). Removing the artwork from cinemat.cpp gets rid of the assert, but I'm not an artwork expert - I cannot see anything wrong with it. |
 No.22453
hap Developer
Nov 18, 2024, 21:39
|
On a Windows normal build (aka the MAME release .exe), you can repro it like: mame.exe warrior -video gdi result = no internal artwork It appears it doesn't like this: <screen index="0" blend="add"> But a lot of internal artwork uses this blendmode on stuff, and it works fine? If you draw the internal artwork the other way around, it'll also work fine, I'll attach a file. If noone wants to fix the underlying issue, that can be used. |
|
No.22455
hap Developer
Nov 19, 2024, 08:49
|
I attached another test file. put default.lay in artwork/pacman put default.lay in artwork/tempest on MS Windows: mame pacman -video gdi mame tempest -video gdi pacman works, tempest doesn't show the internal artwork |
 No.22458
cuavas Administrator
31 days ago
|
So is the actual issue that the software compositor doesn't support support add and multiply blend modes for vector primitives? |
|
No.22460
hap Developer
31 days ago
|
At the time it reaches the assert during this test, PRIMFLAG_GET_BLENDMODE(prim.flags) == BLENDMODE_ADD. Yes, blend="multiply" also won't work there. FWIW the test case with pacman also fails with multiply blending, draw_quad_palette16_multiply is unimplemented, it gives a fatalerror (draw_quad_yuy16_multiply is missing too) |
|
No.22474
cuavas Administrator
29 days ago
|
1c50756b3a43811fcd54718f99ef7f96727d06b4 adds support for RGB multiply with 16bpp textures (palette and YUY), as well as reducing a bit of redundancy. Supporting vectors is somewhat more complicated. |
|
No.22580
hap Developer
8 days ago
|
I swapped the internal artwork with the one attached above. It works with -video gdi, snapshots work, and it won't assert with a debug build. |