Serpentine

Engine code warnings : 11 (All are SSE+asm related, meh!) Game code warnings : 1031 Thats what you get for using Boost and hiding things with pragmas :/ Now to see if missions actually work, hmm!

Not entirely standalone, but ehhh - Portability. First run of the ported code - amd64(x64), openal and all the rest, running without any horrible hacks natively on FreeBSD 10-Current. Should on *nix and be a billion times easier to compile and package, just a lot of stuff to now make cleaner and finish making it happy with Windows again Soon my pretties.

I just use the convert functionality in foobar2000, you just need to put the encoder executables somewhere it can find them and then it acts as a reasonable front-end. The preset functionality is also fairly good for consistency.

Also toot toot, I'm 60% through hand fixing the headers(i.e includes, since throwing away the pch and cleaning the large game_local) for game code. Compile times are down, but there's a lot of boost stuff that still needs to be verified. Boost murders the compile time, as well as it just being generally painful :/ Soon my pretties!

Hey, I dont really plan on using this. At the moment I'm transitioning everything to cmake, which will make your life a whole load easier - but this will be useful in the mean time while I try find time to fight our horrible game code mess into something more orderly. The cmake merge also brings in most of the nice parts of dhewm3, so we should end up with amd64 and all the niceness. Thanks for the patch tho, I'm not entirely sure that the MFC stuff is completely cut out in my current stuff - as I've been testing on nix + clang/gcc/icc, but its likely you'll save me a bit of time figuring out the windows side of things when that time comes

Yup

I was watching a documentary the other day on dark-age art; It was full of AoE 2 sound effects. I'm really surprised that there wasnt a 2 minute wohololololo loop spam. I miss lan lobby sound effects That said, I think the two large free SFX repos are free for commercial use too.

Just rename the xml file - it'd be useful to see what is causing the crash (I wouldnt expect a completely malformed xml document could... interesting). It's just your settings for DR, which normally isnt too much. If that fixes it, I'd appreciate a copy of that file

Ah ok, well then - thanks for investigating the faces. The snow should be there if you're looking down, if you're using a brush. With the exception that if the brush is behind a portal which is closed by you looking down. I guess you have a horizontal portal over some street sections?

As far as I understand, it will make no difference to the performance/visuals if all of the faces have the material. Might want to cross check that. I also think one of the material keywords for particles uses the texture scale to adjust density, the other one is fixed. I like single material brushes too I've only used this stuff once - just going on what I remember of the code (which is a bit foggy).

Some of these look a lot like war/jousting helms - Not that I'm some kind of expert on these things. But they just dont look like something you'd have a guy patrolling in. (Which reminds me, the BBC 3 part docu series : BBC Metalworks! is pretty damn good - well worth ahem, finding 720p rips of - at least the Knights ep.)

Umm, try using brushes as rather than patches for the emitters, I think patches are ignored in a few situations which brushes would not be. Just a wild shot in the dark.

afaik : Yes. If you're using windows, try download : http://connect.creativelabs.com/openal/Downloads/ALCapsViewer.zip Under 'all extensions' there should be EFX 1.0.

It would, and they're actually not too hard to normalmap either.Here's an example that is ingame: And that then pops into your SSBump or whatever, and is under over the diffuse (for small details), letting the hightmap give the larger structures. Nope, It's ready for the cmake branch - just finishing up the game code fixes before I put that up as a fork for testing. It's slow due to how messy the headers are, but yeah... soon.

