cabalistic

Hm, console works fine for me in windowed mode. But there is still at least one slight rendering issue I'm currently tracking down. Perhaps, under the right conditions, it might stop the console from rendering properly? Does the console react if you type a command blindly? If yes, it might be that rendering issue. If not, it sounds more like a logic issue and I'm not sure how these changes would have affected that.

I committed a partial fix for the crash on mission success. I moved where the final save is created so that it can now succeed. However, trying to quit the game afterwards freezes the game in an infinite loop. This is caused by some interactions not being properly cleaned up, or so the game claims. Will continue to investigate.

Okay, now I'm really confused. After looking at the code, any saving of the game happens in the frontend. How the hell is this even working at all with SMP enabled?! At the latest, my vertex cache changes should have broken it completely, at least the part that's trying to take a screenshot. And yet, somehow normal saves seem to work ok, even with screenshots, it's only the final save that crashes the game. I must be missing something... Edit: Never mind, regular saves appear to be scheduled via the command queue, which is executed before the frontend/backend split. I was confused by the calls to SaveGame in RunGameTic(), which is apparently dead code? Because it's only triggered by setting the cvar 'saveGameName', but that one's set to read-only...

Hm, underwater is expected for the reason I stated, underwater vision is doing stuff on the frontend it shouldn't. Over water artifacts I'm not sure, might be the same cause or something completely different. But I'll find out soon enough Thanks for letting me know.

Crap, I forgot about the water. I kinda expected this to need work. Also just debugged the mission end issue. It boils down to the mission end triggering a final savegame on the frontend thread, which in turn tries to take a screenshot, and that can no longer happen (if SMP is enabled) on the frontend because it no longer has a GL context. As i recall, the water is potentially a similar issue, with it trying to do stuff on the frontend that it shouldn't. Do either of you have a mission in mind where I can quickly get to some affected water? Both issues need a slight refactor to properly adhere to the frontend/backend split. All perfectly doable. I'll try to get it fixed asap, but it might not happen before the weekend, sorry.

It's done, I merged the changes. Also did a quick fix for the lightgem; it turns out that the lightgem was rendering to the window, not the FBO. That should have been fine, but for some reason it didn't quite work. I haven't figured out why, yet. Possibly a clear missing somewhere or something similarly trivial. But for now I switched lightgem to the (primary) FBO, and that works fine on my machine. A separate FBO could still be worthwhile, especially if MSAA is enabled, because we really don't need to render the lightgem with MSAA... New test executable: https://github.com/fholger/thedarkmod/releases/download/2.06_bfg_cache/TheDarkModx64.zip

The lightgem on this branch *does* work, even better than before, because it's integrated into the frontend/backend split. It's the fbo/MSAA part that's not working with it And yeah, I'll fix that.

Of course, that's why this was postponed after 2.06, anyway, and why I had testers give this a spin. I'll merge it to trunk later, then.

Now that 2.06 is basically done and in feature freeze, I would like to get this merged to svn trunk Any objections?

I'll have a look, but in general, if you mess with any settings influencing the fbo, you may need to restart the game. Changing them ad-hoc may or may not work, depending on the current state. That being said, I can confirm the ghosting issue in 'Closemouthed Shadows'. Weird Given that this is not going into 2.06, we should probably take this discussion to another thread, though. Edit: Found the error. Bloom post-processing really needs its own fbo. Then we can also get rid of r_fboSharedColor as an option. Will update when I'm done. Edit2: Fixed the post processing ghosting error: https://github.com/fholger/thedarkmod/releases/download/fbo_msaa_v2/TheDarkModx64.zip

Figured as much. I committed MSAA support to trunk. If anyone would like to test it, I built a test executable available here: https://github.com/fholger/thedarkmod/releases/download/fbo_msaa/TheDarkModx64.zip

I just implemented MSAA with fbos in my VR fork. It was pretty straightforward. Would you be interested if I tried to implement it over the weekend for 2.06, or is it already too late?

Btw, are the scenes where it stutters always the same, or is it (somewhat) random?

