duzenko

A harder question. How thread safe is the collision manager? Putting physics in a separate thread looks so beautiful and exciting in theory but my uneducated attempts to QueueUserWorkItem anything related to collision manager from the gametick code crashed and burned with null ptr AV. Ideally, SMP might easily double fps in the cavern, unless throttling kicks in. It's funny, really, how killmonsters doubles the fps here. We should absolutely put it in the Performance Tweaks wiki [trollface.png].

So we have been using the NHAT cavern for general benchmarking. Performance issues are obvious - I get 20 fps or less looking at the three spiders (notarget on). And I have a problem with it - the problem is that the bottleneck here is not the graphics rendering. I think I narrowed it down to physics simulation. The map author appears to have assigned the smaller white spiders to be "chewing" on the corpses. When you kill/gas the spiders or simply notarget off so that they move towards you then fps skyrockets. My research shows that CPU is sweating in the debris of Collision Model Manager. Quick questions: 1. How 'normal' is this? Do we need to do something about this issue? If it's exploitation of game mechanics to shock player with cannibal spiders then we probably should not use this scene for benchmarking. 2. Do we first kill spiders and benchmark then? I would not guess this unless I knew the spiders are the problem. 3. Do we need to blend animation frames each game tick for physics simulation? In my case, I have 20 graphics frames per second and 60 game ticks. If animation is 24 fps (judging by md5anim files) then would it not be enough to simply use the current frame? I understand that we want as much precision as possible for physics simulation but not at the expense of visual slideshow? Maybe introduce a new option - high precision vs low precision sims or something like that. Maybe automatically switch based on current fps. Again, these scene is CPU limited and I have a 2.7 GHz Core i5. We should aim to achieve at least 30 fps on modern midrange CPUs, shouldn't we?

1. I used to use Fraps but it might not work for you 2. (Wild guess) It might hook some OpenGL functions like glReadPixels that DM uses for lightgem and draw over it. Can you try my custom build from here and see if it helps.

It's around 10fps for me - glad I did that mission back when I had a real video card, not this energy efficient joke On the other hand, it gives some stimuli for optimization

Now there is one last step to do and we're done with it for a while. I have prepared a patch to use a Pixel Pack Buffer, OpenGL 2.1 style. It reduces the performance impact even further, better utilizes both CPU and GPU. Framerates with and without lightgem should be roughly the same in low-fps situations. It requires an OpenGL 2.1 class hardware, which is 2007 or later. Diff Patch Screenshots (Intel HD5500) Binaries download link for testing (make sure you have the new materials file from post#44)

Try another recording program?

If the video ram is ddr3 then I would not expect 60 fps in 1080p

Disable shadows? Reduce screen resolution? What does com_speeds show? How much is GPU utilized, in %? This particular scene on the deck of the ship could use r_skipfoglights, r_skiptranslucent

Thanks for the download link. My problem was I did not have the new material file. Now the lightgem works for me as well.

I tried last build and in the beginning of thief's den lightgem does not appear to work. It reacts on crouch but that's it. It was working a couple of weeks ago but it was a different mission. Last svn rev with lightgem working was 6626, and 6627 broke it. BTW it's interesting that you mentioned shadows - after much struggle with my laptop I turned them off and now it's more or less playable in 720p. I never liked them anyway but it's harder to find a place to hide without them BTW2: I got this stupid idea about doing SwapBuffers before rendering. I suspect all the other opengl calls only make driver to cache the commands and actual gpu work is triggered by swapbuffers. If we could somehow tell the driver to start rendering and without waiting for this frame start calculation for the next one? So like this: Now: - engine renderer frontend does culling and prepares commands for backend (a lot of cpu, gpu idle) - backend converts them to opengl commands (a lot of cpu due to the opengl overhead, some gpu to copy data etc) - backend calls swapbuffers and all hell breaks loose. Gpu does all the delayed rendering, driver is waiting for gpu to finish and only then presents the new frame In my dreams: - frontend does the culling for the new frame - backend calls swapbuffers (somehow gpu has completed some or all of its work) - backend converts new frame data to opengl calls - backend somehow magically tells the driver to start actual rendering but not wait for it - glFlush??? Am I completely detached from this world or is it somehow possible?

