taaaki
-
Posts
1020 -
Joined
-
Last visited
-
Days Won
8
Posts posted by taaaki
-
-
That's not really "running the entire codebase inside LLVM". clang is a C & C++ front-end for LLVM, which is just a compiler infrastructure. Using clang doesn't mean that your code runs inside a VM as the "VM" in LLVM might suggest. The resulting object files and executables are normal Windows / Linux / Mac executables, just like if MSVC or GCC was used as the compiler (although, the generated assembly code will likely be different due to different optimisations etc.)
The benefit that clang brings is pretty hardcore code analysis and warnings. From what I've seen, performance of the resulting bin can be lower (or higher) than GCC depending on the nature of the code, so we'd have to evaluate that in the TDM case. clang also tends to compile much faster, so you don't sit around waiting for builds quite as long if you are making lots of small modifications followed by a new build each time.
-
Hi hammadnadeemx
We're likely going to need a bit more info to diagnose this. What graphics card do you have (I assume that you're on laptop, so it will be one of the integrated options from Intel/Nvidia/AMD)? And are you using the proprietary/blob driver or the opensource driver for AMD/Nvidia (RadeonSI for AMD, Nouveau for Nvidia)?
If you have 'gdb' installed, could you please give us the output of:
gdb '/home/hammad/darkmod/thedarkmod.x86'
run
backtrace
quit
-
Hm, I meant that only the player locally votes for a mission he plays. No online voting needed at all, just a reminder for later which mission one liked the best! These votings could then be uploaded and compared or listed, if one wishes, but I agree with you that moving online votes into the mission list might cause problems.
Ah, I think I'm getting the right end of the stick now (yesterday was a bit of a long day, so I apologise for my lapse of braining). That shouldn't be too hard. It could likely just be added to missions.tdminfo or something.
-
Yeah, I saw that the latest LLVM had implemented some Windows/MSVC compatibility features. Definitely very useful for static analysis of the codebase. However, that's quite different to the earlier LLVM discussion where we'd likely end up replacing the current idCompiler/idLexer/idParser with a LLVM front-end and a suitable back-end.
-
1
-
-
Yeah, I'm not sure I follow either. I'm fairly certain that we only want to give the voting ability for a particular mission to people who've actually played said mission. And the exact method of uniquely identifying a player is the problem at hand here. Any other kind of system would be open to abuse and vote rigging (either to "trash" a mission or push one to the top of the ratings).
-
As for the map server MD5 issues and automation, I'm all for it! Taaaki, can you rename all left over series missions so they can be recognized and automatically replace the non-series versions? Oh, and would you be the right guy to add some more informaton, like a player score or difficulty or similar in a colour coded system like I suggested here recently?
At first, I just want to get it working nicely and relieve some of bikerdude's mission admin headaches. I guess we can handle the renaming when we migrate the missions to the new db. Player ratings were discussed and we're keen to do it. I don't think that we settled on exactly how. We can pre-populate certain mission ratings based on the ratings from the forums threads, but it would be nice to allow players to rate a mission after playing it. But there are some issues with collecting player ratings like ensuring that each user only gets 1 vote, etc. (maybe try some SSO thing and link it to forum account). But yeah, I'm trying to make the system extensible enough to cater for these requirements.
-
1
-
-
I updated libcurl and changed from openssl to polarssl in 2.02, so I'd like to investigate if I broke anything with the in-game downloader. My testing didn't pick up any issues though. If you have any further info to help debug this (OS & version, 32bit/64bit, etc), I'd appreciate it. I'll also have a look at that mission you mentioned when I get some time.
-
I'm already building the updated backend for the mission db stuff (using SHA1 instead of MD5 but that's just an implementation detail). Lots of the mission db administration is fairly manual at the moment, so I'm trying to include some automation. The mission db admin should be able to upload a mission once, have the hash calculated automatically, and have the mission pushed out to the mirrors with one click. At the moment, there is no hash, the fm has to be manually uploaded to each mirror and then links added to the db one at a time. I also want the primary server to be able to check for mirror availability and toggle mirrors on and off if they are no longer accessible or have out of date missions (for whatever reason).
-
My initial interest is in the script interpreter to LLVM idea was more for improved error-checking and warnings and not so much on the performance side. Like I said, it isn't on my current todo list, so I haven't given it too much thought. So yeah, don't expect anything from me on this topic until after I've finished off some other stuff and have some time to think about it properly (assuming someone else doesn't take up the task).
-
Heh, that is actually an idea I had a while back (using LLVM for the script interpreter). I don't have any LLVM experience, but I do have a wee bit of (university) compiler development experience, so I was going to use this as a learning project. It's not on my current todo list though (which has been delayed trying to get a complete and correct SVN to Hg conversion going).
-
1
-
-
Just delete the Darkmod.cfg and it will be re-created from defaults the next time you run TDM.
-
Upon trying the first command, I get the error "FATAL: Module snd_seq_oss not found." Am I missing something? I checked to make sure I had all OSS related packages installed, but I certainly don't claim to be an expert on the matter. Also, what exactly does the modprobe command do? For the other two lines I don't get any output, so I don't know if it really did anything.
modprobe is used to load kernel modules (like the _oss modules). I don't think snd_seq_oss is required (it was mentioned for Arch, but it doesn't seem to exist on my Debian system). After using modprobe, you should be able to see the oss modules that have been loaded by running: lsmod | grep _oss
If that command gives you some output with snd_pcm_oss, chances are that /dev/dsp now exists and you should be able to use oss in TDM. I've shown what my Debian box does when loading these modules:
# ls /dev | grep dsp <no output - dsp device doesn't exist> # lsmod | grep _oss <no output - oss not running> # modprobe snd_pcm_oss <no output - this is good> # modprobe snd_seq_oss FATAL: Module snd_seq_oss not found. <this probably doesn't matter> # lsmod | grep _oss snd_pcm_oss 28671 0 snd_mixer_oss 10461 1 snd_pcm_oss snd_pcm 47226 3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec snd 34399 6 snd_pcm_oss,snd_mixer_oss,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer # ls /dev | grep dsp adsp dsp
That being said, it might be better to try and get native ALSA working as discussed in the thread I linked earlier.
-
i've got a suggestion already just from the menu... plz implement alt+tab for linux. Downloading missions while not being able to do anything else even in windowed mode is not fun. I'm seriously going to start the wine version just to download missions.
Also, please make the menu text highlightcolor something other than white. It's impossible to read, especially on the resolution listings / if you have a unfortunate resolution for your monitor as your default one.
On the other hand, the dark mod started fine out of the box in this new clean install of ubuntu 14.10, no dependency errors or anything. Well, there is a crash on exit that prevents rebooting for setting change, but that can be fixed just by doing it manually and ignored in the normal exit mode so so foul.
I seem to recall being able to alt-tab in Linux if you open the in-game console (ctrl+alt+`) and then alt-tab. Will test it again a bit later. The crash on exit worries me a bit. There was a segfault on exit in 2.01 that was resolved (temp fix addressed the immediate issue - at least to my knowledge - see http://bugs.thedarkmod.com/view.php?id=3579) and confirmed as resolved by some of my test subjects. Are you able to provide the console log by any chance?
-
PulseAudio is meant to automagic your audio so you don't really have to worry about the details of ALSA, etc. If you remove the options that I said you should add to the config and just use PulseAudio, it shooould work (you will get sound), but there is a known issue with Doom3 and its variants (e.g. TDM) that results in delayed audio. The 'oss' trick is one workaround. Another option mentioned here: http://forums.thedarkmod.com/topic/12245-linux-launching-tdm-with-pasuspender/page__view__findpost__p__264879
Just regarding the oss workaround. From my recent experience with Arch Linux, it seems that recent versions of udev don't autoload the oss kernel modules at boot. Try this with the oss settings (with alsa-oss installed):
modprobe snd_seq_oss modprobe snd_pcm_oss modprobe snd_mixer_oss
-
Hi Garrett
Is this with TDM 2.01 or 2.02? Did you perhaps quicksave in 2.01 and then update to 2.02?
-
The dynamic libs that will need :i1386 versions are:
> ldd thedarkmod.x86 linux-gate.so.1 => (0x00992000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0x007a2000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0x00831000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0x00464000) libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0x00711000) libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0x00110000) libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0x00244000) libXxf86vm.so.1 => /usr/lib/i386-linux-gnu/libXxf86vm.so.1 (0x00efe000) libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0x00256000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x0054a000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0x0033b000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00993000) /lib/ld-linux.so.2 (0x00f0f000) libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0x00359000) libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0x00850000) libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0x0036f000) libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0x00373000)
libcurl is statically linked now (and is itself statically linked to polarssl).
-
Yeah, don't expect anything for Serpentine on that front. Last time I spoke to him, he was a bit caught up in dose of "life", so he's pretty much dumped his side projects. I've been looking at doing the merge myself since it has to be done at some stage, and grayman and the rest of the active coders are working on the game side of things and renderer improvements (and it's probably best for them to stick to that). I can't really use Serp's old merge attempt since it wasn't in source control and back-patching recent changes into it would be a hassle.
Unfortunately, the merge is going to take a while longer since the TDM+D3GPL merge was perhaps a bit premature and some of the changes (directory structure changes, etc., include paths, modified GPL header and SVN revision tracking) make a semi-automated merge quite difficult. And we are going to have to change the build system to CMake since I don't really feel like trying to get Scons scripts updated to work with the merged result (shouldn't be a problem for Windows since CMake can just spit out a Visual Studio project file). I'm currently working on some back-end improvements for things like mission db admin page and release process, but I should be able to get stuck in again soonish since I'm starting a new job next month closer to home and less hours a week (and more pay
), so I'll have more free time to work with.-
2
-
-
And regarding this:
Indeed I did. The two files that stalled were TDM_Models02.pk4 and TDM_Textures_Stone_Brick01.PK4. The mirror was the one with your name in it. I don't remember the full name, just that "taaaki" was in there both times.I'm not seeing errors in the webserver logs and I've seen this happen with another one of the mirrors, so I'm starting to suspect that it has something to do with the updater. I'll have to check whether or not it has timeout and resume logic (if not, I'm sure that it's something that can be added).
-
dmargs.txt is from the pre Doom3 GPL merge era when we had a separate launcher. Try adding these two lines to the bottom of your Darkmod.cfg:
seta s_driver "oss" seta s_alsa_pcm "default"
-
The warnings shouldn't be tooo much of an issue. But the "About to exit with code 0" indicates that this isn't a hard crash. I've not seen this happen before though, so I'm not sure where to start. Maybe run the updater again to make sure all the checksums line up (and download correct versions of any bad files). Also, regarding your stalled updater issue, did you perhaps catch which file and/or mirror the updater stalled on?
-
That driver versions looks ancient. I'm not even sure it will support the more current versions of Xorg. Nvidia website has a more recent version that supports your 8600GT on 32-bit Linux: http://www.nvidia.com/download/driverResults.aspx/75820/en-us However, I'm not sure if it is compatible with Debian 6. If you haven't installed it already, you will likely also need the nvidia-glx package mentioned in the Debian wiki article (did you follow all the steps in the article or just use it for the driver link?).
-
Which Nvidia drivers did you install? The binary ones (non-free driver from Nvidia) or the open source one (Nouveau) ?
If you have glxinfo and/or glxgears, you can use them to check if direct rendering/opengl is working on your system. I think they're found in the mesa-utils package. The top bit of output from glxinfo should give you some details about your current opengl setup and whether or not direct rendering is enabled.
-
Have you installed s3tc support? I think the package is named something along the lines of libtxc-dxtn. You'll probably need the 32-bit version as well.
-
The commits to SVN don't work, or they cause the builds on Express to not work?
It's not to do with the version of VS from what I can tell (although, I'm not actually sure if Express actually supports compiling with OpenMP). Even with the correct headers and compiler flags, the code in svn trunk is syntactically incorrect, so it won't compile. I'm just going to comment out the omp stuff and commit so that other work can continue (I'll also commit the updated SCons scripts for building with OpenMP support on Linux - will make it possible to toggle with or without).
TDM doesnt launch on ubuntu 14.04
in TDM Tech Support
Posted
From the backtrace, it looks like the segfault is in the AMD driver (or at least that is where it is bubbling up from). My (very) brief google search didn't pick up any other reports of this though.
I'm assuming that your packages are all up-to-date and that you've installed 32bit versions of the various X libraries (I'll have to check which ones are required when I get home from work) using the ":i386" suffix on the package name? Could you perhaps provide the output of 'dpkg -l' (maybe just dump it in a private pastebin and link here).
Edit: actually, I found someone experiencing the same error as you: http://forums.x-plane.org/index.php?showtopic=75908&page=2&do=findComment&comment=817274 and it appears to be a driver bug. His next post indicates that the bug is fixed in a later version of the driver (see his next post here with the solution - http://forums.x-plane.org/index.php?showtopic=75908&page=2&do=findComment&comment=817285 )
Hope that helps