Serpentine

The penalty depends mostly on if you are doing fancy things it can be quite high, but on the whole it's very low. Most of what you have to watch out for is in the material, or things like segmentations (for making sparks) - and even then, you can budget to not hurt performance too much. I mocked up an animated bat material for using in particles a while back, however I was using borrowed resources and didnt get around to making a free version. Looked kinda nifty.

Think it was just a mistake a long time back. It's also used for a few static skyboxes, as they get extremely big as targas and can't really be DDS at this time.

Nope, it's just the way jpegs are mis-handled atm. Greebo updated the jpeg includes, which had a slight difference to the old id ones, so things get a bit strange. Swapping the texture to tga would fix it, but it wont solve the problem. There are a few different approaches which could be taken, but I guess just put in a small hack like the windows fix for now.

That's an old problem, it's fixed on windows - it's to do with the way we're abusing libjpeg. Not too hard to fix, but I think it would be better to actually stop fighting against the lib and rather use it correctly. If you could make a tracker entry and assign it to me - I'd appreciate it. Don't have my cookie to log me in, don't really feel like resetting it either.

@PranQster - 295 is a fairly old driver, most distros/OS are using 310 for bleeding edge, 304 for stable(also has legacy). So yeah - might want to grab at least 304 for testing this - http://www.nvidia.com/object/unix.html etc. 310 also fixes a few bugs with video colour spaces, which is always nice. And it's reasons like this that I said the cfg's from 1.07 shouldn't be used for 1.08 - Since it saves out a lot of engine internal configs which were changed to work, or certain paths work more efficiently. Rather move custom mouse stuff to an autoexec or something, donno about sound - but that'll hopefully be all changed and fixed for 1.09, when OpenAL will be used everywhere (and from there, OSS / ALSA / JACK etc, as needed - since it knows better, or is more often hacked to work nicely on crap distros). I'd be interested in which beds cause issues. Could be an issue with strange DDS headers, seem to remember one of the bed ones being funny.

Cant say that I did extensive linux testing, though there did not seem to be any issue. I've never seen a problem that looks similar... very odd. That driver is fairly old, could you try updating it?

