Optimizing Math Functions
Moderator: Moderators
Re: Optimizing Math Functions
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?
Re: Optimizing Math Functions
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.
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.
Re: Optimizing Math Functions
Add a linebreak at the end of the script.txt, then run spring with script.txt as parameter.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).
Re: Optimizing Math Functions
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?
Re: Optimizing Math Functions
drop /s:
spring script.txt
spring script.txt
Re: Optimizing Math Functions
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...
[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...
Re: Optimizing Math Functions
Errrm... In latest revision the fast sqrt isn't actually used anywhere, unless you modified the source to include it.Argh wrote: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.
Re: Optimizing Math Functions
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.
Re: Optimizing Math Functions
placebo effect, perhaps? ^^
Re: Optimizing Math Functions
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 :) ).
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 :) ).
Re: Optimizing Math Functions
I think i just saw god
Re: Optimizing Math Functions
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?
Re: Optimizing Math Functions
I think SJ would know what he's talking about, especially if he already half-coded it a while back.
Re: Optimizing Math Functions
Memory is imperfect, even I forget what code does despite having written it myself.
Re: Optimizing Math Functions
The King hath returned, the prophecy is fulfilled and soon we will have proper GPU performance on current generation cards! :DFLOZi wrote:I think i just saw god
(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).
Re: Optimizing Math Functions
Looked at the code, looks like it does that, pretty much per-piece, right now. Wow, that could be a giant cost-savings, imo...If a single display list rendered an entire unit wouldn't you have to rebuild the display list very frame for when it animated?
Re: Optimizing Math Functions
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)
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)
Last edited by jK on 31 Mar 2008, 05:51, edited 1 time in total.
Re: Optimizing Math Functions
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.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
Re: Optimizing Math Functions
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 wrote: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.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
Re: Optimizing Math Functions
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.
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.