cabalistic
-
Posts
1579 -
Joined
-
Last visited
-
Days Won
47
Posts posted by cabalistic
-
-
Why not? I do. Last I tried, it worked fine in the menu. I couldn't load any actual missions for some reason which had nothing to do with the renderer. But if the menu works, there's no fundamental reason why it wouldn't work ingame.
-
No, the equivalent is just qglXMakeCurrent. It's used in e.g. GLimp_DeactivateContext() or GLimp_ActivateFrontendContext().
-
2
-
-
Sorry guys, I was away for a few days...
@woah: If by a while ago you mean months ago, then I may have written an answer to that post where I suggested Freespace, Jedi Knight and perhaps even The Dark Mod (not sure about that). But I was not the OP
@BuckleBean: As you said, it's publically available. I did not post about it outside of this forum due to its vastly incomplete nature, and I feel it might disappoint a lot of people in its current state. My goal is to have it close to the Doom3 VR mods, but it's a looong way off. Even so, as long as you emphasize its current state, I don't mind you mentioning it
@duzenko: I really don't think adding the code to the trunk is a good idea. VR support goes very deep into the engine core; to keep it completely optional would require a lot of code switches in a lot of places. That, in turn, will increase the code complexity and has a high risk of creating diversions between VR and non-VR engine code. Right now, when it's only just the bare-bones stereo rendering and head-tracking, this might just barely be feasible. But if I finally get around to roomscale additions, the changes will become more significant. To be honest, I would personally much rather keep this in a separate repository and pull changes from the SVN when needed. At the very least, this would require a very thorough discussion and analysis by the team before incorporating it into the trunk.
-
2
-
-
@grodenglaive: Thanks. Yeah, mouse movement, GUI elements and the shadow issue are my priority when I continue working on the VR version. However, that probably won't happen before the release of v2.06 anymore. There are just too many changes to the engine to continue working on the 2.05 version.
How was performance?
-
1
-
-
Typically by splitting it into six shadow maps (or a cube map) for each room direction.
-
Actually, never mind, I was just too impatient. I pushed my changes to stop and recreate the frontend thread, it's working for me now. Try it out.
-
2
-
-
@duzenko: Looked at vid_restart, but I'm a bit baffled. For me it works fine in the main menu, but freezes ingame, no matter if com_smp is enabled or not. There is a definite problem with the frontend thread, because the thread is not shut down properly, but the vid_restart function does delete and recreate both GL contexts. I added calls to shutdown and then restart the frontend thread in vid_restart, but it still freezes. Debugger says it freezes in a glGenerateMipmap call during recreation of images.
At this point, I'm not sure if there isn't another issue with the video restart.
-
1
-
-
Then again, the glMapBufferRange is going to be significantly better once we begin to multithread the frontend further. That's where the current approach would need additional GL contexts and cost additional synchronisation overhead. In contrast, the mapped buffer approach can do that almost free of overhead.
I'll look into the vid_restart behaviour. It's probably just not implemented.
-
1
-
-
Not really, but it's a part of the bigger process of updating the engine.
We should end with the BFG engine in the end, and this is one of the many steps.
Ok, but then it's just going to cause merge conflicts with my deeper modifications
(Nothing git can't handle, though, so doesn't matter.)
-
Hm, sounds more like an issue with the VM and potentially with the GL implementation inside that VM. I'm not sure that is a good testbed...
The SMP functionality itself works for me in a native Linux environment. It's other stuff that doesn't
@duzenko: Ok, but did you see any benefits?
-
Given that the Dark Mod engine is currently strongly CPU-bound, switching to shadow mapping would help offload work to the GPU. However, it's also a significant undertaking... Although it depends how easily the RBDOOM implementation could be adopted.
Ah well, I think GPU skinning is more important right now.
-
2
-
-
Interesting, I was under the impression that it is rather problematic to get soft shadows with stencil shadows. But I don't really know enough about stencil shadows
@stgatilov: I implemented the secondary context for Linux. However, it's segfaulting for me in the asm code in Sys_GetClockTicks. If I comment that out, main menu is working fine, but loading a mission fails.
-
1
-
-
Hm, and these are still based on stencil shadows? What's the performance like?
-
So we could get soft shadows and tesselation and parallax occlusion mapping that make our wall corners look like they are made from seperate hand-modelled bricks?
I was thinking more along the lines of performance-related features, e.g. GPU skinning, simplified interaction handling, multi-threading the frontend, ...
Does vanilla BFG even have soft shadows? That would surprise me, seeing as it still uses stencil shadows. I think you might be thinking about the RBDOOM improvements, which feature (soft) shadow mapping. But that is another can of worms entirely
@stgatilov: I'll see what I can do.
-
1
-
-
What kind of flickering? Where?
-
1
-
-
Anything that isn't static is recreated, including vertex and index caches. Not static is anything that wasn't created at level load. I ported some stuff from BFG which statically initialises some of the interactions and some of the model data. (And I think that's the part that doesn't work quite right when loading a save game, so after save game loading the level appears basically unlit.) There might be potential to make more things static or even get rid of them entirely.
-
1
-
-
Yeah, GPU skinning is high on my list now. I think that's one of the areas that should really help both frontend and backend.
-
2
-
-
BFG introduced an abstraction over the buffers called BufferObject, which are used by the VertexCache. You can find the glMapBufferRange etc. calls there: https://github.com/fholger/thedarkmod/blob/vertexcache/renderer/BufferObject.cpp (see e.g. implementation of MapBuffer).
Pat Raynor's variant is only a relatively simple change that changed the existing temp allocations to a MapBuffer approach without changing the general structure of the VertexCache. I actually ported the whole BFG VertexCache concept.
Again, on its own that probably isn't really worth the effort, but I expect it to make porting additional stuff easier.
-
3
-
-
Did you look at the vertexcache branch?
-
1
-
-
- Popular Post
- Popular Post
So, this weekend I went ahead and ported the BFG-style VertexCache in full. This means that, instead of two frame temporary buffers and lots of individual vbos, there are now two larger frame temporary buffers and a single static buffer. The static buffer is filled during level load with static interactions and static model data. Everything else is now allocated on the temporary buffers and thus only valid for a single frame.
This means that the frontend no longer needs to make GL calls, which also means that it no longer needs the shared context and does not have to sync its GL calls. On the other hand, it also means that it currently probably recreates some vertex caches a lot more often than previously, since they are only valid for a single frame.
In practice, the performance appears to be largely unchanged in a Release build. There might be an ever-so-tiny advantage in certain areas, but it's really hard to tell. In debug, performance is significantly worse in some places, probably due to the increased memcpy operations.
The whole thing is highly experimental, so I pushed it to a separate git repository for now. You can find it here: https://github.com/fholger/thedarkmod (you need to checkout the branch vertexcache). I think I broke the lightgem rendering, and it may also have somewhat broken loading of savegames. Still, I expected a lot more problems, so that's not too bad
Given that the change does not really bring any worthwhile performance improvements, I'd rather not integrate it into the SVN repository in its current form. However, the potential promise of the change is that it should make porting additional BFG features a little easier, and also it should allow to further multithread the frontend renderer. I don't know how much the latter would help, though, because in the bottleneck scenes I'm currently investigating, the backend takes about as much time as the frontend. So at the moment I'll try to find ways to improve the backend performance, first.
-
6
-
I enjoyed playing it. Gameplay-wise I think it's really good and an improvement over Human Revolution. Sadly, the story ends rather abruptly at a point that felt (to me) like a mid rather than an end, which makes the whole game feel a bit short. Which isn't really true, because according to my Steam statistics, I still spent about 25 hrs to beat it.
-
I know nothing about assembly, but have dabbled with SSE before. Wouldn't consider me an expert by any means, though
-
1
-
-
Update in parallel - no. Update in one thread, read in another - maybe? I don't think it's likely, since I'd expect this should be limited to gametics and frontend drawing, but I'd have to check to be sure.
Though I see that you reproduced the bug with threading disabled...
-
2
-
-
Not sure when I can test that, maybe not for a few weeks.
But think about this: at the time of lightgem's CaptureRenderToBuffer where is the lightgem draw command - in the frame that the backend has just completed rendering or in the frame that the frontend has prepared for the next backend run?
In the one the backend was just using before, but already reset. So what I said before is actually very unlikely. I'm out of ideas for the moment. Need to know if this is related to SMP at all or not.
-
1
-
Missing GL implementation for Linux
in TDM Tech Support
Posted
I used the NIVIDIA proprietary drivers, and enabling or disabling GLSL made no difference. Again, I'm not sure the problem was related to the renderer at all. But I don't really use Linux outside of work anymore, so I didn't have the chance to investigate further...