You cant use the BFG resource files at all, unless we moved completely to its engine... which isn't going to happen. I poked dhewg about if he'd be backporting changes, he said he's interested but no commitment to it at this stage. Since I'm working to bring TDM closer to his work at the moment (it's very subtly different, but brings in a lot of advantages), we might be able to pick out the cherries in an easier manner. The only real pick up is the render changes, which if they're possible to move over easily; would be a massive boon with texture compression and glsl support (with all of the shaders now released too - no need to re-write any). Time will tell. Really, the code is nice to have and might give us stuff... but at this stage it'd be foolish to try grab things so soon.

Most of the map load is already just reading in binaries, the .map is a really minor part in the grand scheme. Rather the gain comes from the replaced resource management/loader/storage format - which changes just about everything. That said, there's not a chance I'd be happy implementing it in the current non-zip way. Load times are really really low if normalmaps are pre-compressed. <5 seconds to load the training mission from cold on my cheapo ssd. Once we get there, no problems. But yeah, the code is vastly different to the existing stuff - only a very few sections are really easily portable. I don't see this being a big source of stuff outside of the render stuff (which I havent looked into much). ATM my work is going into making the TDM build system(s) sane(because 3 completely different systems is retarded) and code more portable, I'd like that done before anyone starts playing with this. The font support seems interesting, seems to make packed rasters automatically... that might be very nifty.

If the file is a local dependency (i.e you have the header you want to include and it's been written by you - or as part of the project or whatever) then you use the quotation marks to include it with a relative path. If the header is part of the system libraries, as with standard libraries, then you use the angled brackets (they can also have a relative path, depending on how things are set up). Standard headers (i.e that are supplied as part of any standards compliant compiler/toolchain) are generally referred to without the .h extension these days. If your build system/IDE is correctly setting the library paths, you should not have any problems with the changed version of mine. Didn't test with VS, but yeah. As for the pragma directives, they depend on the compilers cpp (c preprocessor) and generally avoided unless you know exactly where the code will be getting compiled; as they vary a *lot* between vendors. Thanks for eating my formatting forum :/

Basically just needed a few changes - variables used out of scope and such. The headers should all be there now, you don't need to have all the specific namespaces or anything. A quick hack and it seems to do what you want, tho the logic allows it to run off into the sunset if you enter anything strange. Pastie If you're doing stuff like this every now and then, you might want to just learn some python basics(it's super simple, compared). Save you a lot of time, and having fun ways to work with strings and text if great if you're doing ling stuff.

The more I casually browse through it, the less interesting much of it seems. There's some stuff which will be worthwhile to pilfer, but for the most part it seems a bit alien and out of place for the old engine. Even things like dmap seem to be completely missing - while I guess I might just be missing something and it could have been renamed, I'm just not so sure there's much worthwhile stuff here. Overall, streamlined for a single platform commercial release, but not much more. The shader release is quite nice, havent looked at the render too closely but perhaps we can at least try get their glsl render working, otherwise maybe mix something up with Dante.

Hmmm, been looking through it for the last hour, some very nicely cleaned up stuff, a lot of what I expected with regards to resource management. Annoyingly it makes my current re-organization either useless, or a lot of redundant work on the way. Will be way too tricky to do a 3 way merge otherwise :/ Some parts I'm very keen to get in tho

Ah Well, shout if you notice anything - always good to have a record of strange problems.

Hmmm - I removed pretty much all of the annoying grabbing that the engine was doing for 1.08 - So I'm pretty sure that whatever is causing it is something else. It might be some screengrabber(fraps etc) or overlay (fraps/mumble/ts/steam). Logitech drivers are also a bag of wtf. At best I can suggest trying to kill off non-essential processes and try to reproduce it then. Or if anyone else is getting this, I'll have a closer look.

Which distro etc. Looks like there's something very broken with the libs over there, don't see why it's trying to link against wine libs :/

If you're hitting this problem, where it eventually runs out of memory and hangs - please send me a copy of the map - or a simplified test case! There are a few bugs in the dmap/optimizer which have alternative functions (which are disabled because they also have issues), but if I can get some test cases and narrow down where the bug lies and if one of the alternative solutions works, I'm sure it'll help make better maps and less annoying bugs are always good

Hey - Sorry I've been dead for so long; Life got real busy and family required stupid amounts of time. Over the past two weeks I've been merging in a bunch of changes and working to replace the TDM build systems to cmake. Most of the work has been in merging TDM with dhewm3, which is a very clean and easy D3 GPL release (mad props to dhewg for awsm). I have yet to get around to converting the TDM game code to cmake. But so far the engine, libs and such are all happy. I've also excluded the SDL parts of dhewm3, as I think it's a bit messy and annoying on some distros. This gives us 64bit(in the engine, this still needs to be wrangled into game code), many more OS compatibility(i.e FreeBSD for meeee :3), OpenAL/EFX for everyone, GCC/Clang/MSVC/ICC compilers all happy. Also makes it dead simple to get things building and maintained. Also a good foundation to merge in other things from other branches, avoiding the incredible mess of the previous build systems and such. I haven't looked closely at Dante, but it might be a good place to dig around for ideas, otherwise I'm gonna start hacking about with some more mapper-centric helper stuff. Anyway, over the next few days I'll talk to the team about the way forward with that - as atm it's just a pile of stuff lying about on my home boxes.

Yeah those Samsungs have dropped a lot in price, whoa. When I looked at their initial offerings, they had hefty premiums - way above even the usual clueless-ripping suspects. Didn't make sense at the time, considering they fab pretty much the entire device. But prices like that now? that's what I was expecting I'd hit one of those no problem.

Hence 'server application' — it's really not a limiting factor in everyday pro-sumer life however. That said, chances are you're not transferring large files from SSD to SSD, so you're going to be limited by the connection or other drive's speed. It's like buying a car on its braking distance; it's a valid measure, but if you're using it often enough you have other problems on your hands. I have no idea about UK prices, but over here Samsung's premium is pretty much high enough that you can bump the capacity of a SF 2218/2200 and beat the difference in performance and price/gb. Indilinix are owned by OCZ, yet last I looked only had a single product line using them... most likely high fab costs for themselves; their performance was pretty crap back in the first gen too(all of those horrible mem brands used them). Marvel controllers are solid, but finding reasonable prices or non-server spec stuff is pretty much off the cards. Edit : argh this forum and eating my formatting ;/

Yup, it was my test for a working model with vertex colouring — funny story that. Turns out the blender exporter that was used for the model had a few typos. I could not understand why the TDM ASE's would not work, but fresh samples I made did. I then remembered my diff viewer had some noise-reduction options, including ignoring one character typos or ~something~. The engine doesn't use the typo'd value, but everything else does. I fixed a few other bugs while finding that tho, whee ;/ Now to work out why vertex normals from 99% of models are ignored/broken/incorrect and how to do them 'correctly' for the engine, urgh. Oh, and I finally tested the models work with something other than that path 'scuse that terrible UVing by yours truly.

I don't get it, what concerns do you have about non or poorly compressible data? The only time you see comparisons about it are either as a result of application specific servers or synthetic benchmarking. In reality, most of what you use will be easily compressible. Remember, this is not per-file compression; and even if the block content is part of a well compressed archive (which games don't use, because they are expensive on cpu time(because for some reason people think we all run celerons :/)), you're going to run into the same bottle neck at the cpu and data-consumer level. Synthetic benchmarks don't need to care about this : hence are quite pointless. In reality, you're pretty much assured that you're going to get good compression on most (80%+ my guess from zfs compression) of your frequently used blocks.

The stats are meaningless on the high end. I'd just get something that has a nice price to performance. Sandforce controllers are generally the cheaper stuff - just make sure they offer the latest firmware else you'll have fun with random BSODs or data loss. Consumer mobo RAID, once again - is completely pointless for SSD. When you are talking about fractions of seconds of load time. People like to talk it up, but in reality the chances of problems, increased performance degradation over time and quirky TRIM only help to make it a gimmick at absolute best; that's not even mentioning the massively increased chances of data loss. In most cases load times are artificially high in any case. With more mem than things to do with it these days, disabling on-the-fly compression of textures and such is by far more of a win than chasing bars on a graph. Loading mission with compression takes about 32-35 seconds to load, without - 4.2 seconds.

Good to hear I'm going to just sync my local branch and make sure a few minor fixes are in for the ASE export, then I will release a new version. Updated the post with a new version - Beta 3. Lists are now compressed to unique elements only. Vertex colour exporting now works correctly! It has a few loader fixes - in specific it should be better at handling existing ASE files. Fixed support for some broken versions of blender's ASE exporter. A screenshot for fun :

Hey there JulioTheDanks, I suspect you have an nvidia card? If so, could you try disabling "Threading Optimizations" in the driver control panel and then try testing again? I'd be interested in the result, if the lightgem works again.

Ah- that looks pretty good I'd be interesting at looking at what is happening with the model. Since my exporter does not export vertex normals, it seems like the engine's generated ones seem to be incorrect (caves are an interesting case for this). Any chance you can package up the map+model so that I can have a look around? Looks pretty interesting, nicer than patch caves tho!