My loading time were about 15 minutes (the game started before I could go in). I suspect it to take a bit too much time, because a friend of mine has almost the same system (i7 instead of i5, and a Ti560 with 1Gb of Ram) but loads waaaaaays faster than me. So I want to give some feedback to the dev's. First, my system specs: - PA Version: 54459 - I5 2500K - 8Gb of Ram - ATI 4770HD (1Gb Ram) - Windows 7 64bit - And of course latests drivers - The game in not bound to steam, however, I've steam launched. I started the game with the following setup: - 1 planet, biome moon, near the sun, scale 1 - 1 planet, biome earth, scale 4 - 1 moon, biome moon, around that planet, scale 1 Before launching a game (in the lobby), PA takes about 700Mb of RAM, and spawns something like 5-6 Coherent UI processes. No CPU on my seems to takes 100% (that feels weird to me, the rendering loop shouldn't renders as fast as possible?). When starting a game, (loading screen), my computer just seems to sit up doing nothing for 5-10 minutes. No CPU running at 100%, no memory allocation are done until a certain point. Then suddenly, the games allocate like 1.7Gb of RAM (almost making windows think that the game has crashed for a couple of seconds as it start being unresponsive), and sits again for 5-10 minutes doing "nothing" like before the memory allocation. Then the games starts. That's lead me to thoses questions (hope a dev can answer them): - I suspect that map generation is done on the GPU, as the CPU / Ram is standing still while loading the game? - Why does the game allocate in the middle of the game load all the Ram? Is this some kind of GPU to CPU ram transfert? - PA seems to generate the map or use only one core, is this correct? - It is normal that the game spawns multiple Coherent UI threads? - It is normal that I do not have such problems when generating a planet in the system editor? Creating them is almost immediate, even when the UI says that it could take a long time... "Optional" questions: - Why choosing Coherent UI over Awesomium? If you need additional informations, feel free to ask. edit: added PA version
I'm not dev, but will answer few question which already asked before and there answer on it. Yes this is correct, check this topic for detailed dev answers: https://forums.uberent.com/threads/question-to-devs-about-vram-usage.51325/ Don't looks like PA moving anything from RAM to VRAM. Actually planet generator able to use multiple cores, at least it's true for older versions on all platfoms and current verion on LInux. Yes it's normal, Coherent work exactly like Chromium work. And I'm think this is right decision because Google don't really support single process mode anymore and I doubt Coherent devs have enough human resources to modify such large codebase on their own. There also looks like no problem with loading time on Linux and also on my Intel HD notebook under Windows 7. It's all looks like a weird bug or multiple bugs which are not affect everyone.
Current version of Coherent used in PA based on Chromium 24.0.1312.36 and masterdigital said there will be an update soon. While latest Awesomium 1.7.2 built on Chromium 18.0.1003.1 this, this might be one of reasons.
Thanks for all the informations. Guess i'll need to test why a better GPU to see if I can get better loading times.
I have a virtually identical system, except my GPU is a Radeon 6850 1GB, and my processor is overclocked to 3.7Ghz. Loading times can be pretty long if there's more than one opponent, and in this case I usually don't get the option to choose my spawn. Most interestingly though is that the PA.exe uses roughly 6GB of RAM once it's finished loading (accordingly to Task Manager).
Loading times are NOT related to GPU, it's some weird bug, most likely only affect Windows version and as I think it's only depend on CPU load. Most CPU-intensive task it's not texture generation, but planet geometry generation which make game stuck for long time.
If you met 6GB RAM used on game with 2-3 planets it's mean you met memory leak because such game shouldn't use so much RAM. Just wait for next updates, I sure everything will be much better soon.
Yep, just running Windows takes around 1.3-1.5GB, then when PA is running it gets to nearly 7GB total usage.
It's memory leaking. When the game starts in a reasonnable time, PA uses 1, 6GB of ram. When it takes a long time it can fill up the available ram (was close to 11GB once). In either case my CPU is at 10% during loading.
I have a fairly new gaming rig and the game takes a bit to load when it tries to load multiple large planets. I tried to load 14 planet game and everyone's computers melted trying to load the game. Something has to be done if 40 man games are going to be doable. But I recall one of the Devs suggesting that the game be preloaded in the game lobby.
Just a note on the "no CPU takes 100%": you can't derive a programs single-core CPU usage from looking at the CPU graphs in Task Manager or similar. A single thread may fully use a cores processing power, but most operating systems will change the core it runs on several times a second. So even if one thread uses 100% of a core, it may, for example, spend 30% if it's time on core0, and 70% on core1. So the CPU usage graph is useless for trying to analyze a programs runtime behavior. You can use ProcessExplorer to see the CPU usage of a programs different threads. Run Process Explorer and then double-click on PA.exe in its main list to see the threads performance breakdown. A thread will run at maximum performance when it's using (100/coreCount) % of CPU; i.e. on a 4-core system a thread fully uses a core with 25%, on an 8-core system that's 12.5%, etc. And when you check PA's CPU usage, you will find that it does indeed often have at least one thread at close to 100% use of one core.
It's clear this "game starting" issue is one of the biggies that we need to address ASAP. Before the game can start, several things need to happen: the game server turns the system description into actual planet geometry. everyone in the lobby clicks ready the server sends the finished planet geometries to each client each client builds render structures out of that geometry the server builds the initial simulation state the server sends the initial sim entities to each client the client switches from the "game starting" screen to gameplay This can be improved in several ways: Steps 1 and 2 currently run is parallel, but step 3 doesn't start until they both finish. That is silly. There is no reason why we can't start sending the game config as soon as you land in the lobby. Also, we are sending more information in step 3 than the client really needs. Step 4 uses the foreground thread more than it should, causing the window to lock up at times. It is also just slower than it should be. (This is the CPU intensive step.) In step 6, we could be a lot smarter about the order the initial sim entities are sent so the client doesn't need to wait for them all before proceeding. But we would have to make sure we sent the important ones (planets+metal spots) first and the less important ones (trees) later. In short, really long start times probably mean than you joined a game with large planets and have a slow(er) internet connection. We can improve this (overlap the download with the lobby, download less) and we can communicate it better (progress bar).
Please when you do find issue and fix it post here some info on what you find. It's just really interested to know why it's not affect Linux build and some Windows users (some people with low-end Intel graphics, what funny) too. Before I'm already guess that's related to some problem with intensive usage of one CPU core, so it's why disabling of Steam Overlay helps to some people and Threaded optimization help to Nvidia users.
Ha, I misunderstood your previous post, I though that everything was generated on the GPU with the use of some sort of CUDA technology.
Sorry about that, I'm never meant any OpenCL/CUDA things. Obviously Uber generate planet on CPU because servers don't have GPU.
I didn't know that. I was thinking that a thread was always bound to the same core, but the core was shared between multiple threads. It's been a long time that I didn't code something threaded and CPU intensive, so please forgive me .
