stgatilov

We can try some more complicated ways to debug the problem, but they would need more patience from @Dracula. For simple checks, could you please set in your darkmod.cfg: r_glDebugContext 1 r_glDebugOutput 2 logFile 1 (in case you have not already) Then post contents of qconsole.log here. Please put large text files into spoiler environment (including your earlier post). That's the icon looking like eye in post editor.

I'm not sure what you are talking about. Rendering in browser lags behind desktop rendering in terms of features by several years. Until WebGL 2.0 came out, I estimated the difference to be about 10 years. Moreover, even if someone managed to build working TDM for browser, working with it would be a major pain for programmers (less/worse tools, more problems, everything is slow, etc). Just forget about browser, it is completely pointless.

Definitely not. It would be a massive time waste for a big step into the past.

I like the idea, but I'm afraid it is not possible to get the key from settings into the map right now. There is method idCommon::KeysFromBinding right now. I think it is possible to add a bit of code which would allow referencing the in a map. And I think there is already some way for a mapper to show text on screen.

The last time I checked the detection from OpenAL did not properly. So there is no way to do it. As soon as menu tooltips are implemented, it would be done easily. However, I have not yet seen any sort of demo of design proposal for them.

If you want to detect visual differences between two sets of cvars, the best thing would be to automatically switch them back and forth every second. Well, if the switching works reliable enough

I had some thoughts about graying it out when mode is not Windowed. Also about graying FPS cap out when uncapped FPS is off (suggested by @r.a.sattarov). It's just a matter of someone coming and doing it (as far as I understand, a pretty bug chunk of GUI code has to be added in order to make a setting gray out ) P.S. You can set r_fboResolution to 2 in console, it's just the GUI slider which does not support supersampling.

I think it stands so since 2.06. The ChangeDisplaySettings was disabled completely, so your OS resolution is never changed by TDM.

beta208-08 has been released. The list of changes is provided in its usual place. Remember that you must download tdm_mirrors.txt again from the link in the original post before running tdm_update. Hopefully, this would be the last one.

Nobody did. So far the problem does not reproduce when a developer wants, although many people have seen it at various times.

Quite hard to believe in "no effect". Try changing it in console as r_postprocess_gamma, and you will see the difference. Could you please test it on Saint Lucia FM? I have recently had to set very high gamma in Hidden Hands, but I think that's specific to that mission. The brightness and gamma do work differently from how they worked in 2.07, because now 1) what was called "postprocessing" is always enabled, and 2) gamma correction is applied before postprocessing, and not after it. You can use r_ambientMinLevel if you just want to see everything. Or you can go through r_postprocess_* cvars and set everything except gamma to its "don't do anything" value, which is usually either 0 or 1.

If you want an adventure, build TDM from sources, including all third-party libraries. Perhaps rebuilt OpenAL would work for you.

Committed all the changes to trunk: 8761-8764: new diagnostics for event overflow error. 8765-8766: new cvars: crash on error (allows saving crashdump), promote warnings to errors. 8767: fixed the main problem with flying AIs which caused event spam in Hidden Hands.

I have implemented some code to simplify diagnostics of events overflow without a pocket coder When number of alive events exceeds 2K (controlled by g_eventAliveSoftLimit), a warning is posted to console every 5 seconds. Along with this warning, 10 currently alive events (controlled by g_eventNumberPrintedOnLimit) are printed to console. Half of them are chosen randomly, the other half are the very last in the queue. When something bubbles the event queue, all of the printed events will most likely be related to the problem. For instance, here is what I see for Hidden Hands: WARNING:Soft limit of alive events exceeded (2048)! Some events printed below: Event idAI::_reEvaluateArea on elemental_l2 at T=10351854 Event idAI::_reEvaluateArea on elemental_l1 at T=10353214 Event idAI::_reEvaluateArea on elemental_l2 at T=10354606 Event idAI::_reEvaluateArea on elemental_l1 at T=10359374 Event idAI::_reEvaluateArea on elemental_l1 at T=10363582 Event idAI::_reEvaluateArea on elemental_l2 at T=10368174 Event idAI::_reEvaluateArea on elemental_l2 at T=10368190 Event idAI::_reEvaluateArea on elemental_l1 at T=10368190 Event idAI::_reEvaluateArea on elemental_l1 at T=10368206 Event idAI::_reEvaluateArea on elemental_l2 at T=10368206 Total: 2048/10240 events alive WARNING:Soft limit of alive events exceeded (2662)! Some events printed below: Event idAI::_reEvaluateArea on elemental_l2 at T=10353470 Event idAI::_reEvaluateArea on elemental_l1 at T=10354414 Event idAI::_reEvaluateArea on elemental_l1 at T=10363566 Event idAI::_reEvaluateArea on elemental_l2 at T=10363630 Event idAI::_reEvaluateArea on elemental_l1 at T=10367598 Event idAI::_reEvaluateArea on elemental_l1 at T=10373182 Event idAI::_reEvaluateArea on elemental_l1 at T=10373198 Event idAI::_reEvaluateArea on elemental_l2 at T=10373198 Event idAI::_reEvaluateArea on elemental_l2 at T=10373214 Event idAI::_reEvaluateArea on elemental_l1 at T=10373214 Total: 2662/10240 events alive ... Aside from that, the new command listEvents prints all the currently alive events to console. When number of events processed in single frame exceeds 5K (controller by g_eventPerFrameSoftLimit), warning is posted to console. In fact, two warnings are posted: the first when it hits the limit, and the second when processing ends (if it ends properly, of course). First 10 events (controlled by g_eventNumberPrintedOnLimit) after exceeding the limit are printed to console between the two warnings. Here is how it looks in Painter's Wife: WARNING:Soft limit of 5120 events per frame exceeded! Some events printed below: Event idThread::<immediateremove> on multistateposition::onMultiStateMoverArrive at T=20318312 Event idThread::<execute> on tdm_elevator::storeTrigger at T=20318312 Event idThread::<execute> on multistateposition::onMultiStateMoverLeave at T=20318312 Event CMultiStateMover::propagateSound on marlow_elevator at T=20318312 Event CFrobDoor::propagateSound on scissorgate_1 at T=20318312 Event idThread::<immediateremove> on multistateposition::onMultiStateMoverLeave at T=20318312 Event idThread::<immediateremove> on tdm_elevator::storeTrigger at T=20318312 Event idThread::<execute> on multistateposition::onMultiStateMoverArrive at T=20318312 Event CFrobDoor::propagateSound on scissorgate_1 at T=20318312 Event idThread::<immediateremove> on multistateposition::onMultiStateMoverArrive at T=20318312 This spam gets posted every frame when the limit is exceeded, without any speed limit. I think if someone manages to consistently process 5K+ events per frame, the game will slow down dramatically, and playing it won't be nice anyway. Interestingly, there are several moments when I see 1100 or 2700 events processed in one frame during game start. These events are usually something like calling postspawn function for most of the entities. If we see a problem with it in the future, I suggest increasing the limit x10 times during the very first frame after game start of game load. UPDATE: Created issue 5270 for improving events overflow diagnostics --- that's worth being tracked.

