Optimizing Math Functions

[Argh]

I see that the new math header has been committed. I don't suppose I could see an installer build to do comparisons and testing against?

[Argh]

Testing 5609. Difficult to do complete comparisons, due to SpringSP currently failing to launch the game (some sort of parsing error in script.txt generated by SpringSP, game runs fine when run directly).

What I saw was interesting, and am somewhat hopeful about final results of this. During early game, with nothing going on, there was practically zero difference between this and previous revisions, but during heavy gameplay events, this seems to have improved performance by a bit, and performance feels smoother, with fewer giant slowdowns occuring.

[rattle]

Testing 5609. Difficult to do complete comparisons, due to SpringSP currently failing to launch the game (some sort of parsing error in script.txt generated by SpringSP, game runs fine when run directly).

Add a linebreak at the end of the script.txt, then run spring with script.txt as parameter.

[Argh]

Hmm. Running it that way, fog of war was turned off, and resources were doing something really bizarre... I'm just supposed to use "/s script.txt", right?

[imbaczek]

drop /s:

spring script.txt

[Argh]

I can still see everybody, like I'm spectating.

[BIG EDIT] The economy is broken... damn, didn't test enough... if storage < starting value given, then it keeps resetting the value

This is fixable, but I'll have to add zeros to every economic value in P.U.R.E...

[Jonanin]

What I saw was interesting, and am somewhat hopeful about final results of this. During early game, with nothing going on, there was practically zero difference between this and previous revisions, but during heavy gameplay events, this seems to have improved performance by a bit, and performance feels smoother, with fewer giant slowdowns occuring.

Errrm... In latest revision the fast sqrt isn't actually used anywhere, unless you modified the source to include it.

[Argh]

Eh, really!?! Then it's just stuff working more cleanly in the rest of the code, then. That's great news, really- if this also improves performance, this will be the fastest-running version of Spring I've tested, for a lot of heavy tasks.

[imbaczek]

placebo effect, perhaps? ^^

[SJ]

Somewhat of topic but if you want to increase spring fps totals i think the correct thing to do would be to rewrite how the units are drawn.

As they are now they treat each piece of the unit as a separate display list which was nice and optimal on my GF2 but probably not so good any more as it generates an awfull lot of "drawcalls" (glCallList in GL?, too much DX for me).

A better aproach would be to treat the pieces and bones although with only one bone per vertice and do a single drawcall per unit. I did some testing with this a year or two back that i never finished but I had about 50-100% better fps when displaying 500 AKs on a map (somewhat of a best case for this admitedly).

Well I hope no one has fixed this without me noticing (or it would be good if someone had but it would make this post look foolish :) ).

[FLOZi]

I think i just saw god

[AF]

If a single display list rendered an entire unit wouldn't you have to rebuild the display list very frame for when it animated? Thus defeating the whole point and making the game actually slower than it was to begin with?

[lurker]

I think SJ would know what he's talking about, especially if he already half-coded it a while back.

[AF]

Memory is imperfect, even I forget what code does despite having written it myself.

[LordMatt]

I think i just saw god

The King hath returned, the prophecy is fulfilled and soon we will have proper GPU performance on current generation cards! :D

(I sort of suspected it was something like this, as on my 8800 GTS the FPS takes much too quick of a drop as you add units, relative to what happens when you add things like dynamic water or shadows).

[Argh]

If a single display list rendered an entire unit wouldn't you have to rebuild the display list very frame for when it animated?

Looked at the code, looks like it does that, pretty much per-piece, right now. Wow, that could be a giant cost-savings, imo...

[jK]

i didn't understand what SJ meant, but it is true that unit drawing becomes slow if there are multiple hundred units on the screen. But still simulation is MUCH slower, else you should get your frames back if you watch a place w/o any units (atm you don't get a fps boost) ...

regenerating a displaylist foreach unit in motion wouldn't be smart, you would need to create (and destroy/recreate) multiple 1k dlists to do so what becomes slower than the current code. (SJ can't meant this)

so i would suggest:
using vbo's & glDrawElements (it is what nvidia always suggest in their papers for >1k unit drawing)

PS: forgot to mention that there still is a third way:
using 1 dlist for the whole unit and using a vertex shader to move the single pieces (should be quite fast, but much more complexe)

[Argh]

didn't understand what SJ meant, but it is true that unit drawing becomes slow if there are multiple hundred units on the screen. But still simulation is MUCH slower, else you should get your frames back if you watch a place w/o any units

I see a huge jump in FPS, in testing, when I do this. Give yourself 500 Units that don't have any script functions running (i.e., just an empty Create() ) then pan back and forth... it's obvious there's a big difference, at least on my rig.

[jK]

didn't understand what SJ meant, but it is true that unit drawing becomes slow if there are multiple hundred units on the screen. But still simulation is MUCH slower, else you should get your frames back if you watch a place w/o any units

I see a huge jump in FPS, in testing, when I do this. Give yourself 500 Units that don't have any script functions running (i.e., just an empty Create() ) then pan back and forth... it's obvious there's a big difference, at least on my rig.

it is true for the case that the units stay still, but if they move or fight, your fps will go much deeper than with watching those 500 units.

[Argh]

Absolutely, script costs are significant, especially if they aren't well-optimized. Most OTA scripts are almost completely optimal, if SmoothAnim == 0, but are terrible, if interpolation is turned on. I wrote a long, blog-like essay about this, awhile ago, when I went and looked at the assembler-level stuff that COB does, but meh, it's not that important, it'd require that UpSpring was able to output step-animation stuff correctly.

I'm just saying that the display lists are anything but free, and if they can run 50%-100% faster, that's pretty significant. Small speedups here and there really add up, and it sounded like it might be a fairly easy thing to do.