Yep that is correct - sorry about the bad wording! It offloads all audio stuff to OpenAL-Soft, which has a lot of advantages for *nix players. For Windows folk, it doesnt bring much, besides the effects for erryone. I'm not sure what other features you're looking for? None that I know of (that's the aim!), most things should work as a drop in replacement. If you don't have EAX at the moment it would not be a good idea to start throwing numbers out and hoping it matches up later, I guess most editing can happen post-release.

OpenAL-Soft Backstory: OpenAL was started to be a standard for positional audio, so that different vendors could implement the same features in their own products, but share an easy way to make use of them - like OpenGL. OpenAL however was not intended to be used for effects, and as such did not conflict with Creative's EAX. EAX was/is a fixed set of effects which can be applied to audio being output. EAX however is specific to Creative (or, licensed from). EAX does not really allow custom effects, a bit like if graphics cards had a single 'water shader'. Later on this became a bit limiting and not very exciting, tho EAX versions added more bells and whistles they never really got exciting. OpenAL on Creative has since become very closed off and no one actually bothers anymore, just like EAX. Since other vendors could not use EAX, there was very little real use of it - many games that advertised it actually used to just roll their own software methods for better control anyway. However EFX was later born to be a more flexible replacement, allowing customization of effects and filters, and an open standard for other vendors to adopt. Sadly this all came a bit late in the game and while it's supported by the main vendor drivers, it's often a limited subset of features. EFX can essentially be seen as a superset of EAX (technically it's missing parts, but no one really uses them anyway). OpenAL-Soft is essentially a software version of both parts, it takes care of positional audio (and supports many more backends, whee) and can do EFX. Since it's a near drop in replacement, the code change is minimal, and if people want to use their hopefully accelerated windows drivers, they can do that too. The EAX effects in Doom3 have been changed to equivalent EFX effects, meaning that everyone can hear them, *nix and Mac included. Performance hit should be very low these days, and a few effects might need to be balanced to fit, but all round it should make life a lot better for both devs and players

OpenAL-Soft / EFX will be in the next released engine version.

Damn, I've never been much for NPC faces, but that looks really good Spring

In DarkRadiant there is the 'Entity Class Tree' view, located in the Entity menu at the top. To quickly find something in it, select the base 'darkmod' node, holding your shift key down then press the right arrow to fully expand it. You can now just type in what you're looking for eg 'arrow', it will jump to the first match. To move through to other matches, press the down arrow key. The same applies for adding a model. I generally expand all of the 'darkmod' tree, then type in 'chair' or whatever and try find the one I want. Less hastle, and it also shows you skins at the same time, which spices things up a bit.

Nah, some of them do use the normals - and I have no idea how the engine works out if it wants to use them or not. Not all models have normals for all of the geometry either, so making a list of models that the engine generates normals for doesnt help (I tried). I'd just leave it be, maybe one day it'll become annoying enough to deal with, right now I've just got home and some time to fix some game code porting.

The vertex normals can invert a whole face - leading the issues with shadow casting being incorrect, they can also do some strange magic which results in the face just looking shadowed when it should not be. A lot of the currently working models with custom VN supplied are only working correctly because the engine is actually ignoring them (only _some_ versions of the 3ds max export seem to work, other exporters seem to just be ignored, at worst result in rendering issues if they are used). I'd really just not export them, see if it changes anything. Maybe leave it in as an option if there's benefit - sometimes the generated normals will smooth sharp edges, however it usually gets that correct.

I don't really see why you'd export the vertex normals. Unless you are exporting an existing model, the normals in the export will be the same one as the engine generates on load for shared vertices on load. I spent a long time fighting them for the assimp exporter, only to find that it's almost always pointless to even supply them. In most cases you just add a lot of resource overhead.

I'm sure this creeps up quite often but doesnt get noticed all that often, or overlooked as a stray keystroke. BD might run into it, all that fiddly work Did you by any chance edit the map in the engine and then save it out? (i.e when working with ragdolls or something). Other than that, was it aligned to grid, or is it perhaps a rounding bug?

Timedemos are quite closely bound to the engine internals (a bit like savegames), so they'd need to be re-recorded per-release - which would invalidate the results - as well as being a fairly unrealistic representation of CPU load. Perhaps we could do something with a timed camera fly-around of a map, throw in some scripted physics events and AI.

Very interesting I'd love to get some procedural stuff like that masonry plugin into the engine some day. Looks really neat seeing it all accurate to the textures(tho some normalmaps look inverted or something... hmm) like you have there! Also - Welcome to the 16:10 bros club.