Instalar Steam
iniciar sesión
|
idioma
简体中文 (chino simplificado)
繁體中文 (chino tradicional)
日本語 (japonés)
한국어 (coreano)
ไทย (tailandés)
Български (búlgaro)
Čeština (checo)
Dansk (danés)
Deutsch (alemán)
English (inglés)
Español de Hispanoamérica
Ελληνικά (griego)
Français (francés)
Italiano
Bahasa Indonesia (indonesio)
Magyar (húngaro)
Nederlands (holandés)
Norsk (noruego)
Polski (polaco)
Português (Portugués de Portugal)
Português-Brasil (portugués de Brasil)
Română (rumano)
Русский (ruso)
Suomi (finés)
Svenska (sueco)
Türkçe (turco)
Tiếng Việt (vietnamita)
Українська (ucraniano)
Comunicar un error de traducción
Asking and ♥♥♥♥♥♥♥♥ about it is two different things. It all about how you present yourself.
indeed lol.
There are also build logs from at least 2012.
The PC team was much smaller as R*'s primary focus was next-gen consoles. It was originally slated to release along with them and well it's easy to guess it was still a mess.
False:
For what you are saying to occur, the programming would have to be done on the metal level,
Memory management on modern operating systems (Since Win9x infact) is done virtually, the API and the Game do not get to touch registers directly and as such cannot remain forever in memory after having been loaded.
Under a virtual memory managed operating system, processes request a memory space of their own to operate in or request for it to increase by , with the Kernel itself performing the virtual <> physical mapping,
To put it in terms the majority will understand, the process Asks for space, and this space is provided in a Bubble, whatever the application does in this bubble affects only this bubble, this bubble can grow and shrink (under normal conditions) and have rarely used portions paged out to disk, unmapped, and freed as should be normal behavior of an application.
When the application exits, or is terminated forcefully, this bubble is destroyed by the OS, all of the data within the bubble is removed and the kernel free's the physical memory and any data paged to disk is also removed.
Application Memory Leaks are contained to the User Address Space, and are fully removed from memory once the offending process is terminated.
Driver memory leaks are contained to the Kernel Address Space and depending on whether they are high or low level drivers, may or may not be removed from memory once the driver is stopped.
I''ve field experience with programming and IT2 and a number of other IT fields that im not certified in
And I'm saying you are talking out your ass.
The issue is a textbook example of a modern Memory leak (your textbook seems stuck back in the PCDOS days), it can be reproduced under the games safe mode and affects both graphical and non graphical data,
At 800x600 with all settings off, this game should not be eating 5GB's of GPU Commit. (3GB Vram + 2GB dumped to page), and yet, it does.
I'm Squall from the Visual Boy Advance, XBCD, X360CE, NrageInput, Project64, eduke32..etc, its a long list of projects.
I just felt the need to call Shamanalah on his bs.
oh, for those interested,x360ce fully works with GTA5 now :)
True lol ^^^^^^^^^^^^
However, I have 16GB of RAM and even if it leaked quite a bit that would take quite some time to use up on a 64-bit system. But it also depends on whether or not GTA is a 64-bit or 32-bit app. If it's 32-bit without large address aware then it can only use 4GB else it can use all of my RAM. This might explain the timing of my crashes, etc,
If you want to see RAM usage then use the Process Explorer from SysInternals. Windows Task Manager is not a good tool to use for this.
A memory leak is simple. Allocate memory from the system and fail to de-allocate it. Or in C terms malloc without free and in C++ new without delete. However, given that C++ 11 has new constructs to assist with memory management like shared_ptr, weak_ptr, etc. most C++ programs will rarely use raw pointers so leaks will be less frequent. I'm not sure if games would use these or not and b/c I haven't been using C++ 11 much I don't know the overhead (if any) for using these constructs. They are from Boost and TR1 but not sure how they were implemented in MSVS.
Keep in mind even though this has the appearance of a memory leak it doesn't mean it has one. You would have to track memory usage over time and then find out what actions in the game caused it to jump. But in the end you really need to see the code to verify what is happening. Its very easy to be an armchair developer but code is complex and it could be a number of different things.
Best bet is to wait for a patch. Rockstar did a fantastic job on the port in general so I hesitate to go off half-informed and start making assumptions. The team that ported the game knew what they were doing but since it is the PC and there are a million different configurations out there its usually impossible to squash every issue before release. Give them time.
The game is 64bit,
Because the game excessively maps VRAM and fails to free old data, it spills out into and consumes additional Commit Charge which leads to even more physical memory and page file usage then it would if it was just a process memory leak.
Cool. Thanks for the link. Most of my hunting had turned up hearsay.