Serpentine

TDM can standalone for the most part already, it doesn't crash or anything spectacular without doom3 (in 1.08-svn so far). It's just a pile of assets that needs to be replaced. Some missions the missing content is pretty obvious or could be game breaking, others seem fine (I have only tried 4~). So at this stage 1.08 will deffo not be stand-alone, but due to be being possible to play, maybe this will get some people interested in helping replace the stuff. I'll update the wiki page and link it here when I update it (perhaps tomoz).

That's already in 1.08 :)As for GLSL, it'll show up later on, there's no point at all supporting it's fit for our use, and even then, there is a lot of work needed to port our shaders over. And Phoronix is still a horrible news site, how amazing :/

Yeah, the lantern is plenty bright as is, increasing that would be mad.

Hmm, they are working on my side. However, if the NPC you are trying to lure guards which are on their idle patrol, if the arrow it 'quite far' away, they will just become alert and start looking around, not actually trying to get to the noise. If you fire closer to them, they will head towards it. I would have expected them to head towards the source from further away.

Square Enix, the bulldozer trying to make games out of Western IP. But I guess it'll sell a billion copies and spawn a terrible follow on series like AC.

Just remember that heat haze will mean that the particles will be rendered above glass, so windows etc become a problem. Edit: Actually, I'm not too sure about that, particles might work fine.

You can always crank up the ambient while testing

Thanks for the report I'll see if I can reproduce it later - might need some info, but I'll keep you updated.

Nope, but if you're interested in helping out - let us know. We use subversion and don't host publicly as the repositories are all far larger than any of the acceptable free services allow.

Yeah, it's not really all that complex - the engine doesn't get the full number of dynamic models/entities for the map, and as such allocates far too little memory, to get around that I just hardcoded two high values for now (not a large amount of mem anyway). When things are more stable, I'll move the allocation later into the loading, so that the numbers are valid and no longer magic numbers. Resizing it when needed could also work, but I'd prefer to keeping things simple as to avoid issues with runtime entity creation.

Well, I spent some time moving over to qmake... now to move that over to CMake.

I like both, but there's a little problem with the second in practice. The outward held weapon is realistic, since it gives you a good initial place to start swinging from, and keeps the weapon from harming you if dropped. However it'd only really be used outside. While the current, inward hold is slightly unrealistic, it is more practical for a game, since you dont want to have the weapon intersecting with geometry wider than the character all the time. It makes sense inside and doesn't look bad outside, while the other would look very awkward in many situations like passages and average sized rooms. If it's somehow possible to determine these things, I think both would have their places. Or if the proposed one however can be shown to not look strange in inside gameplay - I'd be happy with that too!

Nice, has similar geometry to something I added to the revised training mission - Nope, I didn't steal it - and it looks very different with those textures... just didn't want you thinking funny things! I do like that 3rd shot too!