Exciting!

No, I'm pretty sure that the slow part in lightgem is this gameRenderWorld->RenderScene(&m_Lightgem_rv); Because it takes a lot of cpu time to go through the entire scene and do all the usual rendering calculation. It's not just my guess, this is what tests say. Actual "backend" rendering is not "blazing fast" too but it definitely is only a fraction of time because virtually all geometry is culled by frontend. As for multithreading it's Carmack's own words that eventually he ended up with backend rendering on main thread and software preprocessing (frontend) in background as opposed to his failed attempts in D3 to call OpenGL api in background. My own limited experience is the same - at least on Windows it only makes sense to have opengl calls and user input in main thread while everything else can safely go to threads. In our case it means that potentially we could move renderer frontend (gameRenderWorld->RenderScene) to a thread but still need the backend (R_IssueRenderCommands) remain on main thread. With all that said, for me personally the multithreading way, while probably most exciting from a programmer point of view, is least promising in term of end result. My own problem is low fps on a ULV processor, so simply rearranging the load in parallel will result in more throttling, lower cpu clock speed and same fps. My problem can be solved by doing less work, so again I urge the game programmers to find a way to not do rendering preprocessing separately for main render and lightgem. And on "normal" computers the framerate will be still limited to 60fps due to the engine internal cap.

My research shows that the actual analysis of the lightgem screenshot is fast enough on cpu so no use spending effort on that. I understand that camera projection is different for lightgem rendering but I suspect that actual geometry being rendered is largely the same, because camera position is very close. And I'm almost sure that lights culling result is the same. If we can't reuse main renderer data for lightgem then another workaround could be doing lightgem in a thread on a separate rendering context - if only d3 engine supported that. What about the subviews feature? The engine appears to have some support of mirrors and cameras so that can be utilised, right?

What I can gather from tdm sources is that lightgem render does essentially same work done by main renderer That is, visible geometry and lights are calculated twice each frame If we could reuse results of main rendering work for lightgem it should help a ton

This must have been discussed before but here it is I am playing on a skylake core m5 There is a huge difference in fps between software and rendered lightgem calculation I am talking 30 and 20 fps I know about the split frame trick but it is not working well for me The main issue that I see here is low gpu utilization Software lightgem - 30 fps - 90+% gpu usage Rendered lightgem - 20 fps - ~60% gpu usage I can't help but conclude that during the lightgem rendering phase most of the time nothing is actually being rendered Can someone revise the code for hardware calculation and see if it can be improved? Or at least additional configuration options added? Regret software lightgem is practically unusable or else I would not be returning to this now

great (although short) mission thanks!

Funny little mission, thanks

Great missions Thanks!

Great mission, thanks!

This mission turned out too hard for me - could not complete even one objective Maybe because I hadn't played for a while

Nice story - I especially liked the Anderson\Elisabeth thing Thanks for this little pretty mission

Yep, that's why I used the F letter in "T2 FMs"

Hi, demagogue! Thanks for the great mission! I played with the highest difficulty, just for more fun, and it appeared too hard - I had to check this thread several times to find out what to do next. I had the "too large save" problem, leading the game to crash during quick load, but I resolved it by loading an earlier save. Someone mentioned AI as possible cause, and I probably agree - it is something intermittent and connected to dynamic processing and needs to be saved/loaded, so AI fits best. Warehouse rules, I felt like in a horror movie. The murderer did not see me though, as I am used to move along the walls, where it is darker. The whole story was great, but maybe you should've allowed more freedom to the player to go through pieces in differnt orders, except the warehouse, of course. If I was responsible for T4, I would hire you and some other folks, who made great FMs! Looking forwad for more missions, maybe some remakes of T2 FMs. P.S. I have played a few missions, but only in this one I had to learn that I am able to shoulder bodies!

Where do I find ?