@tapewolf: That doubled framerate is what the multicore enhancement should actually deliver. That it tanks framerates in certain places is somewhat surprising and could have any number of reasons. OpenGL is a potential culprit, yes. I have additional improvements in the works (see http://forums.thedarkmod.com/topic/19257-testers-and-reviewers-wanted-bfg-style-vertex-cache/)which improve the way OpenGL is utilised in the multi-core setup. There is a chance that could fix your issues, and I would invite you to test those changes, but I don't have a Linux build ready, sorry

Sort of. Yes, the CPU and sync overhead for OpenGL draw calls is quite bad. TDM is even worse because it uses deprecated pipeline features. For my VR port I've ported the main parts of the renderer to a slightly more modern OpenGL4 approach, getting rid of the fixed function pipeline and the assembly shaders, and it does reduce the cost for draw calls. Not significantly, mind you, but the CPU overhead in the rendering backend is measurably reduced.

The flickering is most likely a synchronisation issue. I believe the problem is that in the way it's used if r_useMapBufferRange 1 is set, it will forego any synchronisation between CPU and GPU. This means that there is a chance that the frontend will update buffers which the GPU is still rendering, leading to the flickering. Obviously, not doing synchronisation "improves" performance, but it is not a valid fix. It took me a while to get it right in my BFG-style branch, and it involves triple-buffering.

Hm, shouldn't movement depend on the gametic rate, not on the fps? Because in that case, it shouldn't matter whether you run 60 fps or 300, as long as the gametic update rate is stable.

Great to hear the initial alpha is finding some use Just to manage expectations, though: due to current time constraints, it's unlikely that any new release will be ready before May, and that will still be a seated version. So please be patient with me

Haven't posted here in a while, because I haven't had much time, and progress has been slow as a consequence. But I'm still working on it and still working on getting performance to another level. So far, I have been copying the BFG style approach to stereo rendering by simply doing each eye frame individually, meaning that both back- and frontend basically have to carry double the load. And that causes problem in many places where the CPU load just is too high to do double the load at 90 fps. So instead I'm now aiming to do things smarter. The frontend will only assemble a single view from the head position, which is then rendered twice with slight offsets for each eye. That already saves the double load on the frontend and is already working, aside from a few minor quirks. But to truly profit from that, I also need to lower the CPU load on the backend side. To do that, I have been working on an all new OpenGL4 renderer, which is now in a state where it can render all basic elements of the game. It doesn't do any advanced stuff, yet (no soft shadows or advanced interactions etc.), and it won't until I think I might actually have some room in stereo rendering for it. But what it does, it does with less CPU overhead than the standard renderers, which is good and boosts the VR framerate in tight situations. Also, I can now make use of fancy new OpenGL features to basically render both eye views with a single pass, which will further reduce CPU overhead. So I'm cautiously optimistic that after I've done that, performance will be up at a level where I deem roomscale viable, even if it may not be perfect

Nothing significant. I cleaned up a few things in code, but apart from that the latest executable is still state-of-the-art Far as I can tell, it runs pretty stable now, so from my side it could be merged to SVN after 2.06 is released. Only thing I still need to check is underwater vision. I have a feeling it might be broken.

Well, VR and shadows can definitely work together:

Excellent. Thanks for testing

@nbohr1more: Found a few more instances where caches were potentially not renewed consistently. It seems to have fix one instance of flickering triangles I could previously observe in Rightful Property. Please test again: https://github.com/fholger/thedarkmod/releases/download/cache_v4/TheDarkMod_VertexCache_v4.zip As for those messages: they are probably fine and should recover in the next frame. So unless they are spammed consistently, I wouldn't pay them too much attention. I believe this is some border case when geometry is being loaded late or something like that.

@nbohr1more: Hm, might be a similar problem to the fog issue. I'll look through the code again @HMart: Thanks for testing. Great that it's now working and giving the performance boost that I hoped for

Alright, I think I found the fog light bug. @nbohr1more, perhaps this also solves your shadow triangles? If not, it might be a very similar problem, so just let me know and I'll look again New test build here: https://github.com/fholger/thedarkmod/releases/download/cache_v3/TheDarkMod_VertexCache_v3.zip @HMart: I switched the buffer handling again, let me know if you have any issues with it and how the performance is compared to beta build. @stgatilov: I don't fully understand interactions, either, but they do generate vertex and index data. Possibly the culled versions? In any case, disabling the static interactions did not make any noticable performance difference, so you might be right. But in theory, anything that doesn't have to constantly be regenerated would lessen the load on the CPU->GPU memory pipeline. As for the shadows, I really don't know. I basically just tried to port what BFG did, and it didn't quite work, so I left that part out. Perhaps it is indeed unneeded