To hell with high-poly models - Page 2

To hell with high-poly models

Various things about Spring that do not fit in any of the other forums listed below, including forum rules.

Moderator: Moderators

User avatar
Buggi
Posts: 875
Joined: 29 Apr 2005, 07:46

Post by Buggi »

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 ^_^;
el_muchacho
Posts: 201
Joined: 30 Apr 2005, 01:06

Post by el_muchacho »

And submit a bug report afterwards if the pb can be reproduced.

BTW, is there a formal process for bug reports ?
el_muchacho
Posts: 201
Joined: 30 Apr 2005, 01:06

Post by el_muchacho »

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'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).
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.
User avatar
NOiZE
Balanced Annihilation Developer
Posts: 3984
Joined: 28 Apr 2005, 19:29

Post by NOiZE »

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
stisoas
Posts: 4
Joined: 02 May 2005, 11:04

Post by stisoas »

dude.

just start by test WITHOUT shadow.
Shadow eat many cpu power. try without and send us report :wink:
Xon
Posts: 33
Joined: 07 May 2005, 17:07

Post by Xon »

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.
I wouldnt be suprised if it was the pathfinding.

But I want to get my hands on a proper profiler 1st before I make any types of judgement calls.
Lets not forget COB threads.
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.

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.
el_muchacho
Posts: 201
Joined: 30 Apr 2005, 01:06

Post by el_muchacho »

stisoas wrote:dude.

just start by test WITHOUT shadow.
Shadow eat many cpu power. try without and send us report :wink:
I've never used shadows. The game crashes with them and my CG.

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.
F for Fragging
Posts: 24
Joined: 07 May 2005, 17:33

Post by F for Fragging »

I have a AMD Athlon XP 2500+, 512 MB PC3200 DDR RAM and a GeForce 5900 XT.

I never got the lag you described when playing. Camera movement lag only happens when I'm playing a replay and I turn up the game speed.

Oh, and I disabled shadows. They caused the game loading to take over a minute.
User avatar
SinbadEV
Posts: 6475
Joined: 02 May 2005, 03:56

Post by SinbadEV »

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...
Post Reply

Return to “General Discussion”