stgatilov

The instructions miss --noselfupdate parameter. It is absolutely necessary for 64-bit updater now, otherwise the updater will self-update back to 32-bit build

No. His twitter looks like a personal one, I think it is wrong to write there with things like that. Bumping priorities in this way also sounds wrong to me. After all, since Duzenko found a workaround, their response is no longer critical. Also, I don't like all that negative attitude towards drivers developers They are our colleagues, with far more skills and problems than ourselves. It is usually ordinary players who go to AMD/NVIDIA/Intel forums and complain there how bad their products/company/developers/whatever are without knowing anything at all. And this is exactly the reason why it is so hard to reach the developers: I guess 99% of public bug reports are utter rubbish filled with negative emotions.

I can write many reasons, but I guess it mostly boils down to present habit and skill. I have huge experience working with C++ in Visual Studio (Linux hardly has any equivalent), working with files in Far Manager (I used mc over putty, it's too bad in comparison). Same can be said about skills of OS maintenance. Switching to Linux means dropping all those skills and learning entirely new ones, which is tremendous waste of time overall.

Still no answer from AMD guys. I wonder how much time it usually takes for response...

Have the same problem. It seems that I actually broke it myself The ARB shaders are weird enough to receive normals both in 2-nd and 11-th attribute. I hope we can revert to 2-nd attribute at the end.

Unpack the archive into TDM installation directory, then run the executable file from it. Note that these additional files will affect the old executable too. So while you are testing, run the new executable. If you want to revert to clean 2.07, you will have to remove glprogs directory at least.

Somehow this comes to my mind...

I think you have to run the game at least once before upgrading from 2.06 to 2.07. Then the CRC mismatches will go away, and the next differential update should apply, I hope. A CRC checksum written in crc_info.txt and tdm_version_info.txt is not checksum of the archive itself. It is a composite checksum of all the files within it if they are uncompressed beforehand. It is normal that CRC reported by 7-zip does not match, it will not match for any CRC written in those files. This is really weird. I wonder which of them gets installed and how the rogue tdm_custom_scripts.script appeared in the first place. I cannot even recognize its contents: it is different from both 2.06 and 2.07...

Looking at this adventure, my first desire is... to nuke the whole list of "ways to install on Linux" from the wiki ! The core problem is that the list of options is hugely excessive (and thus probably partly broken). Also, it is not clear which ways are "officially supported" and which are just alternatives for the adventurous people. The officially supported way is the same on Linux and Windows. It is as simple as: 1) Download the TDM updater from TDM website (choose Linux 64-bit version if you have 64-bit Linux) to the directory where you want TDM to be installed. 2) Run the updater. Don't forget --noselfupdate parameter if you are using 64-bit Linux updater (this nuisance will get fixed by 2.08, I hope). 3) If it installs well, play and enjoy. If it does not, go to forums and report. Of course, there are various details like 1) chmod updater executable 2) permissions in TDM directory. TDM 2.06 and 2.07 also complains about missing OpenAL package (hope to fix it by 2.08). But I guess most of the people can solve them using common computer knowledge, googling and asking on forums. For non-tech-savvy Windows users, we also started offering Freyk's GUI installer, so that they don't get problems by trying to install TDM into "Program Files", for instance. Linux users should be tech-savvy by definition, at least this is my opinion. All the rest like playing on Wine, playing on PlayOnLinux/PlayOnMac, various packages and such stuff are unofficial (playing on Mac also is). While it is great to have this information on wiki, it should be clear that this is not what a newcomer wants to try. I think I will take this article (which is directly linked to the main page), and try to slightly restructure it to accent what is "normal installation" and what is "adventurous installation". EDIT: in fact, the instructions I posted above are present both on the Downloads page on website and in the linked wiki article...

I don't know any. We have an issue which I reference everywhere. And this thread which draws everyone with non-working lighting... despite the fact the screenshots in the very first post are clearly different from what they see

