Support more opponents

[NaN]

My total gui rewrite reached an amount of changes where I don't feel comfortable any more. It touches too many components. Thus I've decided to go for a more incremental approach. This means one feature at a time. This will cost more time but will keep the regressions manageable and produce more robust code I hope.

Part one
More opponents, up 23 to be exact. The current code deals with the gui part only. There will be performance optimizations and profiling required to make this work properly. We can reduce the maximum number later. But it is a nice target I think.

The branch is gui-24.
The data is branches/vdrift-data-gui.

So please check out, compile, test and report your findings. Try different numbers of opponents. Any help is greatly appreciated. Let's make it work!

PS: I'll upload a windows binary asap.

[NaN]

Windows build(without data) vdrift-gui-2012-04-17.exe:
https://sourceforge.net/projects/vdrift/...%20builds/

Checkout/switch to vdrift data:
https://vdrift.svn.sourceforge.net/svnro...t-data-gui

And delete user settings:
C:\Users\{user}\Documents\VDrift

[NaN]

A few profiling results. I've picked a simple track/car(due to intel gpu).

Physics delta per simulation step with Z06 on Ruudskogen:
8 cars: 5ms
16 cars: 10ms
24 cars: 12ms

Seems to scale quite well and looks like we are limited by graphics card here(ok it's intel crap). Will test with a hd4850 later to see how it performs there.

[NaN]

New Windows build(without data) vdrift-gui-2012-04-18.exe:
https://sourceforge.net/projects/vdrift/...%20builds/

Changes:
- Bugfix: Update DOUBLESTRINGWHEEL to use signal/slot functionality.
- Bugfix: DOUBLESTRINGWHEEL center position not parsed.
- Bugfix: Check for .car file when scanning for cars(directories).
- Reduce sound list lock contention.
- Avoid sound buffer reallocation.

[NaN]

Profiling with 24 cars has revealed that we are spending the same amount of time in the sound as in physics. Sound is processed in a separate thread usually, thus not a big deal. I took the chance to cleanup the sampling code a bit though. So nothing exciting in this build. The new positions code will follow asap.

It should be possible to speed up physics too. A considerable amount of time is spent in wheel ray routines. We can reuse the wheel cylinder contact information to speed up them.

I've noticed that the game is not able to fully utilize the cpu(2/4cores). I am at max 50% per core load on the notebook(weak gpu) and desktop system(powerful gpu).

New Windows build(without data) vdrift-gui-2012-04-21.exe:
https://sourceforge.net/projects/vdrift/...%20builds/

Changes:
- Rewrite sound sampler to use integer math only instead of mixed floating point. This should allow the compiler to optimize it more aggressively.

[NaN]

New Windows build(without data) vdrift-gui-2012-04-23.exe:
https://sourceforge.net/projects/vdrift/...%20builds/

Changes:
- Start position is the center of a 2 x 4 x 1 meter box on track surface. Move car to fit bounding box front lower edge of the position box. Disable align with ground for testing.
- Fix: Close files on track loader clear.
- Clean up sound(source) code.

I've noticed sound crackling with 24 cars especially on start(windows). I think we need to look for a way to reduce/limit the number of active sound sources.

Testers don't forget to pull latest data. Due to disabled align with surface code starts on some tracks will fail. This is intended to support track position work.

Tracks updated to 24 start positions:
a1ring
bahrain
barcelona
brands
charade70
detroit
dijon
jerez88

Help updating other tracks is appreciated. See also http://vdrift.net/Forum/viewtopic.php?t=1757

[NaN]

A few more tracks updated:
dirt-3
estoril88
fuji

[Timo 6]

Looking good so far. No issues apart from those already mentioned.

[NaN]

Sound crackling turned out to be a regression. There will be a new build with fix tomorrow.

Edit:
I have still been able to trigger it. From my current understanding it comes from dropped sampling buffers. So limiting the number of sound sources depending on distance/gain should help. Need to run a few checks with less opponents to confirm my assumption.

Anyone with experience in sound coding/processing here?

[NaN]

The limit for crackling free sound on a 2GHz Intel Dual Core seems to be about 10 cars. Will try a priority queue with some simple sound culling, maybe with a configurable sound.sources setting.

[Timo 6]

Occasional crackling starts for me with ~7 cars:
Processor 2.7 GHz Intel Core i7
Memory 8 GB 1333 MHz DDR3
Graphics Intel HD Graphics 3000 512 MB

[NaN]

I think I am starting to get an idea of what is going on. With 24 cars I counted up to 528 sound sources, with a maximum of 278 active at once. 10 cars max out at 120/310. Crazy shit huh..

The actual problem is that there is too much going on in the sound callback, which is executed asynchronously and has a hard timing limit depending on sampling frequency and buffer size. Anyway the current implementation is not even thread safe. It could happen that a source is updated by the game(position, pitch, gain) while it is sampled in the callback. This issues can be fixed by moving most of the calculations out of the callback and passing sound source state copies(currently pointers are passed).

I am wondering if we could avoid reinventing the wheel here. Are there sound libraries for games(low latency) out there that can deal with a decent amount of dynamic sound sources with variable pitch and have a somewhat usable api(c++)?

Back to sound hacking...

[NaN]

New Windows build(without data) vdrift-gui-2012-04-25.exe:
https://sourceforge.net/projects/vdrift/...%20builds/

Changes:
- Fix sound crackling by moving sound source calculations out of sampling callback into game loop. This means up to 20% more load on the main thread. Limit number of active sound sources(disabled atm, needs profiling). Sound callback is still not thread safe.
- Fix: Don't mess with gain when incrementing sound source, leads to crackles.
- Fix #85: Rename signal.h to signalslot.h.
- On game leave clear sound instead of removing each sound source separately.

A few more tracks updated:
hockenheim
ruudskogen

The latest changes are fixing the crackling but increasing main thread load from 50 to 70%. But that's OK I think. Run vdrift -profiling to get some performance data.

@Timo
There is a max active sound sources implementation, disabled atm. I haven't had the time to test/profile it yet. If you are interested in testing uncomment sound.LimitActiveSources() in game.cpp

[NaN]

New build(without data) vdrift-gui-2012-04-26.exe:
https://sourceforge.net/projects/vdrift/...%20builds/

Changes:
- Clean up soundbuffer a bit.
- Minimize sound list lock contention(by double buffering). Ideally one would use atomic swap instead of mutex. Add active sound sources limit setting(gui, config file). Default active sources maximum is 64.

We've got max active sources setting now, helps a lot with performance. The sound system is still not thread safe though. If you still have crackling please report.

[NaN]

New build(without data) vdrift-gui-2012-04-28.exe:
https://sourceforge.net/projects/vdrift/...%20builds/

Changes:
- Fix: Don't load opponents in practice/replay mode.
- Fix: Rewrite sound system to be thread safe. Max active sound sources culler not reimplemented yet.

I haven't profiled/optimized the new sound system yet and the max active sources culler is broken. Thus it might be a bit slow when running with more than a dozen cars. Anyway please download and test.