What am I doing? Fixing memory leaks and trying to move to CMake :3 Most of the big batch of cache/table fixes made it into the svn last night, some testing shows very noticeable gains (we're talking 15 fps -> 25fps; still a way to go). Needs more posting of work in here! (Also, not imageshack pleaaaase)

I've been compiling and debugging some stuff using the Intel compiler set lately, having to fudge the solution each time is extremely annoying and a waste of 5 min :/ So yeah - CMake for a build system would be lovely. Windows users only need to generate the solutions once (and they could always just share one like atm). You also have the option of CDash, which gives you your desired web interface and whatever ever. Since I now know that at least there's someone else who'd like an alternative, I'll see if I can start hacking together the CMakeLists files, tho I have never written from scratch... should be interesting.

The problem with hard numbers is that there's two situations that you can try to look for and fix. The normal but intensive scenes - i.e the map is well constructed but during some sections there is a lot of geometry which drops the fps. In this case it's a matter of digging around and making things as efficient as possible, cutting out render work where it's not needed and such. This is nice to fix. Then there is the bad case - i.e the map itself has not been well laid out, there are far too many portals open at once, hub areas leaking everywhere and generally poor performance. This while it is helped by the previous case, is nearly impossible to really get large noticeable gains in. The latter case involves looking at the big picture, while the former allows you to profile and methodically move through areas. Expect the former case to be quite a bit faster. As for cubemap lights - Any 'new' stuff for the render is effectively deferred to beyond 1.08 - since there are many possible knock-ons, as well as no content that uses them. But expect it when the glsl stuff comes through. Less pie in the sky - more general health.

It looks like the script is exporting a lot more components per frame than the current one. 430 vs. 75 or something. I think a lot of this is just 0.00003's being slopped to 0, and 0's being removed. But I havent looked at the code or anything. I have a feeling that this 'removed' stuff would just be populated by the engine either as 0's or an average of something else, so the extra detail might actually be a good thing and come at no reduction in performance or memory(once loaded). Once again, I really havent looked at it, but that's my guess.

<p> Can you upload one? sounds like it's exporting duplicate/extra frames, and then using a higher framerate setting. Also, I think the scale for maya is 0.93 Edit - This forum software's abuse of scripts to magically do formatting is getting old, fast ;/

\\purgatory\purgatory\doom\ Is automatically ignored by the engine - It's not a huge problem to just batch remove it from all ASE's anyway. Sotha - Does the geometry that you're exporting contain faces with caulk on it? afaik the script ignores that, and by doing that it might not be updating other references. I havent looked, but I have a feeling that it's possible.

Nope, I have never needed to RAID other than for my fileserv which uses a zpool. I have have lost one drive in 15 years and retired one that had issues(ironically bad firmware to avoid a firmware bug), I have all of my app profiles from nearly 8 years ago (I still use an Opera profile which has been updated from 6.x as well as my Miranda-IM db from 2002). I've never had to use a non-live backup of pretty much anything I only use single partitions (and sometimes, like with win7 a recovery partition) drives, they are well looked after and have no active power management enabled, meaning that they pretty much live forever(the last drive I retired was a Maxtor 120gb sata disk from 2003, 9 years with maybe a week powered down in that) and don't have any slow spin-up times. Over the years I've had to help with a good number of broken RAID arrays, listen to tales of how X lost everything, Y's controller ate some stuff. Read through countless patch notes addressing RAID issues. BIOS updates warning and disabling RAID features. Laughing about nvidia raid eating arrays on friends boxes. Felt the underwhelming difference in performance between friends with quad 15k raptors (which later were jbodded - controller died). Dice rolls sure are fun. If you're getting benefits other than load time, you should spend the cash on memory and push up all of your caching, buffers and make sure your disk is well laid out. RAID in industry, fine - it's got many reasons for existing and is essential for some (but understand why there's also a large number of recovery companies that deal specifically in array recovery - and that's with expensive, good controllers), at home, a powertool for powerfools betting on beating the odds. But then again, I also feel that my SSDs were a waste of cash, about the only benefit to me is that they're silent, meh.

Try to get another 4gb that roughly matches the PNY 4gb. You use modelling/PS etc, 16gb will come in handy in the future and is a fairly cheap to round off now. When using AHCI, make sure that you have the AHCI driver installed - else you will get degradation. Don't — EVER — use RAID at home, though others will claim this to be BS and mention how ~amazing~ it is, it's simply not worth it. Unless you're running a NAS with ZFS or something. Use your soundcard and dont use any USB sound crap, while you cant see the performance difference much these days, its there (sometimes 5%-10%, good chips about 2%). The XFI stuff also seems way happier on win7/new intel boards. I have also found that the PAX drivers avoid a _lot_ of the installing trouble and dont come with fluff.

That guys work is working towards essentially throwing away everything that is 'nice' about the tech4 engine modding and replacing it with very cut-and-dry simplifications. It's modern, but it's got clearly defined goal posts which will be a complete pain to work within, its his choice and I dont know why people are getting uppity about it. His engine will not support any current mods nor do I expect it will even remain within everything down to the map format. It's a non-starter for the long term, so why gum up the wheels by rushing in without thinking? It's not that TDM will not get improvements, we're already looking at nearly 50% bump in performance (a good bit which I still have to check and commit, but about 25% atm) bump in performance, and drop in cpu use. Note, that's more than pretty much all of the other branches — because everyone is adding and replacing rather than reading and dusting — boring, but I'd rather have something that works well than a shiny turd at the end of the day. The need for revision and improvement of the engine is far higher than 'add new shit which no one understands but the patch works'. If you want new things, you must also deal with making something sustainable. I expect we will move towards amd64, more portable code and GLSL in the next release. Fancy things come later, once we've got everything going smoothly — and people who can look after and develop them in the first place. Organic, iterative development vs. Rushed, blind leaps.

The last one is much better, however I still think that the current one has more of an urgent look about it. The last one looks like someone running a race imho. But it's nice to see the animation moving over so seemingly smoothly

No, that is far too far from tech4 to merge, it's also not something I think that we should even look at, we dont have anyone to maintain code like that.

I've seen it happen where the tray is being pulled in too much (i,e the motor is trying to pull it, tho it is essentially jammed in). After a few seconds the drive gives up and ejects the tray. Just needed a new elastic belt thing. I've also seen laptop drives which randomly eject when the drive is spun up at max speed, but I've not opened one and had a look.