Modifié par JironGhrad, 17 novembre 2009 - 05:08 .
Memory leak ?
#51
Posté 17 novembre 2009 - 05:04
#52
Posté 17 novembre 2009 - 05:25
I reinstalled the game, thanks to patch 1.01b. However, this time, I forgot to place DAO into my special gaming folder, but I let it go straight to the Program Files (x86) default folder of Windows Vista. Lo and behold, I have been playing for ~30 minutes (through the entire Red Cliff village undead defending quest) with no lag at all.
Crossing my fingers and waiting for a longer session tomorrow in the Red Cliff castle.
#53
Posté 17 novembre 2009 - 07:16
Core 2 Duo 2.3Ghz (OC 3.2Ghz)
4Gb 800MHz Ram
Before I start playing RAM usage is around 20% Startup DA:O and It's around 30% Start playing and as I pass through loading screens it reaches 75% and will never go higher. After I reach the 75% usage point the loadtimes increase, from seconds to several minutes. I watch the ram usage at the loading screens and it seems to clear very slowly once it drops by a varying amount it's as if it begins loading propely and the ram returns to 75% and the next area loads.
Hope this helps
#54
Posté 17 novembre 2009 - 02:56
#55
Posté 17 novembre 2009 - 04:27
Instead, the load and performance issues demonstrate growth characterized by a resource leak or algorithmic error. Note that I use the words resource leak as opposed to memory leaks.
My guess is that it's a leak in a thread that gets much less CPU time if you don't have extra cores available.
Oblivion had a bug like that in Shivering Isles. There, this lead to something else than a slowdown, but it hit people with fast machines harder/sooner.
#56
Posté 17 novembre 2009 - 08:04
The truth is, the game currently suffers from, at minimum, 2 separate serious technical/programming issues, and more than likely 3-4 DIFFERENT ISSUES : )
Issue #1: Maxing the effin hell out of our CPUs. Pegging all cores at 100% from the outset of the game with zero relaxation is a problem in itself, and is irrefutably NOT a “memory leak”. This is ranked #1 because it is hands down the most severe and serious of the issues. It causes much of the crashing, slowdowns, and BSODs. Those 3 things I just listed are what the medical community would call…..”symptoms” lol. When you peg out a CPU at 100% load for hours upon hours it will begin to cause an insane amount of heat, and if that particular system is not adequately equipped with an expensive aftermarket case & cooling system, immediate problems will ensue. Those can be, but not limited to, crashing, slowdowns, & BSODs. But even for systems like mine with the very best cooling systems, having a CPU pegged at 100% for hours upon hours, days upon days will most certainly cause problems of the worst kind. System-wide degradation as a result of a dying CPU is almost guaranteed for everyone if they play long enough with their CPU pegged at 100%. I have had CPUs die on me plenty of times – I’m an overclocker. It is NOT fun. Hence, the CPU issue is, without question, public enemy #1. As some have stated, this is not anything we have any control over and it is a rampant problem. The ONLY way this can be alleviated is by a patch, as it is certainly a programming/coding issue.
Issue #2: Reported Memory Leak. I wasn’t sure there actually was one (still not 100%), but the fellow who said his system hit 5.5GB usage and crashed…..well…….that definitely sounds like a memory leak for a 32bit app. But for the love of god please stop intertwining the two! Sheesh people….
If you want to be able to visualize the difference, pause the game, alt-tab, and bring up your Task Manager. With the game MINIMIZED, take a look at the CPU usage….. Its still pegged at 100%. I don’t know about you guys, but most every PC game I have played in the last decade will cap the FPS at a small number (usually 10-30ish FPS) when the game is minimized and use less than 10% CPU time (usually less than 5%). Never once have I seen a minimized game continue to press the CPU to the edge of madness without remorse. That folks…..is no memory leak. That is an entirely different issue and a very troubling one.
But aside from that, its one helluva game hehe. But they gotta fix the CPU issue asap or they will have the blood of a million CPUs on their hands and a PR nightmare to boot o_0
#57
Posté 17 novembre 2009 - 10:35
#58
Posté 17 novembre 2009 - 10:47
#59
Posté 17 novembre 2009 - 11:35
#60
Posté 18 novembre 2009 - 12:12
Otherwise, I have had no other major issues with the game. Some smaller complaints, but nothing anywhere near game-killing. All in all, I have been enjoying the game immensly.
Windows XP Home (2002) SP 3
AMD Athlon 64 X2 dual core 4600+ at 2.41 GHz
2 GB Ram
NVIDIA GeForce 8600 GTS
#61
Posté 18 novembre 2009 - 12:19
#62
Posté 18 novembre 2009 - 05:27
#63
Posté 18 novembre 2009 - 07:58
Restarting every hour or two alleviates this, but it's a pretty big annoyance...
#64
Posté 18 novembre 2009 - 04:16
This permits the 32-bit application to have more than 2G of "address space". Address space means more than just RAM here; an application can (and will) use more address space than RAM.GvazElite wrote...
what does this enable exactly
I got it as a part of Microsoft Visual C++ Express 2008. That's an awful lot to install just to get one tiny utility... there must be something smaller out there that people can use! Maybe I should just write one.andysdead wrote...
where do you get editbin from?
#65
Posté 18 novembre 2009 - 04:42
I played for about 3 hours and the load times did not get above 20 seconds or so (per the G15 stop watch). Per the task manager "performance" tab, DA:O was using around 2Gb once actually in game and did not go above about 2.8ish Gb.I did notice however much more HDD activity due the page file being accessed more. Also I did notice that DA:O about the same amount of RAM (2.5Gb) for most of the time, but there were drastic spikes (maybe when loading?) and it would go back down to a relatively level graph.
I was doing pretty much just doing the side (chanter, irregulars, etc) quests so I was bouncing all over the place and must have loaded 20 times.
I wonder if it is an issue of the game (or related process) not purging memory once it has loaded the level. And is clinging onto the previous levels junk, or maybe a certain portion of it?
I wonder if there is a console command to purge the memory? I know this has been possible in other games (Arma 2 comes to mind).
I'll try it again tonight with 8Gb where the pagefile will not come into play.
On a side note my processors are not running 100% either, they do hover around 75% when loading a level, but typically hover around 50-60%. One may occasionally spike to 100% .
#66
Posté 18 novembre 2009 - 05:10
Galaxyrise wrote...
Since the thread on the daforums is gone, I wanted to post what worked for me (Win7 64-bit): Enabling "Large Address Aware" in the game's executable. To do that, I used a developer tool, editbin. Someone else posted a utility you can download to make the same change... perhaps someone else can do the same.
Tried the affinity thing but didn't work. This however worked and a big thanks for that!
I enabled the Large Address Aware with a software called LaaTiDo.
System specs if anyones interested:
Intel Quad Core Q8200
4GB DDR2 800MHz RAM
Geforce 8800GTS 512MB
Windows 7 Ultimate 64-bit
#67
Posté 18 novembre 2009 - 05:33
System spec:
Processor: AMD Athlon 64 X2 Dual Core Processor 4600+ (2 CPUs), ~2.4GHz
Memory: 4096MB RAM
Card name: NVIDIA GeForce GTS 250
Windows 7 Ultimate 32-bit
Modifié par Las0mbr4, 18 novembre 2009 - 05:37 .
#68
Posté 18 novembre 2009 - 06:23
Finished my first run through yesterday and watched the credits.
They behaved very strangely speeding up and slowing down depending on the blood ink blot graphics.
Just wondering if it was these ink blot thingies on the loading screen causing the problem not the actual loading, making it a graphical memory issue.
Just my computer illiterate observation.
#69
Posté 18 novembre 2009 - 06:33
Marvin TPA wrote...
Have been having the slow load problem and have pretty much got in the habit of hitting F5, F9 every now and then to keep things moving.
Finished my first run through yesterday and watched the credits.
They behaved very strangely speeding up and slowing down depending on the blood ink blot graphics.
Just wondering if it was these ink blot thingies on the loading screen causing the problem not the actual loading, making it a graphical memory issue.
Just my computer illiterate observation.
Hmmm, oddly enough when I am on a loading screen, my FPS counter sits around 14 FPS, which is odd for a loading screen. Maybe there is an issue with the process that makes that ink/blood splotch spread across the loading screen, or the rotating tribal type ring that rotates, causing the game to overload the memory on the video card or the system ram?
Modifié par zacrobmer, 18 novembre 2009 - 06:39 .
#70
Posté 18 novembre 2009 - 10:14
#71
Posté 18 novembre 2009 - 11:05
Well since i tried almost every "placebo" fixes around the forums (affinity set in 1 core - downloading beta drivers for gfx card - playing on windowed mode - changing power plans to high/low - setting compability to winxp SP3 - running daorigins.exe as administrator and some other things i dont recall atm) i think i will give it a shot by updating my win7 to 64 bit version.
#72
Posté 18 novembre 2009 - 11:13
ByblosHex wrote...
It can't be a memory leak or it would affect everyone.
ByblosHex wrote...
Its a forums, so im not going to be 100% completely detailed and specific in every post I make. Obviously it could be a memory leak.
On topic: I've had similar issues, but just work around. What's the harm in taking a break every couple hours?
#73
Posté 18 novembre 2009 - 11:25
Try this software guys. I'm downloading it right now to see if i'll be able to turn on Large Address Aware.
Manual how to do it for 64bit and 32 bit systems:
www.jaloonz.com/2008/04/enabling-large-address-aware-for-games.html
Modifié par Goryen, 18 novembre 2009 - 11:28 .
#74
Posté 18 novembre 2009 - 11:43
I also set compatibility to XP, that may have helped as well.
#75
Posté 18 novembre 2009 - 11:44
I also set compatibility to XP, that may have helped as well.





Retour en haut






