Georgie Posted July 1, 2012 Share Posted July 1, 2012 Does CMFI have an even better solution for the OOM problem? 0 Quote Link to comment Share on other sites More sharing options...
Lt Belenko Posted July 3, 2012 Share Posted July 3, 2012 I'm not familiar with the OOM problem? is that the opposite of the lack of dead cows problem; otherwise known as the MOO problem? 0 Quote Link to comment Share on other sites More sharing options...
Georgie Posted July 3, 2012 Author Share Posted July 3, 2012 Not quite. Its an "out of memory" problem where your computer crashes on huge scenarios. BF has already almost completely corrected the problem with the latest patch but it is still possible to reach an out of memory condition. CMFI uses less polygons in models and I am wondering if this or some other better utilization of polygons has corrected the OOM problem even better. 0 Quote Link to comment Share on other sites More sharing options...
sburke Posted July 3, 2012 Share Posted July 3, 2012 Not quite. Its an "out of memory" problem where your computer crashes on huge scenarios. BF has already almost completely corrected the problem with the latest patch but it is still possible to reach an out of memory condition. CMFI uses less polygons in models and I am wondering if this or some other better utilization of polygons has corrected the OOM problem even better. That would seem to be implied in some of their statements. I certainly hope so and not just across size, but also based on content. I understand trees can really drag the game, though I haven't played that many really large forested maps. That will change by the time we get to a Bulge game and perhaps before depending on what scenario content we see when the MG module comes out. 0 Quote Link to comment Share on other sites More sharing options...
Broadsword56 Posted July 3, 2012 Share Posted July 3, 2012 But if they're winter (naked) trees, maybe that will save a bit of strain on the silicon - since there's no need to represent all that foliage blowing around. 0 Quote Link to comment Share on other sites More sharing options...
sburke Posted July 3, 2012 Share Posted July 3, 2012 But if they're winter (naked) trees, maybe that will save a bit of strain on the silicon - since there's no need to represent all that foliage blowing around. I was thinking Pine trees (covered in snow!) for Bulge and for MG possibly some of the Huertgen fighting. I have already taken a stab at a large Schmidt map and depending on the size and focus of the map it could be really heavily forested. 0 Quote Link to comment Share on other sites More sharing options...
Childress Posted July 3, 2012 Share Posted July 3, 2012 Does CMFI have an even better solution for the OOM problem? You have 1.10 installed? Haven't suffered a visit from the OOM alien since then. 0 Quote Link to comment Share on other sites More sharing options...
Vanir Ausf B Posted July 3, 2012 Share Posted July 3, 2012 AFAIK the OOM crashes were caused by the game running out of usable system RAM. I suspect that polygons and normal maps are stored in video RAM. 0 Quote Link to comment Share on other sites More sharing options...
Georgie Posted July 3, 2012 Author Share Posted July 3, 2012 But if they're winter (naked) trees, maybe that will save a bit of strain on the silicon - since there's no need to represent all that foliage blowing around. Probably will. Seems like most of the trees in the Ardennes are pine though. Maybe I'm wrong. Also, will the snow in the branches add a lot to the polygon demand? 0 Quote Link to comment Share on other sites More sharing options...
Redwolf Posted July 3, 2012 Share Posted July 3, 2012 There are three problems that were all called OOM problems at some point: Running out of virtual memory on 32 bit machines on large scenarios (improved in latest patches)Some running out of virtual memory in PBEM (fixed earlier than the other)Running out of graphics memory. Not sure what the status of this one is. The way to tell this problem from the others is that this one gives you a dialog box clearly stating that it ran out of graphics memory, whereas running out of virtual memory is implemented as a crash-to-desktop in CMBN. 0 Quote Link to comment Share on other sites More sharing options...
Childress Posted July 3, 2012 Share Posted July 3, 2012 AFAIK the OOM crashes were caused by the game running out of usable system RAM. That's almost certainly true. 0 Quote Link to comment Share on other sites More sharing options...
Redwolf Posted July 3, 2012 Share Posted July 3, 2012 No, the OOM crashes were virtual memory, not physical memory, running out. Adding RAM was an unfortunate thing that some less technical people recommended and that cost a bunch of people some money for no effect. Adding video RAM against problem #3 did help, of course. 0 Quote Link to comment Share on other sites More sharing options...
Georgie Posted July 3, 2012 Author Share Posted July 3, 2012 You have 1.10 installed? Haven't suffered a visit from the OOM alien since then. Yes I have 1.10 installed and so far haven't had an oom event while building a huge scenario ie 3000m x 4000m. But, I have experienced an oom event by adding trees treees trees and two yes two battalions for each side and bringing them together to exchange fire on a 4000m x 4000m map. Kinda of an extreme circumstance? Yes, but that is in CMBN, will the next game need more memory? Try snow, lots of trees, massive battles, maybe not IRL but massive battles by the very hard working and ever imaginative scenario designers. Im sure BF is aware of this and are taking steps to alleviate it. I'm wondering if the coding of CMFI already has the first step in alleviating this problem once and for all. 0 Quote Link to comment Share on other sites More sharing options...
Vanir Ausf B Posted July 3, 2012 Share Posted July 3, 2012 How much system RAM and video RAM does your comp have? 0 Quote Link to comment Share on other sites More sharing options...
Georgie Posted July 3, 2012 Author Share Posted July 3, 2012 How much system RAM and video RAM does your comp have? I have a new computer built just for CMBN. It has 12 gig ram and 24 gig virtual mem so that shouldn't be a problem. My operating sys is 64 bit and I sure would like to be able to use it on CM. I think that BF is making a mistake sticking with 32 bit. 0 Quote Link to comment Share on other sites More sharing options...
Georgie Posted July 3, 2012 Author Share Posted July 3, 2012 Here is the plan. Stick with 32 bit thru the CMBN game and go to 64 bit with the Bulge game. CMFI will have to struggle along with 32bit. But, to do any thing outstanding compared to what they have already done with CMBN and CMFI BF will have to go to 64bit. Believe me, I think that CMBN is the cats meow and CMFI will be too. But BF is gonna need lots more bits for the Bluge and the OST front. 0 Quote Link to comment Share on other sites More sharing options...
Vanir Ausf B Posted July 3, 2012 Share Posted July 3, 2012 Good plan! 0 Quote Link to comment Share on other sites More sharing options...
Battlefront.com Posted July 7, 2012 Share Posted July 7, 2012 Im sure BF is aware of this and are taking steps to alleviate it. I'm wondering if the coding of CMFI already has the first step in alleviating this problem once and for all. We're always looking for ways to improve stability, but I can promise you that without artificial restrictions on what people put into their scenarios (map features and units) there will always be people that find themselves out of memory. And of course we also have the fun of being hit by bugs or oddities within the various flavors of OSes and drivers to contend with. Short of it is we feel the OOM problems are solved to our satisfaction for now. We haven't done anything specific for Version 2.0 in this area. However, we have made other changes that most likely will make a difference. I can't promise it will, though, because we've not had a specific situation to test out. Steve 0 Quote Link to comment Share on other sites More sharing options...
Redwolf Posted July 7, 2012 Share Posted July 7, 2012 We're always looking for ways to improve stability, but I can promise you that without artificial restrictions on what people put into their scenarios (map features and units) there will always be people that find themselves out of memory. And of course we also have the fun of being hit by bugs or oddities within the various flavors of OSes and drivers to contend with. Short of it is we feel the OOM problems are solved to our satisfaction for now. We haven't done anything specific for Version 2.0 in this area. However, we have made other changes that most likely will make a difference. I can't promise it will, though, because we've not had a specific situation to test out. Steve Well, is there a status update on a windows 64 bit version? That would get rid of the virtual memory exhaustions for good. And the mac version already is 64 bits so it seems the code can't be too 64 bit unclean. 0 Quote Link to comment Share on other sites More sharing options...
Georgie Posted July 7, 2012 Author Share Posted July 7, 2012 We're always looking for ways to improve stability, but I can promise you that without artificial restrictions on what people put into their scenarios (map features and units) there will always be people that find themselves out of memory. And of course we also have the fun of being hit by bugs or oddities within the various flavors of OSes and drivers to contend with. Short of it is we feel the OOM problems are solved to our satisfaction for now. We haven't done anything specific for Version 2.0 in this area. However, we have made other changes that most likely will make a difference. I can't promise it will, though, because we've not had a specific situation to test out. Steve Thanks for the reply Steve, it sounds to me like Version 2.0 is another step in the right direction. 0 Quote Link to comment Share on other sites More sharing options...
Georgie Posted July 7, 2012 Author Share Posted July 7, 2012 No, the OOM crashes were virtual memory, not physical memory, running out. Adding RAM was an unfortunate thing that some less technical people recommended and that cost a bunch of people some money for no effect. Adding video RAM against problem #3 did help, of course. Hello Redwolf, this isn't the correct forum for me to ask this but we are on the subject. I am getting ready to install a SSD in place of my mechanical hardrive and the SSD instructions suggest that a minimum size "virtual memory" be used. Do you think that this will be a problem as far as the OOM condition is concerned? 0 Quote Link to comment Share on other sites More sharing options...
Redwolf Posted July 7, 2012 Share Posted July 7, 2012 Hello Redwolf, this isn't the correct forum for me to ask this but we are on the subject. I am getting ready to install a SSD in place of my mechanical hardrive and the SSD instructions suggest that a minimum size "virtual memory" be used. Do you think that this will be a problem as far as the OOM condition is concerned? No, that is just Microsoft using the term "virtual memory" incorrectly in some of it's consumer facing documentation. What they mean there is swapspace, or paging space, which is a form of physical memory. They use these terms correctly in their programmer facing documentation. CMx2 runs out of virtual address space. No amount of buying RAM or adding swapspace will do anything about it. Of course you could manage to run out of physical memory if you have few RAM and don't add swapspace but that wasn't a factor in CMx2 crashes as discussed at length here. At least BFC did enable the large address aware bit in the latest patches (CMBN and I think CMSF, can anyone confirm?). So you get as much as your OS can deliver without using special tricks on your part. 0 Quote Link to comment Share on other sites More sharing options...
Georgie Posted July 8, 2012 Author Share Posted July 8, 2012 No, that is just Microsoft using the term "virtual memory" incorrectly in some of it's consumer facing documentation. What they mean there is swapspace, or paging space, which is a form of physical memory. They use these terms correctly in their programmer facing documentation. CMx2 runs out of virtual address space. No amount of buying RAM or adding swapspace will do anything about it. Of course you could manage to run out of physical memory if you have few RAM and don't add swapspace but that wasn't a factor in CMx2 crashes as discussed at length here. At least BFC did enable the large address aware bit in the latest patches (CMBN and I think CMSF, can anyone confirm?). So you get as much as your OS can deliver without using special tricks on your part. Thank you for the input Redwolf. 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.