Serpentine

I can't promise anything, but... lately a lot of things have aligned. Also, my skills are shameful, you guys really did a lot of work for standalone - now is about you, I'm sure tomorrow morning will have plenty of coverage. Spring and grayman deserve some sort of medal

Long time no see TDM Team I just wanted to pop in and say a bit congrats on making it to standalone! I apologise for running away for 6 months, and I'm not entirely sure if I have the time to return... but really, damn fine job guys! Sure this place will be picking up a lot in the next little while

There is a (little bit) of method in DR's madness. ASE is intended to be used in a way which sharing of vertices is left up to the user. There is a field that defines at what angle the vertices should be seen as having a hard edge, i.e a corner should not be smooth shaded. However since games tend not to leave this up to the model format itself, because 3dsmax had a lot of duplication in the format and it all became a bit too complex, generally sharing vertices will result in edges not being hard, even if the angle is > the predefined limit. D3 does the vertex merging itself if the file is correctly formed (however the exact reason for it not always applying is a mystery to me). DR on the other hand does not compile the map and as such has no need for storing this information for brushes. So if we used a solution like you are asking for, the corners of things would start to look really horribly shaded. So, if you group the materials and faces, you will likely run into the problem where the entire area is seen as a single smoothing group (_nothing_ uses ASE smoothing groups correctly - are you noticing something about ASE being left up to the user?). This is why after I complained about this same issue, I didn't actually fix it, there is a little accidental method in the madness. Ideally we could use the face normal to offer an option about when to merge, and when to preserve hard edges (and then likely have the engine ignore them anyway). So yeah, if you need the script modified, I'm sure it can be sorted out for your case The last option is to find my old ASE aware version of the assimp exporter on these forums and throw the model into there, it may or may not do what you want...

I completely agree with Carmack, and there are many things I don't agree with his ideas (MT, heh). The nature of Linux and the expense of keeping up with the generic gnu/linux fragmented developments is extremely high. Most commercial interests will just pick a 1-2 distros to support and call it a day. That's not even taking into consideration that Steam will need to try and ensure that games also keep up in part. You're stuck with the constant changing and breaking of the graphics ABI and APIs, the uncertain future thereof is well known. While Intel are trying hard to fix it, they are going to be making changes which everyone else needs to keep up with. Graphics drivers are immature, while Intels latest efforts are indeed great, nVidia's are starting to lose out a bit (and then run into issues about GPL licensing and such of kernel memory stuff that they want to share etc.) AMD's are somewhat of a joke. Sound is even worse. So the solutions to a lot of this are binary blobs - well, we were always going to have that with the games themselves, but if you expect their kernel drm module to be anything but a pain in the ass in time. How much you linux guys love all that stuff eh. How long do you think distros will care about Steam's inevitable constant breaking, once again excluding issues that games might pose (because who does the QA there eh?). A massive hurdle is simply that of expectations management, and that's something you'll never see talked about. It's entirely about Steambox, they hardware partners(note : s) are already quoting huge prices and they want to lower them by cutting out the costs of a Windows license; Which in itself is a completely valid move. I would not be surprised at all if they fork debian/ubuntu and start releasing a Steam'OS', similar to Android. While Valve are playing with the gloves on at the moment, when they finally offer that sweet sweet cashing-out IPO and gaben gets to walk away looking good, that's where the underhanded corporate involvement shows up. The subtle art of do-no-evil-we-love-linux. Once in the control of their own destiny and distro, how long will your 3rd party platform support remain? Steambox 2, MIPS? ARM? surely not the expensive x86 I'm not saying it's Valves fault, I'm saying that the nature of mainstream gnu/linux is extremely likely to /force/ their hand into making better business choices, which do not align with the idealism of many. So maybe he's right and avoiding it for now is the best road. Maybe a Steam distro would bring the stability and support required for both hardware and software QA. But the here-and-now? That's for companies and gamblers who want to lose to the house. Or maybe I'm just a jaded, conspiracy-prone hermit, shouting my delusions to the sky.

This seems like the wrong way to fix the problem then, as well as the possibility of making some legacy result which will need to be dragged around. So I think perhaps its an issue which needs to be talked about more, with people that are more understanding of the gfx stuff, and fixed correctly if possible. Right now I think visual examples are needed or a test case. I'm not sure there's anyone around with experience in this area at the moment Hmm!

We're not looking at it really, sometimes I check if they've fixed a bug or something... but nah, it's not being looked for anything besides reference.

Not entirely sure what you're asking for really, but I think we can already do soft transitions?

Piracy called, it wanted to tell you that its copies are still working fine and you don't even need to feel guilty, they got their money. I've never bothered to use any cd/dvd/thing that's come with a textbook, I have a whole pile of them sitting around. If the content was important they'd have printed it in the book. Extra examples and work never seemed worth it.

Please please pleassse tell me you have a copy of the map with that happening? There are a number of situations which this could result in the dmap process screwing up, and I'd really like any examples of it that people can recreate. I've manually mangled a lot of brushes to try recreate it, but I just cant seem to get it right. It also helps that it's an actual map, because the resulting geometry needs to make sense

