Jump to content
The Dark Mod Forums

Savegame problems


Haplo

Recommended Posts

  • Replies 106
  • Created
  • Last Reply

Top Posters In This Topic

the loop above could be aborted once the entity is found, since there should be ever only one. But I don't think that matters.

That's on purpose, there can indeed be more than one entity of that type.

 

Maybe the DifficultyManager is not properly cleared upon reload? It also seems to have "subobjects" and calls store/restore on them, maybe these objects are the problem? Just brainstorming.

Not that I could see - also, there is no technical difference between a quickload and an ordinary load, both call the "loadgame" routine.

 

 

Wouldn't it be better to cache the value of _settings.Num() in the tight loop? Calling the method a few thousand times must be much more expensive than comparing to an integer. Noticed such constructs all over the place, and a few million calls will add up needlessly.

Not worth the effort at all, the Num() routine will be inlined in release builds, as Crispy mentioned, and there are far more performance-eating tasks than this one. Optimising things on this micro-level (where performance is not even critical) is just wasted effort in the end, and the code is not more readable afterwards either. There are not even many difficulty settings stored in that list too, maybe a dozen or so.

Link to comment
Share on other sites

If the save issues can be sorted, should we consider rolling out a minor update?

It will be fixed in the next regular release. It's not like we can just take our current gamex86.dll and push it out, as other dependent changes (scripts, defs) need to be rolled out as well (and they need to be tested beforehand). All or nothing in this case, and I'd rather not rush out an untested update, this will seriously backfire on the team in terms of support.

 

Maybe it's an easy fix and I can provide a non-breaking DLL, let's see.

Link to comment
Share on other sites

Ah, I found the problem. There is indeed a Clear() call missing in between load calls, which I thought was happening automatically. Or maybe I confused MapClear() with Clear() in gameLocal, who knows, it's been a while since I touched that code.

 

Expect this problem to be gone in the next release. For the people here experiencing this problem, I guess I can provide a fixed DLL, totally unsupported of course.

Link to comment
Share on other sites

Here's a fixed DLL (Windows only) for those people having problems in Patently Dangerous: http://www.bloodgate.../tdm_game01.pk4

 

Let me know if this fixes the problem. It probably won't remedy your bloated saves, but when starting the mission afresh the problem shouldn't happen anymore.

Link to comment
Share on other sites

Now I'm getting savegame crashes on my Heart map. Presumably this game pk4 is the same as on today's SVN update?

No, this PK4 I linked above is only for players of the 1.00 release. Your SVN version is independent, needless to say.

 

If you're having crashes with SVN, the internal forum is the way to go.

Link to comment
Share on other sites

I installed the patch, deleted my bad saves, and recreated them. So far it has prevented the save game bloat. At one point my Quicksave was up to around 200 MB, and another named save was around 100 MB. Now after 10-20 saves into Quicksave, it is still at 22 MB. I looked at a couple other FMs, including Crown of Penitence that had crashed several times previously, and there were no bloated saves in there.

Edited by smithpd
Link to comment
Share on other sites

