Serpentine

Hmmm, can you PM me a copy of the map? I cant promise answers now, but I like to keep these issues as test cases.

afaik BC has fixed this issue. I will be taking a look at the engine side of things - so that in future it bails with an error.

Ah ok - fair enough. This should be resolved in the next version

Hmm I seem to recall this happening if not all of the files were downloaded correctly. Also your gamma should have been reset correctly if you quit normally (I made this a bit better behaved in 1.08, but it's still not foolproof). Could you try running the installer/updater again?

Rather fix old articles imho. English is the language of the Western Internet. Besides for French people who actively fight it. It'd be nice if we had a list of articles which no longer apply or are out of date (e.g. DoomEdit related) - that's a pretty good task, and if you're not sure I'm sure we can answer.

Meh, I can add it - but it's not very handy for audio. It's also what people will look at rather than the bit- and sample rates - which are important and correlate closely with size (there is slight compression). I'd need to be hacked into the parser anyway, so maybe another time. Would be useful for other asset types.

Oh, I forgot to post the link : TDM Sound files The headers should be sortable, the sorting is dumb - but good enough. The table is huge, so if it lags - don't spam click on the headers. The col 'ExtraInfo' contains any other metadata found in the file. There are a few oggs with strange sample rates (these should be fixed to 44.1), a lot of really high bitrate stuff. In future I'd recommend finding a more reasonable level for saving out release ready oggs, but yeah. Not a huge problem or worth transcoding everything.

BD & Melan - love the materials use , really slick @Capela - Tiles look a bit odd... but the rest has this really nice proportion to it, real atmospheric for such an early stage!

Ah - forgot to give some feedback Rewrote the script a few nights ago, it's outputting a lot of nice info now. I just want to remove some of the excess and make it highlight possible issues more clearly. I'll put up a basic version of the output(one big ass html table) a little bit later tonight.

I wrote a little tool to dump all of our audio info a while back. Should still work, want me to make a table of it for you?

I own a pile of SSDs now, I still don't see the point in them for 'performance' - I just use them since I hate physical damage being an option - and the majority of my boxes spend a lot of time idling, so the primary disk seems a bit of a waste. If you want performance, take your silly raid money and go bribe Intel for one of their big nvme engineering samples. 1.7mil iops, whee.

Basically, yeah - SOME audio hardware will deal with OGG, but these days its very uncommon, the majority (which is still fairly small) will just decode it in software at the driver level, a tiny percent will really be done on hardware. So pretty much it's going to be done in software, the engine already has a very fast and simple decoder which is rather up to date in regards to libs. OpenAL-soft can deal with OGG, but this is just done in software too - and since it's a compile time option and you cant tell if your distro package maintainer has selected that - good luck! (This doesn't even go into the way that the game manipulates the PCM for effects like shake etc) Don't get me wrong, if there's stuff which has been encoded at insane values, by all means that should be fixed - However for the sake of load time its pointless. The load time is all about textures and texture compression - about 90% of it. I have allowed s_nosound 1 to completely disable the sound system in my branch. Testing with it, I can't really see a difference in load times. Speaking of that - just after you left I got everything working, still a few script functions seem a bit crashy, but otherwise it's happily running on amd64.

You will only really encounter bitrate setting when you are exporting. There should be some advanced options there. Project Rate is the internal sample rate. i.e if you're working with something you imported at 44.1k, and then import a 22k clip, you will need to resample it else one will play super quickly and sound stupid It should be 44100 for D3. Other values will cause trouble, specially if they're used in effects.

Hmm, ok I'm no expert on audio stuff. We will make some assumptions and cover some likely over simplified/incorrect theory in mono! Sounds are waves. We can draw nice graphs to represent them. Most interesting sound however is rather high frequency, and making pretty graphs of those waves is extremely hard(In the same way recording them with precession in real time would be), and to play back would require a lot of calculation. So we cant really use nice waves to store most natural sound on a computer. Rather we take samples - Think of it like a record players head floating in the air, the sound a wave which it runs along. Our sample rate is how many times a second we look at how high/low the needle is in respect to the starting point. The difference is a point of data - it could be 7 away, then the next time 9... and so on. This works quite well, however there is no way for us to know the true frequency of the wave. Should we be taking a sample every second - and at 0.5 seconds the sound does a little dip then comes back to where it was at 0.9s, we are none the wiser. If we sampled more frequently we would be able to catch more detail in this regard. In such a way, sample rate depends on what the wave you are trying to record is coming from, too low and you lose lots of detail, too high and you end up with lots of 'unnecessary' data points. Now, that's fantastic and all - we've taken out samples and made a bit of a bargraph out of the wave. Playing this back would sound terrible - unless you had sampled at an insanely high frequency to capture the smallest details. This would eat up a load of storage space and throwing data around. This is more or less what raw sound is however. We also need to take into consideration the sample's possible magnitude, we are recording these numbers, but to keep it all easy to work with. The problem is once again that sound is unpredictable, just as with graphics we have a bit depth. Just as we have 8 bits per colour channel for a pixel of colour (for example), we could use 16 or 24 bits for our audio sample. So let's play this back! We take our raw samples, they sample rate is way above what we need to hear it accurately, the depth is good and has no clipping. We can jump around the recording easily. If we want to go to 23 seconds, we take our constant sample rate, figure where that starts and continue. However if we're storing this all in a computer, it helps to know where in memory that position is, so we take our sample rate, times it by our sample depth, and work out how many bits of information the offset it. Fast and efficient - but frigging huge. PCM includes the info about bitrates and such, where true raw does not. Just like TGA, working out PCM size is very simple and fast. This is hopefully what we store in our wav files (they can store other stuff too, just containers!). Now we want to be more efficient with storing the audio, so we drop our sample rate to match the desired object - a phone call, human voice. This then makes us have more error in our already non-analogue form. Playing it back sounds pretty crap, so we add some filtering that takes those values and tries to smooth the output wave between samples. A good start. Then we decrease the bit depth. Now, just like pictures, dropping depth is sometimes fine, sometimes not. We now end up with a situation where two slightly different values are now the same, giving heavy distortion. So we tune the filtering as best we can, try a few tweaks, but it's not all that great. Now rather than killing the quality, we rather look at changing the encoding. Storing that huge bar graph became a mission, so we rather start to just record at high quality, then process it in a way that takes consideration of the recording, but fits into our budget for storage space. First of all, with the whole recording we can eliminate extra bit depth, we recognize common features that we can store in a simplified way, but restore when we decode it again. However this encoding means that we're gonna need decoding later on to play it back. How do we play it back? we decode it back to our bar graph like state which re reconstruct as best we can and output it in raw. (Ok, some hardware can decode storage formats without software, but in this case - no.). Different encoding schemes are allowed in OGG, and they vary depending on what they are intended for, Vorbis will be our most common - and is a good general purpose one. However Speex for example is optimized for storing human speech, and as such uses far less information per second to store it, meaning a far lower bitrate. So lower bitrate means lower information, but it does not always mean lower quality - since that information might be completely useless detail, encoders will allow you to specify your desired bitrate, then try to squeeze things to fit, where lots of trouble can happy... or conversely very little difference for a large decrease in size. Changing the samplerate means many things, but since your computer's sound system will require specific rates and depths, the engine expects the rather standard or easy to adjust values, but dislikes completely custom values(The engine should already moan about this - but still, for some stuff it could be dropped - but this is one which requires listening). The decoder in the engine makes a few assumptions on what values we can use, sample rates and such - as to make it fast - but at the end of the day, we're caching decoded PCM stuff and this all makes little difference besides for filesize. Do it right the first time, I'd only look for clearly errant sizes otherwise. tl;dr - wav/pcm = bitmap; ogg = jpeg. We internally use bitmaps anyway. Edit : Oh hey, I forgot to open the search results I was going to just paste anyway, maybe a better overview: http://grahammitchell.com/writings/vorbis_intro.html

Just remember that the sample rate supported is fairly static on the decoder side of things. Adjusting the bitrate however in cases where it's pointlessly high is not a problem afaik - you just have the possibility of adding aditional transcoding artifacts - meaning that batch processing can lead to unexpected consequences. Remember also that the ogg's are decoded to pcm at runtime, so only the raw size really matters.

I have a great movement related trick that someone could use... I might have talked about it once on the forum, but I've never seen it actually used in a map before. I will sell you my secrets for a fair price!

Nuke your config, don't set AA to 16 if it allows you to - it should limit you to 8.

I cant really see any detail in 640x480 screenshots - Please could you try get some higher res shots?

Hmmm, which graphics driver are you using? nv or nvidia? I suspect it's the nv driver - in which case please try installing the nvidia proprietary driver. It also looks like TDM might be missing some files - could you try running the updater/installer again?

Largish expansion for Dishonored.

Yeah, gpreftools is the Google Performance Tools (and not gnu/gtk - annoying naming!). The output is fairly good, and KCacheGrind accepts it as a supported input format, making it a lot easier to work with. I've not used it extensively, but the combo worked well enough for me in the past. I'll get Taaaki to reply about the Intel tools, I know he's been using them to fix up leaks lately, not entirely sure about VTune tho.

I know I should post it in some forum feedback thread - I just noticed it as I was going to bed and doubt I'll remember later. This subforum isn't visible when logged out, though it is in the "public" section. Mistake?

Nope, not really - aside from amd64, which should be a slight bump (Truth is I haven't built it on Windows yet, nor am I able to start missions just yet - close tho). It's just a lot cleaner than doing it ourselves. At the moment it's still got some SDL, which feels a bit clunky and slow, it however makes porting super easy. I plan to remove it, but keep the current simplified platform support. Performance should just... remain the same, but I think we can lighten the cpu side of things a lot from the game code side of things. Taaaki is currently waiting on me to try and investigate some threading for the AI (which seems to have been attempted in the past). Compile time should be way down on nix - More threads the merrier. Took apart my main box and physically cleaned it, then rebuilt userland/kernel/ports etc. Now for some sleep - then a branch or tarball later for people to try play with.

Haha, It wont be running off anytime soon - but hopefully over time we can replace most of it with C++11 as that becomes more established But it'll be something I want out of the engine asap. As well as all that SVN stuff, never understood why it was really needed. Will have a little team talk about these once my stuff is in the repo (I really need to make a branch I know!) Whatever clang default warn level is. It doesn't try to understand the msvc pragmas, gcc does a few I think (and I've now just removed them all anyway, heh). The static analysis html output is pretty insane, will compress and upload it sometime.

Generally nothing, they are usually part of larger collections of software which either cost a load, or cost nothing. I've used gpreftools + KCacheGrind a bit, maybe a heavy but rather good for my needs. A big advantage of gpreftools is it works happily with clang, which is handy to have in conjunction to clang's static analysis and other tools. There are also the Intel tools for linux, which are free for noncommercial use afaik. Never tried profiling with them, but taaaki should have some experience.