 No.12855
Robbbert Senior Tester
Jun 30, 2016, 04:15
|
Confirmed. |
|---|---|
 No.12861
Osso Moderator
Jun 30, 2016, 05:46
|
this only happens with the d3d render module. |
|
No.12863
Augusto Tester
Jun 30, 2016, 06:31
edited on: Jun 30, 2016, 06:33
|
Some games run in perfect speed and after of some seconds run in less of 25 % of speed even if not other programs using the computer cpu. If two times press TAB the speed return to normal. Perhaps an problem with the same root of issue posted ? |
 No.12892
NekoEd Senior Tester
Jul 4, 2016, 06:08
|
FWIW, I can't reproduce this on Linux/x64 with SDLMAME. I'm also unable to reproduce the bug marked as related to this one (06276) |
|
No.13104
DarkMoe Tester
Sep 3, 2016, 02:02
|
Still happening on 0.177 |
|
No.13113
Haze Senior Tester
Sep 5, 2016, 10:06
|
Yeah, I've seen this several times during development, usually when alt-tabbing away from the 'machine information' page. |
|
No.13261
Zelda189 Tester
Oct 11, 2016, 09:18
|
Still the error on 0.178 |
|
No.13354
Robbbert Senior Tester
Nov 12, 2016, 23:20
edited on: Nov 16, 2016, 06:39
|
The error has changed, it now says Unable to create the Direct3D device (8876086C) Unable to initialize Direct3D 9 Fatal error: Unable to complete window creation The alt-tab problem was fixed on 2016-10-22, but by release of 0.179 (just 6 days later) it was broken again, with the above message. (tested with official mame 32-bit from the mamedev site) |
|
No.13835
Robbbert Senior Tester
May 14, 2017, 11:12
edited on: May 14, 2017, 11:12
|
Current error message is: Fatal error: Fatal error: Too many live texture instances! (../../../../../src/emu/render.cpp:490) |
 No.14202
SeanRamey Tester
Oct 1, 2017, 21:50
|
Still broken in 0.190. |
|
No.14565
Robbbert Senior Tester
Dec 26, 2017, 11:17
|
Referenced by https://github.com/mamedev/mame/issues/2421 |
|
No.16244
Robbbert Senior Tester
Mar 15, 2019, 22:22
edited on: Mar 15, 2019, 23:20
|
Current situation is it crashes with d3d; other video modes don't crash, but the app you're tabbing to won't appear, and mame won't go to the background. ---------------------------- Referenced by https://github.com/mamedev/mame/issues/4763 , where the crash happens if you try to minimise MAME. In that case d3d works fine; but the crash happens with all other video modes. |
 No.16550
u-man Tester
Jun 16, 2019, 01:42
|
Can not confirm this bug with 0.209 It doesnt crash for me in gdi, bgfx or d3d- (hlsl on) mode. It behaves normal, like it should. I am on Windows 10 64bit, i7, nvidia 1080gtx. Only thing that is true (for bgfx) is, the app you're tabbing to, won't appear and mame won't go to the background. Other modes does that properly. You can solve this problem with ALT+Enter (while in MAME) or Windows key. Other than that, everything is working fine for me. |
 No.16551
Tafoid Administrator
Jun 16, 2019, 02:28
|
Are you simply loading the UI (load no game) then doing ALT+TAB from the UI while in Full Screen? Some people report it for all video types - for me it only exhibits in d3d. It is valid. |
|
No.16552
u-man Tester
Jun 16, 2019, 08:15
edited on: Jun 16, 2019, 08:20
|
Ah ok, i see the problem now. Yes, i started a game before. That did work normally. Small solution: You can select "configure options" and after that "customize UI". Choose "hide filters" (left sidepanel) and then save the config. Should work after that and behave correctly in d3d. At least on my side. All other modes have "the app you're tabbing to, won't appear and mame won't go to the background." Simply said, hiding the "filter section" solves the problem. |
 No.16562
