NTai XE10.1b

AF · Post by AF » 10 Aug 2007, 12:09

Im sorry but thats not helpful. I have no explanations or help, just people complaining "its slow". I cant work with that.

Imagine me saying its brilliant to you. What is thats brilliant? and why? Its just very ambiguous and unhelpful

1v0ry_k1ng · Post by **1v0ry_k1ng** » 10 Aug 2007, 12:48

..? I thought it was pretty clear;
it is very cpu intensive.
this means it is running too many checks and processes at once.
solution is lower the frequency of checks and processes or limit the number/ second.

AF · Post by AF » 10 Aug 2007, 12:56

It isnt that simple, NTai hasnt got a 100 line codebase. To make a difference I have to know what it is thats causing lag otherwise continuous lag turns into spikes of lag

1v0ry_k1ng · Post by **1v0ry_k1ng** » 10 Aug 2007, 13:38

the lag is a result of large numbers of parallel processes and checks, is there not a changeable timescale between each check?

AF · Post by AF » 10 Aug 2007, 15:31

I said before thats not how it works.

If something is taking up too much cpu processing then making it happen less often wont solve the problem.

Your just going to have "fine fine fine HUGE LAG SPIKE fine fine fine HUGE LAG SPIKE fine fine etc..."

I'm writting a worker thread so I can start queuing up build algorithm tasks, that way I can control how mny ongoing searches are occuring at any one time. This should give a performance improvement.

However that assumes its the build algorithm causing the slowdown, and if it isnt then the performance gains would be marginal. I'm doing it atm because it might help the solobuild issue, and it'll make things neater, aswell as making multicore operations more efficient.

As such the next NTai will use 4 worker threads, which should do fine on dualcore and quad core cpus. Single core cpus wont have more than 4 build algorithm threads running at once so that'll be fine.

AF · Post by AF » 13 Aug 2007, 23:00

- New thread pooling to improve performance
- Increased blocking map resolution for greater accuracy
- Capturing added to commander AI
- Builder retreating improved
- Reclaim radius reduced from 1000 to 400

http://spring.unknown-files.net/file/34 ... e-release/

DJ · Post by DJ » 15 Aug 2007, 13:20

has anyone tested this yet? I've been in Rome so haven't had a chance...

AF · Post by AF » 15 Aug 2007, 13:58

20 people have this atm, although once 30 ppl downloaded an older NTai before someone reported it had an instant crashbug on startup a few years ago

I have tested it on my machine for as long as I could, it does build stuff other than mexes so its not borked.

1v0ry_k1ng · Post by **1v0ry_k1ng** » 16 Aug 2007, 00:49

testing now..

1v0ry_k1ng · Post by **1v0ry_k1ng** » 16 Aug 2007, 01:00

this version creates incredible lag spikes, 5 minutes into a game using my XTA profile and it was unplayable and im running a 3.6ghz.
can send you logs/replay if you want?

AF · Post by AF » 16 Aug 2007, 02:35

At 5 minutes into the game the base is still small enough to debug with the human eye and a good dose of common sense.

DJ · Post by DJ » 16 Aug 2007, 10:48

I've just tested this at work, I did notice some small slowdowns but nothing like incredible lag spikes as reported by IK. I can't really test properly but i got a good 10 minutes into the game and it was still running ok...

AF · Post by AF » 16 Aug 2007, 14:40

Increasing the resolution of the blockingmap so the squares where 16x16 not 32x32 could be a culprit, but it makes the blocking map system much more accurate.

DJ · Post by DJ » 16 Aug 2007, 15:22

if the blocking map is capable of detecting hills then this might be worth while NTai occasionally builds vehicle labs in places where the vehicles just get stuck leaving... However if it doesn't detect hills which i suspect is the case then there is no need to increase the resolution, as far as I am concerned it worked very well before and is just aother drain on performance.

DJ · Post by DJ » 17 Aug 2007, 10:30

OK tested this last night

@IK were you using a dual core? I tested on my PC and performance was improved, I haven't had a chance to download and test your config yet but prob will next week.

@AF Performance seems to be much improved with this release BUT there is a crash bug which happened on two successive games. Unfortunately it happened some 45 minutes in on both games so it was almost impossible for me to find what the problem is. The log and the stack trace are on my home pc but i assume they aren't of much use to you? The last mention in the log was a construction task, I'm guessing this is to be expected seeing as that's what you have changed...

AF · Post by AF » 17 Aug 2007, 14:35

Indeed my cpu can handle it fine, and I get very very low cpu usage with the newer NTai.

3.8Ghz pentium 4/AthlonXP < 1.8Ghz Core 2 duo

This stacktrace business is getting out of hand. Debugging NTai used to be so easy, now with the TDR driver crashes and the borked debuggers its a nightmare.

DJ · Post by DJ » 17 Aug 2007, 17:46

next week i'll try get debugging working on my machine. Is SVN for NTai kept up to date?

1v0ry_k1ng · Post by **1v0ry_k1ng** » 17 Aug 2007, 18:21

i run a single core 3.6ghz with gig o ram on winXP

DJ · Post by DJ » 17 Aug 2007, 18:31

OK i'll build a single core PC to test on as well and see if I get the slowdowns you described...

AF · Post by AF » 17 Aug 2007, 20:05

I've made one or two changes since the last release, the matrix resolution is back to 32x32 squares not 16x16, and the number of active threads was reduced from 10 to 6/8.

And yes the svn is usually upto date, and its almost always more upto date than the latest release.

Spring RTS Engine

NTai XE10.1b