Saving is not exactly performance-critical (it doesn't happen every frame; far from it). Also note that the time required to write stuff to disk will certainly dominate, and probably even mask, the time required to jump around in memory to pull out that integer value. (By "mask", I mean that the CPU is probably bottlenecked by disk access anyway, so optimising its memory access at this point would simply mean that it ended up waiting longer for the disk! End result, no actual speed improvement.)

 

It was more a general question, not specific to this instance of "during save".

 

Plus, in theory that call could be partially/wholly optimised away by the compiler, turning it into a simple pointer lookup, which once in L1 cache is pretty fast anyway. In practice it may or may not be optimised very much (only way to be sure is to check the generated assembly code).

 

I think I need to make a small example and try that and see how far it is optimized away. All I know is that gcc is particular bad with that, it almost never inlines object oriented stuff (or actually it inlines it by generating two dozend opcodes...)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I think I need to make a small example and try that and see how far it is optimized away.

That would certainly be instructive. Be careful about drawing conclusions about the actual performance of that code in a real-world setting, though. I'm not saying that it's never worth optimising such loops, but all serious performance analysis must be led by profiling results, not gut feelings that "this code looks slow". Gut feelings about performance tend to be wrong and/or irrelevant (unless you're really, really experienced).

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to comment
Share on other sites

Like Crispy said that is almost certainly optimized away by the compiler.

In the old days you needed to do it yourself.

Loop unrolling for example and specifying register for a variable to ask(no guarantee) the compiler to place it in a register to speed up access.

 

Nowadays you do not need to go to those extremes though we aren't running 486's anymore after all and compilers are super smart compared to the old days.

I haven't lost my mind. It's backed up on disk!

Oops bad sectors damn floppy's!

Link to comment
Share on other sites

  • 3 weeks later...

I've run into this bug too, with Patently Dangerous.

 

Here's a fixed DLL (Windows only) for those people having problems in Patently Dangerous: http://www.bloodgate.../tdm_game01.pk4

 

Let me know if this fixes the problem. It probably won't remedy your bloated saves, but when starting the mission afresh the problem shouldn't happen anymore.

For Linux (Ubuntu 9.10), compiling the SVN code should fix it, yes? Will Sparhawk let me in if I ask nicely?

Link to comment
Share on other sites

I've run into this bug too, with Patently Dangerous.

 

 

For Linux (Ubuntu 9.10), compiling the SVN code should fix it, yes? Will Sparhawk let me in if I ask nicely?

 

I can compile you a new version, greebo, which SVN revision should I use?

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I can compile you a new version, greebo, which SVN revision should I use?

 

Check out the 1.00 release branch (/branches/release1.00) in the darkmod_src repo and apply this patch:

 

Index: game/game_local.cpp

===================================================================

--- game/game_local.cpp (revision 3746)

+++ game/game_local.cpp (working copy)

@@ -2073,6 +2073,7 @@

m_RelationsManager->Clear();
}
m_ConversationSystem->Clear();
+ m_DifficultyManager.Clear();

// greebo: Don't clear the shop - MapShutdown() is called right before loading a map
// m_Shop->Clear();

 

(Important: don't commit anything, as this changes the revision tags in the code.).

Link to comment
Share on other sites

If you know how, compiling the TDM code should fix it. It's on the download page of www.thedarkmod.com _> http://www.bloodgate...od.1.00.src.zip

Feeling adventurous I grabbed the code and patch, ran into the same problems as Hyeron here and copied his solution (build in a Hardy VM).

I started over on Patently Dangerous, and it is indeed fixed, save game size is down from 425 MB to 27 MB... And the game no longer crashes on reload, so I could finally get rid of 'the man upstairs'.

Thanks for the help. :)

Link to comment
Share on other sites

Too little time, sorry. You can add your issue to the bugtracker, but I cannot make any promises at this point. (With the little time which is left in between work, my family and other hobbies I found that it's better when I focus on one of the two projects at a time. Trying to work on both just stretches myself too much and I don't accomplish much for either of them. At the moment, I'm in DarkRadiant mode.)

 

Also, from the description it's sounding like a very strange problem, not sure if this is happening to anybody else, or what I could possibly do to investigate it.

Link to comment
Share on other sites

Too little time, sorry. You can add your issue to the bugtracker, but I cannot make any promises at this point. (With the little time which is left in between work, my family and other hobbies I found that it's better when I focus on one of the two projects at a time. Trying to work on both just stretches myself too much and I don't accomplish much for either of them. At the moment, I'm in DarkRadiant mode.)

 

Also, from the description it's sounding like a very strange problem, not sure if this is happening to anybody else, or what I could possibly do to investigate it.

 

That is fair enough.

 

I have VC9 installed and can debug the code. But before that it would be nice to have a feedback from the code about what is going wrong. That is fair enough. Is there a logging feature I could enable to see what is exactly happening? Surely there must exist some logging facility?

Link to comment
Share on other sites

Yes, there is a log file. Open darkmod/darkmod.ini and set all the debugging settings to 1. By default it'll create a file Darkmod.log in your Doom 3 directory (or, in Linux, your home directory), or you can change the path in the ini file. This may or may not help you though.

 

My first step would be to run it in a debugger, trigger the crash, and look to see where it crashes. If you post the stack trace here we may be able to provide some insight.

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to comment
Share on other sites

Ok I have some information for you guys. The circumstances that trigger the crash are described as issue #1 in the first post of this thread. To trigger the crash I quickloaded. I used VC9. The game crashes in thedarkmod\win32\include\boost\detail\sp_counted_base_w32.hpp, line 100:

 

void release() // nothrow
{
   if( BOOST_INTERLOCKED_DECREMENT( &use_count_ ) == 0 ) //<--- crashes here
   {
       dispose();
       weak_release();
   }
}

 

 

The stack trace is:

 

gamex86.dll!boost::detail::sp_counted_base::release()  Line 100 + 0x9 bytes	C++
gamex86.dll!boost::detail::shared_count::~shared_count()  Line 208	C++
gamex86.dll!boost::shared_ptr<ai::Mind>::~shared_ptr<ai::Mind>()  + 0x19 bytes	C++
gamex86.dll!_CallSettingFrame(unsigned long funclet=0x02feee9c, unsigned long pRN=0x00000103, unsigned long dwInCode=0xd4153d4c)  Line 73	Asm
gamex86.dll!__FrameUnwindToState(EHRegistrationNode * pRN=0x02feee9c, void * pDC=0x02fecfd0, const _s_FuncInfo * pFuncInfo=0x0a9cb6e0, int targetState=0xffffffff)  Line 1151	C++
gamex86.dll!__InternalCxxFrameHandler(EHExceptionRecord * pExcept=0x02fed490, EHRegistrationNode * pRN=0x02feee9c, _CONTEXT * pContext=0x02fecfdc, void * pDC=0x02fecfd0, const _s_FuncInfo * pFuncInfo=0x0a9cb6e0, int CatchDepth=0x00000000, EHRegistrationNode * pMarkerRN=0x00000000, unsigned char recursive=0x00)  Line 479 + 0x13 bytes	C++
gamex86.dll!__CxxFrameHandler3(EHExceptionRecord * pExcept=0x02feee9c, EHRegistrationNode * pRN=0x02fecfdc, void * pContext=0x02fecfd0, void * pDC=0x02feee9c)  Line 365 + 0x1f bytes	C++
ntdll.dll!7c9032a8() 

 

 

And the disassembly:

 

 

        if( BOOST_INTERLOCKED_DECREMENT( &use_count_ ) == 0 )
0A494C7F  mov         eax,dword ptr [this] 
0A494C82  add         eax,4 
0A494C85  or          ecx,0FFFFFFFFh 
0A494C88  lock xadd   dword ptr [eax],ecx ; <---------- crashes here
0A494C8C  dec         ecx  
0A494C8D  jne         boost::detail::sp_counted_base::release+3Dh (0A494CADh) 

 

 

The crash reports says "Access violation writing location 0x0e41ce04". That is the value of EAX (the value of ECX is 0xFFFFFFFF just in case). Basically 'this' is junk for some reason. Attempting to look at 'this' in the watch window shows:

 

this	0x0e41ce00 {use_count_=??? weak_count_=??? }	boost::detail::sp_counted_base * const
__vfptr	CXX0030: Error: expression cannot be evaluated	
use_count_	CXX0030: Error: expression cannot be evaluated	
weak_count_	CXX0030: Error: expression cannot be evaluated	

 

 

I have limited knowledge of Dark Mod source code, but I am a member of openDarkEngine team and we have had similar problems before. My guess is that for loading a new game, or getting to the stats window, or just quitting the game the current session has to terminate. In the termination process a class instance gets destroyed, but one of its member functions gets called afterwards. There is probably a mistake in the order of things getting destroyed in the code that ends the session.

Link to comment
Share on other sites

When maps are changed or the mission is ending, the engine code (closed source) is calling idGameLocal::MapShutdown() which in turn calls MapClear(true) which is deleting all the entities, which is where the ~idAI() destructors are invoked.

 

gamex86.dll!idAI::~idAI() Line 589 C++

gamex86.dll!idAI::`scalar deleting destructor'() + 0x16 bytes C++

gamex86.dll!idGameLocal::MapClear(bool clearClients=true) Line 1985 + 0x2d bytes C++

gamex86.dll!idGameLocal::MapShutdown() Line 2047 C++

 

The stacktrace you posted is different, which suggests that there is an unhandled exception going on (see also "UnWind"). Usually the line below MapShutdown() is located in DOOM3.exe, not ntdll.dll, or are these stackframes not reliable? Maybe there is some sort of exception leaking through the engine coming from an OS-level call?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...