hap Developer
Jun 18, 2019, 11:53
|
Crash is fixed for D3D, but the alt-tab-not-working-at-all bug in fullscreen for the other renderers is still there. |
|
No.16563
u-man Tester
Jun 18, 2019, 12:20
|
The alt-tab-not-working-at-all bug in fullscreen for the other renderers is there, because it was fixed only for d3d/HLSL and this fix was done by Jezze. I do not want any beef with you devs or wash dirty laundry here. When i finish my work, i can help you point out, at which MAME version Jezze fixed this and maybe someone can adopt the fix for the other renderers. If you want to know, why Jezze fixed this only for d3d/HLSL, please PM me. |
|
No.16564
u-man Tester
Jun 18, 2019, 18:29
|
Ok, i have looked into it. From MAME 0.180, the bug was fixed for d3d/HLSL. It should be this commit from Jezze: https://github.com/mamedev/mame/commit/c4b8e48b579c68fc5a095eb7524ece378bfa5248 Hope it can help you. |
|
No.16565
hap Developer
Jun 18, 2019, 21:19
|
https://mametesters.org/view.php?id=6417 That was a crash with HLSL enabled, not related to alt-tab problem that even the simple GDI renderer is having. |
|
No.16566
u-man Tester
Jun 19, 2019, 00:53
edited on: Jun 19, 2019, 01:07
|
"That was a crash with HLSL enabled, not related to alt-tab problem that even the simple GDI renderer is having." This is not true. With 0.179 you can alt+tab a game, but you will not be able to get back to MAME (or game). So it is alt+tab related, just the report is not complete enough. Try it and you will see what i mean. I must admit, that i never ever looked at this bug in that way. I mean testing d3d mode "without" HLSL. Before i go further, i would like to ask you some questions. It would help me better understand what is really wanted and maybe i do not need to write a long text. Would you agree with me, that this bug-report here, or better some posts in it, describe at least two bugs? One is the gui filter section+alt+tab, which you fixed now (i guess it is more gui related and less the d3d renderer mode) and one is a any render mode+alt+tab, no matter if gui or game. Would you agree that we currently (with your fix) have at least two render modes, that is pure d3d and d3d+hlsl, that work properly now and as intended? Alt+tab (or windows key) works in gui and game mode properly. If i look now at the pure d3d mode alone, i would say this mode never had a problem with alt+tab (or windows key). In all my tested versions today (0.170-0.180), d3d alone was always working properly and i guess, this would still be valid for many versions before. The gui+alt+tab bug here, is a exception and in my eyes not really d3d to blame for. If you want the other renderers to work properly, then the solution must be somewhere in the pure d3d or in the d3d+hlsl renderer, as both are working. |
|
No.16567
hap Developer
Jun 19, 2019, 09:42
|
Yes they are different bugs. The one in this MT report was fixed by me. And another related bug was fixed by yz70, this 1: https://github.com/mamedev/mame/issues/4763 |
|
No.16568
Robbbert Senior Tester
Jun 19, 2019, 10:01
edited on: Jun 19, 2019, 10:02
|
Tested current git against the bug as originally reported - no problems. Tested also against issue 4763 - no problems. So, resolving. If there's issues involving HLSL or other matters not covered by this bug, please open a new report - after the release of 0.211 and you must confirm against 0.211 or later. |
|
No.16571
u-man Tester
Jun 20, 2019, 14:27
|
@Robbbert: Here is my problem. If i need to wait, till next release, i will not have the time to report the next related bug to this one ( at least not for another 2 weeks because of work) and probably would need to start from scratch again. Looking for a bug that old (3 years or older), is very exhausting and time consuming. I am sadly not smart enough, to fix a bug, but i hope that i can help you, to narrow down the problem, like in this case here. The alt+tab (or windows key) problem with all the other render modes that are not minimizing MAME, is a very old one and i do not think, that it will be solved with 0.211 . Would it be ok for you all, to just create a new report without waiting for next release? |
|
No.16572
Robbbert Senior Tester
Jun 20, 2019, 16:07
|
Which render modes? |
|
No.16573
u-man Tester
Jun 20, 2019, 16:28
edited on: Jun 20, 2019, 16:36
|
gdi, bgfx, glsl are not minimizing MAME, when alt+tab or windows key is pressed. MAME stays still in front/foreground and is not minimizing, like it should. Only d3d or d3d+HLSL is working properly. |
|
No.16578
Robbbert Senior Tester
Jun 21, 2019, 02:48
|
Well, they all worked correctly for me.... then I thought maybe you're using full screen. So, in full screen the problem occurs as you described - but no crash. Since this bug is about a crash, the problem is solved and so it's done and over with. u-man you can create a new report when you're ready, and just copy from here any notes of relevance. |