stgatilov

Probably AL_EAXREVERB_AIR_ABSORPTION_GAINHF: It is called air absorption hf in the current effects system, and it must currently be set in millibels instead of gain. However, this does not apply to direct sound --- those should be affected by sound source settings (outside of EFX). To be honest, the more I look into EFX effects guide, the more I see that D3 integration with it is rudimentary. It does not take into account at least the following things: 1. Listener close to walls in a big room hears things differently than in the middle of the room. 2. When listener-source direct path is blocked, the sound should be very different (i.e. occlusion). 3. The sounds coming from neighboring rooms should be handled differently, including different reverb properties and setting some overall direction for them.

This is strange. I added the following code to stock mainmenu_briefing_video.gui: // #4535: this event fires up only for non-legacy (i.e. FFmpeg-based) videos onNamedEvent CinematicEnd { // Hide video set "HideBriefingVideo::notime" "0"; resetTime "HideBriefingVideo" 0; } Unless something got broken, it should do an action equivalent to end of video duration. If you have custom gui file, then you have to intercept this event yourself. Also, all sort of debriefings, campaigns, and SDK-controlled videos are not modified to intercept this event.

Created issue 4864 for removing this hotfix. Planned for 2.08, where tdm_update will get big cleanup anyway.

I think timestamps are used to make reloadImages work (only images with newer timestamps are loaded --- otherwise it would be too long). Wouldn't it be OK for players if we ensure that timestamp = -1 is never returned from file operations when file exists? Something like if (timestamp == -1) timestamp = -2 ?

Could you please explain one thing for those late to party: why the hell are timestamps important? In my opinion, I can randomize timestamps of all pk4 files to everything ranging from 2000 B.C. to year 10000. And TDM should still work perfectly after that.

The latest SVN trunk (7543) should also compile properly.

It is not possible, due to how OpenGL works. There is perspective 4x4 matrices, perspective division (clip -> ndc coords), all this is baked into rendering pipeline. You cannot magically change all this for some nonlinear math, except if you wish to drop OpenGL and implement your own rendering engine directly on CUDA or OpenCL. With this curvilinear perspective even 3D triangles are no longer triangles on-screen (if I'm not mistaken), so GPU cannot rasterize them as it usually does. The only possibility is to render something in traditional perspective, then bind the obtained picture as texture and perform full-screen post-processing to get bended view. So you either render player's view as usual and then stretch it, or you render cubemap (much slower) and then apply post-processing to it. If there is a clear place where this postprocessing could be applied, then I guess it won't need much changes in renderer. If it is so, someone can try to implement it even now (for 2.07) under cvar.

Right now TDM does not collect any information about players to send it anywhere. At least for me, a suggestion to create any sort of account in-game or connect to something usually generates negative feelings. This is the only real downside from adding such feature.

Do I understand correctly that this thing works like: 1. You render full frame as usual. 2. You do a full-screen post-processing, which stretches some curvilinear part of the frame output onto the screen. ...? The main problem, I guess, is that we must not distort GUI, weapons, tools, lightgem, text messages, etc.

The latest trunk does not compile on Linux due to latest Duzenko changes. Overally, trunk is very unstable starting from the end of 2.06. Things are improving steadily, but unfortunately in a "two step forward, one step back" fashion (if I'm not mistaken in the ratio) If you want to compile latest SVN, you can try rev 7532.

Ok. I checked it. Indices are 32-bit, and vertices are always idDrawVert, which includes texture coordinates and a coordinate system. So it is 12 bytes per triangle vs 60 bytes per vertex, giving a ratio 24 : 60 = 2 : 5. This explains everything

Why? Is it too bad to allocate VBO memory in chunks? For instance, with increasing sizes: 1 MB, 2MB, 4MB, 8MB, 16MB, ... With the old way, each geometry was living in a separate VBO, and we wanted to avoid that. The problem is that it would be a bit more complicated with chunks, since you have to handle end of VBO and move to the next one, and maybe even allocate it. But it is not too hard: just check if current chunk has enough memory for allocation request, and if it does not, move to the next chunk (making the remains of current chunk unavailable for current frame). Now initially allocated memory is 12 MB for both vertex and index buffers, i.e. 24 MB in total. Given that only 0.58% of steam users have less than 512 MB VRAM, we can bump it. On Inn Business, 20 MB is allocated for vertices, and 10 MB is allocated for indices. This is 90MB in total. If you set 32 MB initial size for both buffers, that would be 192 GB --- is it acceptable today? There is no thing like swap for VRAM, so even if you don't use these 192 GB, they are still unavailable for textures. BTW, size of index buffer should be 2x larger than size of vertex buffer, since a typical triangular mesh has about twice as many triangles as it has vertices. However, in the Inn Business mission at least, I see reverse thing: the size of vertex buffer is twice as large as the size of index buffer. Doesn't it mean that converting some assets into indexed form can reduce VRAM footprint by 50% ?...

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.