I suggest getting to that same point, and hitting "b" for debug and see where your processor is being hit.
That'll give us more info ^_^;
To hell with high-poly models
Moderator: Moderators
-
- Posts: 201
- Joined: 30 Apr 2005, 01:06
-
- Posts: 201
- Joined: 30 Apr 2005, 01:06
I've no idea, but I think at one point, I was lacking memory, because the hard disk started to scratch frantically, and then the sim time quickly rose to 320% (i.e 2 frames late), at which point I simply killed the game. I think I had no other app open at the same time although there was still the antivirus and the firewall in the background (but the antivirus didn't start a scan).Sean Mirrsen wrote:A sim frame is a total update of everything you see on your screen. I don't know what your problems are, but even though I finally figured how to make my video card display shadows (which it wasn't supposed to), and even though I made the water go up and down with the tides, I have little problem running a hefty lot of units on my comp. I have no idea what causes the severe slowdowns you describe. Try setting texture size back to normal. Or turn off high-res clouds. Or set unit LOD a bit lower. Or something...
I play with the standard game settings and a little bit of AA and no shadows (my GC is a radeon 9600 pro).
I have tweaked my Bios settings since then and I think the game is a little bit more stable right now, but I didn't have any problems with Doom3 or LockOn with the original settings.
when running sprin.exe
i builded 1000 units
with both team 1 and team 0
together they had 1000 units
@ 400 units the game was unplayble the camera shocked all the time and the delay was huge..
basicly i think the pathfinding and stuff like that uses a lot of cpu power, cuz when all the units were just sitting around i got still a "decent" 10 fps but as soon as i started a battle i got a pretty 1 fps slideshow
so i think 200 units per team is playeble, beyond that, it's only annoying..
my specs:
amd2600
1024 mb ram
radeon 9800 Pro
shadows/reflective water was turned on
i builded 1000 units
with both team 1 and team 0
together they had 1000 units
@ 400 units the game was unplayble the camera shocked all the time and the delay was huge..
basicly i think the pathfinding and stuff like that uses a lot of cpu power, cuz when all the units were just sitting around i got still a "decent" 10 fps but as soon as i started a battle i got a pretty 1 fps slideshow
so i think 200 units per team is playeble, beyond that, it's only annoying..
my specs:
amd2600
1024 mb ram
radeon 9800 Pro
shadows/reflective water was turned on
I wouldnt be suprised if it was the pathfinding.Buggi wrote:So, optimizing the pathfinding is key here. Obviously the machine can handle the drawing of the screen as you can move the camera around, but unit lag should be focused on what those units are doing.
But I want to get my hands on a proper profiler 1st before I make any types of judgement calls.
COB threads shouldnt be taking much CPU time. about 90% of the time they are waiting on something or only run for a dozen or so instructions.Lets not forget COB threads.
Even the loops can be fixed by implementing pre-emptitive waits if the script takes too long to complete. It should only be a quick hack todo it.
-
- Posts: 201
- Joined: 30 Apr 2005, 01:06
I've never used shadows. The game crashes with them and my CG.stisoas wrote:dude.
just start by test WITHOUT shadow.
Shadow eat many cpu power. try without and send us report
But the code is ful of redundant calculations.
For instance, in the float3.h file, a functions like operator/ has 3 divisions by l where one suffices. Of course, the compiler might optimize this, but since it's an inline, if one passes an indirection to Normalize, then the compiler probably won't optimize it and will perform 3 divisions.
Or each call to va->AddVertexTC (i.e for drawing nearly every unit on screen) repeats calculations with camera->right and camera->up, which the compiler doesn't optimize.
Simply defining outside loops
const float3 camup(camera->up);
const float3 camright(camera->right);
and using them saves a lot of generated code (look at the asm), one saves a few adds and multiply each time, which, multiplied by the number of units and projectiles and the framerate, makes quite a nice saving.
Also, it's a good idea to declare const a lot of variables that are indeed const, to help the compiler optimizer. I'm sure there are lots of things like that to do on the code.
Last edited by el_muchacho on 18 May 2005, 00:03, edited 2 times in total.
-
- Posts: 24
- Joined: 07 May 2005, 17:33
that's happened to me a couple times with the ignoring my orders thing, usually when I have a pile of contruction aircraft doing stuff (like over 50) it was funny because the orders that were stuck were to build 400 contruction airplanes at the time. I think that time it was single player so couldn't have been network lag... happened another time right near the start with only like 50 units built... it was odd though, because I would give the commander an order he would stop nanolathing brifly, turn towards the new command and then turn back to nanolathing...