I'm just saying what some reviewers will say, i doubt wargaming specialist will care, like wargamer.com or rock papper shotgun. But if mainstream reviewers start reviewing it, it will come up.
And yes there is a huge difference in fps feel in almost all games, many people will simply get headaches and get sick if the fps drops much under 60. and while sow might not need 60fps most games benefits hugely from it.
Optimised?
Re: Optimised?
yes there is a fixation with reviewers on the latest shooter 3d's as that's popular with the general gaming communities, and as in the past, SOW has been poorly reviewed by some because of this. They can't see past sprites and sub 30 fps which is a shame as it means they haven't done their homework as a 'game reviewer'.
I note that the demo videos shown so far have a 'faster' reaction time (eg moving around the map, panning) than GB.
cheers
I note that the demo videos shown so far have a 'faster' reaction time (eg moving around the map, panning) than GB.
cheers
Re: Optimised?
In testing running the full battle scenarios I was getting steady results in the 20+ FPS
My computer is a
i-7 2600k at 3.4ghz 64bit win7
16gb ram
GeForce GTX 560 ti card
and believe me with that much action going on all across the
Waterloo map you are hard pressed to control your troops and don't
have time to watch the pretty sights
My computer is a
i-7 2600k at 3.4ghz 64bit win7
16gb ram
GeForce GTX 560 ti card
and believe me with that much action going on all across the
Waterloo map you are hard pressed to control your troops and don't
have time to watch the pretty sights
Last edited by kg_sspoom on Thu Jun 04, 2015 5:06 am, edited 1 time in total.
Re: Optimised?
We have lots of threading in the single player game. We've picked up some fps on that. It runs very smooth for most of us, even with large battles. All the LOS code is multithreaded. But, sorry to say that I did not have time to work out the issues with the threading and MP, so that is not threaded. There might be a few, but nothing like single player. Mp is lock step, so the threadpools that I used for SP needed to be tuned and we ran out of time.
But... should see some great improvement with multicore cpus. I create as many threads as you have cores.
But... should see some great improvement with multicore cpus. I create as many threads as you have cores.
Re: Optimised?
Thread pool is a good choice, Norb. At least you're going to avoid "oversubscription". Well done.I create as many threads as you have cores.
Just another technical question: how is LOS shared data synchronized with the AI which is going to consume it?
Honestly I can't see much potential gain coming from threading just LOS... but let me try the game first.
Really can't wait anymore.
Good luck.
Re: Optimised?
LOS calculations are our single biggest bottleneck. They also are one of the major causes of units not reacting to others. This is very prevalent in huge battles, as the game cannot run los of everyone ever frame. Yet everyone is moving and has a constantly changing los. The main product being a valid target list.
To get the threads to work, we had to make sure that the LOS function only affected one unit at a time. We wanted to avoid having a ton of locks in there, so we made the single los unit have to access every other unit as const. This was the biggest hurdle, but the easiest solution because once that code change was made the pools worked great.
The AI always works from the current target list and all LOS is done at a single point in the process. It's actually towards the end of the function because previously this is where we tweaked to gain some frames. We also put in some checks to not run land/building los if a unit has not moved at all since the last time. I've been tweaking this code for years not sure if that made it better or just a jenga tower, but you'll see that on multi core cpus that you can run much larger battles without a sixmillion dollar man look.
To get the threads to work, we had to make sure that the LOS function only affected one unit at a time. We wanted to avoid having a ton of locks in there, so we made the single los unit have to access every other unit as const. This was the biggest hurdle, but the easiest solution because once that code change was made the pools worked great.
The AI always works from the current target list and all LOS is done at a single point in the process. It's actually towards the end of the function because previously this is where we tweaked to gain some frames. We also put in some checks to not run land/building los if a unit has not moved at all since the last time. I've been tweaking this code for years not sure if that made it better or just a jenga tower, but you'll see that on multi core cpus that you can run much larger battles without a sixmillion dollar man look.
Re: Optimised?
Thanks for replying, Norb.
I coded a LOS algorithm only once in my life, so can't help very much on this subject.
Being a Napoleonic battlefield not truly a "continuous motion" however, I think caching (above some sort of spatial partitioning like grids) may come in handy.
That would result especially useful in the common situation of units with similar pathfinding moving toward static or semi-static defenders.
Additionally you could assign some coarse (fast to compute) LOS results immediately (say when you're far from the enemy) and build finer in background (not fork-and-join) with an "urgency" (cavalry approaching, etc.) preparing policy.
Finally I'd consider storing all AABB of units into a few recycled buffers at every frame, feeding the right one as read-only (thus thread-safe) to the next frame's LOS being requested (it's not a FPS after all).
Try to avoid mutexes.
Ciao.
I coded a LOS algorithm only once in my life, so can't help very much on this subject.
Being a Napoleonic battlefield not truly a "continuous motion" however, I think caching (above some sort of spatial partitioning like grids) may come in handy.
That would result especially useful in the common situation of units with similar pathfinding moving toward static or semi-static defenders.
Additionally you could assign some coarse (fast to compute) LOS results immediately (say when you're far from the enemy) and build finer in background (not fork-and-join) with an "urgency" (cavalry approaching, etc.) preparing policy.
Finally I'd consider storing all AABB of units into a few recycled buffers at every frame, feeding the right one as read-only (thus thread-safe) to the next frame's LOS being requested (it's not a FPS after all).
Try to avoid mutexes.
Ciao.
Last edited by Guest on Mon Jun 08, 2015 1:37 pm, edited 1 time in total.