 |
I checked it some time ago, and as far as I remember, there crash was in VertexCache. Assigned it to Duzenko, since he was the only one to change it after 2.07. |
 |
With com_smp 1 I get a hang in frontend wait With com_smp 0 I get a crash with stack trace > TheDarkModx64NoTools.exe!R_ReallyFreeStaticTriSurf(srfTriangles_s * tri) Line 377 C++ TheDarkModx64NoTools.exe!R_FreeDeferredTriSurfs(frameData_t * frame) Line 471 C++ TheDarkModx64NoTools.exe!R_ToggleSmpFrame() Line 187 C++ TheDarkModx64NoTools.exe!idRenderSystemLocal::EndFrame(int * frontEndMsec, int * backEndMsec) Line 688 C++ TheDarkModx64NoTools.exe!idSessionLocal::UpdateScreen(bool outOfSequence) Line 2740 C++ TheDarkModx64NoTools.exe!idCommonLocal::Frame() Line 2512 C++ Both ways I'm not sure on a fix Am I correct that fm's like NHAT should be broken now? |
 |
No, NHAT is three different missions. Each mission knows nothing about the next. I checked released missions, and the only one using target_endlevel is the "Sound Trainer". The first map includes helmet-less guards to test your blackjacking skills. Next to your starting position, a lever sends you to the second map, where you can test with helmeted guards. That mission works fine in 2.07, but crashes with the current SVN, so it's a second data point. |
 |
If it crashes in "ReallyFreeStaticTriSurf" in one of the allocators, it may not have anything to do with the VertexCache at all, but potentially your threading changes in the frontend. I remember vaguely that in my own attempts to thread the frontend, I had removed/replaced all of these allocators because they were inherently not thread-safe. Of course, since you probably used a different approach, my findings from way back then may not apply, but it's just an idea. Either way, I don't think I can help you with this. |
|
|
I think by default all parallel stuff is disabled. Especially with com_smp 0. Let's fix it first. |
|
|
The revision 8477 seems to resolve the single thread case but I still think @cabalistic needs to look at frontend sync when changing maps on the fly |
|
|
As of 15781/8548, there's no crash with 'com_smp 0'. It hangs during the second map load when 'com_smp 1'. Since I was using 'com_smp 0' when I filed the report, I'll assume that something got fixed after that that at least allows 'com_smp 0' to work around the problem. |
|
|
I suggest replacing: MoveToNewMap( args.Argv(1) ); with: cmdSystem->BufferCommandText( CMD_EXEC_INSERT, ret.sessionCommand ); in idSessionLocal::RunGameTic. This way map-changing commands produced by game code will be put for delayed execution as a console command. Then map change will start from main thread instead of frontend. The only problem is that game continues running for some time on frontend thread, and it continues to issue map change repeatedly. Something has to be done to avoid it. Another issue is that this way mission-loading GUI is displayed, while with direct call to MoveToNewMap picture freezes for some time, then jumps straight to "Hit Attack to start". |
|
|
I decided not to change the logic, but instead give the Session a generic way to delay execution of certain code until after the current frame has finished and the two threads are joined. It's not super elegant, but I think it is a safer approach and might come in handy if we encounter another edge case. (I do wonder why it was working in 2.07, though.) Btw, is the absence of a loading screen really desired? Particularly if the load takes a while, I would prefer and expect a loading screen.. |
|
|
I vote in favor of the loading GUI for this. It could potentially take minutes to load the assets for the 'other' map from slow storage. |
|
|
If the mapper wants to have no loading screen appear for maps beyond the first, they can include a unique loading screen w/o an image or loading bar. That's what I plan to do for mine, since the appearance of a loading screen "gets in the way" of what's happening. Perhaps a GUI that just says "Time passes ...". |
|
|
Well, I suggested using "console command" as a way to delay-execute code, but this will also do. Two comments about fix: 1) The case with "died" command already worked normally, because it turns on GUI. I hope you checked that it still works with com_smp on and off. 2) Putting std::function-s into idList is the worst thing to do. Better put idStr or idCmdArgs instead. Passing callbacks long way and between threads feels bad. P.S. I think idStrList should be stored, one string per command. EDIT: I reworked it myself in svn rev 8650. I hope you don't mind. |
- Anonymous
