stgatilov

In case user system does not support the fence, the finish call is used. It is slow, but it works at least. One possible use for the cvar is to make it easy for us to emulate such conditions on our GPUs which have fence support and normally will use it.

Tested on Windows 7 32-bit in virtual machine. The installer by default chose directory in Program Files, which of course was not allowed to be accessed initially without admin rights. After installation, I the access it granted (I see it in Security dialogs, I can edit the txt files without UAC intervention, tdm_update downloads files there properly). So this part works for me. 32-bit version was downloaded, but not installed. Also, it is the wrong version: it is named vc_redist.x86.exe and has size 14 MB. The installer downloaded by tdm_update is named vc_redist.x86.exe and has size 6 MB. In fact, your installer is for MSVC2017: it will work for 2.07, but won't work for 2.06. I have no steam in my VM. Aside from that, all files are downloaded properly. Unfortunately, I cannot check anything in-game. The shortcuts are created on desktop, and point properly both to the game itself and to updater. The uninstaller works properly (it removes the whole darkmod directory).

Issue 4531 is waiting for someone brave enough

I'll test it in the nearest future. Note that tdm_update is expected to install VC redist package by itself, so theoretically this step is unnecessary in your installer. Although I'm not sure how well it works now --- I plan to test it on clean Windows VMs. Some duplication on this part won't hurt. Anyway, please don't call this part "Install Visual C++", because "Visual C++" usually means the whole multigigabyte software including compiler, IDE, Windows SDK, and tons of other stuff. I believe this thing is called "VC++ Redistributable", or just VC redist for short.

In the current implementation noselfshadows is a hack, meaning that bad consequences happen at some moment. In order to implement a 'correct" noselfshadow rendering, it is necessary (while rendering every such object) to have all shadow volumes in stencil buffer except the volumes cast by the object itself. For an efficient implementation of such feature, it is necessary to not only add shadow volumes into stencil buffer, but also subtract them. On the other hand, isn't it possible? Render all shadows into stencil buffer first, then render all normal objects, then for each noselfshadows object: render its shadow volume in "subtract" mode, then render the object to frame, then render same shadow volume in "add" mode. This is not very efficient of course Anyway, I guess it is possible to add something like forceSelfShadows, but it will probably make things even more complicated.

From iddevnet: Could someone explain me why "noselfshadow" objects don't receive shadows from other entities? It does not follow from the name, and does not follow from description.

I have changed the line locally to: return handle.IsValid() && handle.frameNumber == ( currentFrame & VERTCACHE_FRAME_MASK );Both flickering and warnings are gone (at least most of them).

Perhaps you have too much hope for these changes. It has no new capabilities compared to TDM 2.06. Just it makes it somewhat easier to use. If you point me to some particular example, I'll try to see if it is possible. But if location entity is needed for ambient sounds, then probably it makes no sense to do anything,

Ok, committed the changes to code SVN. It gives players access to 113 presets I should not forget to update wiki for 2.07.

I have got to doing a small revamp of EFX definitions (4815) There is an important question. OpenAL supports having several different effects on single effect slot. Aside from EAXREVERB, there are also: REVERB (reduced version of eaxreverb), CHORUS, DISTORTION, ECHO, FLANGER, FREQUENCY_SHIFTER, VOCAL_MORPHER, PITCH_SHIFTER, RING_MODULATOR, AUTOWAH, COMPRESSOR, EQUALIZER. Speaking solely about room settings, does it make sense to support any other effects than EAXREVERB? After reading a bit on these effects, it seems that most of they make sense only for vocal/music studios. REVERB and ECHO are the only things interesting, but it seems that EAXREVERB covers them both. Pitch modulation is unlikely interesting (recall that it is configured room-wise), and EQUALIZER is probably not that important.

I see guards disappearing every time when a bunch of ambientCache miss warnings appear. This happens randomly, but with annoying regularity. Link to video. Flicker happens near the end of it.

Why do I have a feeling that creating infrastructure for multiple renderers will have about the same impact on the code and its stability as simply moving to GL3 renderer?...

This is hard to reproduce problem, and it is completely unrelated to cinematics (I mean everything named: roq, ffmpeg, video). While playing through the mission, I also noticed some white objects (issue 4869).

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% ?...