Bit of a strange issue, it should remove the brush but meh. Just spawn the model directly then change its class, for now. (And use the TDM/DR bugtracker not GitHub.)

If you ever have maps which are not hugely complex, or have narrowed down a dmap crash. Please pm me a copy of the map or something. Models causing crashes are also welcome (I know sometimes freshly exported stuff has issues) Once my engine porting work is all done that's something I really want to look at (as well as other mapper/content related problems/crashes) Making an item on the bug tracker is also a good idea! (likely what you should do first )

Yup, that's pretty much it. I'd just recommend if you're using colour to alpha rather than multiply, that you make a duplicate layer or two and blur them slightly, then multiply those under the alpha layer. Makes things look a bit more used and organic

Slowly grinding down the last of the SDL dependencies, half ported xlib to xcb. Woop woop. I just have no good idea of how to do the merger now :/ Think I figured out a nice way of speeding up load times for you guys who use on-the-fly compressed textures... just need to spend some time with OpenMP and icc (damn you clang, your one weakness ) Oh well

I've just removed most of the SDL stuff that was acting as a place holder in my work, which would have given this a chance at working. But I guess I might return it as an optional pseudo platform. Which is doesn't seem like a bad idea. But yeah, the overheads of TDM would destroy any portable hardware - and I don't see that changing. We'll get more efficient, but the CPU and especially GPU stuff would pretty much make it impossible without forking and implementing many data-specific assumptions.

CCC settings apply directly to the driver (or parts of the X session), TDM has no way of knowing if its values are being used or what CCC's are. Technically there is a way, realistically, no one ever uses it, it's overboard and you need a pile of constantly changing and breaking libs. vsync in X is a real mess - it's one of Waylands selling points... meh. It's generally easier to get vsync if you're running windowed, but fullscreen is somewhat iffy and depends a lot on how everything else is configured, truthfully I've never really tested it on nix, will do sometime soon tho. This goes back to the previous point, iirc if you are using compositing you will need triple buffering to get vsync to work in a window. I know KWin handles this quite nicely in that fullscreen stuff disables compositing which helps things work smoothly, but Compiz in the old days used to not do this (and since it's pretty much a dead project, I wouldn't be surprised if thats still the case). That said, I've seen a number of people report issues with DDC(and the newer version, whatever its called) not working on Ubuntu with radeon drivers (different project), both open and closed. Ubuntu screw around a lot with packages and I really wouldn't be surprised if the X plugin is completely broken. But If your res and stuff is being correctly detected, I'm sure it'd get your refresh timings right.

Wow, loads of stuff To anyone that might merge : Can you just hold off, a lot of this stuff is hopefully changing soon, I really don't feel like having to merge this one twice. I'd really just like the tree frozen atm, but I can't Shouldn't really be on sys, but... not too sure where else it'd be good. Don't really need more flexibility in events and stuff, TDM already has overkill flexibility in many systems. Already have loads of stats here, which arn't really a core feature. If you'd like to talk about stuff, please feel free to join irc #thedarkmod on freenode. I'm usually around. Also might be good to have you there as I'm starting to move back to SDL-less system stuff, having more platforms that can be tested would be nice

Hey plasticman, I'm not sure about the AA / VSync issues - that sounds a bit strange. I will put a bit of time into seeing if there's possibly something wrong there. Your AA should be set to a max of 8, if TDM allows you to select 16 then there is something wrong and it will not work (setting it to 8 or lower will fix it). VSync and interval are slightly different, however they both work for me, so I suspect it might be something to do with Compiz. I really don't think we can/will/should cater for different wm and stuff if they require special workarounds or anything. That said, 1.09 should at worst, be easy to get built and working if you have any trouble with the binaries. And having native amd64 means you don't even need to fiddle much with packages, whee.

Sweet, solved the script crashing - yay for magic numbers. So with a little luck I'll be able to look at this tomorrow.

Hmm, think I've also fixed this in my branch (since there is a more serious issue that the internationalization requires the dynamic link to be correct else the engine will fall over.). But good find nevertheless.

Sadly I'm fighting some tricky stuff in the amd64 porting of the game code - it works, but there's some trouble with the script side of things. Tracking it down is proving to be a pain and has eaten a few evenings :/ I really want to get all this stuff done before I look at other issues. Meeeeh

Hmmm, haven't really looked at that side of things yet - so I cant say. But if you get AI acting strangely, it could be something to look at. I'd just ignore them for now.

Yup, it's not ideal - but if it's being caught by dmap it should be fixed when actually playing the map. If you're getting a bunch of these when you're loading a map then there might be something strange going on.

Ooh that's interesting - EAX should work regardless anyway in the future, but this points to a specific cause (which I spotted in static analysis earlier). Thanks for the observation!

Yup - completely safe. Warnings will usually just mean that something is skipped (in this case - the material is already there so no problem). Errors however will generally mean something is broken and might be fatal. Continued errors will result in a FatalError, which will try to close the game down gracefully and give you an error message. You'll see a load of Warnings - Don't freak out, it's just part of moving away from being a mod.

No, it only results in division. We have no problem with people using google translated text and have done well so far. It can also lead to a lot of unsatisfiable expectations and wasted time. TDM needs sustainable, simple systems.