This is expected and easier to fix. You can use either of the two workarounds described here. However, you will be limited to hard stencil shadows as the result. Anyway, the original issue is quite strange. It is even more strange that 64-bit version still does not work for you. I would be grateful if you record a memorydump for this crash. Normally, when a program crashes, you are presented a dialog box with choices like "close", "send info", "debug", ... At this moment you can start process explorer and record crashdump (i.e. before clicking on any of the buttons).

Here is the list of files which I upload to Azure mirror (for tdmsync prototype and TDM 2.07): crc_info.txt tdm_version_info.txt tdm_update_linux.zip tdm_update_win.zip tdm_shared_stuff.zip fms/newjob/newjob.pk4 fms/stlucia/stlucia.pk4 fms/training_mission/training_mission.pk4 tdm_ai_animals01.pk4 tdm_ai_base01.pk4 tdm_ai_humanoid_builders01.pk4 tdm_ai_humanoid_females01.pk4 tdm_ai_humanoid_guards01.pk4 tdm_ai_humanoid_heads01.pk4 tdm_ai_humanoid_mages01.pk4 tdm_ai_humanoid_nobles01.pk4 tdm_ai_humanoid_pagans01.pk4 tdm_ai_humanoid_townsfolk01.pk4 tdm_ai_humanoid_undead01.pk4 tdm_ai_monsters_spiders01.pk4 tdm_ai_steambots01.pk4 tdm_base01.pk4 tdm_defs01.pk4 tdm_env01.pk4 tdm_fonts01.pk4 tdm_gui01.pk4 tdm_gui_credits01.pk4 tdm_models01.pk4 tdm_models02.pk4 tdm_models_decls01.pk4 tdm_player01.pk4 tdm_prefabs01.pk4 tdm_sound_ambient01.pk4 tdm_sound_ambient02.pk4 tdm_sound_ambient03.pk4 tdm_sound_ambient_decls01.pk4 tdm_sound_sfx01.pk4 tdm_sound_sfx02.pk4 tdm_sound_vocals01.pk4 tdm_sound_vocals02.pk4 tdm_sound_vocals03.pk4 tdm_sound_vocals04.pk4 tdm_sound_vocals05.pk4 tdm_sound_vocals06.pk4 tdm_sound_vocals07.pk4 tdm_sound_vocals_decls01.pk4 tdm_standalone.pk4 tdm_textures_base01.pk4 tdm_textures_carpet01.pk4 tdm_textures_decals01.pk4 tdm_textures_door01.pk4 tdm_textures_fabric01.pk4 tdm_textures_glass01.pk4 tdm_textures_metal01.pk4 tdm_textures_nature01.pk4 tdm_textures_other01.pk4 tdm_textures_paint_paper01.pk4 tdm_textures_plaster01.pk4 tdm_textures_roof01.pk4 tdm_textures_sfx01.pk4 tdm_textures_stone_brick01.pk4 tdm_textures_stone_cobblestones01.pk4 tdm_textures_stone_flat01.pk4 tdm_textures_stone_natural01.pk4 tdm_textures_stone_sculpted01.pk4 tdm_textures_window01.pk4 tdm_textures_wood01.pk4 They are enough for official installer to update. Here is the anatomy: 1) crc_info.txt --- updater uses it to check pk4 for being correct. Also contains the file list. Not needed to play. 2) tdm_version_info.txt --- another file used by current differential update only. Not needed to play. 3) tdm_update_linux.zip, tdm_update_win.zip --- these contain updaters which new players download from website. Also used for updater self-update. 4) tdm_shared_stuff.zip --- these are all files which should be at TDM root directory unpacked. 5) fms/*/*.pk4 --- these are three core missions. 6) *.pk4 --- these are ordinary packages. In order to install manually, you take the URL of some mirror (from official tdm_mirrors.txt, or my Azure mirror), for instance http://darkmod.taaaki.za.net/release/. Then for each file concatenate the mirror URL with the relative file path from the list above, and download the file from there. After everything is downloaded, unpack tdm_shared_stuff.zip and you are ready to play. I don't know any other things tdm_update does. Even if it does, they are most likely unnecessary. Note that all mirrors are simple HTTP websites with public files. This bunch of files is just uploaded to every mirror with the exact directory structure. You can download anything as you wish. You cannot see the files (aka listing) only because it is disabled on all HTTP servers (for avoid bots, I guess).

I don't think this would cause constant looking back. Good players (at least in FPS) have some area awareness. They have a brief look over the scene and as long as it does not change they know what is where. Just like the goalkeeper knows where the goal is. As for implementation, the most right one would be to render AIs view with and without player and compare them pixelwise. Optimized approach would render player's mesh first, then use it as stencil while drawing the rest of the world. Various rectangle/depth-range optimizations included. Of course, it should go low-resolution, with simplifications, in parallel, with huge interleaving (nobody needs 15ms-reacting guards anyway), etc. In theory this could work well, but it has to be very well optimized. Speaking of ray tracing, it is very similar, but instead of rasterizing AI's view on low resolution, raytrace it on even lower resolution. Shoot rays to several key points of the player mesh (drop rays out of AI's view frustum), let the rays pass through player until first obstacle. If it is farther than player, then check player's lightgem value against intersection point light value. The light value of intersection point can be computed like in classical Whitted raytacing: cast shadow rays to all light sources, check for shadow and compute intensity. While it will probably be faster, it would be hell trying to make the raytracing solution coherent with rendering. As far as I know, there was an attempt to implement lightgem via ray casting, but it never worked robust enough to replace the graphical solution.

Typical installation "from scratch" is downloading the more recent version (currently 2.07) directly. This is what updater does if you run it in an empty directory. If you badly want to download it directly, I can give you the filelist (i.e. what you should download). You can download packages directly, unpack tdm_shared_blabla.zip and play. Another use case which is supported is the goddamn "differential update", when players upgrade from previous version. In such case updater downloads single differential package and applies it. The way you describe with installing 2.0 and applying differential updates in sequence is almost never used. I bet you are the only one who have tried it so far. The reason for the issue around 2.06 that you saw is that starting from 2.06, video and ogg files are stored uncompressed inside pk4. Aside from faster loading times, this is pretty much required for FFmpeg videos to work properly. The whole recompression story is a mess, and it gets more complicated because our current updater has two completely separate ways of functioning. I'm glad it even works if player runs TDM at least once after applying each differential package, and I prefer leaving it as it is. The theoretical plans for new updater take recompression problem into account.

Thanks for the dump. Here is the place where execution was at the moment dump was recorded: Given that it is second frame, it may be a deadlock/freeze on glClientWaitSync. Anderson, could you please try to add the following line to your darkmod.cfg: seta r_useFenceSync "0"And try to start TDM again (both bitness) ?

A minor update: it seems that the issue has reached AMD. Waiting for reply now.

You said that 32-bit and 64-bit versions behave differently: one of them exits itself. Does it look like a crash in this case? What are the contents of qconsole.log in the case when TDM exits itself? If there is a crash, please record crashdump and share it.

Yes, but didn't I try to streamline the whole thing recently? It should be no longer necessary, I guess...

I thought r_fovRatio should be kept at zero, which is the default. To be honest, the set of such settings should be reduced to r_customWidth and r_customHeight only, with other settings being 0 unless player feels adventurous. I guess we are not yet there.

It is a bit sad that TDM is so slow in the video. And this is the smallest (i.e. the fastest) mission. Is it really so bad even when you don't record?

No music is super weird. It means that the problem cannot be in graphics only. Unfortunately, the qconsole.log file does not contain the info about loading pk4 files Condump has this information, but doing it blind is not very convenient. Could you please add line: condump qqqTo darkmod.cfg and run TDM once again? Then post qqq.txt contents in spoiler. I guess it might be corrupt TDM installation. How did you get this version? Which updater did you use and from which version? Are there any subdirectories in TDM directory (except for fms and screenshots maybe) ? Perhaps you should try to rerun updater, or even do a fresh install.

Resizing/maximizing needs special code in order to work. Drag-resizing is working on Windows (but not on Linux I guess) and has worked for quite a long time. Maximizing does not work, and I don't recall whether it worked previously or not. You can file as bug report. Given that there were some discussions regarding changes in Windowed/Fullscreen system, I guess it should be postponed until that it finished.