Yes, and the question is whether this whole load/offload aggregation is related to the 12-mod limit? Why do you think they did it?
MonarchX;n10520322 said:Yes, and the question is whether this whole load/offload aggregation is related to the 12-mod limit? Why do you think they did it?
SigilFey;n10515592 said:Most notably, there is a finite amount of memory (RAM) and other system resources that any engine is capable of utilizing. This is not governed by the amount of RAM on your system, but by the amount of RAM that the engine itself is coded to use.
SigilFey;n10520632 said:the maximum RAM required to load the game assets + mod assets ever exceeds the maximum RAM available in the engine at any instant
MonarchX;n10520692 said:No, still makes no sense because it's all under an assumption that mod COUNT has more influence on the game performance/function than mod CONTENT. 15 mods with a single 128x128 texture each will prevent the game from loading, but my giant 3.2GB MergedPack makes the game load faster than vanilla (due to one of the mods disabling store videos). Where's the logic in that? Besides, you can cripple performance with scripts alone or even settings.
MonarchX;n10520692 said:There is some kind of PER-BUNDLE limit. For example, HD Reworked Project 5.0 (HDRP5) has very large and heavy textures. If you try to uncook it, you get OUT OF MEMORY error during the process. There is no way to merge it to mere mortals, but those who seek the way tend to find it. The way around that is to use Cache Viewer...
Murzinio;n10523232 said:
https://github.com/freebsd/freebsd/blob/master/sys/contrib/octeon-sdk/cvmx-malloc/malloc.cSigilFey;n10524312 said:How much RAM will I have available in the game? Answer: LESS than 8 GB. The engine must obviously load its operating environment, and that alone is going to gobble up, say, 1 GB of RAM. Permanently. That means that even though my system has 32 GB, the engine is only written to recognize and utilize a maximum of 8 GB. It's 100% impossible to tell a program, "Just use unlimited RAM, loading unlimited processes into memory." The program won't know when to stop and will max out all available RAM at the speed of electrons, almost instantly crashing the whole system. I must always program a minimum operating environment and a maximum operating environment. Have to. Computers can't "think". Only calculate mathematical equations.
Murzinio;n10525292 said:...unless you have more than 256TB of RAM or you're using a 32bit OS.
Murzinio;n10525292 said:C++ allows you to either write wrappers or overload the new/delete operators to make your own management system, and it can be easily implemented and made configurable for different platforms/future versions of the engine. And with some config tweaks you can bump the RAM and VRAM usage way over vanilla values so it's either adjustable (there are budget options in config files, though I don't remember if they affect anything in the release build) or set higher for PCs to the point of not being an issue.
Murzinio;n10525292 said:Besides, the scripts and leftovers in wcc clearly show that the modding support for the game wasn't even seriously considered, it's not like modding exists since yesterday so they couldn't make the design decisions with it in mind, so the comparisions with Napoleon and tanks make absolutely no sense.
Murzinio;n10525292 said:Also you're confusing different technical terms in your examples...
traderain;n10525392 said:https://github.com/freebsd/freebsd/b...alloc/malloc.c
Murzinio;n10525532 said:Also, you can't really "design" a program to run at specified clock speed independent of the hardware. Unless you maybe set the clocks when it runs but it would be totally pointless. Different CPUs will have different "speed" on the same clocks, there's much more to that than the frequency. So that would be a terrible idea to rely on for your game time. If you want to limit the framerate you use precise timers to measure the time on each tick in the game loop and render the frame when the desired time has passed, like 1/60 of a second to get at most 60 fps... And for game logic/physics usually you just use a fixed time step. So again, that's not how it works.
SigilFey;n10526252 said:It's still an upper limit. This is another fallacy that has wound up causing problems for the gaming industry...since...forever. "256 TB of RAM!!! That's...insane. It's so much that we'll never hit that limit! It's seriously not even worth thinking about." Kind of like a conversation I had with a bud back in the early 2004. "8 GIGAbytes of RAM!!! Why the @#$%! would you waste so much money on that, man!? There's no way any game is going to come out that requires 8 GB of RAM! You're just wasting your money. That's...insane." I can also go back to the early 1990s, when my father brought home an IBM computer from Kodak with the 286 microprocessor (which weren't released on the open market yet) and 2 MEGAbytes of "above-board memory". And it was so amazingly powerful that all of the games we had could run, like, perfectly. It was...insane. And yet it was never more that 3 years before these "insane" systems were starting to show their age, and newer games with "absolutely mind-blowing features" came out that required me to turn down graphics options in order to get them to run smoothly. Assuming that the way computer systems will work is somehow going to change because "we've broken all boundaries and achieved a whole new plane of technology" will pretty directly lead to disappointment. There are always limits. We have from absolute zero to the speed of light in this existence...and that's it. (That'll be plenty for our gaming needs. )
SigilFey;n10526252 said:Right. It can. And there are engines that will do that. TW3 doesn't. Obviously, there is reason for that. We might not like this reason (whatever it actually is). We might want to argue with that reason. We might even be able to come up with an alternative solution to get around the limit (which many already have). But that does not mean that there is "no reason", nor that the existing reason is invalid.
SigilFey;n10526252 said:I don't code.
SigilFey;n10526252 said:I'm completely amateur
SigilFey;n10526252 said:That's a long read, and I'm not familiar with the "code-y" parts of it. (Only read the first bits, then skimmed around a bit.) From what I gather it's a memory manager for the 64-bit era? Basically, it ensures that no chunks of RAM are wasted?
SigilFey;n10526332 said:Meh. I oversimplified -- like I said I was going to. (You were warned! ) But in the early Pentium days, limiting the Hz (frequencies) is exactly what he had to. Even DOSBox still offers the ability to downclock the CPU by a certain percentage, as running the actual legacy programs still suffer from the same issues. In the beginning, games were created to run "optimally" on very particular hardware. The only way the engine would perform 100% correctly was to have that precise Hz of CPU and the exact amount of RAM it was designed for. So the engine was designed for a specific amount of resources, and having more / less could and would cause issues (even though most were minor enough to be ignored easily until the hardware got waaay more advanced).
SigilFey;n10526332 said:Most notoriously, unlimited FPS, which throws games for a loop sometimes since it's running too fast and falling out of sync with anything requiring frame-timing.
SigilFey;n10526332 said:Engine must set min/max levels.
Murzinio;n10527332 said:...current games are far from the adress space limit. That is 48bits btw, if we will need to we will expand to full 64bits which allows for 16EB adress space, so you don't have to worry about that...
SigilFey;n10526252 said:What you say about future versions is spot-on! It's definitely possible, and it will eventually be implemented in future titles. That's what tends to happen as the industry creates new engines and games!
Murzinio;n10528702 said:1: The numbers I mentioned are hardware limitations, not engine limitations. I don't want to explain the same stuff 3 times...
2: Sound channels - ok I guess. 32/64 bit - you just change the compilation target and you can compile both 32bit and 64bit versions. If you have all the dependencies available for both and don't mess up the code it's not a problem. So kinda true, but you just need to compile it with different target, and if you follow good practices for writing code you won't have to change anything in it.
Memory usage is not fixed at the compilation by itself, you can allocate memory dynamically depending on size of a file that program opens for example, you don't have to know anything about it beforehand, it's a really basic thing to do, without that software would be very limited... And it's called "dynamic memory allocation" for a reason, one of it's uses is precisly when you don't know how much memory you will need when you write the code. Like I said you can write a few lines of code program that will demonstrate this, without specifying anything about RAM. And your program doesn't need to "recognize" the RAM, the operating system handles that, manages the available memory, checks for access violations etc. C++ only provides an abstraction, you don't allocate every single byte manually.
Not being able to use faster CPUs doesn't make sense either, if the CPU can execute the same instructions faster, the code will run faster and even if you have locked framerate, it will just reduce the CPU time the game uses because the computations will be ready sooner and you will only check the timers. For unlimited framerate you will just get more fps. If what you say is true you wouldn't be able to see a difference on newer CPUs or even after overclocking. That only applies to being able to utilize different instruction sets or number of threads but you definitely get a difference with higher frequency or newer, optimized CPU generations.
Cercaphus;n10528692 said:I think we came full circle now
SigilFey;n10528892 said:I asked two questions above, very clearly, but you have not directly responded to either of them. You seem tunnel-visioned on criticizing the simple reality of the situation by repeatedly arguing the way it could have been. Obviously, that's not the way TW3 was built. There's a mod limit. If you truly want to reject everything I've suggested because I used a wrong term or over-simplified the explanation of a process, then you're welcome to reject it. You seem to be convinced.
SigilFey;n10528892 said:However...if it's so simple, why do we have so many different methods being used throughout the industry? Why doesn't every single developer under the sun use malloc with perfect efficiency to manage their heap allocation? Why isn't every engine 100% flawless in its execution, able to make complete use of 128 GB of RAM?