stgatilov

One possible thing would be to rotate player's view direction around before starting game. It won't save you from resizes during game, but will probably remove them at the very beginning. More reliable solutions are more complicated, i.e. allocate VBO in chunks instead of single array.

Yes. Starting from TDM 2.06, MSVC runtime is consumed as DLLs, which must be distributed separately. For TDM 2.06, you should install MSVC 2013 runtime. For TDM 2.07, runtime of MSVC 2017 will be required.

Is it related to 4697 ? What about toggling r_skipRender as workaround (described for quickloading here) ?

Are you sure that you need a replacement? I have looked briefly through viewport 2.0 docs, and it seems that it uses OpenGL 3.0 core profile, depth peeling, averaged transpacency, bumpmapping --- all of these techniques are very old. Your GT670 easily supports all of them, unless I miss something. You have a middle/high-end GPU from rather modern NVIDIA family. Unless you see that Maya is slow for you, you don't need an upgrade. Moreover, if it is slow for you, you should somehow check that it is slow gue to GPU, and not due to CPU.

kano, I suggest deleting every single DLL which you have downloaded. If TDM still asks for a DLL after you do it, then: 1. Run tdm_update again, perform a normal update. 2. Attach here the tdm_update.log file located in your TDM installation directory. 3. Go to Windows's %TEMP% directory. It is at C:\Users\GatilovUser\AppData\Local\Temp in my case. You can locate it by opening explorer, and entering %TEMP% into address bar. Then find files with name like dd_vcredist_x86_20180630132840.log which were created recently. Attached them/it here too. 4. In order to fix the problem, run the redist executables as suggested above. But I hope you will do steps 1-3 before that --- then hopefully I'll fix the problem for future.

It requires only MSVC 2013 redistributable package. Both 32-bit and 64-bit installers of it are automatically downloaded by tdm_updater into your directory. They are named vcredist_x86.exe and vcredist_x64.exe. Moreover, tdm_update actually runs them silently during installation, although for some people it does not succeed. I would be glad if someone points me out why. If you have some DLLs missing, simply run these two exe files already present in your TDM directory and make sure they succeed. Never download separate DLLs from internet, you can get into great trouble. Aside from a chance of getting a potentially compromised DLL, you also create DLL hell which will surely bite you in future. If you want to install the package yourself, go to Microsoft site and download MSVC 2013 redistributable package. Do not download anything from any other site except Microsoft (and TheDarkMod). P.S. Do we have a popular installation FAQ/troubleshooting instructions? We should add an advice to run vcredist_x86.exe and vcredist_x64.exe installers in TDM directory if TDM does not start after install/update, asking for a DLL.

The doubling algorithm creates a problem in Inn Business mission. After player starts, he usually turns around, which causes two or three noticeable freezes because VBO reallocates.

I have stripped FFmpeg libraries in the current developer's trunk. You can find the rules about which videos are supported and which are not on the main wiki page about FFmpeg cinematics. If you create a video right now, you can check it for compatibility with future 2.07 version using ffmpeg test build. The build consists of two files, which are simply TDM binaries of the current trunk. You can copy them to your 2.06 installation and run them from there just as you usually run TDM. With ffmpeg test build, you can use testVideo command to check that your video plays well. I have described how to use testVideo command in "Quick test" section. Note that using the ffpmeg test build for anything except starting some map and calling testVideo command is not supported and not recommended. Do not play or dmap with it

But these commands exist in scripting engine. Can I invoke then in game console?

Ok, I looked into the code: Command origin does not exist. Command teleport surely works only with location name. There are commands getviewpos and setviewpos, which do exactly what I want. getviewpos (having a alias where) prints your coordinates and yaw. setviewpos accepts coordinates and optionally yaw angle and puts you to that location. This is enough for now, I think. Maybe I'll change this a bit for testing system, if I ever get to it.

As a developer, I sometimes have to get to a prescribed place immediately after the game starts. Currently I do it by adding a hack into the code and recompiling, but having a console command would be nicer and more useful. The idea is to have a command which teleports player to prescribed coordinates, e.g.: teleport 11280 -5664 -6108Perhaps someone have heard of any such command? If there is no such command currently, then do you think adding such command is a good idea? Are there any alternative versions of input which would be useful to mappers? P.S. I can also add a command which will show current coordinates in console. It can probably make it easier to beta-test maps (unless author moves rooms), because testers can send player coords when reporting an issue.

Added an issue 4849 for the whole VBO replacement process. I'd like to second lowenz's report about the view being duplicated in the lower-bottom quarter of the TDM window. It happens in the "press attack to start mission" screen regardless of FBO setting, and also in-game if r_useFBO 0 is set.

Probably you should add these includes of OpenGL and remove the other ones? #include <OpenGL/gl.h> #include <OpenGL/glu.h> #include <OpenGL/glext.h> You should either include <experimental/filesystem> or simply <filesystem>, depending on whatever is present on your machine.Setting appropriate ifdefs is a separate question.

