I hope that means you removed the 30hz limit in Brink. :fingerscrossed:
Id tech 5?
murka
(murka)
#64
Tbh some removal of the 30hz tic would be good. Not possible to get good slow-mo videos because of horrid framerate.
dommafia
(dommafia)
#65
Man that would be a huge bullet point on the features list.
I vaguely remember digibob saying it wasn’t possible on the qw engine many moons ago. I hope I read wrong. also think that higher tic = higher server cost.
murka
(murka)
#66
Thats why i suggest partial unlock, maybe interpolation. Would help all movie makers get those slow-mo shots.
Sabayon
(Sabayon)
#67
[QUOTE=deadlights;194800]id released a statement today that the leaked Wolf2 MP was not even close to being a polished game. It was a pre-beta release that got leaked.
I don’t want to go off topic. Because this is not about Wolf2. This is about BRINK, so with that said, you honestly can’t make assumptions until you see som game play footage. And even then it is hard to tell…[/QUOTE]
The Beta Leak was the July 22nd Build of the game. Theres nothing Pre-Beta about that.
On another note. Maybe SD should look into allowing custom maps to be allowed on Ranked servers. So that people actually will stick to the game and not leave it because they must play same maps over and over again. (for all those stat guys out there). 
digibob
(digibob)
#68
[QUOTE=dommafia;195824]Man that would be a huge bullet point on the features list.
I vaguely remember digibob saying it wasn’t possible on the qw engine many moons ago. I hope I read wrong. also think that higher tic = higher server cost.[/QUOTE]
Nothing is impossible, given enough time.
tokamak
(tokamak)
#69
Considering the game consists of two continuous campaigns? How would that work?
I don’t think there should be a difference between ranked and unranked. The difference should lie in ‘standard’ and ‘custom’.
Sebultura
(Sebultura)
#70
[QUOTE=digibob;195152]The old audio code used to submit buffers to DirectSound in large chunks, think it was around 90ms or so’s worth of sound at a time. Since the game code tic ran at 30hz (33ms), this meant that whenever the game code submitted a new sound, there could a variable delay before the sound actually started playing. This took a lot of juggling to work around, and in the end I still wasn’t hugely happy with the solution.
We have moved over to using the XAudio2 API now however, which is a much nicer API to work with, especially as a lot of the annoying fiddly bits are handled for you. Write once, compile twice (it runs on the 360 as well!) is also very handy, as it cuts down on the number of APIs we have to support, and thus, the code we have to write.[/QUOTE]
Damn, I’m not sure about it, but I can recall I had serious problems with Quake 4 audio part in the case of what we called back then a “dynamic music system”.
Let me try to explain the idea: our audio artist made one music, then at key points, he knew the music could have specific transitions to another music chunk, so I made a small system taking this into account and launching those specific events at key moments into the game, and this is where we remarked this problem: although all seemed to launch in due times (based on the event system), the music chunks were the right ones, etc…, there always was those very small blank times between sounds, making the music unperfect in the end (although I guess it was rather ok for a thing coded with the SDK only).
At that time, I contacted the Raven dudes & got an answer back, stating that all they could see was that audio system running at xx hz (don’t remember the exact #) and they didn’t saw what else could make this happen.
In the end, we decided to make the system less complex & using “fading transitions”, so the small delay weren’t noticeable…
I know this is hard to figure out this way, but do you guys think this was really due to the engine (I passed a hell of a time to understand the thing & the audio chunks were all good, no blank stuff, etc… never understood why it acted this way) ?