Speaking of the second case with an elevator in Painter's Wife, it looks like an error in the custom script. The script code for onMultiStateMoverLeave was: if (door.IsOpen()) { door.Close(); tdm_elevator elev; elev=mover; sys.waitFrame(); elev.stopMoving(); //mover.disable(); while(door.GetFractionalPosition()) { sys.waitFrame(); } //elev.lastTriggeredBy.trigger(elev); elev.activate(elev.lastTriggeredBy); So when you call and elevator, which is at some station with door open, it starts calling activate, which in turn calls onMultiStateMoverLeave again, creating an infinite loop.

Aside from fixing the actual problem, I think we should change something in the event system in general. Here is my proposal: Post a warning if 2K and 5K events are created (either in total or per frame). Mappers should know about the problem far earlier than it starts crashing. When soft limits named above are exceeded, print some information about a few events in the queue. It should make it easier to diagnose the problem without serious code diving.

The code for flying AIs has a hack to remember closed doors as closed to avoid bumping into them infinitely. It schedules an event for itself 120 seconds into the future to recheck the area in case it has become available. The problem is that this event is scheduled again and again every frame. So it manages to push 7200 events per one elemental. I guess the intent was to not do anything for an area if it is already "forbidden". I would simply make AddForbiddenArea return a bool (true if the area is new and was added), and avoid posting event unless it is true. Maybe @grayman would say something? Here is the relevant code:

I'm trying to reproduce using this data in Hidden Lands, did not succeed from the first try, but succeeded on the second. The culprit is idAI::_reEvaluateArea on two elementals: elemental_l1 and elemental_l2. They spam all the 10K events except for 60 normal events. These events are sorted by their time, which increases from 10313870 (current time) to 10431966 (two minutes in the future). All for same area 307. Investigating further.

I think it is possible, but it would require writing one more shader. So not for 2.08... No idea which rescaling is best though. Nbohr1more has complained that even with natural scale like r_fboResolution 0.5 the picture looks blurred, voting for "nearest" filtering So opinions differ here...

Here is another announcement, arguably more important than what would happen to 32-bit executable. Starting from version 2.09, TDM will not run on Intel HD 3000 and below. The reason is that TDM 2.09 will require OpenGL 3.3 to run. OpenGL 3.3 is the final version of GL 3, and both NVIDIA and AMD have updated their drivers to support it on every hardware which supports GL 3 (e.g. GeForce 8600 from 2006 is OK). Despite Intel HD 3000 being only 9 years old, Intel has already discontinued it (last driver update in 2015, no Win10 support), and did not upgrade the driver to version 3.3. Going with GL 3.3 will greatly simplify rendering code, and will finish the effort of removing deprecated stuff. There is no plan for further increases in required OpenGL version. OpenGL 3.3 will be enough to play TDM for a long time. More recent OpenGL features will be used via extensions, only in case your hardware supports them. Speaking of TDM 2.08, we tried to do our best to support HD 3000, leaving some hacks around. Despite that, we bumped into problems with running the game on the GPU when we accidentally found it. In case you are trying to play TDM 2.08 on Intel HD 3000, please set cvar: r_uniformTransforms 0

beta208-07 has been released. The list of changes is provided in its usual place. Remember that you must download tdm_mirrors.txt again from the link in the original post before running tdm_update. Please pay attention to AI behavior, in particular sitting and sleeping.

I think a separate thread would be better. Why would someone want more than 10K events per frame? The main question is: what are all these events, and why are there so many. The problem is that there is no limit that would be enough for everyone. Someone could always write a loop over all entities and exceed any preset limit.

Ok, I tried the material that you cited. It has the turbulent deform, that's the reason it is excluded. Something to think about. Maybe continue discussion elsewhere?

This is material for water overlay, but not for water surface. I.e. it is the material which is intended to be shown all over the screen when the player dives in. But not for the water surface itself. If you look into tdm_water.mtr, most of materials there have "water" keyword. The rare material which don't should be fixed, I think. The translucent keyword should not do any harm.

You have to add water keyword to the material of the surface which you want to block rain. All proper water materials should have this keyword, since without it player won't be able to dive into it. I know that one brush side is usually enough, but why not expect it on all water surfaces?