duzenko

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 ?