For learning a language, good IDE and debugger is very important. So if you start with Python, try to set up Python development environment in Visual Studio. As for which languages will live long enough, I'll say C++ is most unlikely to die, Java probably comes next. Javascript is also likely to live long unfortunately Things like Python, Kotlin, Closure can easily die in long perspective. One crazy direction may be game hacking: start with memory rewriting (i.e. MHS) --- that's fun and rather easy. However, the next step (ollydbg/IDA) is too hard --- requires good C/C++ knowledge and tremendous motivation/patience.

Oops, sorry. Fixed in rev 7494.

Committed a fix in svn rev 7493.

As far as I see, this macro is defined in XCode projects. Probably it's better to use __APPLE__. In one place it even checks for either macro to be present. However, there are already too many usages of MACOS_X in the code, so changing all of them does not sound like a good idea. I have added automatic setting of MACOS_X macro in sys_public.h, which is included at the very beginning of precompiled header. Committed in svn rev 7492. I hope this will cover all places where MACOS_X is used, or at least most of them. It uses something like OpenGL 2.1 with some extensions from OpenGL 3.0. Currently OpenGL 3.0 should be absolutely enough to run everything in TDM. These errors say that typedefs for function pointers are undefined. These typedefs must be defined in glext.h header (the one which declared OpenGL extensions). This header is located inside renderer directory, and it should be included from qgl.h. Check qgl.h file: perhaps there is some ugly hack which blocks the include.

I'm afraid such hotfix needs more work than you think. Doing it for one change which neither affects player nor affects existing missions is overkill.

First of all, you should not use the whatever osx branch which you see in SVN: most likely, it is too old. Use either release2.06 version or trunk. Second, there were some instructions for compiling macosx version in the old compilation guide. Go to the compilation wiki page, and expand a section at the very end of it. Then find text about macosx there. Note that 2.06 changed a lot. For instance, there is no thing like game pak any more. Also, the guide mentions MACOSX_TARGET_ARCH, but I guess I removed it from scons, because 1) more generic TARGET_ARCH is now present, and 2) I hope no one needs ppc binaries any more.

Attention to everyone who has started creating new videos or intends to do so before 2.07. FFmpeg is a huge library with tons of codecs and formats, and the actual set of supported formats greatly depends on how it was configured. It is hard to keep this set constant over time, which can potentially result in breaking TDM cutscenes regularly in some distant future. To avoid breaking maps, there is a plan to restrict the set of supported formats/codecs to the bare minimum. This way the chance of breaking existing video files should become much lower. Unfortunately, the unrestricted FFmpeg is already released with TDM 2.06, so the restricted version will be used starting from 2.07. It means that if you now add FFmpeg cutscenes in wrong format to your missions, then they won't play in 2.07. This is why your attention is important here After some internal discussion, we decided to start with this set of codecs and containers: containers: avi m4v mp4 roq video codecs: h264 mpeg4 roq audio codecs: mp3 aacAs you see, it provides two options in each domain (in addition to legacy roq). One option is usually the most widespread currently (i.e. mp4+h264+aac), and the other option is something which was popular in the past (avi, mpeg4, mp3). BTW, all the above-mentioned codecs (except roq) are patent-encumbered. Our conclusion is that it is not a problem for TDM given that the game is free and will remain free for eternity. There exist completely free codecs and formats (ogg+theora+vorbis and webm+vp8+opus), but it seems that they are so unpopular that it is hard to find a converter which could create such videos. The plan is to come to final conclusion about the set of codecs/formats in the nearest future. After that I'll probably release a tool (e.g. ffplay.exe) which could be used to check that a video is going to be playable in uncoming TDM 2.07. If you already have done some work for compressing videos for TDM 2.06, please check which container, video codec and audio codec you used. Any comments on the situation are welcome

Fixed in svn rev 7478. Of course, you can simply comment the problematic static_assert-s as a workaround.

It is not asm, it is my code with SSE instrinsics. It seems that offsetof should solve the problem.

Any suggestion about how to get offset of a member in a struct in bytes, so that it is compile-time constant?

As you probably know, TDM 2.06 still works on Windows XP. We had an issue that the latest tdm_update did not boot on Windows XP. There is a fixed version. If you need it, please PM me. The current idea for the future 2.07 version is to allow running it on Windows XP too. However, this support cannot last forever. Windows XP support by Microsoft ended in 2014 (though hacks can probably extend it to 2019). A lot of libraries (including the ones we use) have already dropped support for Windows XP. For instance, FFmpeg has dropped support in version 4 released two months ago. There is no prebuilt version of boost for MSVC2017 with XP support. Microsoft Visual Studio 2017 can still build stuff compatible with Windows XP, but it is not clear when this will end. The idea is to drop Windows XP compatibility by TDM 2.08. This is not the next version yet unreleased, but the one after it. So I would like to ask everyone: who still runs TheDarkMod on Windows XP? If yes, then what do you think about dropping Windows XP support? Do you have a plan to migrate to newer version of Windows (or to Linux) ?

I assume you created a tracker issue for the reported problem, so it would be great to post the link here